CYBE231 Lab 3 - Vulnerabilities and Foothold

This lab we started looking at vulnerabilities and exploiting them. In the prior lab we talked about fingerprinting systems and the services running on them to take a guess at the vulnerabilities, but that can require a lot of work, and be hard to keep documented and updated. So to start off with this lab we focused on some for automated ways to find the vulnerabilities. Firstly with the nmap scripting engine, where we scanned and collected all the banners on the systems (15.218.53.100, .102, .104, .106, .108, .110) to show how it can be used to gather information, on many systems at once in a scripted manner. We then used another script smb-vuln-ms08-067. To scan the systems to see if any of the machines were vulnerable to the MS08-067 bug and could be exploited. There was a box that was vulnerable system 15.218.53.100 was vulnerable.

Individually scanning all your systems is time-consuming, and hard to manage if you are attempting to secure systems. This is where passive tools can come in that will scan systems automatically, and report the potential issues found. We used Nessus to scan our systems. After taking some time to scan, we found that every single one of our systems was vulnerable to some number of vulnerabilities, with our Windows 2000 box being the most vulnerable.

The next step that we took was a walk-through of the basic of Metasploit. We started up the Metasploit framework, navigated to the SMB vulnerabilities, found an exploit that would work against the Windows 2000 system (MS08-067), configured it to target the correct host, then launched the ms08-067 exploit against the Windows 2000 Machine. Shortly after it showed that exploit completed successfully, and we could do things like dump the system info with sysinfo. Then next task we were set on was to find some other commands that could be run in Metasploit that would be beneficial to an attacker. The few that seemed most useful to me were getsystem, upload, route, and execute. These are all commands that have the ability to escalate privilege, or monitor the system traffic to potentially find new devices on the same network.

Having access is nice, but what about when the machine is rebooted or updated. That would mean finding a new exploit to use, and is a pain. So the next step was to set up a backdoor that will allow us access anytime we want. Since we are running as SYSTEM and executing our code through the SMB process itself. We first migrate to another service that will be running at the system’s boot like explorer. We then run the persistence command, which will set up a TCP reverse shell with the settings to start at boot, and send pings back to our Kali box every 5 seconds. We then start a listener on our Kali machine, and rebooted to start the reverse shell.

To finish off the lab we had to exploit a different machine and gain persistence on it. The first thing that I thought about doing was trying a super simple password spray while looking for other attack opportunities. I wrote a quick set of usernames common for this class and for CYBE 230 root, admin, ubuntu, cpre230, cpre231, bob, alice, chuck, and a set of passwords to go with it admin, toor, root, ubuntu, cpre230, cpre231, alicepw, bobpw, chuckpw, rootpw. Then used the ssh_login module in Metasploit with a 1-second delay between attempts on each machine in an attempt to prevent being locked out from something like fail2ban on each machine with ssh open. After a short time running, it found that the username cpre231 and the password cpre231 worked to login on the Ubuntu box ending in 104. This got be into the machine with a weak credentials vulnerability. After dropping to a shell, the next thing I did was try sudo whoami to see if the user had sudo access, which they did. With now having the highest level of control over the machine, the way I decided to create a backdoor was by creating a password for a user to let me login as I please. Since Ubuntu has a variety of pre-configured usernames, that are without passwords, I picked one of them ```games`` changed the password, then added them to the sudoers group to allow me to login and run things as root whenever I please. All while seeming like “fairly normal” activity since it is just a regular simple ssh session with propers authentication being used.