NotPetya と 脆弱性 CVE-2017-0199 の関係
NotPetya のインシデントが世間をにぎわせた当初、エントリポイントのひとつとしてメールに添付された Word ファイル（CVE-2017-0199 を悪用）といった話があったので調べてみていた。
結果的に無関係との判断に達したが、すっかり記録を残すのを忘れていたので備忘録に追加。
問題のファイル：
Order-20062017.doc（101cc1cb56c407d5b9149f2c3b8523350d23ba84）
実行すると「hxxp://84(.)200(.)16(.)242/myguy.xls」にアクセスする。
myguy.xls（736752744122a0b5ee4b95ddad634dd225dc0f73）
実行すると PowerShell が呼ばれる。
アクセス先は「hxxp://french-cooking(.)com/myguy.exe」で調査時点では 404。
ここに置いてあったのは、
myguy.exe（9288fb8e96d419586fc8c595dd95353d48e8a060）
// VirusTotal, PayloadSecurity, Malwr
Unpack 後は 96240c41c656fc786ab8cf50926c1140e24726c9
アクセス先は「hxxp://coffeinoffice(.)xyz/cup/wish.php」のようだが、 調査時点で名前解決が不能。
関連する IP アドレスは「111(.)90(.)139(.)247」となっているが、それ以外にも「72(.)5(.)65(.)111」や「146(.)112(.)61(.)107」との関連も疑われる。
これらの情報をもとに調査をしても、結果的に NotPetya にはリンクしなかった。
// 参考情報
NotPetya : 9717cfdc2d023812dbc84a941674eb23a2a8ef06
NotPetya : 34f917aaba5684fbe56d3c57d48ef2a1aa7cf06d
BRs,
War Driving での気軽な調査をしてみた記録
実際のところ、無線 LAN のアクセスポイント（AP）の状況ってどんな感じなんだろうということで、通勤中に AP の情報を集めてみました。今回、利用したのは簡単に入手が可能な Windows 向けフリーソフト（WirelessNetView）です。これを Windows タブレットに入れて出勤しました。
合計で 2,132 の AP を記録できました。
| Open（暗号化を行っていない） | 389 |
| WEP | 194 |
| WPA TKIP | 11 |
| WPA2 TKIP | 13 |
| WPA AES | 67 |
| WPA2 AES （WPA2 パーソナル） | 1,149 |
| WPA2 エンタープライズ | 309 |
Open の AP が多くありますが、ほとんどがキャリアや店舗などが提供しているAP（001softbank, atre_Free_Wi-Fi, at_STARBUCKS_Wi2 など）です。
Open の AP のリスクとしては Evil Twin（偽AP）がありますが、これは別途検証中。
思ったよりも WEP の利用があり、全体の 9.1 % で、通信キャリア提供や WPA2 エンタープライズ等の個人管理以外を除くと割合はもっと高くなりそうです。
MACアドレスでソートして確認すると、マルチSSID対応の機種を利用中の個人が、そのまま WEP を ON にしているような感じが見受けられます。
最近の AP の多くは初期状態での WEP が OFF になっているケースが多いのですが、実情としてはまだまだ踏み台の危険性がある AP が多いようです。
WEP については OFF にする（提供ベンダはデフォルトOFFで）、どうしても利用する場合は、せめて「東西通信の禁止（プライベートセパレータ）」や「ネットワーク分離機能」の利用はしたいところです。
また、割とステルス機能を使っている AP も多く見受けられました。が、セキュリティ上はあまり意味がないのが実情です。
特に Open や WEP でステルスというのは、、、、 いかがなものか。
個人利用であれば、以下の点を考慮さえしていれば、必要十分です。
- WPA2 PSK を利用する（ただし、よくあるパスワードは避ける）
十分に強度のあるパスフレーズを利用する（13文字、大文字,小文字,数字を混ぜる、できれば記号も）
- AP の管理コンソールの ID と PASSWD は初期値から変更する（IDは変更できないケースが多いが）
- 必要に応じてネットワーク分離機能を利用する
結構、面白いネーミングの AP があって大喜利っぽくて面白かった。
BRs,
MACアドレスを含むSSIDのリスク
iPad など GPS 機能がない（Wi-Fi 機能のみの）デバイスの場合でも、大体の位置が地図上でわかりますが、仕組みとしては近くの Wi-Fi スポット（AP, アクセスポイント）の MAC アドレスなどから位置を確認しています。
ちなみに、この座標と AP の MAC の相関は自動で収集されていたりします。で、その利用例として、Google では Google Maps Geolocation API を提供しています。
https://developers.google.com/maps/documentation/geolocation/intro?hl=ja
この場合、必須となるのは AP の MACアドレス（が 2 つ）です。例えば、以下の例では同じ AP が複数の MAC アドレスを持っています。
確認すると、物理的なだいたいの位置が判明します。
ここで注目をしたいのが、上の赤で囲んだ部分。複数のMACアドレスが近い値の MAC アドレスを有しています。この性質を利用すると、1 つ MAC アドレスがわかれば、"判明しているMACアドレス + 最後の文字だけ 0~F で変更したMACアドレス" などで、もう 1 つの MAC アドレスを推測することで、2 つの MAC を用意することができます。
ベンダーによって変化する値は少し違いますが、外れても何度か繰り返せば、当たることはよくあります。
で、ここからがリスクとなり得る事象ですが、家庭用の AP であっても機器によってはこれと同じ性質を持っています。また、機器によっては MAC アドレスを含む SSID がデフォルトの SSID だったりします。例えば、こんなケース。
同じようなことをすると。
ただ、この情報が本当にこの AP の存在する住所を示しているかは不明です。
いずれにしても、SSID に MAC を含めることに大きなメリットはありませんので、やはりSSIDは変えておくのが良い気がします。
ちなみに、Google さん他の AP の情報収集をオプトアウトする方法（SSID の末尾に _nomap を付ける）もありますので、必要に応じて利用すると良いかもしれません。
Google の位置情報サービスでアクセス ポイントを設定する - マップ ヘルプ
で、最後に今回の AP の MAC アドレスですが、実はとある SNS のサイトで質問者の方がアップしていた画像です。
この人の場合はデフォルトの PSK や WPS の PIN、管理コンソールのユーザ名とパスワードも写してましたけど、、、。不用意にもほどがある感じです。この写真を撮らせた人が悪い人でない事を祈るばかりです。
BRs,
PIXEL FOR PC AND MAC
PC 向けのラズパイ。 基本的な Linux のコマンドや Python は使えて、コンパクト。 検証環境用にいろいろ捗るかも。 とりあえず、vBox の中で快適に動作中。
https://www.raspberrypi.org/blog/#pixel-pc-mac
BRs,
街でよく見る暗号化のない公衆無線LAN環境のモニタ
無料の無線LAN環境が広く提供されるようになっている今日この頃。安全性について質問を頂くことがよくあるので、備忘録がてら。
環境
- Surface Pro 3 / Windows 10
- kali Linux on Virtual Box
- 無線子機（USBタイプ, Buffalo WLI-UC-G301N） ＞ Surface 本体の無線子機は Kali からは無線LANのNICとして認識されないため
トラブルシューティングはおこなっていないが、なぜか初回起動時に Kali 上の wlan0 がモニタモードへ移行できても、周囲の電波を拾わない（No Network）になる、、、
そのまま reboot すると問題なく無線LAN接続が可能になる。今回は、とりあえず動くので、この手順で実施した。
手順は一般的なモニタモードへの移行手順：
- airmon-ng check kill で wlan0 を解放
- airmon-ng start wlan0 でモニタモードに移行
- iwconfig でモニタモードになっていることを確認（wlan0 → wlan0mon）
- airodump-ng wlan0 で周囲の無線LAN通信がモニタできていることを念のため確認
- wireshark を立ち上げて wlan0mon の様子を確認
出張の空き時間でのやっつけ仕事のため、非暗号化環境のサンプルとしてスターバックスの「at_STARBUCKS_Wi2」をモニタしました。場所は、品川の某スターバックス。
なお、スターバックスの無線LAN環境の利用に関しては、きちんとセキュリティに関する注意書きがされている。「at_STARBUCKS_Wi2 : セキュリティに関して」
「at_STARBUCKS_Wi2」の使用 ch を確認して（今回は ch11）、ターゲットの ch に絞る。ただし、同じ ch を使っている他の無線 LAN も、まだ含まれる。
なお、暗号化されている無線LAN通信は「Protocol が 802.11」ですが、PSK（パスワード）がわかっている場合は、Wireshark の設定をすることで復号は可能。
PSK を壁などに貼ってある公衆無線LAN環境も多く、暗号化されているといっても、全員が共通パスワードを付与される環境は、暗号がない状態と同値。
「at_STARBUCKS_Wi2」を利用中の自分のスマホ（Android）の通信に絞って確認（ip.addr でフィルタ）。通常のモニタの場合は、wlan.addr や wlan.bssid でフィルタするのが吉。
自身のスマホの IP でフィルアたした結果、Yahoo への通信などの通常の HTTPS 接続や DNS のクエリなどを閲覧できることを確認。
BRs,
備忘録 : BURPSUITE
Fiddler と双璧？を成す Windows 環境の Local Proxy 「BURP SUITE」 の情報。Fiddler 使いなので、こういうのは本当に助かる。
[BurpSuiteJapan] HTTP 基礎入門
https://www.slideshare.net/BurpSuiteJapanUserGr/burpsuitejapanhttp
[BurpSuiteJapan] Burp Suite 導入・操作
https://www.slideshare.net/BurpSuiteJapanUserGr/burpsuitejapanburp-suite
[BurpSuiteJapan] Burp Suite 実践編
https://www.slideshare.net/BurpSuiteJapanUserGr/burpsuitejapanburp-suite-76430995
[BurpSuiteJapan] Burp Suite 回答編
https://www.slideshare.net/BurpSuiteJapanUserGr/burpsuitejapanburp-suite-76431008
// 追記@2017.07.06
最近のBurp Suiteについて調べてみた
https://www.slideshare.net/zaki4649/burp-suite-69259761
BRs,
中国に出張したのでホテルの無線LANを調べてみた件
仕事で南京にいってきた。
せっかくなので、フィールドワーク（ライフワーク？）としているタイトルの活動を海外でも実施してみました。 結論から言うと、今回のホテルの環境は、これまでの中で最もイケイケでした。
先に、今回の気づき、
- やっぱり、公衆LANを使うときは、VPN とか使いたい（が、中国はVPNが遮断されがちなので詰む T-T）
- これはもうスマホのテザリングを経由するのが最強なのではないか（パケ死が怖い）
- ただ、日本のまっとうなところは、東西通信ができない設定になっているところが多いので割と安心 （スター〇ックスとか）
- でもやっぱりいちいち気にしたくないので VPN を使いたいところ
- これ、一般のユーザにしてみれば、もうなんだかわからないレベルなので、そこにビジネスチャンスがあるのかもしれない （ただユーザが理解できない = 価値を感じない = ビジネスにならない？）
さて、今回のホテルの無線LANは全館が同じ SSID で、APにアクセス後にブラウザ上でパスコードを入れるタイプです。よく空港やスタバなどと同じタイプで、基本的に 暗号化が行われていない環境です。
■今回の登場人物
| 10.30.13.119 | 被害端末 |
| 10.30.5.103 | 攻撃端末 |
| 10.30.0.1 | Default GW |
| 10.30.*.* | その他のみなさん |
とりあえず、被害端末からの眺め。 攻撃端末には ping を打って reply があるのは確認済み。あれ、他にも見えている、、、 もしや、、、。
とりあえず、サブネットの範囲でスキャンをかけてみる。怒涛のデバイス発見祭りへ。
とりあえず、攻撃者役端末（10.30.5.103）から自身の被害者役端末（10.30.13.119）に対して APR Spoofing を行ってみた。 ＞ Status は Poisoning へ（成功）
念のため、被害者端末で確認。MACアドレスが変更されて、通信が攻撃者端末へ流れる状態（中間者攻撃が可能な状態）を確認。 ここまで 2 分。
さっそくパケットを見てみる。 見えている、いろいろと。
そういえば、ここの環境、、、 DNSがいきなり外の public DNS サーバになってた、こんなもんだっけ？ いや（ry
BRs,
