Edited at
PearDay 3

AWSセキュリティ学習サイトflaws.cloudのwriteup 中編


flaws.cloudのwriteup (Level3~Level4)

前回の記事AWSセキュリティ学習サイトflaws.cloudのwriteup 前編の続きを記載する。


Level 3

ブラウザでhttp://level3-9afd3927f195e10225021a578e6f78df.flaws.cloudを開くとLevel2の解説があり、下の方に「今回もほぼ同じだ。AWSに関するキーを探せ。他のバケットたちのリスト表示を可能にする何かを見つけるはずだ。」とある。とりあえず今まで通りバケットへアクセスしてみる。

# aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud --no-sign-request

するとアクセスに成功し、中身をみると.gitディレクトリを見つけることができる。

下のコマンドで再帰取得を可能にし、もう一度接続してみると

# aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud --no-sign-request --recursive

.git内に色々あることがわかるので、実際にファイル一覧をダウンロードしてみる。

# aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud . --no-sign-request

.git内のファイルの一覧を見ると、COMMIT_EDITMSGなる怪しいテキストファイルが見つかるので、中をみると「おっと、置くべきじゃないものを置いちまった」っとある。このヒントから“何かやらかしたが、すぐ修正したのかな”ということが推測できるのでコミットログを見てみる。

# git log

すると36秒前のコミットが確認できるので、その状態に戻してみる。

# git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61

そしてカレント内を再確認するとaccess_keys.txtが見つかり、中身をみるとAWSへのアクセスキーとシークレットキーが載っているのでaws cliのコンフィグに登録して、バケットの一覧表示をしてみる。

# aws configure --profile flaws

# aws s3 ls --profile flaws

Level4での解説にもあるがAWSへのアクセスキーの扱い方を少しでも間違えた場合は、すぐに削除して新しいアクセスキーとシークレットキーを使用するように心掛けておかないと、このようなことが実現してしまうので注意が必要。

一覧を見ると、level4-1156739cfb264ced6de514971a4bef68.flaws.cloudというバケットの存在が確認できるのでブラウザで確認しLevel4へ進む。


Level 4

http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/を開くとLevel3の解説があり、

下の方に「次のレベルではEC2で動作しているこのサイトへのアクセスが必要になる。またNginxが動作しているEC2のスナップショットが役に立つ。」とある。そこでとりあえずAWSアカウントの情報を取得してみる。

# aws sts get-caller-identity (get-caller-identityはAPIの呼び出しを行ったIAM情報を返すサブコマンド。)

するとbackupというユーザーが見つかる。

ヒントにEC2、snapshot、nginxの文字があるので次にEC2情報も取得してみる。

# aws ec2 describe-instances --profile flaws --region us-west-2

するとec2-35-165-182-7.us-west-2.compute.amazonaws.comというパブリックアクセスが可能なインスタンスが1つ見つかり、これをブラウザで開くとLevel4の問題中にもある4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudと同じBasic認証の画面が表示される。

ついでにこのサブドメについてのDNS情報を探ると両者はCNAMEレコードにより同じサーバーに向いており、そのサーバーのアドレスは35.165.182.7であることが分かる。

# dig any 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud

# dig ec2-35-165-182-7.us-west-2.compute.amazonaws.com

次に得られたインスタンスの情報内にEBSの情報があるのでVolumeIdからスナップショットの情報を探ると

# aws ec2 describe-snapshots --profile flaws --filters "Name=volume-id, Values=vol-04f1c039bc13ea950" --region us-west-2

指定したボリュームのスナップショットに関する詳細情報が取得できる。そしてこのスナップショットが復元できるかを下のコマンドで確認すると

# aws ec2 describe-snapshot-attribute --profile flaws --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --region us-west-2

CreateVolumePermissions内のGroupキーの値がallになっており、これにより誰もがこのスナップショットからボリュームを作成できてしまうことが分かる。上の方で用意した自分のAWSアカウントを利用してボリュームを作成してみる。

# aws ec2 create-volume --availability-zone us-west-2a --snapshot-id snap-0b49342abd1bdcb89 --region us-west-2

あとは既存のものなり新しく用意するなりしたEC2インスタンスに、awscliなりAWS管理画面なりからボリュームをアタッチする。その後そのインスタンスにssh接続して利用可能なデバイスを確認してみる。

# lsblk

すると先ほどのアタッチによりxvdfがブロックデバイスとして認識されており、どこにもマウントされていないパーティションxvdf1(環境による)が作成されていることが分かる。

パーティションxvdf1の情報を見ると既にファイルシステムなどが作成されていることが確認できる。

# file -s /dev/xvdf1 (※ブロックデバイス名は環境によって名前が異なるので注意)

マウントする。

# sudo mkdir /mnt/flaws

# sudo mount /dev/xvdf1 /mnt/flaws

ヒントにあったように4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudではNginxが動作しており、Basic認証をしていることからnginxの置き場を調べてみる。

/etc/nginxや、/usr/local/nginxや、/opt/nginxなど人によって置き場は異なるが、パッケージインストールをしている場合はデフォルトで/etc/nginxにインストールされるし、大抵はここにある。

一応検索。

# sudo find /mnt/flaws -type d -name nginx

やはりNginxは/mnt/flaws/etc以下にある。次にBasic認証に使用されていると思われる.htpasswdを探してみる。

# sudo find /mnt/flaws -type f -name .htpasswd

すると/etc/nginx以下に置かれていることが分かる。これも大抵の場合はここにあることが多い。

中身を確認するとユーザー名と暗号化されてたパスワードが見つかる。JohnTheRipper等でパスワードクラックを試みても良いが、マウント先のディレクトリ以下をうろうろしてみたところ、

/mnt/flaws/home/ubuntu以下にsetupNginx.shなるファイルを見つけたので中身を見るとユーザー名:flawsとパスワード:nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M(やっぱハッシュのブルートフォース対策されていた。。)が見つかったので4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudを開くとhttp://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/というURIが記載されているのでそのままLevel5へ進む。

他のサイトのリファレンスを見ると、home以下の.bash_historyを確認してsetupNginx.shに辿り着いている方もいた(なるほど、賢い☘)。Level4のようなハッキングが成功してしまう原因はAWS EBSのスナップショットへのアクセス制限に問題があるからであり、デフォルトではスナップショットはプライベートアクセスになっている。これをパブリックにする場合はかなり注意が必要になる。権限の確認はEC2管理画面の[スナップショット]項目の[アクション]から行える。


Level 5 ~ Level 6

AWSセキュリティ学習サイトflaws.cloudのwriteup 後編