The purpose of this article is to describe, for educational purposes (see disclaimer), the pentesting of a vulnerable image created for training purposes called “De-ICE: S1.100”.
The scenario for this LiveCD is that a CEO of a small company has been pressured by the Board of Directors to have a penetration test done within the company. The CEO, believing his company is secure, feels this is a huge waste of money, especially since he already has a company scan their network for vulnerabilities (using nessus). To make the BoD happy, he decides to hire you for a 5-day job; and because he really doesn’t believe the company is insecure, he has contracted you to look at only one server – a old system that only has a web-based list of the company’s contact information.
The CEO expects you to prove that the admins of the box follow all proper accepted security practices, and that you will not be able to obtain access to the box. Prove to him that a full penetration test of their entire corporation would be the best way to ensure his company is actually following best security practices.
PenTest Lab Disk 1.100: This LiveCD is configured with an IP address of 192.168.1.100 – no additional configuration is necessary.
I am going to skip the configuration process because it is trivial and it is not the purpose of this article.
All the used for this article are or can be installed in a Kali Linux distribution.
Once we have both machines running, our Kali Linux and the training image, the first step should be checking if they are in the same network and we can see the training machine from testing machine. We can use the “ping” command, but in this case is going to fail, or the “netdiscover” command, just to list a couple of them. In my case, I have used “netdiscover”:
netdiscover -i eth1 -r 192.168.1.0/24
After we are sure we can reach the training machine, the first step is to take a look around checking the web page there is available. We can see a brief explanation about the challenge and not much more than that. But, we can see a very important thing here. Reading carefully the page we can see there are some email related with the company.
Head of HR: Marie Mary - firstname.lastname@example.org (On Emergency Leave)
Employee Pay: Pat Patrick - email@example.com
Travel Comp: Terry Thompson - firstname.lastname@example.org
Benefits: Ben Benedict - email@example.com
Director of Engineering: Erin Gennieg - firstname.lastname@example.org
Project Manager: Paul Michael - email@example.com
Engineer Lead: Ester Long - firstname.lastname@example.org
Sr.System Admin: Adam Adams - email@example.com
System Admin (Intern): Bob Banter - firstname.lastname@example.org
System Admin: Chad Coffee - email@example.com
We should pay special attention to the last three because they are admin users.
This gives us a few information:
- Names of people that is working in the company.
- Valid emails.
- Examples of how they are creating usernames.
It is time to start exploring what the training system is offering. For this purpose, I am going to use “nmap”.
nmap -p 1-65535 -T4 -A -v 192.168.1.100
As we can see, there are a few port open in the training machine:
- 21: FTP service. And, something is not right here.
- 22 SSH service
- 25 SMTP service
- 80 HTTP service
- 110 POP3 service
- 143 IMAP service
Considering we do not have any other information, we need to start thinking in what we are missing. We already have some valid email, with this information we can create a list of possible users in the system. In addition, we can add users like “root” or “admin” or similar users that are always useful to have. In this case, our list can be something like:
root admin aadams adamsa adamsad adam.adams bbanter banterb banterbo bob.banter ccoffee coffeec coffeech chad.coffee
Now, that we have a list of possible users, we can try to connect to the SSH service. For this, we are going to use the tool “medusa” trying to do a dictionary attack to see if we are lucky.
medusa -h 192.168.1.100 -U users.txt -P passwds.txt -M ssh -v 4 -w 0
As we can see, we have been able to break one password. Let’s use it and try to connect using SSH.
As we can see, we are able to connect. Now that we are inside, let’s see what “sudo” commands we have available.
We can see we can use the tool “cat” to read file content. Then, let’s check the files “/etc/passwd” and “/etc/shadow”.
With a simple copy and paste we can move the content of both files to our machine to try to use “John” to discover new passwords, specially the “root” password. After the copies are done, we can “unshadow” the files to have everything in one file.
unshadow pasad_file.txt shadow_file.txt > root_password.txt
Trying to save a little bit of time, and because we already have an operative user “aadams” we can copy the “root” credential to a file and try to break just the “root” password.
Great! We have the “root” password. Now we can try to connect with SSH using the “root” credentials.
As we can see, we are not able to connect as “root” user using SSH. But, we are still having the “root” password and a valid user “aadams”. Let’s try to login as “root” using our valid user
Usually, now that we are root we can close the case and deliver our report, but going around a little bit we can find an interesting file, and considering this is a training exercise, we can play a bit more. The file is this one
bin walk salary_dec2003.csv.enc
What do we know about the file:
- It is encrypted with OpenSSL.
- It was in a folder only accessible by the “root” user. We can think that maybe it is going to be encrypted using the “root” password we have.
- We know that we do not know the type of cipher.
We can check the type of ciphers that OpenSSL offers.
openssl enc help
Let’s try on of them out of curiosity to see how an error looks like, and after that, let’s try to figure out how to try/apply all of them to find the correct one.
openssl enc -d -aes-128-cbc -in salary_dec2003.csv.enc -out salary_dec2003.csv -k tarot
I guess that it is because it is just a training environment but the one that does the job is the first one. No more attempts are needed. In the real world probably we should write a script to test all the cipher available.
With this our scenario finish. We have access to the machine, we have root permissions and we have decrypted the “salary” file, our job is done. It has been interesting but I thing that it is just possible because the passwords where not very strong.