ぴよこのーと

ぴよぴよな技術者のノートです(´・ω・`)

CTF for Girlsの第7回ワークショップに参加しました WriteUp②

今回は初級問題2の復習をします。

2_[初級問題2]

flagのパスワードを見つけ出せるかな?

今度もpcapngファイルが与えられるので、Wiresharkで開き、中身を確認します。

192.168.32.128と192.168.32.129の通信のようです。
No.8のパケットでクライアント(192.168.32.128)がHTTP GETリクエストを投げましたが、
No.10のパケットでWebサーバ(192.168.32.129)からHTTP 401Unauthorized(このリソースのアクセスには適切な認証が必要)が返ってきて失敗していることがわかります。

f:id:ukri021:20170624183356j:plain

ここでステータスコード401Unauthorizedは、認証に失敗したことを示すエラーコードです。
WWW-Authenticateヘッダにより、サーバが提供する認証方式を知ることができます。

Packet Detailsペインで、レスポンスの詳細を確認してみます。
このサーバは、Basic認証をサポートしていることがわかります。
ちなみに「relm」はサーバ上でこのリソースが属しているURL空間の名前だそうです。

f:id:ukri021:20170624193843j:plain

Basic認証

Basic認証は、ユーザ名とパスワードによる認証方式です。
ユーザ名とパスワードは、Authorizationヘッダに入れてリクエストごとに送信します。
Authorizationヘッダの内容は、認証方式(Basic)に続けてユーザ名とパスワードを「:」で連結しBase64エンコードした文字列です。
ちなみに、Base64エンコーディングは、簡単にデコード可能です。
つまり、ユーザ名とパスワードが平文でネットワーク上を流れているのと同じなので、Basic認証を使う場合には、それが許される程度のセキュリティ強度でよいのか、SSL/TLS通信にし通信路上で暗号化するのかを検討する必要があります。

【参考】
www.amazon.co.jp


さらにみていくと、2回目のリクエストで、Http 200OKが返ってきていることがわかります。
f:id:ukri021:20170624200056j:plain
認証情報を入力して、認証を突破したのでしょうか?
中身を見てみると、Authorizationヘッダの中に認証方式(Basic)に続けて、Base64エンコードされた文字列が入っていることがわかります。
f:id:ukri021:20170624200104j:plain

デコードは、Wiresharkがしてくれています。
ユーザ名「flag」のパスワードが答えでした(*'▽'*)
f:id:ukri021:20170624201044j:plain


ちなみに、セッションを確認したいパケットの上で右クリック→「追跡」→「TCPストリーム」を選択すると、コネクション切断までの通信ログを表示することができます。
また、必ずしもセッションの最初のパケットを指定しなくても大丈夫です。
どれか1つのパケットを指定すれば、同じIPアドレスTCPポートを持つパケットが自動的に抽出されます。
複数のセッションが存在する場合には、セッション毎に表示してくれます。
f:id:ukri021:20170624214202j:plain
f:id:ukri021:20170624203329j:plain