Hacking De-ICE S1.120

It’s been a while since my last post. Work and other commitments getting in the way unfortunately. But continuing the De-ICE series here’s my solution to gaining root for De-ICE S1.120

For my attacking machine I’m using BackTrack 5 R3. I’ve gone through Backtrack in a previous blog and gave some links on how to set it up. I’m using Oracle Virtual Box as my virtual environment.

Here’s my solution to De-ICE S1.120.

1. Run the following command from Backtrack nmap -A
2. Enumerate and investigate services and ports

ftp – permits anonymous. Log in and examine folder structure. Folder incoming is present but there is nothing in it
http – open http service through firefox and there is a simple set of web pages to add and view products. Add in a product and then view the product through the browser. URL created by the web pages looks like a candidate for further investigation for SQL injection attacks.
mysql – telnet and net cat attempts to log onto this service are rejected. Mysql is blocking remote access to it’s database.

3. From this initial trawl, the web site looks the most promising for an attack. Add two products, go to ‘View Products’ and select on of the products from the drop-down list. Here’s the URL that is generated: I altered this URL to read: or 1=1. This returns both products I entered. Assuming for a moment that all fields are being returned from the database this URL translates into SQL is follows: SELECT * FROM table_name WHERE column_name = 1 OR 1=1. The column_name field will field the id of the product we added. However by adding the OR clause of 1=1 (which is always true), the SQL query will return true on every row in the table and therefore display all records in the table holding products table. This is proof that SQL for this application is not being validated or is running some simple in-line queries embedded in the code. Either way it’s open to an SQL injection attack.

4. I’m going to use a tool called sqlmap to carry out an automated SQL injection attack on the victim machine. To access the tool in Backtrack 5 R3 go to, cd /pentest/database/sqlmap. The first thing I’m going to do is gather as much information and data from the database as I can using sqlmap.

5. The command below will return what the database the website is using and what user it is logging into the db as:

./sqlmap.py -u “” -b –current-db –current-user

-u, Target URL
-b, Retrieve DBMS banner
–current-db, Retrieve current database name
–current-user, Retrieve current databse user

The website is using a database called merch and is logged is the user webapp

6. The command below will return all users in the merch database, and attempt to unhash the users passwords. When prompted to perform a Dictionary Attack, type Y. When prompted on what dictionary do you want to use, accept default and hit enter. When prompted do you want to use common password suffixes, accept default N and hit enter. attack begins.

./sqlmap.py -u “″ –string=”Surname” –users –password

-u, Target URL
–cookie, HTTP Cookie header
-string, Provide a string set that is always present after valid or invalid query.
–users, list database management system users
–password, list database management password for system users.

The end result of this attack is quiet promising. sqlmap has returned a list of users and there passwords. I save these into a file for later user.

7. As a first tilt at the ssh service I take the user aadams (the most senior sys admin from the previous challenges) and use the password from the sqlmpa sweep blahblah and try to log in. Surprisingly this fails with a permission denied.

8. I then separate the usernames and passwords from the sqlmap sweep and run these against the ssh service using hyrda with the command:

hydra -L users.txt -P passwords.txt ssh

This is much more promising and hyrda returns a list of users and there associated passwords. I’m going to focus on the three system administrators initially. Log in through ssh as those accounts and see if I can find interesting.

9. logged in through ssh as aadams and bbanter and didn’t find anything particularly interesting. Both have normal user accounts on the victim box and neither are part of the sudo’ers list (sudo -l)

10. the user ccoffee is more interesting. ccoffee has sudo privileges. The privilege is strict and very exact but ccoffee is permitted to run a script (getlogs.sh) as the root user. What this means is that anything process kicked off from this script will run under the owning process – which in this case is root.

11. if you attempt to edit the current file getlogs.sh you will get a permission denied error. This is because this file is owned by root, and only root can edit it. To get around this rename the file, to something like getlogs.sh.root. (mv getlogs.sh getlogs.sh.root). Now create a new file getlogs.sh. Although this file is owned by ccoffee and under normal circumstances would run under his account. Because of this line in the sudo’ers list.User ccoffee may run the following commands on this host:

(root) NOPASSWD: /home/ccoffee/scripts/getlogs.sh

if you type in the exact location of the file it will run the file under the root account, and thereby gaining access to root privileges. All we need to do is to add the lines below to open a bash script. I initially typed in the following into the new file getlogs.sh:


Once again, don’t forget to give execute permissions on this file (chmod +x getlogs.sh)

12. run this file now with the exact command permitted in the sudo privileges. (sudo /home/ccoffee/scripts/getlogs.sh). I now have root access on the victim machine. The hints section for this challenge says to look for ‘internal documents’. I ran the following commands on the server

find /home -mount -iname “*”.dat
find /home -mount -iname “*”.txt
find /home -mount -iname “*”.csv
find /home -mount -iname “*”.doc

(-mount): ignore mounted drives
(-inmae): search for both upper and lower-case
(.): search from the root down

The results of the .doc and .txt return a number of interal documents. The most interesting of which seem to be /home/ktso/personnel.doc and /home/jdavenport/company_address.txt Both are related to reasonably confidential detail about and for the company.

13. With that the challenge is over


Hacking De-ICE S1.110

In my previous post I demonstrated how to hack De-ICE S1.100 the first in Thomas Wilhelms’ deliberately vunereable Slax Linux platforms. De-ICE S1.100 was a level 1 challenge. For this post I’m going to demonstrate one possible way to gain root and find the flags for the second challenge in the series (also level 1) De-ICE S1.110

For my attacking machine I’m using BackTrack 5 R3. I’ve gone through Backtrack in a previous blog and gave some links on how to set it up. I’m using Oracle Virtual Box as my virtual environment.

Once again, I’ve listed all steps I took to get to the end of the challenge. Hopefully, this might be of use and you could possibly compare it to your own approach. Let me know if you think if it’s too long winded and would prefer just to see the exact steps for each solution.

Here’s my solution to De-ICE S1.110.

1. Run the following command from Backtrack nmap -A

(-A): Additional, Advanced, and Aggressive. This nmap scan is a shortcut for running both the operating system fingerprinting process (-O) and the version scanning process (-sV) during the same nmap scan.

2. Some interesting information returned from the nmap sweep:

Port 21: is running an ftp service and allows anonymous access. I logged on to the ftp service and there were quite a number of files stored in the download directory. After trawling through the directory I came across two interesting files in download/etc/core and download/etc/shadow. The shadow file looks like it could possibly be the systems shadow file. The core file is a core dump file and is generally created when the OS or an application running on the OS has crashed out for some reason. If you type in this command: file core you get this ELF 32-bit LSB core file Intel 80386, version 1 (SYSV). The part in brackets tells us who has created the dump file, in this case it’s the system itself. The core file is a binary file and it’s possible to debug into the file and read it’s contents. But to view it in a text format, type this command: strings core

3. The core file contains shadowed password for the root, aadams, bbanter and ccoffee users. The fact that this information has been written to file during a system dump makes me think this is the the real shadow file, so I’m discarding the other shadow file I found in the ftp trawl.

4. From the nmap sweep I can see this system is running a website on port 80, so I ran onto that through firefox and saw a number email addresses displayed on it’s web pages

Sr. System Admin: Adam Adams – adamsa@herot.net
System Admin (Intern): Bob Banter – banterb@herot.net
System Admin: Chad Coffee – coffeec@herot.net

5. The nmap sweep also highlighted an ssh service running on port 22 and a CUPS service running on 361. I’ll come back to this later if needs be, but I’m going to start the attack using the shadowed passwords I found in the core file.

6. I used John the Ripper in the previous post. I’m using it again here, running it from Backtrack, where it comes pre-installed. The passwords in the shadow file have been hashed with a one-way hash. It’s possible to get a list of various passwords, hash these with various hashes and compare the hashed result to the values stored in the shadow file. If they match, you have the text version of the hashed password. I’m going to use John the Ripper and the rockyou list of passwords that comes pre-loaded in Backtrack to carry out this operation. To do this, go to this folder in Backtrack /pentest/passwords/john and run the following command:

./john –rules –wordlist=/pentest/passwords/wordlists/rockyou.txt shadow

(shadow): the shadow file I created from the users I cut from the core file

John the Ripper returns the following password matches: bbanter/Zymurgy, root/Complexity

10. I then attempted to log on to the ssh service as the root user but the login was rejected. It looks as though root is not be configured for remote access through ssh. I logged out and logged back in as bbanter. Once in, I used the su command: su root to switch to the root user. I now have root access on the victim box.

11. The hints for this challenge advise to look for encrypted customer information. So looking for any files with a encrypted extension (.enc), I entered this command from the root drive:

find -mount -iname “*”*.enc

(-mount): ignore mounted drives in the search
(-iname): ignore case in the file names
(enc): file extension to search for

Because I am the roor user I can search the entire system without getting any permission denied issues on any folders or files when I search.

12. The search returns this file at this location ./home/root/.save/customer_account.csv.enc

13. I went to to the folder ./home/root/.save/ to examine the file and found a second shell script file of interest in the same directory copy.sh

14. Run the command cat copy.sh. The copy.sh file contains an openSSL encyrption command, it also shows location of the password cert used in the encryption process. This looks like the method that was used to encrypt customer_account.csv.enc

15. This is probably overkill but I wrote a small script based on the detail in copy.sh to decrypt customer_account.csv.enc.

openssl enc -d -aes-256-cbc -in customer_account.csv.enc -out customer_account.csv
-pass file:/etc/ssl/certs/pw

Save the file, give it execute permissions (chmod +x decrypt_customer_detail.sh) and run the file

16. When I open customer_account.csv now (cat customer_account.csv) I can see there is a host of sensitive customer information. Customer Id, customer name, creditcard type and account number are all available.

17. And with that the challenge is over

I hope you found that interesting, any comments or improvements please email me and let me know. I’ll be attempting De-ICE S1.120A next. I’ll post my solution once I have it.

Hacking De-ICE S1.100

Thomas Wilhelm created the De-ICE series of vulnerable platforms to teach hacking techniques to beginners and experts alike. De-ICE S1.100 is the first challenge in the series. It’s a level 1 challenge (denoted by S1 in the title. Level 2 is denoted by S2 and so on).

You can the download the De-ICE S1.100 iso from the HackingDojo website. The De-ICE series are built on Slax Linux

For my attacking machine I’m using BackTrack 5 R3. I’ve gone through Backtrack in a previous blog and gave some links on how to set it up. I’m using Oracle Virtual Box as my virtual environment.

I’ve listed all steps I took to get to the end of the challenge. Hopefully, this might be of use and you could possibly compare it to your own approach. Let me know if you think if it’s too long winded and would prefer just to see the exact
steps for each solution.

Ok, with all that out of the way – here’s how I hacked De-ICE S1.100.

1. Run nmap -A Level 1 De-ICE platforms are meant to replicate internal pen-test testing only. You are not hitting firewalls, intrusion detection systems etc during these challenges. So I’m not interested in stealth for this exercise, I’m just looking for what ports are available on the De-ICE system. From the nmap command:

(-A): Additional, Advanced, and Aggressive. This nmap scan is a shortcut for running both the operating system fingerprinting process (-O) and the version scanning process (-sV) during the same nmap scan.

2. Before jumping into any particular port I enumerate through the services. This is information gathering and collating service and port data so I can prioritise what might be the best avenues of attack. Points of interest from the scan:

Port 21: is running ftp and is showing the following broken: could not bind listening IPv4 socket.Telnet to the port (telnet 21) for more information and the following error is returned: 500 OOPS: could not bind listening IPv4 socket Connection closed by foreign host.
I’ll move on but note this for later as this error is referred to in the hints section for the challenge

Port 22 is running ssh Telnet (telnet 22) to the port for more information and confirm the version of ssh given by initial nmap sweep. I find it’s always useful to use two tools to confirm findings. Version of ssh is OpenSSH 4.3 protocol 1.99.

Port 80 is running http. I open through firefox. Examination of the companies web pages reveals a number of staff
emails are displayed on the website. In particular three system administrator emails are listed:

Sr. System Admin: Adam Adams – adamsa@herot.net
System Admin (Intern): Bob Banter – banterb@herot.net
System Admin: Chad Coffee – coffeec@herot.net

These may come in useful I save the list of all email names to a file. I called my file usernames.txt. Also, before saving I juggle the user name format. I do this to to hopefully capture other possible formats used by the same users to log in to any remote services. I’ll also add a few typical account names like root, ftp etc. Snapshot of my file is as follows:


3. From the information above we have a number of email accounts. It’s possible that these email usernames, or something similar, are also used as log-on credentials to access the ssh service. This is the starting point for my attack.
4. First up, rule out the obvious. I’m going to check that none of the users are using their usernames as a password to log on through the ssh service. I’m going to use the hydra tool to carry out this attack.
5. From Backtrack I run the hydra command:

hydra -L usernames.txt -P usernames.txt ssh

(-L): the file containing the list of usernames I created earlier.
(-P): the file containing the list of passwords I want to check. In this case it also happens to be the list of users we are using.
( target IP address
(ssh): target protocol

The hydra command runs and notifies us that the user bbanter is using a password of bbanter

7. I am now in a position to log on to the server via the ssh service using bbanter’s credential’s. From Backtrack we log on to the server via ssh ssh bbanter@

8. I am now logged on the victim machine. I can run a few obvious commands to gather some information and to see what kind of privileges have been assigned to bbanter. Obviously this list could be a lot longer, but here are some examples below:

User and group type: id
Sudo privileges: sudo -l
Open the password file: cat /etc/passwd
Open the password file: cat: /etc/shadow

9. The user bbanter looks pretty well locked down. However, when I ran the cat /etc/passwd command I noticed that one of the system administrators is in a different group to the other two. This is worth further investigation. Also, in the passwd file there is an unusual entry for the root user. The entry is below.

The entry root:x:0:0:DO NOT CHANGE PASSWORD – WILL BREAK FTP ENCRYPTION:/root:/bin/bash

10. Run the command cat /etc/group to examine the different groups on the server. We see that group 10 is in fact the wheel group. The wheel group is used on some Unix systems and allows access control to the su command. The su command allows one user to become another during the current session. Invoked without a without a username, su defaults to become the super user. Of course you need permissions to carry out this action. Luckily, aadamshas this permission.

11. However, we don’t have aadams’s password. Log back out of the server and let’s try to crack the password for aadams. We are using hydra once more. From Backtrack I run the hydra command:

hydra -l aadams -P /pentest/passwords/wordlists/rockyou.txt ssh

(-l): lowercase l this time indicating we are using a single password string instead of a file.
(-P): the file containing the list of passwords we want to check. Backtrack comes with a number preloaded files which contain common passwords used on the web and various applications. Rockyou is one such list. We’ll look for aadams password here as a starting point
( target IP address
(ssh): target protocol

The hydra command runs and finds the password for user aadams in the Rockyou list: the password is nostradamus

13. Log back on to the victim machine through ssh with the aadams account (ssh aadams@

14. I already have the contents of the password file. I know from examing it that the passwords are shadowed. If I can get the contents of the shadow file it may be possible to crack the hashed password for root. The command cat /etc/shadow returns a permission denied message. However, aadams is part of the wheel group so we have permissions to run sudo, run the command sudo cat /etc/shadow. I now have the contents of the password and shadow files. We can use these to crack the root password.

15. aadams has the highest privileges of the system administrator users. Gaining the other sys admin passwords is not going to give me anything new. So I remove everything from both passwd and shadow files except the entries for the root user.

16. John the Ripper is a password cracking tool. It comes pre-installed on BackTrack R5. We are going to use John’s unshadow functionality to create a password file from the passwd and shadow files. Go the directory cd /pentest/passwords/john and run the command

./unshadow passwd shadow > password.txt

17. We now run John The Ripper against the password.txt file we just created. Run the following command:

./john De-ICE-passwords.txt

John the Ripper cracks the root password. The password is tarot

18. If you try to log in through ssh with the root user you’ll get a permission denied error. This is because it looks as though ssh has been configured on the victim machine not to allow remote root access. ssh in as aadams instead, and su to root with the root pasword.

20 Referring to the hints page once more, there is something mentioned about the CEO’s bank account information. Searching the entire file system I carry out the search below on the victim box. I’m looking for some file that might have the name ceo, bank or salary in it.

find . -mount -iname “*ceo*”.*
find . -mount -iname “*bank*”.*
find . -mount -iname “*ceo*bank*”.*
find . -mount -iname “*ceo*sal*”.*
find . -mount -iname “*bank*”.*

(-mount): ignore mounted drives
(-iname): make the search case insensitive
(.): search from the root down

none of these searchs return anything of interest. I ran the search below and it finds a file called salary_dec2003.csv.enc in the /home/ftp/incoming folder. This looks like what we are after.

find . -mount -iname “*sal*”.*

21. Examine the salary_dec2003.csv.enc with the command file salary_dec2003.csv.enc.The file command simply tells me that salary_dec2003.csv.enc is a data file. Not much use. I then typed vi salary_dec2003.csv.enc. The file opens and it appears as though some kind of encryption has been applied to it. At the top of the file are the characters ‘Salted__n’.

23 Google ‘Salted__n’ and I find that OpenSSL encryption typically creates the ‘Salted_n’ header in files that it has encrypted.

24. Great. Now I need to find what type of encryption has been used by OpenSSH to encrypt the file. A little reading up on OpenSSL trawls this command, openssl list-cipher-commands. It gives the list of ciphers used by the OpenSSL protocol.

26. I need to write a small program to loop through these cipher types and attempt to decrypt salary_dec2003.csv.enc using OpenSSL. You could use a number of different programming languages here: c, python, perl for example. It looks like a simple enough script so I’m going to create a simple shell script. One other point of interest, when you encrypt a file using OpenSSL you are asked to password protect the file. And when we queried the /etc/passwd file, it contained this line: root:x:0:0:DO NOT CHANGE PASSWORD – WILL BREAK FTP ENCRYPTION:/root:/bin/bash. That’s a pretty good indication to me that the root password may have been used to password protect the file.

27. Here’s the shell script to loop through the different ciphers:


28. Don’t forget to make the script executable with chmod whateveryoucallthefile.sh +x. Run it and the script discovers the ciper used. For the record it’s aes-128-cbc. Now run the command cat salary_dec2003.csv and you can see the CEO’s financial information in the file.

29. One last thing. It’s not called out directly in the challenge hints section. But the broken ftp service is mentioned. I’m going to get it running before finishing the challenge.

30. When we used telnet to talk to the ftp service in out initial sweep of the victim machine we got this response.

500 OOPS: could not bind listening IPv4 socket. Connection closed by foreign host.

31. A quick Google and we find the issue. Edit the file at /etc/vsftpd.conf and change the setting listen=YES to listen=NO

32. Restart the vsftd service for changes to take effect. Do this as follows: /etc/rc.d/rc.vsftpd restart The service restarts

33. Log back into the server as root through ftp (ftp

34. Run this command cd /home/ftp/incoming and then ls to list the contents of the directory. You should see the salary_dec2003.csv.enc file.

35. Challenge is complete.

I hope you found that interesting, any comments or improvements please email me and let me know. I’ll be attempting De-ICE S1.110 next. I’ll post my solution once I have it.

Vulnerable Platforms for Practicing Pen Testing

In a series of previous posts, I built a virtual Windows domain and a virtual DMZ which hosted a screened subnet. The point of the exercise was to build a network of servers and firewalls from the ground up. Once built the network could then be configured as required to test various penetration attacks, security audits or any other relevant testing scenarios you might want to create.

Of course while it was good practice, it wasn’t completely necessary to build the network. There are a whole host of vulnerable platforms that have been built with deliberate flaws in their configuration or in the services running on them. Generally the ultimate goal of most of the platforms is to break into the server and gain root access or to access sensitive files on the server. To do so you need to use various tools and gain a certain level of expertise.

I’m going to focus on three well known versions of these deliberately vulnerable platforms. I’m going to go through the De-ICE, pWnOS and Kioptrix servers.

First up is De-ICE 100. I’ll post the methods and tools I used to break into this system in the coming days.

If you have cracked these systems and see improvements in what I am doing, used different tools or reached the end-point in a different way. Please contact me as I post my work and share your thoughts…


BackTrack is a Linux-based penetration testing arsenal that aids security professionals in the ability to perform assessments in a purely native environment dedicated to hacking.

It’s a superb tool to recreate, examine and understand exploits that potentially exist in operating systems and web applications.

computersecuritystudent.com provide an excellent introduction to some of BackTrack’s functionality.

Particularly impressive is the lesson which create’s a Virtual Network Computing (VNC) link to a Windows XP machine. VNC gives you a graphical interface to the XP box.

Although this lesson is easily defeated by simply turning on the Windows XP Firewall. It shows the potential for harm that a malicious hacker can cause on a poorly configured machine.

Damn Vulnerable Web App (DVWA)

Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that comes with a set of deliberate vulnerablities built into it.

I can across it while reading through some of the NY Poly courseware.

DVWA is similair to the Web Goat application I mentioned in an earlier post. DVWA’s aims ‘are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.’

While working on DVWA, I came across this superb set of tutorials on the computersecuritystudent.com website

What’s particularly impressive about these tutorials is that they integrate DVWA with BackTrack, Burp Suite, John the Ripper and a number of other security testing tools.

You’d pay quite a lot of money to attend a training course and get access to this kind of information. These tutorials are laid out brialliantly, easy to follow – and they’re free!

Definitely worth checking out.