Introduction
It's been a while since I’ve written a post about some of my penetration testing adventures and thought I’d begin to share a few of my experiences / bugs I’ve identified through the last year of sporadic bug bounty hunting.
To start, I prefer performing network testing off the jump, however there are some nights where I’ll become bored and tired of looking into Active Directory and malware development, and randomly select a program that has a bug bounty program and just go against some live targets with some whiskey poured up and music going. I know this sounds crazy, but using this method of madness, allowed me to choose a program off of Intigriti’s client list and landed me in the top 50 leaderboard!
But if you’ve made it this far, welcome to a tad bit of my methodology as I identified a SQL Injection on a live target. . .
Identification
To begin, the target program is a huge university I have ties with and had a huge in-scope target range. Keeping this in mind, this gave me the idea that various types of application could be exposed ranging from teacher/student applications, student services, dorm/building maintenance, athletics, the whole 9. But after performing some initial recon, I stumbled across an application that just gave me the vibe to tell myself “yo check this out” . So I did.
Typically when I begin analyzing a web application, I’ll walk through the application as a typical end user would. That means clicking all available links, inserting malicious characters into input boxes, and attempting to get an understanding of what the application is expected to be used as.
In this particular instance, I was able to identify an error message that was presented to the user as an alert box. Typically, web applications will present this type of alert box when a user has met the application’s input validations expectation, shown below.
However, this is when its important to dig a little deeper and analyze the underlying HTTP response using a tool such as Burp Suite or OWASP Zap. I utilized the web proxy to intercept the HTTP request prior to sending it to the application server and injecting the malicious character and identifying the application revealing a 500 HTTP response code with a Microsoft SQL Server error message.
Seeing this type of response should have any type of security researcher eyes light up like a CHRISTMAS TREE!
Exploitation
To perform the exploitation, I ended up performing a simple logic check and passing true or false statements to the application and analyzing the output of the application. For the first instance, I ended up passing the 'or 1='1 statement with the assumption the underlying application was utilizing the following SQL query:
SELECT id, requestor_name FROM requests WHERE id = ' " + userInput + " ';Since we control the userInput variable and successfully abide the SQL syntax, the application should function normally as a end user supplied the correct information.
Subsequently, I passed a false statement and successfully returned nothing with the statement no longer being true.
Finally, to confirm the SQL injection existed, I ended up performing a sleep command using the WAITFOR DELAY syntax payload. Typically, I’ll insert a random variable that is not a multiple of 5 to prove I’m able to control the underlying SQL query being performed. In this instance, I used 8.
Timeline
Immediately after confirming the SQL injection existed, I immediately reached out to the concern parties and went through some of my old connections to get this in-front of the required personnel.
This was just a random Friday night where I ended up doing some security research and ended up finding a pretty cool bug, and spend another free Friday night writing up this blog.
Hope you guys enjoy walking through my attack methodlogy and getting a feel for what goes through my mind as I attack applications in my day to day or during free time. As always, if you guys have any questions or concerns, feel free to give me a holla!
Cheers,
jb00gie
