火曜日, 1月 31, 2017

#OCJP-134: ダブル「sh」ELFのリバーシング (Linuxハッキング事件調査)

■はじめに

今回Linuxのハッキング事件のレポートを書かせて頂きます。

内容的には「Linux OS x86」、「ELFバイナリリバーシング」と「シェルコード」の絡みとなります。

この記事を読むだけでもOKですし、もし再現したい場合ASM、gccとLinuxリバーシングのノウハウが必要だと思います。環境的にLinuxのシェルですので解析は全てradare2でやりました。

取り合えず簡単に書きますので、リラックスしながら楽しくに読んで下さい。


■ハッキングされた情報

とあるLinuxマシンに怪しいプロセスが発見されました↓
28641 ?        S      0:00 [kworker/2:0]
30514 ?        S      0:00 [kworker/1:0]
30518 pts/1    S+     0:00 [sh]
31544 ?        S      0:00 [kworker/3:2]
31670 pts/1    S      0:00 netstat -tc <======ココ
プロセスツリーで確認したら↓
systemd-+-acpid
        |-agetty
        |-cron
        |-dbus-daemon
        |-irqbalance
        |-rsyslogd-+-{in:imklog}
        |          |-{in:imuxsock}
        |          `-{rs:main Q:Reg}
        |-sshd-+-sshd---bash ←私はここに居ますよw
        |      `-sshd---sshd---bash---sh---netstat <===========ココ
        |-systemd---(sd-pam)
「netstat -tc」のコマンドを使ったこと無いって聞いたいたので。
「netstat」の親プロセスを探すと「sh」コマンド、それと「sshd」がありますね。

と言う事で親プロセスはここで↓

28641 ?        S      0:00 [kworker/2:0]
30514 ?        S      0:00 [kworker/1:0]
30518 pts/1    S+     0:00 [sh] <==========親プロセス
31544 ?        S      0:00 [kworker/3:2]
31670 pts/1    S      0:00 netstat -tc <========子プロセス
不思議な「sshd」プロセスが見つかりませんでした。

探すと、historyで下記のコマンドが実行されたそうで分かりました↓

2097  2017-01-XX 14:30:54 rm -rf sshd
hddはext4のフォーマットなので、extundelete /○○ --restore-allで偽sshdを取り戻しました↓
-rwxr-xr-x  1 xxx xxx 3336 Jan XX 13:48 sshd
完全に怪しいと思って、「sshd」ファイルの形をチェックしました↓
sshd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, xxx, stripped
ダイナミックタイプですね、次、リンクされたライブラリをチェック↓
$ ldd sshd
        linux-gate.so.1 (0xb7712000)
        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7556000)
        /lib/ld-linux.so.2 (0xb7715000)
やはり偽者です。

もっと見たら(readelfで)ハッキングされたマシンでコンパイルされた物と分かりました↓

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048357
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2216 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 27
   :
Symbol table '.dynsym' contains 6 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND mmap@GLIBC_2.0 (2)
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (2)
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND munmap@GLIBC_2.0 (2)
     5: 08048518     4 OBJECT  GLOBAL DEFAULT   15 _IO_stdin_used
ここ迄見たら、どうやってコンパイルしたのか分からないので、ここからsshdのバイナリを調査します。

因みに残したネットワークソケットの情報があるので、ハッカーの元IPが分かりました↓

180.97.220.28:8080
BGP情報↓
23650 | 180.97.220.0/24 | CHINANET-JS-AS | CN | chinatelecom.com.cn | ChinaNet Jiangsu Province Network
プロキシっぽいですね。。


■バイナリーのリバーシング

最初に偽sshdのストリングでチェックし、面白い物を見つけた↓

[^_]
[^_]
;*2$"(
RRRT[S_
/bin  <====  (ノ゚ο゚)ノ オオオオォォォォォォ...
//sh@u <======   ..ノオオオォ…(ノ゚ο゚)ノミ(ノ _ _)ノコケッ!!
.shstrtab
.interp
「bin」と「sh」の単語を見たら気分が悪くなりますね..

sshdバイナリのDATAセクションを見たら「bin」と「sh」の単語が近い所にあります....

さくっとradare2をインストールし、asmにリバースしました↓

0x0804974c      31f6           xor esi, esi <==== DATA XREF 0x08048343
0x0804974d      f6f7           div bh
0x0804974f  ~   e652           out 0x52, al
0x08049750     .string "RRRT[S_" ; len=8
0x08049758     .string "\\a/bin" ; len=6
0x0804975e      47             inc edi
0x0804975f  ~   042f           add al, 0x2f
0x08049760     .string "//sh@u" ; len=7
0x08049767      b03b           mov al, 0x3b
0x08049769      0f05           syscall <===== (ノ゚ω゚)ノ*...ウオオォォォォォォォー!!
こんど「syscall」の単語が出て来ました(--;;)

0x0804974cが0x08048343からxrefされたので、0x08048343を見ようと↓

0x08048330      8d4c2404       lea ecx, [esp + local_4h_2]
0x08048332      2404           and al, 4
0x08048334      83e4f0         and esp, 0xfffffff0
0x08048337      ff71fc         push dword [ecx - 4]
0x0804833a      55             push ebp
0x0804833b      89e5           mov ebp, esp
0x0804833d      51             push ecx
0x0804833e      83ec0c         sub esp, 0xc
0x08048341      6a25           push 0x25  
0x08048343      684c970408     push 0x804974c <====(1) => "1...RRRT[S_../bin.G.//sh@u..;..1....." @ 0x804974c
0x08048348      e8fe000000     call fcn.0804844b <======(2)
0x0804834d      8b4dfc         mov ecx, dword [ebp - local_4h]
0x08048350      31c0           xor eax, eax
0x08048352      c9             leave
0x08048353      8d61fc         lea esp, [ecx - 4]
0x08048356      c3             ret
恐らく0x08048330はmain()の関数ですね。コードに書いた(1)と(2)の説明は下記となります↓

(1)はxrefの元のアドレス、そこに0x0804974cからのデータをスタック(stack)にプッシュされた。
(2)その後fcn.0804844bの関数をコールされます。

fcn.0804844bはこの辺にありますね↓

↑関数の元名前がstripされたそうですね。

fcn.0804844bをradareで分析をすると↓

0x0804844b      55             push ebp
0x0804844c      89e5           mov ebp, esp
0x0804844e      57             push edi
0x0804844f      56             push esi
0x08048450      53             push ebx
0x08048451      83ec24         sub esp, 0x24
0x08048454      8b5d0c         mov ebx, dword [ebp + arg_ch]
0x08048457      8b7508         mov esi, dword [ebp + arg_8h]
0x0804845a      6a00           push 0 
0x0804845c      6aff           push -1 
0x0804845e      6a22           push 0x22
0x08048460      6a07           push 7
0x08048462      53             push ebx 
0x08048463      6a00           push 0 
0x08048465      e896feffff     call sym.imp.mmap <=====mmap()
0x0804846a      89d9           mov ecx, ebx
0x0804846c      89c7           mov edi, eax
0x0804846e      8945e4         mov dword [ebp - local_1ch], eax
0x08048471      f3a4           rep movsb byte es:[edi], byte ptr [esi]
0x08048473      83c420         add esp, 0x20
0x08048476      ffd0           call eax
0x08048478      8b45e4         mov eax, dword [ebp - local_1ch] //memcpyなはずですが....
0x0804847b      895d0c         mov dword [ebp + arg_ch], ebx
0x0804847e      894508         mov dword [ebp + arg_8h], eax
0x08048481      8d65f4         lea esp, [ebp - local_ch]
0x08048484      5b             pop ebx
0x08048485      5e             pop esi
0x08048486      5f             pop edi
0x08048487      5d             pop ebp
0x08048488      e993feffff     jmp sym.imp.munmap <===munmap()
↑このASMの意味はこんな感じです↓

サイズ0x24とPROT_EXEC+PROT_WRITE+PROT_READフラグのmmap(バーチャルメモリのマッングlinux syscall機能)がコールされ、そしてメモリ(stack)上でにデータを書き込んで(およそmemcpyの動きで)、PROT_EXECのフラグなので書き込み終わったらそのままで実行されるように見えます。

この偽sshdがどうやってコンパイルしたか分からないけど、上記のASMが複雑し過ぎて、恐らくコンパイルの時にstripだけじゃなくて、関数とデータが別れるように設定されたそうなので「memcpy」があるはずだが見えない状況です。

その分析ASMデータをもっとシンプルで書くと(少しパッチして、radare2のESILでアナライズをすると)memcpyが見えるようにしました↓

分かり易く上記のASMをCコードに書きましょう!これはデコードの基本ですね、結果は大体こんな感じです↓

void fnc.0804844b(char *_BLOB_DATA, int __size)
  { 
    void *JunkToExec; // argument passed -> int __size=0x24;
    JunkToExec=mmap(0,__size,PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    memcpy (JunkToExec, *_BLOB_DATA, __size);
    munmap (JunkToExec, __size);
  }
よーし!ここ迄0x0804844b関数の意味が分かったでしょ。実行のローダー機能ですね、英語だと「executable loader」かな? こんな感じのC言語で書いたシェルコードに多いですね。

所で、どうやってfnc.0804844bが起動されでしょ?
ここで上記に書いたmain関数(0x08048330)の流れに繋がりますが、
C言語でmain()関数を書けば大体はこんな感じですね↓

#define __ExecData_SIZE 0x24 // global variable is needed for the "size"..
char __ExecData[] = {"fugahoge.."}; // 実行の為のデータはこんな感じ..
int main(int argc, char *argv[])
{
  fnc.0804844b (__ExecData, __ExecData_SIZE); //ここで↑2件のバリューを0x0804844bに送ります
  return 0;  
}

という意味では"fugahoge"って→「bin」や「sh」単語があるデータ(0x0804974c!0x24)ですね。シェルコードですか?もしシェルコードなら、どんな動きでしょうか?

詳しく確認しましょう。

■シェルコードのリバーシング

一応、偽sshdのリバーシングの時に一応最初からシェルコードの所に行ってしまいましたが、当時未だ色々分かりませんでした。 今、シェルコードがある事、そしてサイズとローダーがある事も分かりますので、明確にシェルコードの部分が見えるようになりました。

この辺ですね↓

それで、radareで最初に偽sshdの「0x0804974c」を開いたけど、 その時にr2は0x0804974cからバイナリのデータとして分析されていたので、ちゃんとx86実行バイナリ「opcode」に分析されなかった。

それをやり直しましょう。

Linux x86のopcode読む方法やツールがあるけど、このシェルコードのサイズが小さいので遣りやすい方法でやりましょう。
私が秀丸で調べ/計算しながら解析したので、その分析した結果はこんな感じです↓

↑まるでシェルコードの形ですね。ASMで結構です(C言語迄に書く必要がありません)。

『重要な調査のヒント』面白いなのは「jnz 0x1f」のコードですね。
意味合い的にこのシェルコードで2回syscall execve("/bin//sh",0,0)を実行されます。自分はこれを初めて見ました。

追加情報ですが、沢山の質問頂き有難う御座います。この場で色々質問の回答をさせて頂きます↓

(1)一番聞かれたポイントはどうやってシェルコードが実行されたのか?
分かり易いように図を作りました↓

読み方は①→②→③→④の方向で、周りの説明を見ながらです。

(2)シェルコードの実行前に、mmap()がコールされた時に、メモリ上で検知が出来る方法がありますでしょうか?

ありません、下記の詳細デバッグ画像を見たら分かるように、mmap()がコールされた時、不具合点が全然見えないので、stack上にフォレンジックをしたいなら、memcpy()からcall eaxの間にある動きのRAMスナップショットを取った方がお勧めです。

(3)デバッギングの時に、シェルコードを確認する方法はありませんか? 

あります。オリジナルのバイナリをパッチしたら『call eax又は((void(*)()) *JunkToExec)』のコールが見えますので、もしシェルコードをデバッギングでみたいならcall eax所で実行をしない、デバッグを一時停止にして、シェルコードが必ず*DWORD[ebp - local_ch]にありますので、[ebp - local_ch]の中身を見たら確実にシェルコードが見えますね。下記は私のFreeBSDでのr2のスクリーンショット↓

記事の通り私は最初シェルコードを読む時にツールを使わなかった、上記の画像はradare2で読み込んだシェルコードの分析結果ですね。そして、このシェルコードから解析などが出来ますね^-^)v 因みに私的に「407504」のdissasは実は「jnz 0x01f」です。


■再現

解析の結果が正しいかどうかの確認が必要です。
偽sshdバイナリを再現したらシェルコードが起動された時にトレースで確認が出来ます。

ちょっとだけミスがありますが結果が大体合っています。

ダブル「/bin//sh」についての再現は↓

※)もし色々試したいならバイナリーをここに保存しました。


■結論

ここ迄の分かった事まとめ↓

1. 中国IPアドレス(180.97.220.28)からのプロキシでハッカーがこのボックスに入りました。
2. ハッキングの方法は恐らくssh経由の攻撃です。
3. ラッピングされたシェルコードのCファイルを偽sshdバイナリとしてコンパイルしたようです。
4. 実行された後にその偽sshdを削除し、開いたshell(sh)を残し、ハッカーが最後に実行したコマンドもそのshell(sh)で発見されました。
5. ハッカーが使ったシェルコードの特徴があり、2回「sh」を実行します。
※)その他の情報が申し訳御座いませんがここで公開が出来ません。

Linuxのリバーシングは楽しいですね!(^-^v #MalwareMustDie!

@unixfreaxjp/0day.jp Tue Jan 31 01:45:34 JST 2017 - AVTokyo ELF Workshop

土曜日, 1月 28, 2017

#OCJP-133: Hancitorマルウェア感染 と ハッキングされたWordpress

■はじめに

今回は新しいマルウェアにハッキングされたWordpressサイトの報告を致します。
恐らく2017年1月25日から、Wordpressで作られたウェブサイト/ブログのハッキング事件が沢山発見されております。

ハッキングされたサイトにZeus(Pony種類)若しくはVawtrakなどのマルウェアファイルを発見されています。ハッカーが古い版Wordpressソフトウェア、若しくは、プラグインの脆弱性を狙い、「/wp-content/plugins/」ダイレクトリーの下に暗号化されたPonyやVawtrakマルウェアファイルを入れていた、との状況でいくつか確認をさせて頂きました。

ハッキングされたサイト一覧の中に日本国内のwordpressサイトもあります。

■Hancitorマルウェア感染仕組みについて

簡単にいうと、Hancitor(Chanitor / Hancitor Maldoc)とは、作り方によって少し動きが違うので、MS-Word(.doc)ファイルに書いたVBAスクリプトとシェルコードでの新しい技法「(1)ドロッパーマルウェア」若しくは「(2)プロセス・インジェクター・マルウェア」です。「ドロッパー」タイプですと感染PCのディスクにマルウェアファイルを保存する動きがあり、「プロセス・インジェクター」の場合はマルウェアを保存せず、メモリー上でターゲットされている「○○プロセス」を開き、その「○○プロセス」のバイナリーデータがマルウェア実行バイナリデータに上書きされます。

□ パソコンにHancitor .Docマルウェアを感染する仕組みの図


□ 本マルウェア感染の「IOC」情報 (次のキャンペーンを一番下に追加します)

1. 2017年1月27日
2. 2017年1月31日~2月1日


□ Hancitor .Docファイルに書いたVBAマクロが下記のイメージです↓

頭の分

※)この部分が簡単に変更されそうです。

WindowsシステムのDLLをコールされるの分

※)独特のコール仕方を使っているように見えます。

本事件、プロセスインテックターのHancitor種類のみの情報なので、ターゲットされているプロセスは「iexplore.exe」で、

...インジェックされたマルウェアファイルはDLLタイプのバイナリーです。 インジェックションの時に
コード上書きの書き込みの為↓この↓loopが重要で、「FAIR」と「GAME」が書き込みのコントロールFLAGになります↓


□ どんなシェルコードのコマンドを使ったのか?

シェルコードのクラッキング仕方が色んなやり方がありますが、本件の調査した時に時間がそんなに無かったので、私はwindwordのシェルコードデータを読み込みした時に全て情報を手に入れました。シェルコードの動きを全てここで書くのは良くないので、証拠としてスナップショット画像を取ったので、下記のように見せます↓


右側に書いたコマンドはシェルコードのコマンドなので、それを見たら大体どんな動きがあるのか分かると思います。今度もしHancitorが無くなったらこの情報を追加する積りです。

このHancitor DLLコードが実行されたらまた別途リモートサイトから2つファイルをダウンロードされ、PCに感染されてます。ダウンロードされたマルウェアは「Zeus系/Pony種類」のトロイ木馬で、他の事件にはVawtrakトロイマルウェアがダウンロードされた事もあります。

動き的にこんな感じ、Hancitor .Docファイルを開いたら、VBAスクリプトが実行され、.Docに保存されたシェルコードを読み込み⇒ロード⇒実行し、.Docファイルに添付されたマルウェアバイナリーデータをロードされ、データを解読してからシェルコードが決まっている「○○プロセス名」にそのマルウェアデータを書き込みします。本事件の上書きされたデータがHancitor DLLマルウェアで、上書きが終了したらそのままHancitor DLLマルウェアが実行されます。

下記の画像にはHanictorがiexplore.exeのプロセスにDLLコードをインジェクした時の状況です↓

↑マークされた所はインジェックされたiexplore.exeの中身ですけれども、通常のiexplore.exeの状態とはまるで違います。
見た通り全然関係ないのdllライブラリ一覧が実行されていて、その一覧自体はマルウェアが使っているdllになってしまい、iexplore.exeじゃなくなりますね。

もしインジェックされたHancitor DLLのバイナリーをデコードすれば、下記のようなCコードが見られますが、
マルウェアの部分が隠れていて直ぐには見られていません↓


但し、もしそのDLLが実行されたら、暗号化されているマルウェアファイルがリモートのURLからダウンロードされています。↓



インジェックされたiexplore.exeのプロセスをデバッグするとシェルコードのダウンロード動きが見えます。

↑HancitorのHTTPリクエストはWININET.DLL経由で投げたそうに見えます。

因みに、ダウンロードURLの実行の前に、Hancitor DLLマルウェアがHanictorのCNC(C2)サーバに感染の報告を送り、そして
CNC(C2)サーバから解読の情報が送られてきます↓


ハッキングされたサイトにあるマルウェアファイルの種類は殆ど「Pony/Zeus系」ですが、時々「Vawtrak」か「Fareit」マルウェアで、たまには「Zloader (zeus loader)」を発見しました、殆ど暗号化されている状況です。
Hanictor DLLマルウェアの感染が始めたら、その暗号化されたファイルがダウンロードされますが。感染が始まった時にほぼ全てのファイルがアンチウイルスとURLフィルター機能すり抜けていました。それは恐らく暗号化の目的だと思います。




これでメモリの上で暗号化されたZeusファイルが解読され、Zeus/Ponyマルウェアの感染が始めます。
!!TIPS!!: 行動分析調査の時に感染の確認証拠としては下記のZeusのCNCトラフィックとなります↓


そして、下記のトラフィックはHancitor DLL又はZeus/Ponyからではなくて、恐らくWin32/Fareitトロイのです。

これで全てダウンロードされたpayloadが分かります。

Hancitor DLLからの別途トラフィックも出ています。例えばIP確認APIのURLコールバックなどなど。

Hancitorの「.Doc」マルウェアの感染が始まってからの全体的なトラフィックは下記のようになっています↓


もしドメイン名とマルウェア情報を入れたら上記のトラフィック情報がこうなっています↓

※もっと細かいなトラフィック情報は【こちらへ】ご覧下さい。

Hancitorの「.Doc」ファイル自体はどうやって来るのか?
数週間前にスパムメールに添付されたパターンが多くて、最近はもっと複雑な仕組みで、スパムメールの文書に
「なりすましURL」で被害者を騙して、「.Doc」ファイルがダウンロードされてしまう感染パターンを発見致しました。
そのスパムとなりすましURLについては、イメージ的には下記の画像となります↓




【重要】Hancitorダウンローダーに付いてのメモ:
1. Hancitorの「.Doc」ダウンロードサイトは改ざんサイトなので、マルウェアサイトではありません。
2. ダウンローダーの仕組みはPHPで作られ、決まっているURIフォーマットがあります⇒「●●/api/get.php?id={ベース64}
3. そのベース64自体はメアドのハッシュとなります。

■C2情報

本マルウェア感染キャンペーンのサイバー犯罪者2つCNCを運用したそうです↓

1. Hancitor感染モニターC2
ドメイン: howbetmarow.ru (レジスター:r01.ru)
IP: 95.169.190.104 (km34714-26.keymachine.de)
目的 : Hancitor感染されたPCの管理データを保存するサーバ(+FareitトロイのC2)
場所 ASN 31103 | Prefix 95.169.190.0/23
ISP: KEYWEB keyweb.de Keyweb AG | Country: DE
最初の発見時間: 2017-01-26 16:37:26 -0000
ステータス:ドイツ警察に押収されました。

2. Zeus(Pony)感染パネル/C2
ドメイン: aningronbut.ru (レジスター:r01.ru)
IP: 46.166.172.105 (server1.)
目的: 盗んだ個人情報/アカウント認証情報/クレジットカードなどを保存するサーバ
場所 ASN16125 | Prefix: 46.166.168.0/21
ISP: BALTICSERVERS1, duomenucentras.lt, UAB Duomenu Centras | Country: LT
最初の発見時間: 2017-01-26 15:50:12 -0000
ステータス:捜査中
関係があるZeusドメイン:rowatterding.ru(レジスター:r01.ru)、同じIP HTTPS対応 2017-01-24 19:00:31-0000から

※わざっとZeusのC2サーバが押収されにくいホスティンッグ/IDCに運用したそうです。
※感染のブロックされないようにHancitor感染モニターC2はドイツで作ったの目的です。
※同じく(感染ブロッキングされない目的で)日本のWordpressサイトにマルウェアpayloadsファイルが用意されたそうですね。

■Zeus/Ponyトロイに盗まれた個人・認証情報について

詳細な一覧を見たいなら下記の画像をクリックしてください。

※)この情報は本感染情報のみとなります。別件の感染には違う情報が出る可能性があります。

■WordpressのマルウェアURLについて

HancitorがダウンロードするマルウェアURLを見たら、全部ハッキングされたWordpressのサイトで、
URLは下記のパターンように見えます↓


たまに別のパターンもあります↓

※)【重要】どんなパターンにも「https(SSL)」のURLがありません。原因は恐らくHancitor DLLマルウェアのダウンローダーがHTTPSに対応していません。

ハッキングの入り口はやはりWordpressソフトウェアやWordpressのプラグイン(若しくはTheme)の脆弱性です。
Wordpress(ソフト+プラグイン)のCVE脆弱性のリファレンスを確認したい場合【このサイトで見れます】

■感染URLの履歴について

ハッキングされたWordpressのマルウェアURLのトレンドがあるみたいです。
よく履歴を見たら色々わかります、例えば↓
1.何のWPの脆弱性を使うのか
2.そして、どのマルウェアファイルの形式を作るのか


※〕フィルタ製品の誤検知されないように上記の情報を画像にしました


■日本国内の影響について

2017年1月25日から、『Hancitor感染のマルウェアダウンロードURL事件』に影響されている日本国内のwordpressサイトがいくつかあります。これからも未だ出るかと思われますので、別途【画像サイトに】データを保存し、対応しながら情報を追加させて頂きます。

■結論

1. Wordpressのソフト/プラグイン/「theme」などのバージョン管理が必要で、必ず最新版のバージョンを運用してください。
2. 出来れば自分のWordpressサイトに脆弱性があるかどうかのチェックをして欲しいです。その為に無料版のWordpressスキャナーツールがあります。急いでチェックしたい場合オンラインのスキャナーもあり、WordpressサイトのURLを入力したらバージョンのアップデートが必要かどうか教えてくれます、例えば本事件のとあるWordpressサイトをスキャンしたら色々が分かります↓


3.Wordpressのサイトにマルウェアのファイルやコードを探すのは大変なので、ファイルの駆除作業するよりもバックアップでデータを取り戻す作業は手間が掛かりませんので、定期的にサイトのバックアップを取る事をお勧めします。
4.もしマルウェアファイルが発見されたら、直ぐに削除して欲しいです。もしやり方が分からなかったら、サイトのアクセスを一旦止めて、詳しい管理者に直ぐにご相談ください。
※)もしマルウェアをそのまま残した場合、恐らく発見されてから24時間後にはブラックリストに登録されてしまうので、大変な事になります。成るべく早めにご対応をください。

@unixfreaxjp/0day.jp Sat Jan 28 14:03:05 JST 2017

水曜日, 11月 02, 2016

#OCJP-132: Linux IoTのマルウェア、国内の感染について

■はじめに

Linux IoTマルウェアについて、僕が書いている英語のブログ/MalwareMustDieで最近結構研究しています。色んなマルウェア種類を発見し、そのマルウェアの感染目的は殆どボットネット、DDoS、ハッキング踏み台、スパムのプロキシ、など。

一つの種類は2年前MalwareMustDieのチームで「ShellShock」の時代にはじめて発見しましたELF/DDoSトロイ「GayFgt/Torlus/LizKebab/Qbot/Bashdoor/Bash0day/Bashlite」のマルウェアですね。名前が沢山ありますが同じ物で、「LizardSquad」が作ったマルウェアです。

当時僕がそのGayFgtのマルウェアをリバーシングしながらそのままでVirusTotalにレポートを書きました。その時の調査実績の証拠はこのゼロデイジャパンのブログに残しました。

今はshellshockの脆弱性がはやっているタイミングではなく、IoTマルウェアの感染時期で、進化された「GayFgt/Torlus/LizKebab/Qbot/Bashdoor/Bash0day/Bashlite」種類のマルウェアを沢山発見しています。

■CNC情報と日本の感染について

今日、海外にとある「GayFgt/Torlus/LizKebab/Qbot/Bashdoor/Bash0day/Bashlite」マルウェアのCNCサーバから感染されたIoTの情報を洗い出して、合計は1,944件 (uniq)のIPアドレスがあることを確認しました。


その中に19件は日本国内からのIPで、その7件は国内でのIoTネットワーク機械のIoTです。

19件の中にtelnetdサービスがダウンしているデバイスが多くて、とても良かったです。何台かハニーポットで、その残りの7件は外からのチェックて機械のモデル情報を確認しました。

■どんな種類のIoTかというと

確認の為にIoTのOS/Distro情報が必要ですので、そのデータを狙い、そして様々なOSディストリビューションに確認しました。チェックした結果は「大体」下記のネットワーク機械情報となります↓

Linux OSのmipsとarm cpuのIoTですね。

■結論

1. 海外と比べたら日本国内の感染率が低いですがゼロではありません。
2. telnetdがグローバルIPで運用されたら直ぐに攻撃が来るので、成るべくtelnetdサービスを使わず、若しくはアクセス制限をかけて、運用をして下さい。
3. IoTデバイスがあるネットワークには、内部⇒外部のネットワークトラフィックに不正なトラフィック(DoSなど)があるかどうかをモニターして下さい。

@unixfreaxjp/0day.jp Wed Nov 2 22:23:39 JST 2016