SQL INJECTION 101

So a few weeks ago a friend of mine whose a well known developer in Kenya decided to create a website with a login page and posted a link and asked if anyone was able to hack the page. The link to the webpage was posted in a group and i happened to come across it. The information that the developer only gave was that the passwords were stored using MD5 format which any penetration tester will tell you its an easy encryption to crack . So below is how i hacked the website’s login page without much say let’s jump in

So to clarify a few things first the developer told some guys that the website was using a weak encryption algorithm (MD5) and some pen tester guys went straight to brute force attacks but that doesn’t really mean anything because

1. We don’t have a hash that we can crack or have a way to extract the hashes from the server which can only be done by use of another vulnerability like SQL Injection or command injection vulnerability of which as of now we don’t have any of those vulnerabilities on these website
2. Even if the website uses a weak encryption algorithm like MD5 but the password complexity is high (like let’s say the password is automatically generated by a password manager or the developer uses passphrases instead of passwords) you have low chances of cracking the hashes even if by chance you have the hashes. The only way you’ll crack the hashes is by use of a brute force attack and not a wordlist attack and this can be done only if you have a high end PC or laptop for cracking hashes or else it could take you hours or even days to crack those hashes on a low end PC

So the fact that the website uses MD5 encryption doesn’t really change a lot for a pen tester it only shortens the time span taken to crack the hashes if by any chance an attacker gets access to hashes that the website uses. But first things first let’s take a look at the webpage

Looking at the screenshot below we are presented with a login page with an intimidating text saying “Hack Me Buddy” 😄

Sorry i prefer hiding the URL since soon this might become a production server and up to the time when i released the walktrough the vulnerability had also not yet been fixed and i hate to find out that someone on the other end of the world dumped the entire database using sqlmap (a tools that makes SQL injection way easier for anyone) am sure you guys understand

So first i tried to use dump credentials on the login page and found out that the login page uses an email and not username

Emails are generally safer according to my opinion as compared to using usernames and i was not even aware of the current email that the developer uses because of this reason brute force was a lame idea.

So i tried using some dumb email addresses and password to log in to the webpage

And after the validation failed i got yet another intimidating message saying

My next ideas was OSINT a common technique known by many hackers which is to use open source information that is publicly available on the internet and this could gain some useful result and probably give me a valid email. The first thought was to look at social media profile of the developer and probably i would be able to a valid email address

My second idea was to try phishing the developer for the right credentials this technique is real simple and easy to replicate . First we need to create an exact copy of the webpage using a penetration testing software called HTTrack which is Copies websites to your computer (Offline browser) HTTrack is an offline browser utility, allowing you to download a World Wide website from the Internet to a local directory, building recursively all directories, getting HTML, images, and other files from the server to your computer then create our own server and if we find a valid email that the developer uses we could send a phishing email to him and if he fall for it we could get the credentials for the login page but i considered it much work and first decided to test every low hanging vulnerability that a web application might have

First i decided to run gobuster a tool used to brute-force URIs including directories and files as well as DNS subdomains since we might get some important directories that might give us some useful information that might lead us to compromising the webpage

Looking at the gobuster i thought there might be a git repo and the web server but it was a dead end

Next i decided to run sqlmap and try finding if the login page was vulnerable to SQL injection

So i saved the login request to a file

And use the request to run sqlmap

I left the sqlmap running in the background and decided to further enumerate the web application. Looking back at the login page we see that there was an image i downloaded it using wget since i didn’t want to clobber the metadata

After downloading the image i used exiftool to extract metadata from the image and the information that i was mainly interested in was when was the first time that the website went live

Looking at the File Modification Date/Time we see that probably the site was created probably on 4th of October at 11:21 in the morning this might be useful since you might know if this is a production site or not and if it was a content management system (CMS) we would use that date to find if the CMS had a vulnerability or not but enough of that

Looking at the sqlmap i had not found any useful information yet

Instead of waiting to see if it works or not i decided to try authentication bypass techniques using a cheat sheet already available on PayloadAllTheTheings repository on GitHub

But i found out i couldn’t use any SQL injection payloads on the email field

So i though this could be probably because of some client side validation using JavaScript and i decided to take a look at the JavaScript file

And looking above we see the line if code doing the validation i tried intercepting the request using burpsuite and try to see if i could bypass the validation but it didn’t work

And these is where most of the pen testers that tried hacking the page gave up and forgot that the password field is sometimes also vulnerable to SQL injection and i also found out that the password field accepted any input that the user provided to i tried to perform SQL Injection in the password field using a wordlist called Auth_Bypass.txt

But the payloads were many about 198 as you can see in the screenshot below

And trying all these payloads one at a time on a browser wasn’t at all smart and since am a fan of creating exploits i decided to create a python exploit that picks the SQL Injections payload from a file one at a time and submit them and then checks the webpage to see if the injection was successful or not and then return the results to you.

A portion of the source code of the exploit is down below

I wish i could explain the source code of the exploit but its a good learning process if someone tries coding there own exploits since i believe with practice someone becomes better

But since the exploit was ready by the time i created these article we’ll just execute and see what we see

After some time i got a success message

What i decide to try and see if the payload could work on the webpage

And after submitting the payload in the password field with just a bogus email it works like a charm since we had bypass the authentication system using ql injections

And looking at sqlmap it was still going

There was verification of user input in the email field but not in the password field and this caused a SQL Injection vulnerability on the web application and these is a lesson that should be taken by any developer always sanitize user input whether in the username/email or password filed

But that’s it for now guys till next time take care if you liked the walk through you can clap for me down below and also follow me so that you don’t miss any upcoming articles