WALKTHROUGH: De-ICE: S1.100

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

Information

https://www.vulnhub.com/entry/de-ice-s1100,8/

Scenario

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.

Configuration

PenTest Lab Disk 1.100: This LiveCD is configured with an IP address of 192.168.1.100 – no additional configuration is necessary.

Download

ISO image

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
01-netdiscover
Figure 1. Netdiscover execution result

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 - marym@herot.net (On Emergency Leave)
Employee Pay: Pat Patrick - patrickp@herot.net
Travel Comp: Terry Thompson - thompsont@herot.net
Benefits: Ben Benedict - benedictb@herot.net
Director of Engineering: Erin Gennieg - genniege@herot.net
Project Manager: Paul Michael - michaelp@herot.net
Engineer Lead: Ester Long - longe@herot.net
Sr.System Admin: Adam Adams - adamsa@herot.net
System Admin (Intern): Bob Banter - banterb@herot.net
System Admin: Chad Coffee - coffeec@herot.net

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
02-nmap
Figure 2. nmap results

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
03-medusa
Figure 3. medusa result

As we can see, we have been able to break one password. Let’s use it and try to connect using SSH.

ssh aadams@192.168.1.100
04-ssh
Figure 4. SSH connection with aadams

As we can see, we are able to connect. Now that we are inside, let’s see what “sudo” commands we have available.

sudo -l
05-sudo
Figure 5: Available tools

We can see we can use the tool “cat” to read file content. Then, let’s check the files “/etc/passwd” and “/etc/shadow”.

06-cat_shadow
Figure 6: /etc/shadow content

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
07-unshadow
Figure 7. unshadowing the passwd and shadow files

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.

john just_root.txt
08-john
Figure 8. John results

Great! We have the “root” password. Now we can try to connect with SSH using the “root” credentials.

ssh root@192.168.1.100
09-no_root_ssh
Figure 9. SSH connection as “root” failing

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

10-aadams_root
Figure 10: We are root!

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

11-found_file
Figure 11. Curious file
12-encripted_file
Figure 12. encripted file, maybe
bin walk salary_dec2003.csv.enc
15-binwalk
Figure 13. confirming is an excerpted file

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
18-ciphers
Figure 14. Available ciphers

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
16-decripting_file
Figure 15. decripting file

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.

17-files_content
Figure 16. File decrypted

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.

WALKTHROUGH: De-ICE: S1.100

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.