CYBE231 Lab 12 - Final Project Part 3
For the third and final section of the final project, we had to attack other networks and get into the systems that had been secured by other students. Then after some time we had to do intrusion reports on our own systems. When we showed up to lab we were given 2 other people’s ip ranges that we should attack, but we were also given a surprise. This surprise was a new computer on our network, that according to the document we were given. Hadn’t been booted up in a while, and had gone through a few old breaches without being fixed.
On the 2 networks I was given the first thing that I decided to look at was the website since there were multiple ways to get root shells. The two people that I was given both had the llehs
page fixed to no longer to be a root shell. They both incorrectly fixed it however, by removing the page from the source, but left the function call it made in. So I was able to exploit both the machines on the main page, after sending a POST request with the command I wanted to run. This got me in as root on both machines, but I also checked the addUser
page since it originally did not require authentication, and found it to also not be fixed on one of the machines.
Since most of the Windows machines either had all the services removed, or had everything but RDP cut off, I decided to take a look at the surprise box that everyone was given for issues. After a quick scan it revealed A LOT of issues that existed on the box. The first thing I did with it was do a port scan to see what services were open and on what port they were listening. The first thing I saw open was port 1337 which is a common port for malware to open shells, and other malicious things on, so I connected to it with netcat and saw I got a root shell. The next thing that I saw was port 14580 was open, which is a uncommon port to be open, so after a service scan it showed up as an Ubuntu ssh server was running. I went to login on the ssh server, it gave a really long banner before giving a login in prompt, and at the top of the banner it mentioned “backdoor” in quotes, so that seemed like a hint to login as a backdoor. When I did that, it logged me in as a root user without a password. The final thing that I saw was that telnet was open. When I connected to telnet, it asked for a login, so I tried backdoor again, and it once again gave me a root shell this time with less logging. There were probably more vulnerabilities on the surprise box that I did not find alongside all those issues. While I would have liked to found them, I had to move onto intrusion reports.
The first place that I thought to look was the auth.log
on the surprise box because it seemed like the most vulnerable machine that we had. It did not take long before I saw that someone had been in on that machine. In the log, I saw a login from a root user that was not me logging in, and also them adding a pair of users to the system, and putting them in the sudoers
file. Alongside this, I was also able to find a flag in the /
directory that someone had left. This to me says that they came in on the open telnet port since that was where the default working directory was for that shell.
The next boxes that I took a look at were all 3 of the windows machines. I was not able to find any flags or signs of login that was not authorized after turning on the firewall that stopped connections to the unnecessary services except for RDP.
After this I took a look at the website box. I decided to take a look at the auth.log
again to see if anyone was logging in unauthorized. I was not really expecting anything since I had changed all the passwords, but to my surprise there was a login from the root user. After taking a look at cron jobs, it was resetting the root password everyday, which I had missed in the earlier pass on the system. While also looking at the cron jobs there was also one that changed the whole website back to a vulnerable version at the same time, so I was also able to find a user added since that did not require authentication. The cron job however did not change the service file, so the python virtual environment that I enabled was still in place, and made the shell not very useful.