IDNスプーフィングから保護するために、Microsoft DNSサーバー用のプラグインを作成しています

IDNスプーフィングは、選択されたドメイン名と「類似」するドメイン名の生成であり、通常、ユーザーに攻撃者のリソースへのリンクを強制的に追跡させるために使用されます。 次に、より具体的な攻撃オプションを検討します。



攻撃された会社がorganization.orgドメインを所有しており、portal.organization.org内部リソースがこの会社内で使用されていると想像してください。 攻撃者の目標は、ユーザーの資格情報を取得することであり、そのために、会社で使用されている電子メールまたはメッセンジャーを介してリンクを送信します。







このようなメッセージを高い確率で受信したため、リンクがどこか間違った場所につながることに気付かない場合があります。 リンクをクリックすると、ユーザー名とパスワードが要求され、被害者は自分が内部リソースにいると考えて、アカウント情報を入力します。 特に従業員のシステムを侵害し、システム管理者の特権を求めて戦っている場合、攻撃者が既に境界に侵入している場合、攻撃者の可能性は特に高くなります。



絶対的な「愚か者に対する防御」を考え出すことは不可能ですが、DNSリクエストを介して名前を解決する段階で、この攻撃を阻止しようとすることができます。



保護のために、インターセプトされたDNS要求で検出された名前を順番に記憶する必要があります。 会社は社内リソースを使用しているため、portal.organization.orgへのリクエストですぐに確認できます。 以前に出会った名前と「似た」名前に出会うとすぐに、攻撃者のIPアドレスの代わりにエラーを返すことでdns応答を置き換えることができます。

「類似性」を決定するためのアルゴリズムは何ですか？

• UTS39 Confusable Detection（http://www.unicode.org/reports/tr39/#Confusable_Detection）Unicodeは、 貴重なファーシンボルテーブルであるだけでなく、多くの標準と推奨事項でもあります。 UTS39は、ユニコード文字列を正規化するアルゴリズムを定義します。このアルゴリズムでは、ホモグリフが異なる文字列（たとえば、ロシア語の「a」とラテン語の「a」）が同じ形式に変換されます
• 内部文字の順列によって特徴付けられる単語。 organization.orgとorgainzation.orgを混同しやすい
• 第1レベルドメインの置換。 通常、名前の最初のレベルは意味をなさないため、「組織」を見た後の会社の従業員は、例外がありますが、.orgまたは.netの違いを無視できます。

ほとんどの場合、企業サーバーはバインドされません。これはWebホストまたはプロバイダーの標準ですが、Active Directoryが広く使用されているため、Microsoft DNSサーバーです。 そして、Microsoft DNSサーバーにフィルターを書き込むときに最初に遭遇した問題-DNS要求をフィルター処理するためのAPIが見つかりませんでした。 この問題はさまざまな方法で解決できます。ソケット作業APIでdllインジェクションとIATフックを選択しました。



方法論を理解するには、PE形式の知識が必要になります。詳細については、たとえばこちらをご覧ください 。 実行可能ファイルは、ヘッダー、セクションのテーブル、およびセクション自体で構成されます。 セクション自体は、ローダーが相対アドレス（相対仮想アドレス-RVA）でメモリにマップする必要があるデータブロックであり、すべてのリソース、コード、その他のデータはセクションに含まれています。 また、ヘッダー内には、アプリケーションが機能するために必要な多数のテーブルへのリンク（RVA）があります。この記事のフレームワークでは、インポートテーブルとエクスポートテーブルの2つが重要です。 インポートテーブルには、アプリケーションの動作に必要な関数のリストが含まれていますが、他のファイルにあります。 エクスポートテーブルは、このファイルからエクスポートされる関数のリストを含む「リバース」テーブルです。エクスポートフォワーディングの場合、依存関係を解決するためにファイル名と関数名が指定されます。



すべての退屈なCreateRemoteThreadなしで行うインジェクションdll。 PEエクスポートフォワーディングを使用することにしました-これは、目的のプロセスを起動するために、exeファイルのインポートテーブルから任意のdllの名前と同じ名前のexeファイルを含むディレクトリにdllが作成されるときによく知られた手法です（主なものはHKEY_LOCAL_MACHINE \ System \を使用しないことです） CurrentControlSet \ Control \ Session Manager \ KnownDLLs）。 作成されたdllでは、エクスポートテーブルはターゲットdllからコピーされますが、エクスポートされた関数のコードへのポインターの代わりに、RVAを「endpoint！Sendto」の形式の転送行に書き込む必要があります。 Microsoft DNSサーバー自体は、％systemroot％\ system32 \ dns.exeにあるサービスHKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ services \ DNSとして実装されます。



dnsサーバーでの最終的な注入アルゴリズムは次のとおりです。

• ％systemroot％\ system32 \ dnsfltディレクトリを作成します（他のディレクトリを使用できます。system32でディレクトリを見つけることはオプションです）。
• ％systemroot％\ system32 \ dnsapi.dllをコピーします-これはdns.exeが何かをインポートするdllです。他の「do n't notknowndll」を選択できます。
• コピーしたdllの名前をendpoint.dllに変更します。この名前を転送行で使用します。
• 挿入されたdllを取得し、適切なエクスポートテーブルを追加し、dllを％systemroot％\ system32 \ dnsfltにコピーします
• レジストリのキーHKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ services \ DNSで、ImagePathの新しいバイナリアドレス％systemroot％\ system32 \ dnsflt \ dns.exeを変更します。
• ％systemroot％\ system32 \ dnsflt \ dns.exeから％systemroot％\ system32 \ dns.exeへのシンボリックリンクを作成します

最後のステップはなぜですか？ 実際には、Windowsには組み込みのファイアウォールがあり、デフォルトでは、Windowsサーバーには％systemroot％\ system32 \ dns.exeアプリケーションのみがポート53をリッスンする権利を持っています。 別のディレクトリから起動しようとすると、ネットワークにアクセスする権利がなくなります。 なぜコピーしたのですか？ システム全体への影響を最小限に抑え、元のdnsapi.dllに触れないようにするため。 アプリケーションのシンボリックリンクを作成できれば、そのネットワーク権限を取得できることがわかります。 既定では、管理者のみがシンボリックリンクを作成する権利を持っていますが、ユーザーにシンボリックリンクを作成する権利を与えると、組み込みのファイアウォールをバイパスできることに気付くのは予想外です。



DllMainからプロセスに読み込んだ後、ストリームを作成し、インターセプトを設定できます。 最も単純な場合、dnsサービスは、ws2_32.dllのsendto関数を介してポート53からUDPパケットを送信することにより、名前のIPアドレスをクライアントに通知します。 標準では、応答が大きすぎる場合に53個のTCPポートを使用できる可能性があると想定されており、この場合のsendtoのインターセプトは役に立たないことは明らかです。 ただし、tcpを使用したケースの処理は、より時間がかかりますが、同様の方法で実行できます。 今のところ、UDPの最も単純なケースを説明します。 したがって、dns.exeのコードはws2_32.dllからsendto関数をインポートし、それを使用してdnsリクエストに応答することがわかります。 関数をインターセプトするにはさまざまな方法があります。古典的な方法はスプライシングです。最初のsendto命令が独自の関数でjmpに置き換えられ、その完了後に、以前に送信されたsendto命令に移行してからsendto関数の内部に移行します。 インポートテーブルではなくGetProcAddressを使用してsendtoを呼び出してもスプライシングは機能しますが、インポートテーブルを使用する場合は、スプライシングの代わりにIATフックを使用する方が簡単です。 これを行うには、ダウンロードしたdns.exeイメージでインポートテーブルを見つけます。 テーブル自体の構造はややわかりにくいため、詳細についてはPE形式の説明をご覧ください。







主なものは、システムが、イメージをロードするプロセスで、インポートテーブルのsendto関数の開始へのポインターを書き込むことです。 つまり、sendto呼び出しをインターセプトするには、元のsendtoのアドレスをインポートテーブルの関数のアドレスに置き換えるだけです。



そこで、傍受を設定し、データの受信を開始しました。 sendto関数のプロトタイプは次のようになります。

int sendto( _In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sがポート53のソケットの場合、lenサイズのdns応答はbufポインターに配置されます。 形式自体はRFC1035で説明されています。目的のデータを取得するために必要なことを簡単に説明します。



標準のメッセージ構造は次のとおりです。







必要な情報のヘッダー：メッセージタイプ、エラーコード、およびセクション内の要素数。 タイトル自体は次のようになります。

 struct DNS_HEADER { uint16_t id; // identification number uint8_t rd : 1; // recursion desired uint8_t tc : 1; // truncated message uint8_t aa : 1; // authoritive answer uint8_t opcode : 4; // purpose of message uint8_t qr : 1; // query/response flag uint8_t rcode : 4; // response code uint8_t cd : 1; // checking disabled uint8_t ad : 1; // authenticated data uint8_t z : 1; // its z! reserved uint8_t ra : 1; // recursion available uint16_t q_count; // number of question entries uint16_t ans_count; // number of answer entries uint16_t auth_count; // number of authority entries uint16_t add_count; // number of resource entries };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

回答を得るには、質問セクションを解析する必要があります。 セクション自体は、ヘッダー（q_count）に示されている数のブロックで構成されます。 各ブロックは、リクエストの名前、タイプ、およびクラスで構成されます。 名前は文字列のシーケンスとしてエンコードされ、各文字列は文字列の長さのバイトで始まります。 最後は長さゼロの文字列です。 たとえば、homedomain2008.ruという名前は次のようになります。







Answersセクションは似ています。ブロックは、名前、タイプ、クラス、TTL、追加データで構成されています。 IPアドレスはaddに含まれます。 データ。 名前の解析には別の困難があります。 どうやら、ラベルの長さの代わりにメッセージのサイズを小さくするために、別のデータ領域へのリンクを見つけることができます。 次のようにエンコードされます。長さの最上位2ビットが11の場合、次のバイトと長さの最下位ビットは、メッセージの先頭を基準としたバイト単位のオフセットとして解釈される必要があります。 このオフセットを超えて、名前のさらなる分析を行う必要があります。



したがって、必要なAPIをインターセプトし、dnsの回答を解析しました。次に、この回答をさらにスキップするかエラーを返すという決定を下す必要があります。 データベースにまだ存在しない名前ごとに、回答から「疑わしい」かどうかを確認する必要があります。

Unicode Technical Standard tr39のスケルトン関数の結果がデータベース内の任意の名前の結果と一致する名前、または内部文字を並べ替えることによりデータベースに存在する名前と異なる名前を「疑わしい」と見なします。 チェックを実装するために、2つのテーブルを保存します。 最初のものはデータベースからのすべての名前のスケルトン結果で構成されます。2番目の表では、最初のレベルを除く各ラベルから最初と最後の文字を削除し、各ラベルの残りの文字を並べ替えることにより、データベース行から取得した行を書き込みます。 ここで、新しい名前が2つのテーブルのいずれかに含まれている場合、疑わしいと見なします。



スケルトン関数の意味は、2行の類似性を判別することです。このため、文字は各行に対して正規化されます。 たとえば、XlœはXloeに変換されるため、関数の結果を比較して、Unicode文字列の類似性を判断できます。



上記の実装例はgithubにあります。

インターセプトに関する小さな技術的な問題に加えて、「類似した」名前の検出にはさらに大きな問題があるため、実際に概説されたソリューションでは通常の保護を提供できません。 処理するのがいいでしょう：

• 順列とホモグリフの組み合わせ。
• スケルトンにカウントされない文字を置き換える\を追加します。
• UTS tr39はスケルトンに限定されず、1つのラベルで文字セットの混合を制限できます。
• 日本語の全角ポイントおよびその他のラベル区切り文字。
• rnicrosoft.comのようなすばらしいもの