Back to Basics
As a penetration tester, it is easy to fall into the trap of looking for the big kill. We look for that SQL Injection (SQLi) or Cross Site Scripting (XSS) flaw that will result in compromise, or even that Zero-day (0-day) that will amaze everyone around us, but we often need to go back to the basics. I was reminded of this on an engagement we performed the other week.
A fellow tester was working on an application and found a Local File Inclusion (LFI) vulnerability. He was able to download/access any file in the web path, but Remote File Inclusion(RFI) was not working. He also could not escape out of the web root. He reached out for help and I gave it a shot.
After looking at the files we could download, I found out the default username and password used for the application. Upon navigating to the '/admin' page, I found a login page. At first I second guessed myself because the login form showed a username field of "email address". I shook it off and tried anyways using the default username and password combination, "admin/password". (I know, real secure right?)
Lo and behold, I then had complete access to manage the site. I could create pages, change content, manage users, anything. I turned it back over to the tester that was working the engagement, but what else can we do from here?
How about creating a page that will give us a reverse shell? Uploading a simple php shell is easy, and once done, you just navigae to the page and you have shell access. Depending on the user account the web application is running under (sometimes root) you can do different things.
First off, you can look at files on the system. You never know what you will find. I have found Secure Shell (SSH) keys that allow access to other systems. I have also found files containing username/password combinations.
Secondly, and another "back to basics" item, you may be able to elevate your privileges. On a Linux box? Type 'sudo su' and see what happens. Recently I was on an engagement where we found a username/password combination in source code, used that to SSH to a box, and typed 'sudo su' and had root access. Bingo was his name-o!
If the user you are running under is not a super user, there are other ways of elevating privileges. Try them out and see what happens! Then use this level of access to grab password hashes and try to pivot around.
Lastly, at a minimum, this system can become a pivot point. Route your traffic through this box, and attack more systems on the DMZ, if they have that setup (hopefully they do), and eventually make your way inside the internal network.
The last "back to basics" point I want to make is, it is not always about getting root/administrator access. There are more important things to look for. Depending on the organization, looking for Protected Health Information (PHI) or Personally Identifiable Information (PII) could be more important. Make sure your test is matching up with the goals of the organization. Sure, you got root access, but if their information is still safe, then you failed.
Let's make sure we always start with the basics, and when that is stopped, then reach further into your toolbox. And as a defender, make sure you change all the default passwords to something that corresponds with your password policy.
