パケットキャプチャ術で秘密もちょっぴりこぼれた？：セキュリティ・ダークナイト（4）（5/5 ページ）

Wiresharkのコマンドライン版「tshark」で知る、平文通信の危険性。膨大なログから狙った1行を検索するテクニック、身をもって体験せよ！（編集部）

[辻 伸弘（ソフトバンク・テクノロジー株式会社），＠IT]

解答編――たった1つのリクエストを見つけるまでのステップ

　それでは、解説編だ。ひとまずパケットファイルを読み出してみよう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　2500弱のパケットを見ることができだろう。眺めているとたくさんのSYNパケットの中に同じディレクトリにアクセスするHTTP通信が見つかる。これらが認証を含んでいる可能性が高いと推測できるため以下のフィルタを行ってみよう。

図16　“http.authorization”で検索してみる

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

もしくは

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

を実行する。27行のフィルタ結果が表示されただろう。しかし、正しい認証情報は1つである。26行は正しくない認証だ。

　さて、HTTPで認証を行った際にはどのようなメッセージ（レスポンスコード）が返ってくるだろうか。認証に成功したときと失敗したときの際を考えてほしい。認証に失敗した場合には、はじめのリクエストの際に返された401（Authorization Required）のみで、成功した際には、200（OK）を返してくる（サイトの構造やサーバの設定により200ではない場合もある）。

　問題から正しい認証情報は1つという前提があるため、以下のように200のレスポンスコードをマッチさせるフィルタ条件を記述し、実行してみよう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　上記のようにフィルタを実行すると、2つのパケットが表示されるだろう。

図17　200のレスポンスコードを持つ行を検索する

　いままでのフィルタ内容から見てみると、レスポンスコードを返しているIPアドレスを見れば、2355番（フレームナンバー）が認証を行っているサーバが返したレスポンスコードであることは分かるだろう。

　いうまでもないかもしれないが、このパケットは、サーバが返したレスポンスであるので、認証後の反応であるため認証情報は含まれていない。しかし、認証後の反応であるということからこのパケットの直前に、認証情報を含むリクエストがあるということは容易に推測できるだろう。

　念のため、フレームナンバーを10個さかのぼり、リクエストを送信しているクライアント（192.168.0.31）に絞ってフィルタを行ってみよう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

図18 直前のパケットをフィルタリングする

　200を返していた2355番の直前、2354番にリクエストが存在していることが分かるだろう。このパケットの内容の詳細を見てみよう。「-V」を利用する。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

表示された内容の後半に ひときわ 目を引く文字列があったのではないだろうか。

図19　該当のパケットを詳細表示する

　「Authorization: Basic」に続き文字列が記述されている。これは、ID:PASSWORDの形式をBase64でエンコードした文字列である。そして、そのデコードを行ったものがその下の行にある「Credentials:」に続く文字列である。

　つまり、問題の答えは、IDが、「ntsvji」、パスワードは、「D@rkkkn18h7」ということになるのである。

---

　さて、導入から応用まで少々駆け足に紹介したわけだが、少しは頭の体操、そして、気分転換になっただろうか。

　また、出題した問題で、平文通信の危険性を感じ取ってもらえたと思う。IDやパスワードに代表されるセンシティブなデータは、平文通信してはいけない。Telnet、FTPなんてもってのほかだ――といったことは筆者に言われるまでもなく、読者の方は理解しているだろう。

　しかし、いろいろな方と仕事を通じて話をしていると、平文通信の危険性を目の当たりにしていない人が多いのも事実だ。机上だけではなく、できる限り実際に触れてみてその危険性を感じとってほしい。そこから学び取れることはたくさんあり、厚み、深みのあることだと筆者は考えている。これは新人に限ったことではないが、手を動かし、自分の目で見ることに貪欲にチャレンジしてほしい。

　筆者は、ペネトレーションテストがしたくて上京し、いまもそれを仕事にさせていただいている。筆者の初仕事はIDS関連だった。そこで、さまざまなパケットを見て、分析することで、「生の攻撃手法」に触れることができ、非常に勉強になったと思っている。表層的な挙動だけでは分からないことも、パケットを見ることで瞬時に解決に向かうといった場面にも数々遭遇している。

　本記事によって、皆さんが遭遇するであろう問題への解決手法の1つとして、「パケットキャプチャ」が加われば幸いである。

筆者紹介

NTTデータ・セキュリティ株式会社

辻　伸弘（つじ　のぶひろ）

セキュリティエンジニアとして、主にペネトレーション検査などに従事している。

民間企業、官公庁問わず多くの検査実績を持つ。

自宅では、趣味としてのハニーポットの運用、IDSによる監視などを行っている。

▼辻氏のブログ「(n)」：　http://n.pentest.jp/

▼辻氏のTwitter：　http://twitter.com/ntsuji

「次回」へ