Script transcript:
Yes, yes, yes I finally did it, I finally found a password that works. Let’s log in, get to hacking
Let’s see what is in here, Ohh userlist.txt, let’s see if I can read that
user list dot t x t : Permission denied
Damn!
Maybe I can copy it from the server to my machine. Just open up a new terminal and scp and …
sscp: forward slash user list dot t x t
Permission denied
Come on, all that time finding web user’s password and they have the right privileges. What a waste… Guess I’ll just gonna have to find a way to escalate my privileges
That incredibly realistic reenactment of a hack in progress gives us a good starting point to discuss just why privilege escalation vulnerabilities are so dangerous.
When a machine or network is initially set up all of the users are typically given only the access to the files and read, write, execute permissions they need.
Take for example the webuser account on the Wisc.edu server. It seems they did not need to be able to read or to copy the user list file, much to the chagrin of our hacker. Which is why they wanted to escalate their privileges.
By doing this escalation our hacker will be trying gain more access to files and read write execute permissions on the server, but really our hacker will not be satisfied until they gain the ultimate privileges, those of the root, or administrator, account. Once the hacker has root there is very little they are unable to do. They can read, write, and execute all files and change any settings they want.
There is no one vector for privilege escalation vulnerabilities. They can come from anywhere including in the form of buggy operating systems, incorrect configuration set ups, poor software design, or really smart hackers.
For example on Windows XP there was a bug where attacker who had access to a user account that was able to modify a screen saver, which was essentially any user, could exploit that the screen saver ran with SYSTEM administrator level privileges to attain those same privileges. A screen saver allowing a hacker to root a system, as was said before these can come from anywhere.
This also means there is no sure way to protect against privilege escalation attacks, but there are some steps which can be taken to minimize there likelihood.
First make sure all accounts use good passwords, and that those passwords are unique. If the hacker can not get into any of the accounts, including low level ones then they can not escalate in the first place.
Second make sure your software is patched, your anti-virus is up to date, and you’re system is malware free. Most escalations are obtained using known vulnerabilities or existing malware so making sure you stay on top of security update and patches and viruses definitions and system scans can really help lower the chances that a hacked account will be able to be successfully escalated.
Third, maintain segmentation. I.E. make sure that getting root access to one system does not translate to other systems. This way a hacker would have to hack all of them separately which makes a catastrophic even much less likely.
Fourth make sure your system is maintaining good logs. This way if something does happen you will be able to determine the what, the how, the why, and even potentially the who.
Finally good luck, and may your systems stay secure and your privileges properly-vated
And that didn’t work either. Damn you wisc.edu sysadmin, why did you have to patch that cron.d exploit. Guess there is nothing for me to do here
logout
Connection to wisc.edu closed.
