MTK is a place to share data forensic tips learned throughout the course of loud keyboard banging.
PGP Key http://bit.ly/UckgPW

Tuesday, April 28, 2015

Acquiring an Image of an Amazon EC2 Linux Instance

As
cloud services continue gaining popularity and become more affordable, more
people are learning about what is available and are increasingly opting-in to
the idea of having computers in the cloud.
This became evident during a recent conversation with my old friend JJ,
@jxor2378. I called JJ to get his
opinion on what an ideal password cracking rig would be? Without hesitation, JJ answered, “Why would
you invest in buying the hardware, when you can just rent it!” And he was right, for what I needed, using
cloud computing services was in fact a good match for me.

It
is not like I didn't know about the concept of cloud computing, it was just
simply that because I hadn't had a need for it, I hadn't taken the time to do
my computing in the cloud just yet. By
that afternoon that changed. JJ
recommended that I play with Amazon's Elastic Compute Cloud, also known as
their EC2 service.

Paraphrased
from their website, http://aws.amazon.com/ec2/.
Amazon's EC2 is a service that provides resizable compute capacity,
designed to make cloud computing easier.
The web service interface allows you to obtain and configure capacity
with minimal friction, and complete control of your computing resources. You can quickly scale capacity, both up and
down, as your computing requirements change, and you only pay for capacity that
you actually use.

That
last line is the neat thing about the service.
You only pay for what you use, and they even offer you a chance to try
their service for free. It only took a
few minutes to get an instance up and running.
Once I had access to the instance, I couldn't help but wonder how I
would go about analyzing it for forensic artifacts.

In
this article we are going to go over the steps of how to acquire an image of a
Linux Ubuntu Server Amazon EC2 Instance.
For the purposes of this article I used a Live Linux Distribution of
LosBuntu. LosBuntu is our own Ubuntu
14.04 distribution that can be downloaded here.

Installing
the Tools:

The
tools that we will be using during the process are ssh, dd and netcat. All of these tools come preinstalled in the
Live version of LosBuntu, so there is no need to install anything else.

The
Plan:

The
plan is to go fire up an EC2 instance, remotely log-in to the instance and then
go through the steps of acquiring an image of the instance back to a remote
location of your choice. Let's get
started

The
Test:

To
set up your instance, you can use your current amazon username and password to
log in to aws.amazon.com. Once authenticated, navigate to the EC2
dashboard and click on create instance.
The instance that we will use for the test is the Ubuntu Server 14.04
LTS t2.micro instance that you can try for free.

For
added security purposes we created a public/private key pair that can be used
to securely SSH into the instance. Using
a key to SSH into a system offers a bit more security than a username and
password combination alone. I named the
key ec2key and downloaded the key.

Once
you have downloaded the key, simply launch the instance with all of the
defaults. The service shines due to the
amount of customization that you can do to your instance, but that is beyond
the scope of this article. For now, all
defaults will work.

Once
you have your instance running, locate the “Connect” icon and click it.

A
set of instructions on how to connect will appear on your screen, including the
username and public IP address of the instance.

That's
it. That is all the information that is
needed to SSH into the instance. We
now have the information that we need, so let’s take care of some final
things. For the command on the
screenshot to work, you will need to make sure that, if your key is not in your
current working directory, you will need to provide the path to it. Also, the permissions of the key must be set
so no other users or groups can read it, the command $ sudo chmod 400 yourkey.pem
will take care of that requirement.

Now
type the below command to SSH into the server.
SSH is the remote login tool that will establish a secure encrypted connection
to the server, the “-i” is the option that points SSH to your identity file
(key), ubuntu is the username and @51.11.255.55 is the public IP of the instance. Remember to change the key to the name that
you provided and use the IP of your instance.

$ ssh -i ec2key.pem ubuntu@52.11.255.55

We
are now logged-on to the EC2 instance.
From here you can remotely control the system and do whatever it is that
you intent to do with it. The
possibilities are endless, but there is one caveat... Since we set up the instance for remote
access using a key, anytime that we want to access the instance we are going to
have to pass it this key so that access can be granted. This means that if you, for example, want to
use Remote Desktop Protocol (RDP) to get a GUI on your screen, you may have to
do it by authenticating to the instance first using an SSH tunnel.

Which
is exactly what we are going to do to acquire the image of this instance. We are going to establish a second SSH
connection to a second remote server a pass the entire contents of the
instance's hard drive through an SSH tunnel.
This process can be accomplished by standing up a second EC2 instance
with enough space to store your image, or you can use an already publicly
accessible existing server that you control.

If
you read the article titled “Analyzing Plain Text Log Files Using Linux Ubuntu”
then you may know that I like to run a publicly accessible server to transfer
data and serve files. So I took
advantage of the SSH access to this server that I control, and authenticated
back into it from the EC2 instance using an SSH tunnel.

The
SSH tunnel consists of an encrypted tunnel created through the SSH protocol
connection that can be used to transfer unencrypted traffic over the network
through an encrypted channel. The
purpose here is to use the SSH tunnel to securely transfer the entire contents
of the hard drive using DD and Netcat through the tunnel, even though Netcat
itself does not use encryption. All of
the contents of the drive from the EC2 instance will travel encrypted through
the tunnel back to my forensic machine in my lab.

You
do not need to go through the trouble of setting up a public server for
this. A second EC2 instance will also
work, but you will then have to transfer the now acquired image back to you. Accessing a server that you control kills two
birds with one stone.

Using
its own terminal window on the EC2 instance, type the below command set up the
SSH tunnel back to your server. SSH is
the command -p 5678 is to tell SSH to use a non-default port to connect to the
server you control, -N is used so SSH does not execute any remote commands,
which is useful when just forwarding ports, -L is to specify the port on the
local host that is to be forwarded to the given host and port on the remote
side. Secretuser is the user on my
server and 432.123.456.1 is the public IP of the server is that will be
receiving the data.

$ ssh -p 5678 -N -L
4444:127.0.0.1:4444 secretuser@432.123.456.1

secretuser@432.123.456.1's
password:

If
everything went well and you entered the password correctly, this shell window
is simply going to hang and will not show any output. From this point forward, any data that is
sent to localhost on port 4444 is going to be redirected to the server back in
my lab.

On
that server you will now need to set up a netcat listening session with the
below command. Nc is the netcat command,
-l is to listen, -p is the port to listen on, and we are piping that data to pv
and redirecting it to a file titled ec2image.dd. Pv is a neat utility that will measure the
data that is passed through the pipe. A
visual of what data is coming in, helps in determining if things are going
according to plan.

$ nc -l -p 4444 | pv
> ec2image.dd

Finally,
on the EC2 instance run dd to image the instance’s hard drive and pipe it to
netcat using the below command. Remember
that you are piping to netcat on localhost to port 4444.

$ sudo dd if=/dev/xvda
bs=4k | nc -w 3 127.0.0.1 4444

This is an illustration of how the data should flow.

# Image courtesy of Freddy Chid @fchidsey0144

After
about 30 minutes it had sent over 4GB of data to my server located many states
away from the EC2 instance.

$ nc -l -p 4444 | pv
> ec2image.dd

4.39GB 0:32:28
[2.51MB/s] [ <=> ]

It
finished in less than an hour and transferred the entire 8GB (default)
bit-by-bit image of the hard drive from the instance.

$ nc -l -p 4444 | pv
> ec2image.dd

8GB 0:57:30 [2.37MB/s]
[
<=> ]

Speeds
will vary depending on bandwidth. In
reference to image verification, since this was a live acquisition, doing a
hash comparison at this point will not be of much value. At the very least, check and compare that the
size of your dd image matches the amount of bytes contained in /dev/xvda from
the instance. This can be accomplished
by comparing the output of fdisk -l /dev/svda against the size of the acquired
dd.

We
have a match. And there you have
it. You have acquired an image of an
Ubuntu 14.04 Server running on Amazon EC2.

Conclusion:

Amazon
offers a full set of developer API tools for EC2 that might offer an easier way
of accomplishing this task. If in a
pinch, and if you have an evening to spare, know that at least you have this
option available to get the job done. If
this procedure helped your investigation, we would like to hear from you. You can leave a comment or reach me on
twitter: @carlos_cajigas