はじめに：本記事に関する注意事項と免責事項
本記事は以下の記事の続きとなります。注意事項ならびに免責事項は
同様となりますので、理解および合意いただける方のみ記事の内容へ
お進みください。
【Tutorial】Wifipumpkin3 によるおとり AP の実行【ハッキングラボ】
https://qiita.com/Jangari/items/23873664dfd1843311a6
Driftnet の概要
Driftnet は通信中のネットワークトラフィックから画像を抽出するツールです。
特にネットワークが有線 LAN か無線 LAN かに依存せず利用することが可能です。
ハッキングラボの書籍ではおとり AP の実験中に WiFi-Pumpkin と一緒に出ます。
なお、今回個別に Driftnet も記事を書いているのは、以下の記事にあるように
私の環境では WiFi-Pumpkin が使えず Driftnet もインストールされていないため、
単体で使ってみようと思ったのが発端です。
【Tutorial】Wifipumpkin3 によるおとり AP の実行【ハッキングラボ】
https://qiita.com/Jangari/items/23873664dfd1843311a6
Driftnet のインストール
Kali Linux (2020.2) の場合は apt でインストールが可能です。
# apt install driftnet
Driftnet の使い方
コマンドのヘルプを雑に調べたところ、どうやらコマンド名だけ入力すれば
全てのインターフェースを利用するようだったのでそのまま試してみましたが、
HTTP のサイトにアクセスしても Driftnet は Kali Linux のターミナルで虚しく
警告を発し続けるのみでした。
# driftnet
Fri Jun 05 11:08:40 2020 - warning: link-level (LINUX_SLL) header is not supported
色々と調査した結果、インターフェースを明示して実行することにより、
HTTP のサイトにアクセスすると Driftnet による画像抽出に成功しました。
# driftnet -i eth0
なお HTTPS の場合は通信が暗号化されているため、そのままでは
抽出できないようです。多分 SSL Strip などが必要と思われます。
Driftnet の使い方の概要は簡単ですが以上です。ハッキングラボの
書籍の範囲であれば上記内容でカバーできているかと思われます。
以下は、今回 Driftnet が出力した警告をどうやって調査していったか
トラブルシューティング的な内容を順に書いていきたいと思います。
睡眠不足＋アルコール入りの思考の過程をそのまま文章にしており、
冗長で読みづらい文章ですがご容赦ください。Driftnet の使い方しか
特に興味がない場合は役に立たない内容のため飛ばしてもらっても
問題ありません。
Driftnet の警告と調査のいきさつ
Driftnet は動かない
Wifipumpkin の記事を書く中で、おとり AP の実行中に Driftnet で
キャプチャされたパケットからの画像抽出を試そうとしていました。
しかし、今回の私の環境では Driftnet の実行中に通信を行っても、
ただただ虚しく以下の警告が大量に出力されるだけでした。
Fri Jun 05 11:08:40 2020 - warning: link-level (LINUX_SLL) header is not supported
この時点の私の知識では「link-level などと出ているため L2 周りっぽい印象はある」
程度しか分かりませんでした。警告メッセージの抜粋を Google 検索しても、特に
有効な情報は出てきませんでした。お前は何を言ってるんだ。英語でおｋ。
オープンソースな世界って素晴らしい
単純にググって調べてもまず分からなそうだったと判断したものの、
よく考えると警告は Driftnet が出力していて、driftnet は GitHub の
リポジトリにソースコードがあります。
ぐぬぬと唸っている中で、GitHub にはリポジトリ内のコードを検索する
機能があることを思い出したため、警告を出力しているコード周りを見て
有益な情報が無いか探していくことにしました。
GitHub の driftnet のリポジトリを警告メッセージで検索したところ、
以下のソースコード上に該当する箇所が見つかりました。
該当のメッセージを出力する行付近の switch 文から、どうやら
L2 のプロトコルのタイプが Ethernet や IEEE 802.11 系ではない
といった状況になっているようです。
~~でもこれじゃまだイマイチよく分からんぞ。~~この時点で LINUX_SLL は
L2 プロトコルっぽい雰囲気がある、という有益な情報が得られました。
switch 文で使われている DLT_EN10MB や DLT_IEEE802_11_RADIO も合わせ、
LINUX_SLL が何か Google 検索してみたところ、tcpdump の公式サイトの
以下のページがヒットしました。
Link-Layer Header Types | TCPDUMP/LIBPCAP public repository
https://www.tcpdump.org/linktypes.html
この資料から、先程の L2 プロトコル風味な何かは、どうやら libpcap
が使うヘッダータイプの識別名のような何かのようだ、ということが
分かります。LINUX_SLL もこの中に含まれていました。
もう少し掘り下げたところ LINUX_SLL は Linux cooked-mode という
何かのようで、これを調べると Wireshark の公式 Wiki に至りました。
Linux cooked-mode capture (SLL)
https://wiki.wireshark.org/SLL
この記事の説明内容から、LINUX_SLL は libpcap が使う pseudo な
L2 プロトコルだということが確認でき、キャプチャ対象のデバイスの
指定が "any" だと、実際のプロトコルのヘッダではなく LINUX_SLL の
ヘッダを利用する、ということが分かりました。何言ってるか分からん
とにかくポイントは「キャプチャ対象のデバイスの指定が "any" の場合に」
LINUX_SLL のヘッダが利用される、という条件があることです。"any" は
「デバイスが複数ある場合のどれか一つ」のようなニュアンスと推測しました。
※ちゃんとした意味は不明です
収集した情報から警告の意味を分析してみる
ここで改めてどのようにコマンドを実行していたかを見てみると、
driftnet を何もオプションを付けずに実行していました。
# driftnet
Fri Jun 05 11:08:40 2020 - warning: link-level (LINUX_SLL) header is not supported
先程の調査から LINUX_SLL は「キャプチャ対象のデバイスの指定が "any"」
の時に利用される L2 プロトコルだと分かっており、警告の LINUX_SLL の
後には「このヘッダはサポートされないよ」と続いています。
これらより「キャプチャ対象のデバイスの指定が "any"」であることが
警告に繋がっており、driftnet の実行時にインターフェイスが未指定
(any っぽい雰囲気) のため「インターフェースを明示すればいける？」
という仮説が立ちました。
仮説の通りになるようコマンドを実行してみる。
driftnet のヘルプを見てみると、どうやら -i オプションで
インターフェースを指定できるようです。
# driftnet -h
driftnet, version 1.3.0
Capture images from network traffic and display them.
Synopsis: driftnet [options] [filter code]
Options:
-h Display this help message.
-v Verbose operation.
-b Beep when a new image is captured.
-i interface Select the interface on which to listen (default: all
interfaces).
このため、以下のようにコマンドを実行したところ、
想定通り警告が出力されないことが確認できました。
# driftnet -i eth0
その上で、Kali Linux のブラウザから HTTP のサイトにアクセスすると
HTTP のトラフィックから画像が抽出されることが確認できました。
また、Wifipumpkin3 のおとり AP に接続した端末からも同じサイトに
アクセスしたところ、同じように画像が抽出されることが確認できました。
これらより、driftnet でのインターフェイス未指定により libpcap が
LINUX_SLL (Linux-cooked ～) を使用したことが、警告が表示された
仕組みと考えられます。
おわりに
今回の調査の過程で Driftnet のソースの一部を読みましたが、ソースコードが
公開されているソフトウェアで警告やエラーのメッセージが出た場合、Web 上で
情報を探すほかにソースを読むこともトラブルシューティングには良い、という
気づきが得られたと思います。
私は普段の仕事は殆どプロプライエタリなソフトウェアしか取り扱っておらず、
トラブルシューティング時はベンダーのマニュアルかナレッジベースかログを
片っ端から漁ることが殆どなので、ソースコードから調べるという発想に
至った時はかなり新鮮な感覚でした。
なお、後から実行したコマンドの違いを比べてみて、自分に対して
「何でこれだけの違いにハマったし、インターフェイスの指定くらい試せ」
と思って反省はしてます o...rz
あと、最終的に LINUX_SLL ＝ Linux-cooked ～ が何をどうするものなのか
までは調べきれませんでした。暇な時に勉強も兼ねて調べようと思います。
ただ、探せばありそうなので記事にはしないと思います・・・