ksnctf #9 Digest is secure!

#Digest is secure!

https://ksnctf.sweetduet.info/problem/9

Digest is secure!：digest認証はセキュアです！

[digest認証](https://ja.wikipedia.org/wiki/Digest認証)についての問題
前回のbasic認証よりもセキュアな通信ができる。

以下がdigest認証の手順

>典型的なDigest認証におけるHTTPクライアントとHTTPサーバの間の通信を紹介する。
だいたいの流れは以下のようになる。
1. クライアントは認証が必要なページをリクエストする。しかし、通常ここではユーザ名とパスワードを送っていない。なぜならばクライアントはそのページが認証を必要とするか否かを知らないためである。
2. サーバは401レスポンスコードを返し、認証領域 (realm) や認証方式（Digest）に関する情報をクライアントに返す。このとき、ランダムな文字列（nonce）とサーバーがサポートしている qop (quality of protection) を示す引用符で囲まれた１つまたは複数のトークンも返される。
3. それを受けたクライアントは、認証領域（通常は、アクセスしているサーバやシステムなどの簡単な説明）をユーザに提示して、ユーザ名とパスワードの入力を求める。ユーザはここでキャンセルすることもできる。
4. ユーザによりユーザ名とパスワードが入力されると、クライアントはnonceとは別のランダムな文字列（cnonce）を生成する。そして、ユーザ名とパスワードとこれら2つのランダムな文字列などを使ってハッシュ文字列（response）を生成する。
5. クライアントはサーバから送られた認証に関する情報(ユーザ名, realm, nc(nonce count), nonce, cnonce, qop)とともに、responseをサーバに送信する。
6. サーバ側では、クライアントから送られてきたランダムな文字列（nonce、cnonce）などとサーバに格納されているハッシュ化されたパスワードから、正解のハッシュを計算する。
7. この計算値とクライアントから送られてきたresponseとが一致する場合は、認証が成功し、サーバはコンテンツを返す。不一致の場合は再び401レスポンスコードが返され、それによりクライアントは再びユーザにユーザ名とパスワードの入力を求める。

とりあえず問題のq9.pacpをwiresharkで見てみる。
見やすいようにhttp通信でフィルタして、httpストリームを追跡する。
![スクリーンショット 2021-07-02 16.01.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/627d0b03-5737-609b-68e9-fd786b8f65e8.png)

##httpストリームの結果
1.
![スクリーンショット 2021-07-03 15.18.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/f9eccc09-e499-1a3b-a954-f4f4725ae4f1.png)
まずクライアントが[http://ctfq.u1tramarine.blue/q9](http://ctfq.u1tramarine.blue/q9])にGETリクエストを送っている。

2.
![スクリーンショット 2021-07-03 15.25.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/85b95e7c-49cd-a3f4-112e-5b58c76b3abe.png)
素直にGETできるわけがなく、401 Unauthorized が帰ってきて認証できない。
この時にDigest認証が必要であることが書かれていて、認証に必要なrealm,nonce,algorithm,qopがサーバーから送られてくる。

3.
![スクリーンショット 2021-07-03 15.30.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/74fdad10-3a7b-9f92-2c3f-06d17d5f621d.png)
クライアントはサーバーから送られてきた認証に必要な情報（realm,nonce,algorithm,qop）と、生成したcnonceや、nc,uriの情報をもとにresponseを計算し、それらをサーバーに送信している。

4.
![スクリーンショット 2021-07-03 15.33.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/5ce2ecb0-8c78-e1d2-d483-79767a314962.png)
クライアントから送られてきたresponseの値と、サーバーで計算した正解ハッシュが一致したから、flagが書かれていると思われるflag.htmlをクライアントに送信している。


##方針
クライアントから送られてきたresponseの値と、サーバーで計算した正解ハッシュが一致すればいいので、一致するようにresponseの計算に必要な認証情報を設定することでflag.htmlを入手する。

クライアントがresponseを作るにはA1(ユーザー名,realm,パスワード),nonce,nc,cnonce,qop,A2(HTTPメソッド,コンテンツURI)が必要。
ユーザー名、realm、パスワード、qop、HTTPメソッド、コンテンツURI、は固定な値。
nonceは一番最初のGETリクエストの応答に含まれていて、毎回ランダムな値。
cnonceはクライアントが生成するものでこれも毎回ランダム値。


responseは以下のように計算する
![スクリーンショット 2021-07-02 16.41.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/bb3f17ac-db18-2dca-7b86-ec700b16a075.png)





##解く
![スクリーンショット 2021-07-03 16.07.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/01baf2af-4540-bf5e-f3a9-3014d5f2aec8.png)
この通信に注目すると、GETリクエストと送る時に、header情報として**Authorization: Digest name,realm,nonce,uri,algrithm,response,qop,nc,cnonce**を同時に送信している。
この情報を適切に設定してGETリクエストを送ればflag.htmlを入手できそうだから、まずresponseの中身を調べてみる。

httpストリームから、**response="e9654c012dc42f9f78f81a685073df98"**がわかる。これをMD5で逆変換してnonce,nc等の情報を見てみる。[このサイト](https://hashtoolkit.com/decrypt-hash/?hash=)で逆変換できる。
![スクリーンショット 2021-07-02 21.16.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/31b1bc37-1f97-a48a-9d62-aba08010b626.png)
見やすいように並べると、

|情報名|値|
|:---|:---:|--:|
|MD5(A1)|c627e19450db746b739f41b64097d449|
|nonce|HHj57RG8BQA=4714c627c5195786fc112b67eca599d675d5454b|
|nc|00000002|
|cnonce|656335d78cef6e86|
|qop|auth|
|MD5(A2)|adea3748da59405c1f4c1650442607a1|

**c627e19450db746b739f41b64097d449**はA1(ユーザー名:realm:パスワード)をMD5変換したものだから逆変換したらユーザー名、realm、パスワードがわかりそう。やってみると
![スクリーンショット 2021-07-03 15.56.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/3d9b2163-8185-0ee3-81ba-f7ab12e6df73.png)
この逆変換はできなかった。もしできたらパスワードがわかったけどそんなに甘くはない。
だけど、ユーザー名、realm、パスワードはサーバーで設定されていて変わらない情報だからMD5(A1)にc627e19450db746b739f41b64097d449を使うことができそう。逆変換はできなかったけど、Wiresharkでユーザー名=**q9**、realm=**sercet**は確認できる。

次に**adea3748da59405c1f4c1650442607a1**の逆変換をしてA2(HTTPメソッド:コンテンツURI)を調べてみる。
![スクリーンショット 2021-07-03 16.00.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/20bc601d-4166-d0a5-a17e-619440d72c65.png)
こっちは逆変換できた。httpメソッドがGETで、コンテンツURIが/q9/であることがわかった。
これらはWireSharkからも確認できた
![スクリーンショット 2021-07-03 16.03.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/174b4fdb-ae1f-12fc-2308-e3648210fb3a.png)
今回は[http://ctfq.u1tramarine.blue/q9/flag.html](http://ctfq.u1tramarine.blue/q9/flag.html])アクセスしたいから、メソッドを**GET**、コンテンツURIを**/q9/flag.htmlとして、**A2を**GET:/q9/flag.html**に変更し、これをMD5変換したものをMD5(A2)とする。変換してみると
![スクリーンショット 2021-07-03 16.23.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1182752/0fe4d888-c9bc-12e8-a829-12b1811c792f.png)
となって、MD5(A2)=**9e2b6bca5d4d92f6ead358623df264c8**と設定する。

残りのqopは**auth**で固定で、cnonce、ncはresponseの計算で使うだけのものだから適当に設定すれば良い（空白でも良い）。

nonceは最初のGETリクエストに対する応答としてサーバーから送られてくる**ランダムな値でアクセス毎に変更される**からnonceはあらかじめ設定するのではなく、応答情報から抜き取ってくる必要がある。
今回はpythonのrequestを使ってその応答情報からnonceを得た。

##実装
```python
import requests
import hashlib
from bs4 import BeautifulSoup as bs

# Authorizationヘッダ作成に用いるパラメタ
url = "http://ctfq.u1tramarine.blue/q9/flag.html"
md5a1 = "c627e19450db746b739f41b64097d449"
nonce = ""
nc = ""
cnonce = ""
qop = "auth"
a2 = "GET:/q9/flag.html"
md5a2 = "9e2b6bca5d4d92f6ead358623df264c8"
username = "q9"
realm = "secret"
algorithm = "MD5"
uri = "/q9/flag.html"

#urlにアクセスして得られた応答のheader情報(WWW-Authenticate)からnonceを抜き出す。
auth_header = requests.get(url).headers['WWW-Authenticate']
nonce = auth_header.split(" ")[2][7:-2]

# responseの計算
not_md5_response = md5a1 + ":" + nonce + ":" + nc + ":" + cnonce + ":" + qop + ":" + md5a2
md5_response = hashlib.md5(not_md5_response.encode('utf-8')).hexdigest()

#header情報の作成
#headerの形式はhttpストリームの3.に示したAuthrizationの形式に合わせる
headers  = {
        'Authorization': \
            'Digest username="' + username + '"' + ', ' + \
            'realm="' + realm + '"' + ', ' + \
            'nonce="' + nonce + '"' + ', ' + \
            'uri="' + uri + '"' + ', ' + \
            'algorithm="' + algorithm + '"' + ', ' + \
            'response="' + md5_response + '"' + ', ' + \
            'qop=' + qop + ', ' + \
            'nc=' + nc + ', ' + \
            'cnonce="' + cnonce + '"'
}

#作成したheader情報をurlに送信する
answer = requests.get(url, headers=headers)
print(answer.text)
```

#まとめ
digest認証について理解できた。
前回のBasic認証よりもセキュアな認証を行っていることがわかった。
しかし、パスワードが分からなくてもAuthrizationの情報をうまく設定すれば突破できてしまう危険性があることがわかった。