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).
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 192.168.1.100. 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 192.168.1.100 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 192.168.1.100 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 192.168.1.100 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 – email@example.com
System Admin (Intern): Bob Banter – firstname.lastname@example.org
System Admin: Chad Coffee – email@example.com
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 192.168.1.100 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.
(192.168.1.100): 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 firstname.lastname@example.org
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 192.168.1.100 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
(192.168.1.100): 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 email@example.com).
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 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 192.168.1.100)
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.