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 192.168.1.110

(-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.

#/bin/bash
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 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 – 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:

webmaster
guest
ftp
root
adamsa
aadams
AdamsA
a.adams
adams.a

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 bbanter@192.168.1.100

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 aadams@192.168.1.100).

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:

Untitled

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.

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…