CYBE231 Lab 10 - Final Project Part 1

8 minute read

For CYBE231 we spent the last 3 weeks of class working on a final project. Starting off the lab we were given the scenario of we were in the IT department of a hospital, with a security director retiring soon. After talking with people we were told while we do not have the formal education, there would be a set of tasks setup to be completed to see if we would be up to the task of taking over the security director position.

The first of these tasks was to conduct a penetration test on the hospital’s systems. We were given an IP range, the names of the machiens, along with physical acess to a single machine to conduct this test and document any issues that were found. The IP range that I was given was 15.218.53.150-160, and the names of “Ambulance Laptop”, “Recpetion Desktop”, “Clinician Desktop”, “Web Server”, and “Database”.

Since this was relativelyt little information I did an nmap scan nmap 15.215.53.150-161 to see what was open on what system, which came back like this.

IP Port Service
15.218.53.150 22, 8000 SSH, Web Server
15.218.53.152 135, 139, 445, 3389 msrpc, netbios-ssn, microsoft-ds, ms-wbt-server
15.218.53.154 135, 139, 445 msrpc, netbios-ssn, microsoft-ds
15.218.53.156 Up, but no open ports No open ports
15.218.53.158 135, 139, 445, 3389 msrpc, netbios-ssn, microsoft-ds, ms-wbt-server

While this gave some good information it didn’t feel that was enough info and wanted some more, so I decided to do a couple more scans nmap -sV, nmap -sS, and nmap -O on the ip ranges. The first scan -sV was a version scan that did a good job of collecting more information like the running version of services. The second scan -sS revealed nothing interesting, and the third used a lot of the prior information to guess the operating system. I then also used the a few scripts built into the nmap scripting engine to look for easily exploitable systems primarily Eternal Blue based. While doing this I also noted down some other issues that I think might exist on the systems that the scan could not find.

IP Port Service Operating System Potential Vulnerabilities
15.218.53.150 22, 8000 Ubuntu OpenSSH 7.6p1, Nginx Ubuntu Linux 4.15-5.6 Web Server
15.218.53.152 135, 139, 445, 3389 MS Windows RPC, MS Windows netbios-ssn, Unidentifiable microsoft-ds, MS Terminal Service(ms-wbt-server) Windows 10 1511 - 1607 Poor Passwords for RDP
15.218.53.154 135, 139, 445 MS Windows RPC, MS Windows netbios-ssn, MS Windows XP microsoft-ds Windows XP SP2 or SP3 MS08-067, MS17-010
15.218.53.156 Up, but no open ports No open ports No clear operating system This might be the physical access system
15.218.53.158 135, 139, 445, 3389 MS Windows RPC, MS Windows netbios-ssn, MS Windows 7-10 microsoft-ds, MS Terminal Service(ms-wbt-server) Windows 10 1507-1607 MS17-010, Poor passwords for RDP

With a few clear vulnerabilities that could be exploited I decided to work on those first to use the systems as footholds if it was necessary. So I started up metasploit and decided to set my sites on system ending 154 since it seemed the most likely to be vulnerable.

After loading up the MS08-067 module, and setting the correct details for the exploit, I let it run to success. The next first thing that I decided to do after having access was dump the hashes, and start the cracking process since it could take some time. To my surprise, LM hashes were still enabled and stored for the system which made the cracking process significantly faster having only a pair of 7 characters to try for each user. Hash Dump

I started out this process only using John the Ripper on the virtual machine we were given, but I quickly realized that was going to take much longer than I would have wanted, since it was only able to run on a single virtual machine CPU core. I took the picture of the hashes ran them through an OCR tools and fixed the mistakes to get a text file on my laptop with the hashes. I then used hashcat on my laptop since it has relatively easy to enable GPU acceleration for password cracking. Cracking all the LM hashes only took a few minutes and could be done without a wordlist, and just incrementing through all the possible passwords. Cracking the NTLM hashes was a little harder and required generating a wordlist based on the previously cracked LM hashes. To do this, I found a ruleset for permutations, so that hashcat would generate the wordlist on the fly here https://blog.didierstevens.com/2016/07/16/tool-to-generate-hashcat-toggle-rules/. This worked well and it only took a few seconds to crack the case-sensitive passwords for the NTLM hashes.

Cracked LM Hashes

Jan Esgroye:789ad9fede5613a7818c64b83048626e:9J"XH`^V4Z
Cindy Rizen:f52a3f0a52175738a7f717d76645e4a6:MYDOGRULEZ
Collin Dune:2ab875a58f32047b3dfc1bb995e4229d:L46NIKTKDO
Administrator:cc01954a4137d5d78b0ea5a7df135b03:R0ADTR1P
HelpAssistant:ddfa615c139783e78c02812a41dbc807:YD$3QSBFXO8GI1
Omar Henriquez:60549f73b8c3aa361a4bb984f7232bed:SPRING202!

Cracked NTLM Hashes

Administrator:565c3996932701fed3c38e70b7e98768:r0adTr1p
Cindy Rizen:858fbc169a0b58777680d3313de96805:mydogrulez
Jan Esgroye:04ebc5722c56bbe00757b93be9f71844:9j"Xh`^V4z
Collin Dune:50a934cc3da931218937bb84e229b7ce:l46NIKTKdo
HelpAssistant:c3b7cfdfa3af3b1cfeb99101181830f4:yD$3QsbFxo8gI1
Omar Henriquez:f7f49473c0a997b4cd52f9dbaec069bc:Spring202!

Having the passwords, and an exploit were enough to show how sensitive data could be obtained, so I decided to move onto the next box ending in 158 since it appeared to be vulnerable to MS17-010. I loaded up the module in metasploit, and set the proper variables and ran the exploit. This got me full access to the machine, where I decided to poke around on the files on the machine to see what I could find. Looking around I found a shared folder labeled Ambulance calls which included things like when a call happened, where it went to, and the way the patient was treated and brought to the hospital. This let me conclude that this was the Ambulance Laptop, and by having sensitive patient information easily accessible, and a way in was enough to show that the system could be compromised.

After that I moved onto the last Windows machine which ended in 152. Looking at this, there were no clear easily exploitable vulnerabilities on the system. But I decided to connect to RDP and see what I could find there. Upon connection it showed the system’s name as Reception Desktop, knowing this I looked back at the briefing we were given to see if it said anything about the Receptionist since that seems like a good place to try “social engineer”. Looking at it mentions in our talk with the receptionist she named her yellow car after her favorite ice cream flavor, so I thought that name was probably the password. This actually took me quite a bit of time to get right as the password was vanilla, but I tried basically every other flavor that I could think of before this like pineapple, lemon, mango, and others before finally getting the right one. After getting in, I saw that the user I got in as Rachel was an admin on the system, so I had full access the system, and on teh desktop there was a link to a contact that contained the contact for doctors and patients of the hospital. That gave me the sensitive information needed for the compromise, so I moved onto the machine that I had physical access to, the database.

On the database there were a variety of ways that you could get into the system like booting into single user mode, or adding a Kali live image and running from there. I decided to use a Kali live image to boot to, where I then mounted the hard drive of the system. Opening up the passwd and shadow files, I edit the default user games to have a login with no password and shell, then added them to the sudoers group. This way on reboot I could login as the user and root access. In doing so, I was able to see that the database running was a mysql database without a password. This database contained, names, credit card numbers, and social security number. Since I could show access to highly sensitive information I could move onto what I thought would be the most interesting system, the web server ending in 150.

This was the most interesting to me as it appeared to be a purely self build django site including many things like a login page, and user checking. After going to the site, the first thing that I wanted to look at was the javascript that came with it to see what was happening locally. Quickly I saw that there was a pair of what looked like shell parsers one with on the root of the site, and another the path /llehs of shell backwards. I decided to go to the llehs page first, and to my surprise there was prompt to run a command. Doing a quick whoami showed that I was running as the root user, unfortunately this did not allow for interactive application like passwd, so I then decided to take a look at the passwd and shadow files and prepared to use linux pipes to finagle them into how I wanted them. But even more to my surprise, the root user did not have a password. With this, I was able to login as root over ssh. After getting into the system and taking a look at the how the website was built there were a variety of errors that could be actively exploited. The addUser page did not do proper authentication, and could be used by anyone. When creating accounts the site did not hash passwords, instead it took them in plaintext, and “encrypted” them with a custom encryption that failed to add entropy making it easy to create a decrypter for. There was also another shell on the root page like I thought, and it gets sent over when a POST instead of GET request is sent. Alongside these issues django supports python virtual environments to highly limit what a user who gets remote code execution access to can do, and this was actively turned off which allowed us to do all the things on the shell.

After getting into the all the systems, and documenting the issues, alongside the personal data that could be gathered from them. The task for next week was remediate these issues and attempt to fix the systems.

Categories:

Updated: