この記事はCTFのWebセキュリティ Advent Calendar 2021の3日目の記事です。
本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。
Cookie
- サーバ間でユーザー情報を管理するためにCookieやSessionが利用される
- Cookieの属性
- SameSite
- Jason - Angstrom CTF 2021 | bi0s
- 属性をインジェクションしてbypassする
- Jason - Angstrom CTF 2021 | bi0s
- SameSite
- TCP/IPを理解している人ほど間違いやすい 常時SSLでもCookieのSecure属性が必要な理由 - YouTube
- テク
Authentication/Authorization
- 認証と認可は違うので注意
- IDOR
- 認可確認不足があり、とあるリソースを見れてはいけない人が見れてしまう状態になっていること
- CTFでよくあるのはSQLiteのDBファイルが見れてしまったり、ログファイルが見れてしまったりする
- 例外のダンプはIDORに入るんだろうか？misconfigurationと言えばそうなのだが、IDORとも言えるのか？
Basic認証まわり
JWT
- JSONをベースとしたトークン
- より細かくはRFCを読むほうがいい
- JOSE: Javascript Object Signing and Encryption
- JWT, JWS, JWEなどを定義している規格群
- JOSEへの批判について JSON Web Encryption (JWE) の解説 - Qiita
- JWTはJWSかJWEを使うことができる
- 署名付きデータの場合はJWS
- 暗号化する場合はJWE
- とりあえずJWTの中身を見るときはJSON Web Tokens - jwt.ioを使っている人が多いイメージ。単なるbase64なのでデコードして読んでも良い
- 攻撃方法
- アルゴリズムをnoneにすることで検証を回避する - JWTの署名アルゴリズムをnoneにすることで、署名アルゴリズムをトークンから取得するような実装をしているサービスで検証を回避できる。pyjwtを使って、生成するのが簡単。 - `eyXXXXXXXXXXXXXXX.eyXXXXXXXXXXXXX.`みたいなのを最終的に投げる - [CTFtime.org / H@cktivityCon 2021 CTF / SpiralCI](https://ctftime.org/task/17330)- 鍵をパスワードクラックみたいなことをして調べる（HMAC キー）
- ただのパスワードクラック。JWTは生データと署名後データがセットになっているので、ローカルでクラック作業ができてしまう。 HMACアルゴリズムで、簡単なパスワードを使っていると、クラックされる。
- CTFtime.org / BlueHens CTF 2021 / speedrun-3
- RS256での署名時にHS256に変換して署名をする
- RS256で署名されていて、公開鍵が分かっているとする。この状況では、署名アルゴリズムをHS256に変更して署名をかいくぐることができる可能性がある
- Web 200: File Rover 'JWT' CTF Challenge
- Abusing JWT public keys without the public key – Silent Signal Techblog
- RS256で署名されているときに公開鍵を求めることができる方法（再署名可能な方法かもしれない）
- rsa_sign2n/CVE-2017-11424 at release · silentsignal/rsa_sign2n · GitHub
x_CVE-2017-11424.py [jwt1] [jwt2]として使う- 2つ候補が出てくるので、Tampered JWTを使って認証をすり抜けらえるか確認する
- 任意のpayloadに変えて使いたいときは、x_CVE-2017-11424.pyのpayload_encodedへの代入のpayloadを
{"user":"admin"}みたいに変えてやればいい - するとTempered JWTに変更後のJWTが出てくるので使える
- jwks spoofing (jwk&x5u)
- 署名を検証するためのurlを適当に改ざんして署名方法を操る方法
- jkuのOrigin検証をしている場合でもOpenRedirectやRFIみたいなものがあればbypass可能
- JWT jku&x5u = ❤️ by @snyff #NahamCon2020 - YouTube
- CTFtime.org / BsidesBOS CTF / skid / Writeup
- 参考ブログ
- 署名を検証するためのurlを適当に改ざんして署名方法を操る方法
- kid path traversal
- JWTにkidという開発者が自由に書けるプロパティがあるが、kidを元にトークンの検証を行う場合に実装依存の脆弱性が入り込むことがある。 ざっくり言うと、kidを元に検証用の秘密鍵を取ってきている場合、悪意のあるkidを指定すると任意の秘密鍵での検証をサーバ側に強制させられる。 kidの値をどのように使っているかで以下のような攻撃を仕掛けられる。
- directory (path) traversal
/dev/nullとすれば、鍵として何も帰ってこないので、署名なしを強制できる。header.payloadで送ればいい- NahamconCTF-B’omarr Style - HackMD
/proc/sys/kernel/randomize_va_spaceを使っている解法もある- 試してないけど、
0\n,1\n,2\nのどれかが定数で帰ってくる（普通は2\n？）
- 試してないけど、
- SQL injection
- CTFtime.org / BsidesBOS CTF / skid
- kidに
'やら"やらを入れてみてエラーが出ないか確認 "kid": "' union select 'a','a','a"こんな感じにして、HS256の秘密鍵をaにしてやれば認証を突破できる
- もしかしたらpublicで参照できる場所に無いか？
[kid].jsonとか[kid]とかで直接アクセス試行してみる- CTFtime.org / BsidesBOS CTF / skid / Writeup
- kidに自分で作ったprivateキーを入れて読み込ませるスクリプト(HackTheBoxのTheNotebook)
- 複数個指定することで検証と使用される実データを分けることで検証bypass
- 鍵をパスワードクラックみたいなことをして調べる（HMAC キー）
- 他
- 先頭が.から始まっている場合は圧縮されているかも
OAuth
- CTFではあまり出てこないが、バグバウンティだとかなり攻撃される
- 安全対策
- stateによるCSRF対策は必須で行う
- 認可コード
- 漏洩のリスクを軽減するため失効するまでの時間を短くしておく
- 使い捨てのコードなので1度利用されたら無効化すること
- PKCE ピクシー
- 認可コードが横取りされるとそれを使ってアクセストークンが発行されてしまうことを防ぐ仕様
- RFC7636
- 認可エンドポイントへのリクエスト時に、code_challenge, code_challenge_methodを送る（認可サーバ側はこれを保存しておく）
- トークンエンドポイントへのリクエスト時に、code_verifilerを送る（保存しておいたcode_challenge, code_challenge_methodを使って検証する）
- 例えばcode_challenge_methodをS256と指定したときは、
BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))==code_challengeとなるかを判定する - code_verifierを送るのは、サーバ上にハッシュ化されたものだけを置く目的
- 例えばcode_challenge_methodをS256と指定したときは、
- Advanced OAuth 2.0
- Implicit Grantまわりですでに問題が出ているOAuth2の後釜の話もある
- OAuth 2.1
- GNAP
- Open ID Connect
- HolyTips/OAuth.md at main · HolyBugx/HolyTips
- 攻撃
- CTF
- CTFtime.org / HacktivityCon CTF / Note Surfer
- ログインしようとしたら、
http://one.jh2i.com:50020/oauth/authorize?response_type=code&client_id=QJ7Bo88ZBioNTZSXTOJrMYDx&redirect_uri=http%3A%2F%2Fthree.jh2i.com%3A50039%2Foauth%2Fsignin_callback&scope=profile&state=7HBwKRgWyDgqfIEJmpU6suYVLxKAAF&action=signinみたいなリクエストが来る - リクエストのシーケンスを眺めていると、
http://one.jh2i.com:50039/oauth/signin_callback?code=Z0QosnS68dCvV7YN6ir32YqcOId0iM1XTuenkMb4HQwR0rYC&state=XXXXXというリクエストが来るので、これを送らず中断する - 攻撃相手に代わりにこれを踏ませる
http://one.jh2i.com:50039/oauth/signin_callback?code=Z0QosnS68dCvV7YN6ir32YqcOId0iM1XTuenkMb4HQwR0rYC- 対策で置いているstateパラメタを試しに消してみるのが重要（不適切な実装だと使ってない）
- あとは、攻撃者のアカウントでログインして、sensitive情報を抜き取る
- ログインしようとしたら、
- CTFtime.org / HacktivityCon CTF / Note Surfer
- hackerone
- CSRF対策がないので、自分でアカウント結合用のURLをredirectでもらったら、被害者にそれを踏ませてAccount Takeover
- リダイレクトを悪意あるサイトにすることでトークンを奪取し、CSRFトークンもないため、自分の認証過程の最後に奪ったトークンを利用することで乗っ取る
- 認証後のリダイレクトを悪意のサイトにすることができ、トークンを奪える
- リダイレクト部分でjavascript:が動く
- リダイレクト後にXSS発動するようにしてトークンを盗む
- リダイレクトのホワイトリストバイパス -> redirect.md
- ワンタイムトークン（たぶん）をjsが発行して、それを利用してリクエストを発行しているようなシステムの場合に、そのjsを取り込むことでCSRFをbypassできる
- 完璧に理解してないやつ
- #202781 Chained Bugs to Leak Victim's Uber's FB Oauth Token
- 2回リダイレクトするとトークンを盗める
- #202781 Chained Bugs to Leak Victim's Uber's FB Oauth Token
- リダイレクトに自分のサイトのオープンリダイレクト脆弱性のあるURLを踏ませることでリダイレクトドメインチェックをbypassして、認証トークンを盗む
- 連携先のサービスにXSSがあった場合に攻撃が成立するという問題
MFA/TOTP/TOTP
OTP
- OTP: ログイン時にワンタイムなパスワードも併用することでMFAを実現する
- TOTP: Time-based One Time Password 時間ベース
- プロトコル的には特定の時間内なら何度でも利用できることになる（再送攻撃対策が無ければ）
- HOTP: HMAC-based One-Time Password カウンターベース
- TOTP: Time-based One Time Password 時間ベース
- 攻撃方法
TOTP
- 秘密鍵だけを共有して、二者間でトークンの生成と検証を行う
- 手順
- クライアントサイドとサーバサイドは完全に独立しているので、秘密鍵と時間だけを使ってOTP認証を実現する
- 秘密鍵からトークンを発行する
- TOTP Generator
oathtool --base32 --totp <SECRET>- otpauth://のsecretを入れる
- otpauth://totp/[ユーザー名]?secret=[秘密鍵]&issuer=[発行者]
- &issuerは任意
- できる対策/注意点
SMS
- SMSは盗聴可能（米国・中国・欧州）
- ASP.NET Core での SMS による2要素認証 | Microsoft Docs
- ここを見ると、SMSを使用したMFAは既知の攻撃ベクトルが大きすぎるから非推奨となっている
- NIST Special Publication 800-63Bを参照
WebAuthn
- FIDO Allianceという認証機能のプロバイダーが提唱している規格
- FIDO: Fast IDentity Online
- 生体認証を簡単に利用できる
- 生体情報がネットワーク上を流れない
- 端末で処理して認証サーバから受け取ったチャレンジに応答するだけ
IDOR: Insecure Direct Object Reference
- アクセスできるべきではない部分にアクセスできてしまう脆弱性
- 見えてしまうもの
- 認証しないと見れないページがURL推測で見れてしまう
- API化しても見れたりしてしまう
- DBファイルとか設定ファイルをURLで直接指定すると見えてしまう
- 認証しないと見れないページがURL推測で見れてしまう
- GETリクエストではアクセスできなくなっていてもPOSTだとアクセスできる場合がある
- #964315 Admin/Info lekage
- 管理ページが他の人でも見れる状態になってますよという指摘
- Evan Ricafort | Blog: Changing other users Episode title & description - IDOR Vulnerability in [REDACTED] (Write Up)
- リクエストにuser_idが含まれる場合、それを変更することで別ユーザーの情報を書き換えることができる。書き換えIDOR
- IDOR: Attack vectors, exploitation, bypasses and chains
- vimのswp（スワップ）ファイルのセキュリティリスクが話題に | うざ夫のうざブログ
- 修正途中にクラッシュとかすると一時ファイルが残る場合があって、それが不意に公開されていたりする
- vimだと、XXX.extというファイルだと、XXX.ext.swpというファイルが一時ファイルとして作られる
- HowToHunt/IDOR.md at master · KathanP19/HowToHunt
