セキュリティ研究者がMiraiボットネット・ソフトウェアに脆弱性を発見 – カウンター攻撃に利用可能

最近数週間で、世界は、IoTボットネットが理論から現実に変わり、壊滅的な結果をもたらすというコンセプトを目撃しました。 ISP、DDoS緩和サービスなどは、この新しい脅威に対応するために従来の防御手段をどのように強化するかを理解するために時間を掛けていますが、これまでとは異なるアプローチを検討することにしました。

攻撃者は、当社のシステムにツールをインストールするために、所有しているソフトウェアの脆弱性を悪用することにしばしば頼っています。 これらのツールがIoTデバイス上に存在すると、攻撃者が私たちよりもデバイスにもっとアクセスできるようになり、状況はさらに複雑になります。 だから、なぜ彼らの戦略を彼らに対して使用しないのでしょうか?

これは、Miraiボットネットの脆弱性を明らかにする一連の投稿の中で初めてであり、これらの脆弱性の悪用がどのように攻撃を止めるために使用できるかを示しています。 我々は反撃を主張するのではなく、活発な防衛戦略を使用して古い脅威の新しい形態と戦う可能性を示しているだけである。

始めに

攻撃コード内の脆弱性を悪用することの意味を理解するためには、Miraiが攻撃を開始する方法を理解することが重要です。 以下のコードは、Miraiのattack_start()関数です。これはbot / attack.cで定義されています。

invincia2

5-7行目は、実際に攻撃を実行する子プロセスをフォークします。 9行目から16行目では、指定された期間の後に攻撃を殺す別の子プロセスをforkします。その期間だけスリープ状態にしてから、起動時に親プロセスを強制終了します。 最後に、攻撃プロセスは指定された攻撃(22行目〜32行目)に対して正しい関数ハンドラを呼び出し、終了します(35行目)。 つまり、攻撃プロセスがクラッシュした場合、攻撃は停止しますが、ボット自体は機能し続けます。

すべては場所、場所、場所

おそらく最も重要な発見は、HTTPフラッド攻撃コードのスタックバッファオーバーフローの脆弱性です。 悪用されると、セグメンテーションフォールト(SIGSEV)が発生し、プロセスがクラッシュし、そのボットからの攻撃が終了します。 脆弱なコードは、MiraiがHTTPフラッドリクエストから送信されたHTTPレスポンスの一部であるかもしれないHTTPロケーションヘッダをどのように処理するかと関係しています。 これはbot / attack_app.cのattack_app_http()関数にあり、次のようになります。

invincia3

まず、ロケーションヘッダーが良質であると仮定しましょう。

Location: http://google.com\r\n\

上記のコードが実行されている時点で、generic_memesバッファにはHTTPレスポンス全体が含まれています。 行1〜3はロケーションヘッダを見つけ、オフセット変数にURLの開始のインデックス(すなわち ‘h’文字)を入力します。 次に、行5-15は、nl_off変数にヘッダ値を終端する ‘\ r \ n’のインデックスを設定します。 これは、URLの先頭からのゼロベースのインデックスであり、ロケーションヘッダーまたはgeneric_memesバッファの先頭ではないことに注意することが重要です。 memmoveを25行目で呼び出すと、後に来るものを左の7文字に移動するだけで、URLから「http://」を削除しようとしています。 これは、20行目でii変数が7に設定されている理由です。良性の場合、nl_offは18です。つまり、memmoveのlenパラメータはnl_off – iiまたは18 – 7です。
invincia4

正常に “google.com”(10文字の文字列+ヌルターミネータ)が左に7文字シフトされます。 ただし、代わりに場所ヘッダーがある場合:

Location: http\r\n

次に、nl_offは5です。つまり、memmoveのlenパラメータはnl_off – iiまたは5 – 7です。

invincia5

memmoveのlenパラメータは符号なし整数(つまりsize_t型)として扱われます。つまり、-2が本当に大きな正の数0xFFFFFFFEとして扱われます。 したがって、memmoveはgeneric_memesバッファをオーバーフローさせ、メモリ全体を破壊します。

PoC

この脆弱性が実際に悪用可能であることを確認するために、Miraiコマンドおよび制御サーバー、Miraiボットのデバッグインスタンス、および被害者を実行するために3台の仮想マシンを設定します。 すべての仮想マシンはUbuntu 16.04の32ビットインスタンスです。 犠牲者はlocation_attackと呼ばれる次の内容(読みやすさのために改行と改行が ‘\ r’と ‘\ n’に置き換えられています)を提供します。

invincia6

実際にファイルを提供するには、ポート80でlistenしているnetcatのインスタンスで十分です。

invincia7

前述のように、攻撃コードを実行する前にボットがフォークするので、ボットのデバッグコンソールを観察すると、攻撃の停止以外のクラッシュが発生していることを示す視覚的インジケータはありません。 代わりに、GDBがSIGSEGVをキャッチしてプログラムの状態を調べるようにします。 まず、コマンドと制御サーバーで実際に攻撃を実行する方法を見てみましょう。

図1:MiraiのCNCコンソールを使用してHTTPフラッド攻撃を実行する

mirai_http_cnc

デフォルトでは、ボットは被害者にGETリクエストを送信します(図2)。 ホストヘッダーフィールドにfoo.comドメインも挿入されていることに注意してください。

図2:被害者が見たHTTPフラッドリクエスト

mirai_http_victim

最後に、ボットに何が起こったのか見てみましょう。 図3は、デバッグフラグ付きでコンパイルされ、GDBで実行されているMiraiボットの実行中のインスタンスを示しています。 図の上部にある「Starting attack …」デバッグメッセージは、上記で説明したattack_start()関数から出力され、その後に被害者が受信した正確なHTTPフラッドリクエストが表示されます。 次に、プログラムは、私たちのロケーションヘッダーエクスプロイトを受け取った直後にSIGSEVを受け取ります。

図3:GDBで実行中のMirai botのデバッグコンパイルと被害者からの応答のクラッシュ

mirai_http_sigsegv

図4は、クラッシュ直後のスタックの外観を示しています。 backtraceコマンドを使用すると、attack_app_httpによって呼び出されたmemmoveでクラッシュが発生したことは明らかですが、残りのスタックは破損しているようです。 これはgeneric_memesバッファがスタック上で定義されているため、オーバーフローした後に期待されるものと一致します。

invincia8

図4:GDBバックトレースコマンドによるスタック破損の検証

mirai_http_bt

最後に、ポイントホームを駆動するには、nl_offとiiの値をチェックしましょう。

図5: `nl_off`と` ii`が正しい値を持っていることを確認する

mirai_http_print_vars

結論

この単純な「エクスプロイト」は、リアルタイムでMiraiベースのHTTPフラッド攻撃を防御するためのDDoS軽減サービスによって使用されるIoTボットネットに対する積極的な防御の例です。 IoTデバイスからボットを削除するのに使用することはできませんが、特定のデバイスから発生した攻撃を停止するために使用できます。 残念ながら、これはHTTPフラッド攻撃に特有なものです。そのため、最近のDNSベースのDDoS攻撃を軽減できず、多くのWebサイトにアクセスできなくなっています。 その後の記事では、他の種類の攻撃の軽減策を開発する際に役立つ可能性がある他の攻撃コードの脆弱性を検証します。

 

参照:

https://www.invincealabs.com/blog/2016/10/killing-mirai/

http://www.scmagazineuk.com/researcher-finds-mirai-flaws-that-could-allow-counterattack-on-botnet/article/569478/