Honeynet Scan of the Month 26
=============================
February 2003
Hans Van de Looy (hans (AT) madison-gurkha.com)
Brenda Langedijk (brenda (AT) blackhats.org)
TOOLS
=====
To complete this challenge, the following tools were
used:
TASK 1.52 http://www.atstake.com/research/tools/task/
Autopsy 1.62 http://www.atstake.com/research/tools/autopsy/
stegdetect
0.5 http://www.outguess.org/detection.php
bvi
1.3.1 http://bvi.sourceforge.net/
nmap
3.0.0 http://www.insecure.org/nmap/
mozilla 1.2b http://www.mozilla.org/releases/
pkzip
2.5 http://www.pkware.com/
xv 3.10a_3 http://www.trilon.com/xv/
Invisible Secrets 2002 http://www.invisiblesecrets.com/
The actual analysis was done on both a FreeBSD 4.7-STABLE
platform and a Windows 2000 professional platform.
SETUP
=====
The scan26.zip file was
downloaded from the Honeynet website
(http://project.honeynet.org/scans/scan26/scan26.zip) to the FreeBSD
platform.
The following md5 checksums were extracted from the Honetnet
website as
well:
MD5 (scan26) =
e9c7d0c87ab0ecce09bf90362b830a74
MD5 (scan26.zip) = c8e2454b970538de26a0fa887017109b
Using the md5 utility we validated the received scan26.zip file. It was
then unzipped using the pkzip utility and the scan26 file was placed in the
morgue directory. The morgue directory
must contain all
images and configuration files for
Autopsy to read. The fsmorgue file for Autopsy
contained the following information:
scan26 fat12 A:\ EST5EDT
The md5 value of the scan26 file was placed in md5.txt so that we could
verify its integrety through Autopsy as well.
The file containing the police report was downloaded from the Honeynet
website
(http://project.honeynet.org/scans/scan26/scenario.html) and
read carefully.
QUESTIONS
=========
The following questions must be answered:
* Who is the probable supplier of drugs to Jimmy Jungle?
* What is the mailing address of Jimmy Jungle's probable
drug supplier?
* What is the exact location in which Jimmy Jungle
received the drugs?
* Where is Jimmy Jungle currently hiding?
* What kind of car is Jimmy Jungle driving?
Bonus Question:
Explain the process that was performed so that there were no entries in the
root directory and File Allocation Table
(FAT), yet the contents of each file remained in the data area?
Remark: The bonus question also indicates that another
party has already done a, perhaps limited, investigation of the material which was handed over.
INVESTIGATION
=============
Since
the amount of data is limited
we used the strings command to extract possible interesting data.
The last two lines of the output read as follows:
pw=help
John Smith's Address:
Next the content of the scan26 file was examined using
the Autopsy tool, by
first selecting the File
System menu option. This provided the following data:
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT
OEM: "RVRbIHC
Volume ID: 383387204
Volume Label: NO NAME
File System Type (super block): FAT12
META-DATA INFORMATION
--------------------------------------------
Root Inode: 2
CONTENT-DATA INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 512
Sector of First Cluster: 33
FAT 0 Range: 1 - 9
FAT 1 Range: 10 - 18
FAT CONTENTS (in sectors)
--------------------------------------------
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
Using the File Browsing menu option gave the message No Contents. The Data Browsing
menu option showed that both
FAT0 and FAT1 were filled with
zero's (0x00) directly after the header bytes 0xF0 0xFF 0xFF,
while the root directory was empty as well (i.e. contained 0x00 bytes).
The sector of the first cluster (as indicated above 33) still
contained information. Interpretation of the header indicated that it is probably the
start of an .jpeg (JFIF) image file.
Such a file always starts with the following flag-bytes (more information on this can be found using the URL: http://www.obrador.com/essentialjpeg/HeaderInfo.htm):
0xFF 0xD8 0xFF 0xE0
and ends with the following
hexadecimal sequence:
0xFF 0xD9
All data (a total of 32602 bytes) between these sequences were stored using the bvi
tool in the image000.jpg file. Viewing this file using the xv graphics viewer
did not provide much useful information, just the location of a place called
Danny's (Pier 12) and the text
"Boat Lunch". We calculated the md5 checksum and include it here for
future reference:
MD5 (image000.jpg) = aee13c3e61441da124125fc1f9e9b869
Further browsing using bvi learned
that from the sector directly after the
first retrieved image other data was
stored. This data started with the sequence 0x42 0x4D
(the two characters "BM"). Using google we quickly could
determine that such a sequence can
be an indication of a bitmap image file.
The header of a bitmap image file contains the length of the image, in
the four bytes directly
following the 0x42 0x4D sequence. These bytes contained the
following information:
0x76 0xCC 0x11 0x00
So we had to
extract a total of 1166454
(0x11CC76) bytes for the complete
content of the
bitmap image -- directly
after the last extracted byte thee filling with 0xF6 bytes began. This information was placed
in the image001.bmp file. Viewing this
file using the xv program displayed
the same information as
the image000.jpg file, but
also included an indication of a
place called "Hideout" at 22
Jones Ave. We also calculated the md5 checksum of this file which is included
here for future reference:
MD5 (image001.bmp) = 0bfa07f4debbc96a3f52459e6baa4a82
Further browsing through the scan26 image only showed 0xF6 bytes. So we used the
dd and hexdump tools to
quickly check the rest of the disk:
dd
if=scan26 bs=512 skip=2376 | hexdump
0000000 f6f6 f6f6 f6f6 f6f6 f6f6
f6f6 f6f6 f6f6
*
0002b50 7770 683d 6c65 f670 f6f6 f6f6
f6f6 f6f6
0002b60 f6f6 f6f6 f6f6 f6f6 f6f6
f6f6 f6f6 f6f6
*
002d760 6f4a 6e68 5320 696d 6874 7327 4120 6464
002d770 6572 7373 203a 3231 3231
4d20 6961 206e
002d780 7453 6572 7465 202c 6f4a 656e 2c73 4620
002d790 204c 3030 3030 f631
f6f6 f6f6 f6f6 f6f6
002d7a0 f6f6 f6f6 f6f6 f6f6 f6f6
f6f6 f6f6 f6f6
*
003f000
Here we can
clearly see the two
strings already mentioned
above embedded inside (they are
actually stored on the sectors 2397 and
2739
respectively) while all other bytes are filled with 0xF6. The hexdump program
(by default)
does not repeat values that are the same
as the previous line, which is indicated by an asterisk.
STEGANOGRAPHY
=============
Since the police
report already mentioned that the suspect
is fairly computer savvy, we
used the program
stegdetect
on the extracted image000.jpg file. This provided us
with the following clue:
image000.jpg :
invisible[7771](***)
An indication that
most probably the windows based
program Invisible Secrets
(created by neobyte
solutions) was used to
hide some other information
inside this image file. Since stegdetect can not detect any steganography inside a bitmap
image, the file image001.bmp was not analyzed.
A free trial copy of the software mentioned above can be
downloaded from the following website:
http://www.invisiblesecrets.com/downloads.html
Using this
software we tried
to unhide the data
inside using the password found
on the floppy as indicated by the string "pw=help".
But each of the decryption algorithms we could use (AES - Rijndael,
Twofish, RC4, Cast128, GOST, Diamond2, Sapphire II,
Blowfish) resulted in the error
message:
ACCESS DENIED
Invalid carrier file, password or algorithm.
(Notice that the provided error message gives no
indication on what is the real
reason of the error! This is as it should be, making it much harder for the analyst to find
out what actually went wrong).
We also tried to unhide data from the
image001.bmp file using the same
password, but this also failed.
USE ALL CLUES
=============
Since we reached a dead-end at that time we decided to
take a small rest and list all clues we had collected thus far. Reading the police
report again we
came across some information we had not
included into the investigation
thus far, namely the following text
(reformatted here for
readability):
"However, there was a single floppy diskette lying on the floor in the only upstairs bedroom, dfrws.org was
written on the outside of
the disk."
This could be an indication of a domain name. The host command returned
the following information:
dfrws.org has address
206.74.229.17
The nmap scan of the above
address provided the following information:
Interesting ports on (206.74.229.17):
(The 1587 ports scanned but not shown below are in state:
closed)
Port
State Service
21/tcp
open ftp
22/tcp
open ssh
23/tcp
open telnet
25/tcp
open smtp
53/tcp
open domain
80/tcp
open http
81/tcp
open hosts2-ns
110/tcp
open pop-3
143/tcp
open imap2
443/tcp
open https
444/tcp
open snpp
3000/tcp
open ppp
3001/tcp
open nessusd
3306/tcp
open mysql
Remote operating system guess: Linux 2.1.19 - 2.2.20
Uptime 4.358 days (since Thu Feb 6
TCP Sequence Prediction: Class=random positive increments
Difficulty=1816725 (Good luck!)
IPID Sequence Generation: Busy server or unknown class
Nmap run completed -- 1 IP
address (1 host up) scanned in 25 seconds
Lots of services are provided by this system, but we went first for the
website (http://www.dfrws.org/), since
that is the easiest
way to provide information to the
outside world. Reading the webpages (they use
frames) does not
provide us with other clues, but
reading the HTML source of the
webpage with URL: http://www.dfrws.org/dfrws-overview.html
(the right hand frame -- first open the frame in another tab and than select the View Page Source function) enables us to view
comments in this source code as
well. Here we have included the part of the source that contains some
additional information (the source
presented here is reformatted for clarity):
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
<!-- 100 guest rooms have
been reserved at a special conference rate of-->
<!-- Invisible Secrets -->
<!-- $149.00 per night for
non-government-->
<!--
http://www.invisiblesecrets.com -->
<!-- employed attendees and
$86.00 per night for government-employed attendees.-->
<!-- PW=lefty -->
Please honor this pricing arrangement and do not attempt to receive the
government rate without proper
identification and/or government travel
orders.
<!-- Algorythm=
twofish -->
In order to ensure room availability we ask
that your room reservation be completed
by
<!-- PW=right -->
fee will increase to US $375.00
</i></b></font><br><br><hr>
<!--
<a href="challenge.html"
target="main"><font face="arial"
size="5"> DFRWS Challenge on Honeynet
</font></a><br>
-->
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
As can be easily detected in the above source two passwords
are included and an
indication of an
algorithm (spelled incorrectly as Algorythm) used.
The two
passwords are "lefty" and "right" and the algorithm is twofish.
STEGANOGRAPHY Revisited
=======================
Using the new information we return to the two extracted
image files and the
Invisible Secrets
program. Using the twofish algorithm and
the password "lefty" on
the image000.jpg file unhides the John.doc file, which we saved.
Using the same program
with the password
"right" and the twofish algorithm
on the image001.bmp file unhides the Jimmy.wav file, wich we saved
as well. We also calculated the md5 checksums of these files which are included
here for future reference:
MD5 (Jimmy.wav) =
27de3209e3b68414a7429e4104c22185
MD5 (John.doc) = 85dba2fec1af9153a25e62a70c37d7b3
Listening to the Jimmy.wav file
we can hear a voice say:
"This is Jimmy. Meet me at the
pier tomorrow. I drive a blue 1978 Mustang with
The text in the John.doc file can only be read after providing another password (the password
"help" wich was included
on the floppy). The contents are
included here as well:
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
Dear John Smith:
My biggest dealer (Joe Jacobs) got busted. The day of our
scheduled meeting, he never showed up. I called a couple of his friends and
they told me he was brought in by the police for questioning. I'm not sure what
to do. Please understand that I cannot accept another shipment from you without
his business. I was forced to turn away the delivery boat that arrived at
Danny's because I didn't have the money to pay the driver. I will pay you back
for the driver's time and gas. In the future, we may have to find another
delivery point because Danny is starting to get nervous.
Without Joe, I can't pay any of my bills. I have 10 other
dealers who combined do not total Joe's sales volume.
I need some assistance. I would like to get away until
things quiet down up here. I need to talk to you about reorganizing. Do you
still have the condo in
Thanks for your understanding and sorry for any
inconvenience.
Sincerely,
Jimmy Jungle
------%<----%<----%<----%<----
SNIP ----%<----%<----%<----%<----%<------
ANSWERS
=======
1/ Who is the probable supplier
of drugs to Jimmy Jungle?
John Smith as indicated in the file John.doc.
2/ What is the mailing address
of Jimmy Jungle's probable drug supplier?
John Smith's Address:
3/ What is the exact location in
which Jimmy Jungle received the drugs?
Danny's at Pier 12. As indicated in the file
John.doc and the retrieved image labelled
image001.bmp
4/ Where is Jimmy Jungle
currently hiding?
5/ What kind of car is Jimmy
Jungle driving?
A blue
1978 Mustang (Ford) with
Bonus Question:
---------------
Explain the process that was performed so that there were no entries in the
root directory and File Allocation Table
(FAT), yet the contents of each file remained in the data area?
Answer:
-------
Both the root
directory (sector 19 upto and including sector 32) and both File Allocation Tables (sector 1
upto and including 9 and sector 10 upto and including
sector 18) were filled with
0x00 bytes, with the
exception of the FAT headers,
the first three bytes of
a FAT must contain the following
values: 0xF0 0xFF 0xFF, at the beginning of sector 1
and 10.
Since these disk area's only point to the actual data stored and provide information on the filenames given to these area's, cleaning them only destroys this information but not the actual contents of the files which is stored on a standard FAT12 filesystem starting at sector 33.
The easiest
way to
fill both File Allocation
Tables and the root directory with zeros
(0x00) is of course by using
the Quick Format option (flag) of
the format "command".
FINAL REMARKS
=============
The hiding of additional information on a remote site actually made the
analysis of this challenge quite difficult.
Then again, it also made it quite clear that ALL clues must be examined
during an investigation.
All extracted evidence is attached to this
message in one zipped tar file
with the following md5 checksum:
MD5 (evidence.tgz) =
dc8ac4e9dcfecfe1aa9a87271f119c4f