VNC Over AWS

If you followed the instructions from the last post, you have a Kali instance running in AWS. The problem is that you are limited to SSH access, which is the management protocol allowed by default through the AWS security groups. You really want to be able to get GUI access so you can run the pretty tools. Well, there are a couple of ways to do that. One way is a bit more complicated, though it doesn’t involve adding rules to your security group. It requires that you install an X server on your local desktop and then turn on X11 forwarding through your SSH session. If you are using PuTTY, this is fairly simple. Getting an X-server isn’t very complex. Xming works pretty well, though there are others. Ideally, if you enable X forwarding, your display host will be set to your X server on your local system so any program that requires a screen, keyboard and mouse will be thrown back to your X server and displayed on your local system. While I’ve used this approach for … well, decades … I find it’s not foolproof. Sometimes the variable doesn’t get set and often pushing X-based programs back through an SSH session can be just plain clunky. So, we’ll try another approach. 

This will be fairly easy and straightforward, as well, though it does require altering the security group in AWS to allow a port through to your Kali instance. The first thing you want to do, though, is to open an SSH session to your Kali instance. Once you are there, run sudo vi /etc/init.d/vncserver to create a script that will be used to start the VNC server at boot that we are going to be using. Once you have vi running (you need to use sudo because you are editing in a directory where you need to have administrative privileges), paste in the following code:

#!/bin/sh
### BEGIN INIT INFO
# Provides: vncserver
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start VNC Server at boot time
# Description: Start VNC Server at boot time.
### END INIT INFO

USER=root
HOME=/root

export USER HOME

case "$1" in
start)
echo "Starting VNC Server"
#Insert your favoured settings for a VNC session
/usr/bin/vncserver :0 -geometry 1280x800 -depth 16 -pixelformat rgb565
;;

stop)
echo "Stopping VNC Server"
/usr/bin/vncserver -kill :0
;;

*)
echo "Usage: /etc/init.d/vncserver {start|stop}"
exit 1
;;
esac

exit 0

Kali Linux uses the newer systemd startup process, though you can still use init scripts with Kali. Once you have the script created (use ‘I’ to insert, then paste the code using Ctrl-V as you normally would, then hit ESC followed by ‘:wq’ to get the text entered and saved — skip the ‘ characters when typing), we need to make sure that Kali uses it when the system boots. In order to do that, run the following:

ec2-user@kali:~$ sudo chmod 755 /etc/init.d/vncserver
ec2-user@kali:~$ sudo update-rc.d vncserver defaults
ec2-user@kali:~$ sudo /etc/init.d/vncserver start

Your Kali instance will add the service as a startup script in the default run levels, which is all we need to do. When you start the VNC server for the first time, you will be asked to set a password. This is a password you will be asked to enter when you connect to the VNC server, so it’s a minimal amount of security to keep unauthorized users out. The last thing to do is allow the VNC traffic through the security group, which is essentially a firewall where you create rules for traffic control. We need to allow TCP port 5900 in. Below, you can see what those rules look like. From the left hand side of the AWS portal, go to Security Groups. You should see one where the Group Name says something that includes Kali Linux. Right-click on that and select Edit Inbound Rules. Once you are there, you can add the rule just the way it’s shown below.

If you happen to know the public IP that you are using through your ISP, you can enter that into the Source field but don’t go too crazy or you’ll just end up locking yourself out. If your IP address changes, you will need to change it here to allow yourself VNC access. Once you have saved it, it becomes active. There is nothing further to do.

All you need to do now is to start a VNC client to connect to your server. There are a number of clients, including Screen Sharing on a macOS system. On Windows, you can use the RealVNC client as a reasonably good application to connect to VNC servers. You will be asked for the password you created when you started the VNC server when you are configuring the settings. You will also need the public IP address. When you go to the AWS portal and select your running Kali instance, at the bottom, you will see two lines. One is for the Public DNS (IPv4) and the other is IPv4 Public IP. You can use either of those. Both will likely change when you shut down and start up your Kali instance. Use either the hostname (DNS name) or the IP address and the password you created then connect to your VNC server. You will be presented with a desktop running XFCE, so it doesn’t look like the same desktop as if you were running it locally in a VM. However, it is still a fully functional instance of Kali with the desktop and access to all the applications. 

 

Chasing Data Using Sleuth Kit

Working on a new set of videos for O'Reilly Media -- basically updating one of the first video titles from back when it was Infinite Skills. In the process, I had to refresh my memory on a number of things. One of them was using The Sleuth Kit tools to run through a disk image to locate the contents of a file. Sure, you could just pop it open in a browser using some commercial tool but where's the fun in that? Autopsy you say? Yeah, but ultimately, Autopsy uses The Sleuth Kit tools to begin with even if you don't see it. Why not just learn what it is that Autopsy does so you can be ahead of the game? Having said that, let's step through how you might go about this.

We're going to be working with a disk image taken from a Linux system and the partition on the disk was formatted with ext4. However, the same steps will work for a Windows disk, particularly if the partition was formatted with NTFS. Since we have a disk image and not a partition image, the first thing we need to do is determine where the partition actually starts. In order to do that, we are going to use the program mmls, which lists all of the partitions in a disk or disk image. We could also use fdisk -l to do essentially the same thing.

What we discover here is that the partition we are looking for starts at byte 2048. The other Sleuth Kit tools we will be using will need to be told what offset to start at because they are really looking for the start of the partition in order to parse the data structures that begin there. Once we know where the partition starts, we can get a list of the files that are in the partition. For this, I'm just going to get a list of active files and not worry about doing a recursive listing down through all the directories (adding a -r). We also aren't going to deleted files (adding a -d). For our purposes, it doesn't much matter whether we have those or not. We are going to use fls and we need to add a -o 2048 to indicate that the offset to where the partition starts is 2048 bytes.

We now have a listing of the small number of files that are in the root directory of this partition. What we get from this listing is whether the entry is a directory (d/d) or a regular file (r/r). The second column is the inode where the metadata for the file is located. The metadata for the file not only includes date information but also, more importantly, the data blocks that belong to the file. Those data blocks are where can get access to the contents of the file. In order to get the data blocks, we are going to use the program istat. This will give us all of the information that the inode has related to the file. Keep in mind that while you think about the file in the context of the filename, on a UFS-based system (ext inherits a lot from UFS, the UNIX File System that goes back to the 70s and 80s with BSD, the Berkeley Systems Distribution), a file is just a collection of related data blocks. We could have multiple filenames that all point to the same "file" on the disk.

Running istat, we provide the offset to the start of the partition, just as we did with fls. Additionally, we provide the image that we are searching and also the inode that we want to interrogate. You can see the results of this below.

Among other things, we can see that the inode has been allocated. It's not free space because it refers to a file. You can see the date and time information. You can also see the permissions that are associated with the file. Additionally, as I mentioned above, different filenames can point to the same set of data blocks (the same inode). The "num of links" entry indicates the number of filenames that point to this inode, and by extension, the data that the inode points to. This is where the "Direct Blocks" entry is important. The direct blocks tells us where to get the contents of the file. For this, we use the blkcat command.

Again, we have to provide the offset because blkcat expects to start with the beginning of the partition, as fls and istat do. We provide the image name then the block number where the data is located. This is followed in this case by the number of blocks we want to extract. By default, we only pull one but since all of the blocks for the file are consecutive, we can pull all of them at once. Beneath that, you can see the contents of the file.

While it's several steps, using mmls to get the partition start, fls to get a listing of files, istat to get the data block address and finally blkcat to extract the file contents, it does help to highlight how the filesystem is put together. Being able to follow this chain, no matter the file or the filesystem, will help with the understanding of the workings of a filesystem such that no matter what tool you are using, you know the process.