コンピュータプログラムを使用して、トラップドアのテストを自動化できますか？
別のプログラムのソースまたはオブジェクトバージョンが指定されたコンピュータープログラムを使用して、トラップドア/バックドアのテストを自動化できますか？
要件によって異なります。
十分に複雑で適切に設計されたシステムを使用して、最も単純なバックドアまたはトラップドアをmostプログラミング言語。ただし、言語が Turing complete の場合、単一の式または関数を無限の方法で表現できるため、そのような分析は halting problem と同等になります。
これの簡単な例は、aとbを一緒に追加してcを生成することです。
c = a + b
c = (-a) - (-b)
c = (a - 1) + (b + 1)
c = ((a * 2) + (b * 2)) / 2
これらはすべて等しく、同じ計算を実行する他の方法は無数にあります。これは、（ほとんど）同じことを行うために使用できるさまざまな命令がある場合、さらに複雑になります。
実行可能ファイルの静的分析に焦点を当てた最新の脆弱性分析は、コンパイラのアーティファクト、つまり潜在的に脆弱なコードフラグメントの署名ベースのマッチングを可能にする個々のコンパイラの奇妙さと特異性を識別することによって機能します。ただし、自動化されたツールは多数の誤検知を吐き出すため、熟練した担当者は結果をふるいにかける必要があります。
バックドアは定義されたアーティファクトではないため、バックドアはさまざまな形式（バックドアアカウント、リバースシェル、隠しファイルなど）で存在する可能性があるため、このような問題を特定することはさらに困難です。バックドアが意図的なバッファの誤用のようなもので、簡単にバッファオーバーフローを悪用できる場合は、そのような問題を検出できる可能性があります。ファイルアクセス制御を無効にするために使用される特定の秘密コマンドのように、それがより複雑なものである場合、それはほとんど不可能です。
理論的にできることは、特定のアプリケーションに対して、その正確な機能の正式な定義を提供し、次に正式な証明（コンピュータで検証可能）を提供することです）アプリケーションが実際にその定義を満たしていること。これはできませんすべての一般的な方法で既存のプログラムで平手打ちをかけます（ Halting Problem を参照してください：機能が「完全に停止した」場合でも"、それはすべてのプログラムに対して真または偽であると証明することはできません）。ただし、これはプログラマーまたは彼のコンパイラーの助けを借りて行うことができます。
非常に削減されたバージョンが存在します。 Java仮想マシンのバイトコード。この機能には、「バッファの外側に書き込みを行わない、オブジェクトに存在しないメソッドを呼び出さない」（もちろん、かなり単純化されています）があります。 JVMはコードをロードし、この機能が尊重されることを「証明」します。これは、概念的に単純なフロー分析で機能し、Javaコンパイラフロー分析が機能するコードを生成するように注意を払いました（最近のバージョンでは、コンパイラーは、JVMが再計算するのではなくチェックするだけのヒントも含んでいます）。
理想的には、よりユーザーレベルのセマンティクスを取り込む正式な仕様が必要です。これにより、3つの問題が発生します。
悪意のあるコードと悪意のないコードを区別することは困難です。ファイルの削除は悪意のある行為ですか？はい、ただしそれがユーザーの望みの場合を除きます。ユーザーの気まぐれを正式な仕様に変換することは、非常に困難な作業のように見えます。
仕様は、自動検証が可能な数学的構造に従う必要があります。停止問題が近くに迫っています。
プログラマーは、仕様を効率よく証明可能なコードに効率的に変換できる必要があります。
3つすべてを実行できる場合は、悪意のない可能性のあるアプリケーションを作成できます。副作用として、アプリケーションにバグがないことも証明します。これだけでは簡単ではないことを示しています。
一部の人々 はそれに取り組んでいます。ただし、息を止めないでください。
いいえ。コード内の悪意のあるバックドアを自動的に検出することは、最新技術を超えています。
もちろん、特定の既知のバックドアを探すコードスキャンツールを作成できます。しかし、問題は、攻撃者がバックドアを導入する方法が多すぎることであり、そのようなパターンをすべて特定することは現実的ではありません。実際、少し考えれば、バックドアがないことを確認することは、コードの正確さを確認することと同じくらい難しいことがすぐにわかります。今日構築するほとんどのソフトウェアシステム。
悪意のあるバックドアを自動的に見つけることは、停止問題の軽減に基づいて困難であると信じる深い理由があります。ただし、実際的な障壁はさらに深刻です。その結果、現時点では、プログラムを自動的にスキャンして、悪意のあるバックドアが含まれているかどうかを判断するための適切で信頼できる方法はありません。
したがって、今日の標準的なアプローチは、プログラムを作成した人々に対するあなたの信頼に依存することです。信頼できる誰かがあなたを攻撃しないプログラム（たとえば、Microsoft、Apple、信頼できると仮定している）のプログラムである場合は、プログラムを実行して、プログラムのソースへの信頼を信頼することができます。このアプローチは、あなたが関係を持っているブランドや個人に依存することにつながります。または、プログラムのソースを信頼しない場合は、プログラムを実行してリスクを冒すか、プログラムの実行を制限するサンドボックスで実行するかを選択できます。後者は、WebブラウザがJavaScriptの実行を提供するなど、サンドボックス化された実行プラットフォームにつながります（一般に、JavaScriptを送信したWebサイトを信頼する理由はないため、安全な唯一のオプションは、Javascriptをサンドボックスで実行することです。悪意のあるバックドアが引き起こす可能性のある危害が制限されるように）。これらのアプローチには独自の制限がありますが、最先端の技術を考えると、これらのアプローチは現在最も現実的な防御手段です。
TL; DR：はい。ただし、_computer program_、_source or object version_、automate、testing、backdoorsの意味によって異なります。
上記の用語のいくつかに特定の定義を提案することから始めます。これは、以前の回答が異なる意味を参照していたためと、議論を理解しやすくするためです。
- コンピュータプログラム：完全にベンダーにとらわれないままにするために、ルールをプログラムして、ターゲットコードに適用されます。これは特定の形式で機能する必要があります。以下を参照してください。しかし、そのような製品が存在すると仮定しましょう。
- ソースまたはオブジェクトのバージョン：ここでソースコードの分析について説明します。理論的には、バイナリオブジェクトフォーマットをソースコードに逆コンパイルして、そこから続行することが可能です。しかし、私はこの部分をテストしたことがなく、これをきれいに行う製品についてはよく知りません。したがって、ソースコードはこの回答の要件です。
- Automated：このようなプログラムでは、手動による介入なしに、数千行から数百万行のコードを自動的にスキャンすることを期待していますが、これは必須ではありません箱から出してすぐに100％自動化されました。また、プログラムがすべてのターゲットプログラムに対して一般的な答えを持っているとは思いません。むしろ、フルスキャンを実行する前に、手動での構成、調整、スクリプト作成を許可します。
- テスト：ここでの目的は、既存のバックドアを見つけることです。必ずしも100％である必要はなく、数学的に他のものがないことを証明するのではなく、できるだけ多くを見つけることです可能性が高く、高い信頼性が得られます。 XSSスキャナーがmostのような欠陥を見つけようとするのと同じですが、数学的な保証はありません。さらに、信頼度は脅威モデルに直接相関しています。バックドアの各クラスを脅威として扱い、それらをスキャンできます（実装に関係なく）。あなたがそれをモデル化していない場合-それは見つかりません。
- Backdoor：From OWASP's definition ：_
Malicious code inserted into a program for the purposes of providing the author covert access to... the program._
具体的には、トロイの木馬やBackOrificeなどの他のマルウェアなど、「バックドアソフトウェア」のいかなる形式も含めません。非表示のOSユーザーなど、システムレベルのバックドアは含めません。 Ken ThompsonのクラシックなUnixコンパイラルートキットなど、フレームワークレベルまたはコンパイラベースのものが含まれていません。また、Debianの欠陥などの暗号トラップドアは含めません。私はコードレベルのバックドアについてのみ話しています（そうでなければ、それらのコードをスキャンすることは無関係です）。
私は非常に具体的に、一般的なセキュリティの脆弱性を含めていません。 @ D.W。 コメント ：backdoors (deliberately introduced by a developer)とvulnerabilities (inadvertently introduced by developers)に入れます。あるいはもっと単純です：_Unauthorized functionality_。
説明のために、信頼できないクライアントアプリについても言及しません。大規模なエンタープライズサーバーシステムの場合のみを説明する方が簡単です。脅威は、システムの多くの開発者の1人が不要な機能を挿入し、「秘密のアクセス」を許可することです。ただし、これは後でクライアントやサードパーティのアプリに簡単に転送することもできます。
続行する前に、この「バックドア」の定義によれば、_testing for backdoors_は追加の定義がなければほとんど意味がないことに注意することが重要です。 （これは、「すべてのバグをテストする」と言うのと同じです。どのような形式のバグが見つかるかを調べる必要があります。または、PHBがディルバートに言ったように、_I need to know all the unexpected things that can go wrong._）今、私たちは単にバックドアを明示的に説明する必要があります。そうすれば、それを見つけることができます。ただし、バックドアには特定の数のクラスがあり、バックドアの定義済みのクラスをスキャンできます（もちろん、実装の数は無限にあります）。
たとえば、（誤）機能によって分類されたバックドアのいくつかのクラスを次に示します。
- 認証バイパス（特別なユーザー/「マジックナンバー」またはパラメーター/隠しURLを介して）
- 許可バイパス（特別なユーザー/非表示パラメーターを介して）
- バックエンドリークによるデータアクセス（つまり、保護されたデータベースの外部にデータを送信する（クレジットカード番号を電子メールで送信するなど））。
もちろん他にもありますが、無限ではありません。 （誤）機能が設計できれば分析できますが、とりあえずこれらから始めましょう。
ここで、検索したいfunctionality（実装とは無関係）を定義したら、そのような（誤った）機能を見つけるために、考えられるプログラムとルールセットがどのように見えるかを説明しましょう。
明らかに、特定の機能を実装する方法は無数にあるため、特定のパターンとシグネチャのコードをスキャンしても、そのようなスキャナーは機能しません。
むしろ、スキャナーがこれを成功させるには、データフロー（入力、変数、パラメーター、出力などの間）と制御フロー（たとえば、分岐するタイミングに影響するもの、呼び出す他の関数、ループの仕方など）、およびそれらの間の相関（たとえば、入力に基づく計算の結果に応じた分岐）。
さらに、スキャンする各ターゲットプログラムに合わせて、アプリケーションの特定のグローバルで明確に定義された要素を見つける方法を定義できなければなりません。たとえば、認証チェックを表すオブジェクトまたはメソッドは何ですか？これは、オブジェクト/メソッド名のように単純な場合もあれば、ヒューリスティックスまで複雑な場合もあります。しかし今のところ、認証メカニズムの名前を指定できるとしましょう。アプリケーションがデータベースにアクセスする方法も同じです（設計された正当な方法で）。
ここで、独自のルールセットをスクリプト化できれば、ユーザー入力から得られたユーザー名とデータベースからの値の有効な比較と有効な比較なしで、認証メカニズムを渡すことに成功したフローを見つけることができます。ユーザー入力から取得したパスワードとデータベースからの値の間。
言い換えると、私たちが探しているのは、次の条件に一致するフローです：_( (pass-authentication) && !( (input.username == database.username) && (input.password == database.password) ) )_（非常に哀れな疑似コードで...）データベースからプルされ、アプリケーションコードにチェックインされました...
（以前と同じように解決できるパスワードの暗号化についても調整する必要があります。ここで、パスワードが暗号化されていることを確認します。それ以外の場合は脆弱性をスローします...）
基本的に、有効なユーザー名とパスワードを送信せずに「認証」が可能なすべてのケースを見つけました。問題が解決しました。
同様に、認証バイパスについても同じことができます。認証メカニズムを宣言してから、これがユーザー名またはID（実際にはユーザー名の影響も受ける...）によって覆されたりバイパスされたりする場所を見つけます。また、アクセスチェックがない場所を見つける必要がありますが、デリケートな/不審なアクションが実行されます。
バックエンドデータの盗用：機密データを定義します（例：パスワード、クレジットカード番号など）。 find anyデータベース以外の外部ターゲット（メール、ネットワークアクセス、ファイルなど）にデータが流れる場所。アプリケーションに応じて、これを微調整する必要があるかもしれないことに注意してください-おそらくすべてをメインフレームにコピーするMQサーバーがあります...しかし、データベースを除外したのと同じように、それらも単に除外できます。また、これらの建築家に知られている必要がありますにも注意してください。
したがって、そのようなスキャンプラットフォームが存在し、ルールセットをスクリプト化する努力を考えると、不正な機能（問題の私の定義）を絶対に見つけることができます。
脚注：
しかし、あなたは今、反対意見を上げるかもしれません：「まあ、確かですが、あなたは可能なバックドアの小さなサブセットしか定義しませんでした」。
実際には、これは厳密な意味で当てはまるかもしれませんが、少なくとも以前の定義によれば、実際的な方法ではありません。
非常に高いレベルでは、プログラムへのアクセスを達成するための非常に限られた方法があります-私はそれらすべてに言及しなかったが、リストは長くはありません。 any非表示の機能ではなく、コードレベルでaccessを提供する機能のみを探していることに注意してください。
さらに、アプリケーションの脅威モデル/リスクプロファイルに従って、他の形式のバックドアが関連すると見なされた場合は、that形式を同様に分析およびスクリプト化できます。
たとえば、暗号化された命令のブロックを含むコードがプログラマーによって埋め込まれていないことを確認したい場合、そのキーはさまざまなシステムパラメーターから派生しており、実際のバックドアは非表示になっています。コードがブロックを復号化する場所に配置し、これを動的に実行します。確かに、それは可能性誤検知が発生する可能性があります-おそらくこれを実際に行うために奇妙でユニークな機能要件がある場合（実際に？）-しかし、これらを調整してスキャンすることができます暗号化前の元のコード。
つまり、ボトムライン-バックドアの特定のクラスのソースコードをスキャンすることは可能ですか？
はい。問題のある部分は、関連するバックドアのクラスを定義することです。
これは通常、100％の保証と数学的な証明を提供しますか？
番号。次に、同じことが他の種類の脆弱性スキャナー（XSSのソースコードのスキャンなど）にも当てはまりますが、労力の量に応じて、漸増的および異種同型的に100％に近づけることができます十分。
ブラックボックス（オープンソースではない）ソフトウェアを調べ、それをブラックボックスとしてのみ扱う場合、つまり入力データを提供して出力を分析する場合、十分にインテリジェントに埋め込まれたバックドアが検出される可能性がほとんどないことは直感的に明らかです。 。たとえば、ソフトウェアには「時限爆弾」が含まれている可能性があります。つまり、特定の特定の時期が来たときに特定の動作を行いますが、それ以外の場合は期待どおりに正常に動作します。数十年前、私はそのような時限爆弾を偶然知りました。会社のコンピューター（メインフレーム）は、ほぼ毎日、夜間にクラッシュし、システムスペシャリストである従業員が再びシステムを立ち上げるために一生懸命に努力しなければなりませんでした。 。しばらくして、経営陣はこの男の会社にとっての重要性に気づき、彼をコンピューティングセンターの責任者に昇進させました。その後、通常の夜のクラッシュは「不思議なことに」消えました。
コンパイル済みのバイナリで動作する市販のアナライザー（VeracodeやFortifyなど）があります。
もちろん、停止の問題があるため、何も見つからない場合でも、落とし戸がないという意味ではありません。