July 7

Forensics: How to find the public key used to encrypt a file

When coming across encrypted files you may have a need to see what key was used to encrypt the file.  Although this does not help you decrypt the file it can possibly provide a small piece of a much larger story.

The easy way is to use gpg -vv then your file name:

Eg.

gpg -vv mytest.gpg

:pubkey enc packet: version 3, algo 1, keyid E4805172EBD35C7D
data: [4096 bits]
gpg: public key is EBD35C7D
:encrypted data packet:
length: 76
mdc_method: 2
gpg: encrypted with RSA key, ID EBD35C7D
gpg: decryption failed: secret key not available

If you are unfortunate enough not to have access to gpg you can also use a base64 encoder and a hex editor.  If you have both of these you are probably not using Windows and already have gpg, but lets have some fun for learning sake.  There are several ways to approach this.
The simplest it to make a copy of the file:
cp mytest.gpg copy-mytest.gpg

Encode the file
base64 copy-mytest.gpg

Use xxd or your favorite hex editor to look at the first 17th – 24th byte.
00000000: 8502 0c03 e480 5172 ebd3 5c7d 0110 00d7  ……Qr..}….

 

 

Category: Forensics | Comments Off on Forensics: How to find the public key used to encrypt a file
January 27

Forensics: Erase/Zero out a drive

Before using a drive to copy forensic data on to it you should make certain the drive is completely free of past data.  You can accomplish this by using the following command in your favourite variety of Linux:

(Make 100% certain you are zeroing out the right drive before running this command.)

dd if=/dev/zero of=/dev/sdX

By: Nighthawk
Category: Forensics | Comments Off on Forensics: Erase/Zero out a drive
May 15

Forensics: Using DD Over Netcat vs SSH

The following example are for theorectical use in a pinch.  There are better methods when collecting live data from a computer.  Also, it is better to use cryptcat rather than netcat- nighthawk

dd is a very handy shell command for writing raw data blocks from one place to another. Since it can read directly from raw device files, it is very useful for copying entire partitions or drives from one location to another. One traditional way to get this drive data from one location to another is to pipe DD’s output stream over SSH to a shell on a remote machine which in turn uses dd to pipe it to a given output file/device. This is commonly invoked as:

1
dd if=/dev/sda | ssh [email protected] "dd of=/dev/sdb"

This would make an exact copy of the local /dev/sda device on /dev/sdb attached to servername.net. This method generally suffices for fast speed transfers and smaller amounts of data, and also has the advantage of using SSH‘s built in encryption for secure transfers.

The problem, however, is that because of this encryption SSH has a lot of overhead which sacrifices transfer speed. When data encryption is not a concern (i.e. for internal network transfers), then there is another option. Netcat (or nc on some systems) is a handy utility for setting up quick and dirty TCP or UDP sockets for the transmission of, well really anything. I will get into the details of how to perform a transfer akin to the one referenced above, however let’s first take a look at some of the speed comparisons of dd over netcat vs dd over SSH.

Performance Benchmarking

Tests below were conducted with an empty 10GB partition. Since bzip encoding includes pooling similar data to achieve compression, partitions with actual data are most definitely going to see slower transfer rates and longer times. For instance, a partition with 2.5GB worth of data slows bzipped results by 50%. The results included here are to showcase he performance improvements by using netcat, which has a much lower overhead that SSH.

Average of Methods

Each transfer method was repeated three times with the same empty 10GB partition and then averaged here. The tests were conducted within our datacenter, from two servers within the same facility, in different VLANs, each uplinked at 100Mbit:

Time Elapsed (Sec) Speed (MB/s)
Over SSH 1787.4 6.1
Over Netcat (no compression) 1622.4 6.6
Over Netcat (bzip compression) 889.3 12.1
Over Netcat (16M block size + bzip) 490.0 21.9

Average Time Savings

Time Savings (Seconds) Percentage Savings
Over SSH 0%
vs Netcat (no compression) 165.0 9%
vs Netcat (bzip compression) 898.1 50%
vs Netcat (16M block size + bzip) 1297.3 73%

Test Notes

  • Bzip may or may not be ideal for your transfer, and this should be judged on a case by case basis. Bzip compression of mostly textual data is certainly going to be more efficient than MP3 or JPEG data. Bzip compression also comes with increased CPU overhead, which may increase transfer time.
  • Although a block size of 16M was used in the test, you may have more luck with smaller or larger block sizes depending on the structure of your network. 16M was arrived at by trying different values from 1M to 64M, although these results were not included. A larger block size can also be used on servers with harddrives that have larger on-disk cache (some as high as 64MB).
  • A full empirical test would have also included bzip compression and block size setting with dd over SSH as well, however we felt this was unnecessary as a compressionless and default block size test clearly shows netcat is quicker. It would very likely retain a similar margin of speed if these tests were included.

Using DD over Netcat

Netcat opens an encryption-less connection from one host to another, which is why it outperforms SSH. If using the netcat method, take a moment to consider the implications of sending raw, unecrypted data over your network. We strongly recommend against using this method for WAN data transfers, unless you are doing so over an encrypted tunnel (e.g. VPN).

Further on the subject of the warning above: Because netcat does not use any sort of authentication mechanism, it is possible for someone who knows your netcat port (e.g. from a trivial portscan) to inject arbitrary data into the stream thereby corrupting your dd operation. You will probably want to implement a firewall rule on the server to restrict traffic sent on the netcat port to only be permitted from the address of your remote transfer host.

We will assume for the purposes of this tutorial that you have the nc version of netcat. If you have the the other, then the command line options will be slightly different but the idea is the same. You set up a listening server on the destination, and then you send data to the port you’ve specified form the source. Let’s assume we are transferring a full disk image from serverA (/dev/sda) to serverB (dev/sdb). We are going to assume block size of incoming data for dd will be 16MB and that it will be bzip compressed. On serverB we would run the following:

1
nc -l 19000|bzip2 -d|dd bs=16M of=/dev/sdb

 ▾

This tells netcat to listen on port 19000 for incoming data, then pipe that data to bzip for decompression, and then finally pipe the decompressed data to dd to be written to /dev/sdb.

Once we have this listening (you won’t see any output after you hit Enter), we can move on to starting the data transfer on serverA:

1
dd bs=16M if=/dev/sda|bzip2 -c|nc serverB.example.net 19000

You again will not see any output after you’ve hit Enter, but do not fret! You can start another session (or launch the netcat in a screen session and back out), and run a tcpdump on port 19000 on serverB to ensure that traffic is indeed flowing. You can also send a USR1 signal to dd and it will output it’s current statistics. You’ll get a DD output on both ends summarizing the read/write time and bytes transferred when the process is complete. In this case no additional configuration is needed. /dev/sdb is a mountable and readable block device that’s ready for use!

By: S. Reitan

Category: Forensics | Comments Off on Forensics: Using DD Over Netcat vs SSH
April 30

Forensics: How to create a bitstream image of a live server

A typical scenario for creating a bit-image of a running server is an incident response situation where a critical server may or may not have been compromised or otherwise tampered with and needs to be thoroughly examined, but a server shutdown procedure cannot be justified. For the purposes of this technical tip, we’ll assume a simple single-disk Windows server.

One of the most important questions when imaging a server is where to put the image. You can’t save it to the drive you’re copying. Two good options are a USB drive or over the network. We’ll explain copying it over the network.

All you need to create this disk image and copy it over the network to another computer is a Windows version of the common GNU/Linux tools DD and netcat, which are both free and open source. DD creates the bit-image disk copy and netcat will send anything over the network. Of course, you’ll need the second computer on the network that will receive the image and has enough capacity for the image. You’ll want to put these two tools on safe media — preferably a CD. This way they are known to be “good” and won’t be compromised when used on a compromised system.
More incident response resources

How should a company’s security program define roles and responsibilities: Follow this implementation plan for your security program in order to help you define incident response roles.

Acceptable use policy for Internet usage helps data protection efforts: Acceptable use policies are an inexpensive, yet effective, control in limiting exposure to data breaches.

DD creates the copy by reading each raw disk cluster, starting at the first on the disk and continuing to the end. On a running computer the drive is often changed, depending on how active the server is, so there may be changes made to the disk after DD has already copied that segment.

For DD we’ll use DCFLDD — this version of DD was created by the U.S. Department of Defense Computer Forensics Lab. It is functionally identical to the normal version of DD but has added capabilities relating to hashing the data it copies. The hash creates a signature that allows us to validate the output is the same as the input (the original disk). Since we’re imaging a live server the disk is always changing — this means a second image will not have a hash that matches the first image.

DCFLDD is a fairly simple tool to use and its documentation can be found at the projects homepage at sourceforge.net. The parameter “if=” is used to specify the input, typically the drive or drive partition you are imaging. Determining the correct name for your input device can be a little tricky — the cygwin documentation will explain it in-depth. The quick version is that “/dev/sda” refers to the first hard drive, “/dev/sdb” the second drive, “/dev/sdc” the third drive, and so on. Some other builds of DD, that do not support hashing, provide a “–list” command to enumerate the drives on the system for you, which is quite handy. You can use DD to copy an image to a physical drive by using an image file for if and a physical device as of.
dcfldd if=/dev/sdc hash=sha256 hashwindow=512M sha256=mydrivehashes.log / bs=512 conv=noerror split=2G of=mydrive.dd

1 – DCFLDD Example
This example of DCFLDD will:

Copy the third hard drive (/dev/sdc) to the file mydrive.dd.
Use SHA256 to hash the drive contents in 512 Mb segments.
Record the hashes to “mydrivehashes.log.”
Split the file into 2GB files.
Skip over read errors rather than stopping (conv=noerror).

I’ve now shown how to create a disk image, but only to a local file on the system. That’s not helpful when there is no spare physical media present. This is where we use netcat, nc.exe, to redirect the output of DCFLDD over a network connection. This copy will not be encrypted so if the server image contains sensitive material it could be intercepted by anyone who is monitoring your network. When the output (of=) is omitted DCFLDD will copy to standard output. That means you can redirect to another tool, such as netcat. Netcat for Windows can be found online. First, on the destination server, launch netcat as a listener and redirect that to a file. I’ll have netcat listen on TCP port 3333 and write the image file to myimage.dd.
nc.exe –l –p 3333 > myimage.dd

Next, you can image the server (10.1.1.1) and send the image (via insecure cleartext) to that destination server by directing the output to netcat, through standard out, by not specifying the output file (of).
dcfldd if=/dev/sdc hash=sha256 hashwindow=512M sha256=mydrivehashes.log / bs=512 conv=noerror split=2G | nc 10.1.1.1 3333

If you do need to do this, and it’s for an incident response effort, make sure and document exactly what you do and at what time. This is critical if the resulting evidence is ever going to be used in court. If you don’t need this for incident response purposes, and don’t need the hash record, then a different version of DD, one supporting –list to enumerate your drives, might be a better choice.

Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.

This was first published in September 2009

By: T Chmielarski

Category: Forensics | Comments Off on Forensics: How to create a bitstream image of a live server