OMG:MiraiベースのボットがIoTデバイスをプロキシサーバーに変える

2018年3月にスペインのマドリッドで開催予定のRootedConセキュリティ会議における「IoT:ボットの戦い」と題する講演の準備をする中で、FortiGuard Labsチームは新たなMiraiの亜種に遭遇しました。

Miraiボットネットのソースコードが公開されて以来、FortiGuard Labsチームは複数の開発者によるいくつかの変種と改変されたマルウェアが、IoT脅威ランドスケープに加わるのを目にしています。これらの改変されたMiraiベースのボットは、オリジナルのtelnet ブルートフォースログインに、エクスプロイトの使用やターゲットとするアーキテクチャを増やすことを含め、新たな技術を追加しオリジナルとは違ったものとなっています。また、Miraiに加えられる変更点の動機としては、より多くの金銭を得ようという意図があることも観察しています。Miraiは当初DDoS攻撃目的で設計されましたが、その後仮想通貨のマイニングのために脆弱なETHマイニングリグをターゲットとして改変されました。この記事では、OMG と呼ばれるMiraiベースのボットがどのようにIoTデバイスをプロキシサーバーとして利用するのかについて説明します。

2016年10月にブライアン・クレブスは、サイバー犯罪者たちがどのようにIoTデバイスをプロキシサーバーとして利用し、金銭を得ているかについてまとめたブログ記事を公開しました。サイバー犯罪者たちはサイバー窃盗やシステムのハッキングなど、さまざまな犯罪行為を手がける際にプロキシを使用して匿名性を高めます。プロキシサーバーで利益を得る方法の1つは、これらのサーバーへのアクセスを他のサイバー犯罪者に売ることです。これがMiraiベースの最新のボットの隠れた動機であると私たちは考えています。この記事ではまた、オリジナルのMiraiと比較しながら改変された亜種との類似性も見ていきます。


MiraiとOMG

それではまず、OMGの構成テーブルから検討しましょう。このテーブルは、当初暗号化されていたものを、0xdeadbeefを暗号キーシードに使用して、オリジナルのMiraiでも採用されていたものと同じ手順で解読したものです。最初に目が留まったのは、 /bin/busybox OOMGAOOMGA: applet not found という文字列でした。Mirai という名前は、 /bin/busybox MIRAIMIRAI: applet not found という文字列からMiraiボットに与えられたものですが、これは、ターゲットのIoTデバイスへのブルートフォースによる進入に成功したかどうかを判断するコマンドです。これらの文字列はSatori/OkiruやMasutaなどの他の亜種でも同じように見られます。

このため、この亜種をOMGと名付けることを決めました。

この亜種ではオリジナルのMirai コードに追加が加えられたり、いくつかの設定が削除されたりしています。注目すべき2点の追加は、2つのランダムなポート上のトラフィックを許可するためにファイアウォールルールを追加する2つの文字列ですが、これについては記事の後半で説明します。

図1. OMGの構成テーブル

OMGは攻撃、キラー、スキャナモジュールを含む、Miraiのオリジナルのモジュールをそのまま残しているようです。これはつまり、元のMiraiに可能であったこと、つまりプロセスを(開いているポートをチェックしてtelnet、ssh、httpに関連するプロセス、また他のボットに関連するプロセスを)強制終了し、拡散するためにtelnetブルートフォースログインし、そしてDOS攻撃をすることです。

図2. Miraiのメインモジュール

モジュールを初期化した後、OMGはコマンド&コントロール(CnC)サーバーに接続します。以下の構成テーブルには、188.138.125.235へと分解されるCnCサーバー文字列ccnew.mm.myが含まれています。

図3. CnCドメイン分解

構成テーブルにはCnCポート50023も含まれています。

図4. CnCポート50023

残念ながら、CnCサーバーは私たちが分析を行った時点では応答していませんでした。したがって、多くの調査結果は静的分析に基づくものとなっています。

接続されると、OMGは定義されたデータメッセージ(0x00000000)をCnCに送信し、それ自体を新しいボットと認識します。

図5. 送信されたデータがそれ自身を新しいボットとして認識する

コードに基づいて、ボットはサーバーから5バイト長のデータ文字列を受け取りますが、最初のバイトはIoTデバイスの使用方法に関するコマンドです。予想される値は、プロキシサーバーとして使用する場合は0、攻撃の場合は1、接続を終了する場合は1より大きくなります。

図6. CnCサーバーからの予想される選択肢


3proxyを使用するOMG

このMiraiの亜種はプロキシサーバーとして利用するために3proxyというオープンソースソフトウェアを使用します。設定は、http_proxy_portおよびsocks_proxy_portが使用する2つのランダムなポートを生成することから始まります。ポートが生成されると、CnCに報告されます。

図7. プロキシの設定

プロキシが正常に動作するためには、生成されたポート上のトラフィックを許可するためにファイアウォールルールを追加する必要があります。先に述べたように、これを有効にするためにファイアウォールルールを追加・削除するコマンドを含む2つの文字列が構成テーブルに追加されています。

TABLE_IPTABLES1 -> used to INSERT a firewall rule.
iptables -I INPUT -p tcp --dport %d -j ACCEPT;
iptables -I OUTPUT -p tcp --sport %d -j ACCEPT;
iptables -I PREROUTING -t nat -p tcp --dport %d -j ACCEPT;
iptables -I POSTROUTING -t nat -p tcp --sport %d -j ACCEPT

TABLE_IPTABLES2 -> used to DELETE a firewall rule.
iptables -D INPUT -p tcp --dport %d -j ACCEPT;
iptables -D OUTPUT -p tcp --sport %d -j ACCEPT;
iptables -D PREROUTING -t nat -p tcp --dport %d -j ACCEPT;
iptables -D POSTROUTING -t nat -p tcp --sport %d -j ACCEPT

図8. ファイアウォールの有効化と無効化機能

ランダムに生成されたHTTPおよびSOCKSポートをトラフィックが通過することを許可するようにファイアウォールルールを有効にした後、コードに事前定義された設定を埋め込んだ3proxyを設定します。

図9. プロキシ構成

分析中はサーバーが応答を停止していたため、このOMG の作者がIoTプロキシサーバーへのアクセスを販売し、アクセスクレデンシャルを提供しているというのは私たちの仮定です。


結論

私たちは今回初めてDDoS攻撃ができるよう変更されたMiraiの亜種と、脆弱なIoTデバイス上へのプロキシサーバーの設定を確認しました。このような事実から、より多くのMiraiベースのボットが新たな収益化の方法とともに登場すると考えられます。

今後も、FortiGuard LabsはMiraiとその亜種を引き続き監視し、調査から得た興味深い洞察を共有します。

すばらしい洞察を提供してくれた同僚のArtem SemenchenkoとDavid Maciejakに感謝します。

-= FortiGuard Labsチーム =-


IOC

Linux / Mirai.A!trとして検出された全サンプルは以下の通りです。

  • 9110c043a7a6526d527b675b4c50319c3c5f5c60f98ce8426c66a0a103867e4e
  • a5efdfdf601542770e29022f3646d4393f4de8529b1576fe4e31b4f332f5cd78
  • d3ed96829df1c240d1a58ea6d6690121a7e684303b115ca8b9ecf92009a8b26a
  • eabda003179c8499d47509cd30e1d3517e7ef6028ceb347a2f4be47083029bc6
  • 9b2fe793ed900e95a72731b31305ed92f88c2ec95f4b04598d58bd9606f8a01d
  • 2804f6cb611dc54775145b1bb0a51a19404c0b3618b12e41b7ea8deaeb9e357f

CC

  • 54.234.123.22
  • ccnew.mm.my
  • rpnew.mm.my