Each one of us has a different way to learn and understand technical concepts. Therefore I thought of
adding text writeups for my SQLi LABS series to go along with the videos.
This covers theory of SQL injections, different types and the basics of error based sql injections. Less-1, Less-2, Less-3 and Less-4 are discussed in the writeup.
Second order injections are the ones which are not widely discussed. Firstly these cannot be detected by tools and one needs to understand the application logic and flow to detect this. A code review is better to understand the injection.
In general the Injections happen when the developer trusts the input/or fails to sanitize input to build up the query being used in the application.
What are second order injection?
Second order injections can be considered simmilar to the stored XSS. Injection does not directly yeild result but this injection is used at some other places insecurely causing the injection to trigger and yield results.
As an Example to understand this imagine an application which allows user to create a user account in the system. Now a malicious user can try to inject SQL keywords in the user creation form which is nicely escaping dangerous characters by use of mysql_real_escape_string() and making it safe for that form. Because mysql_real_escape_string() escapes the dangerous chars, therefore if attacker tries to inject admin' OR 1=1-- in the username field, because of the function, the quotes would be escaped and input would become admin\' or 1=1--. If other values of form are valid, the user account is created with the name admin' OR 1=1-- .
Now with the user created, he can login with newly created account and go to the password reset page. As this page is checking for old password , and building up a query behind the scene something like UPDATE users SET passwd="New_Pass" WHERE username="Username" and passwd="oldpassword"
Now as the username is being taken from the database, the developer treats this as trusted info. As he is confident that initially there is no SQL Injection on the pages. This blind trust on the data from database is called without any escaping, thereby causing the username to trigger the SQL injection.
The query becomesUPDATE users SET passwd="New_Pass" WHERE username =' admin' -- ' AND password=' old password '.
Effectively SQLi working and changing the password of Admin user commenting out rest of query which is marked in brown
A video demonstration for the same can be found on the location below.
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
As we discussed before in the earlier posts, enumeration is the first and very essential part of every penetration test. Knowing the workflow of application is trivial to its testing. The more one knows about the application, the better and effective it becomes.
Secondly, all input parameters should be tested. These do not include just the form fields, but also the other input fields like the referrers, user-agent, cookies. Developers these days take care to sanitize the the form inputs and take extra care for those but forget to pay the same attention to the other inputs.
We discussed the injection in update query and injection in the headers in our previous lessons. In this lesson we will discuss the injection via cookies.
Technically speaking, it is trivial to understand, how cookies are being generated by application and how the same is used within application. Understanding the cookie generation logic is trivial to the successful testing.
In Less-20, we introduce the basics and use a clear text cookie generation logic to explain. There is no difference in how the injection is performed via a cookie or any other form parameter. In Less-20 and 21 we deal with error based injections.
Less-21 uses an encoded cookie value and the application logic is used to encode and decode the data and use the result in the queries later on.
Because both are error based based injections, and the database is interacting with the webpage, therefore we can use union statements to dump the databases or we can use the double query injections for dumping the database.
For enumerating the application, we first try to see the workflow off application by providing a legitimate input.
This successful login places a cookie in the user browser with Key value ==> pair. Cookie name uname and value as username.
This cookie value is then used to retrieve some information from the database causing the vulnerable injection point.
Using firebug, tamperdata or any interceptor proxy like burp suite, ZAP (Zed Attack Proxy), web scarab or any other similar, we can modify the cookies and inject in our payloads. Fuzzing the cookies, we observe that sql query breaks and mysql error is displayed on the screen.
Once we achieve this error, then this can be considered similar to error based injection and proceed accordingly to dump the database.
For Less-21 we observe that the system is using Base64 encoding scheme to send an encoded cookie to the browser. Hence forth we need to encode our injections using Base64 to be consumed nicely by the web application.
In the earlier parts of the series we looked at the GET and POST based injections and dived into details on error based SQL Injections (string type, Integer type), Double Query injections error based, Blind injections (Boolean based and Time based) or use the outfile/dumpfile to . In this part we would look at the injections in the update Query. For this we would look at the Less-17.
A general update query looks like
UPDATE TABLE SET PARAMETER-1="some value" WHERE PARAMETER-2="some value";
In the general case, a front end for a password update or profile update would have this query working in the backend. During a pentest be extra careful while handling these queries, because one wrong test can update the complete production database with wrong values.
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
In the update statement injection, our objective is to extract info and not update the database, therefore we can use the the basics of
Double query injection
Blind injection
Dumpfile/outfile to extract the information.
Basic query injections: Less-17 Line number 97 $update="UPDATE users SET password = '$passwd' WHERE username='$row1'";
Thanks a ton to everyone who are watching/following the videos series closely and also appreciating it. Another link on Facebook posted by Vivek Ramachandran, I am really really touched with the wonderful words from the Guru himself..... thanks a ton.
In the last part we started to explore the error based sql injections in the POST parameters. We were able to use the UNION statements to dump the database of the test bed. In a situation when the database does not interact with the web page and only was the database displays some info on the web page is through the mysql errors. Then in this case the fastest way to extract the info is through use of type caste errors involving sub queries also referred to as double queries, but MYSQL is very flexible and returns empty rows rather than throwing an error, so infosec guru's figured out some combinations of functions, if combined make sql queries which pass the compile time check but throw run-time errors. With the errors dumps the useful info which is needed.
DOUBLE QUERY INJECTIONS
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
As these involve sub query injections, the focus is to use the internal query to dump the info we want and wrap around a query which is syntactically correct, passing the compile time checks and produces error at run time and in process spit the core query as part of error.
In MYSQL this is achieved by using combination of count() and group by clause. In my personal understanding issue happens when the aggregate functions produce dynamic entries and group by clause clubs them and with the next round of aggregate function finds the values changed, causing duplicate entry issues. We discussed the same during the part 6. There the injection point was in GET parameter, and in this we used the POST parameter.
For detailed instructions, you can follow the video.
Basic query to cause injections :
Less-13 line number 57 @$sql="SELECT username, password FROM users WHERE username=('$uname') and password=('$passwd') LIMIT 0,1"; ') or ('1')=('1 Will work nicely if injected in username and password field. username = ('') or ('1')=('1 ') AND password = ('') or ('1')=('1') ') or 1=1 --+ Will also work only in one field. username = ('') or 1=1 --+' commented out ') or 1=1 # will also work only in one field. username = ('') or 1=1 #' commented out
Less-14 Line 57,58,59 $uname='"'.$uname.'"'; $passwd='"'.$passwd.'"'; @$sql="SELECT username, password FROM users WHERE username=$uname and password=$passwd LIMIT 0,1";
" or "1"="1 Will work nicely. username = "" or "1"="1" AND password = "" or "1"= "1" " or 1=1 --+ Will also work. username = "" or 1=1 --+" commented out " or 1=1 # will also work. username = "" or 1=1 # " commented out
Thank you all your feedback's and the responses. I am highly motivated to complete this series and start with a new one soon after.
Today we will discuss about the injections in the forms. In the last 11 lessons of the series we discussed injections via the GET request. When I had started to learn this topic, I realized that a lot of stuff was available on internet for the GET based injections but POST injections were rarely discussed. That increased curiosity in me much and this was the point when i started this lab. The forms , lesson 11 to 20 are different implementations similar to GET method. We would cover
Error based injections
Double Query injections
Boolean based Blind injections
Time based Blind Injections
Injections in update query
Injections in the Headers
Injections in cookies
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
POST BASED INJECTIONS
In general, nothing changes with the change in injection point. The logic for injection remains the same, the process remains the same. In a general scenario we take up Less-11 and 12 for this. As the page displays a login field. therefore we can build our first sudo query which would be behind the scene as
SELECT * FROM table WHERE username="$uname" and password="$password".
The basic steps involved in the testing to exploitation are:
1. Fuzzing: Try to give random inputs to all points where it is accepted, be creative and send the values which the developer has failed to visualize. Objective is to try to break the underlying query and gain more insite on how the query is formulated by reviewing error.
2. Then try to fix the query by either providing the extra characters to balance off what we injected to break the query or comment off rest of query in such a way that it gets fixed.
3. Once we successfully achieved the above, we effectively get the left side, and right side of the injection and sql statement we inject in between these gets executed on backend.
As discussed in the previous post on error based injections, we used the UNION SELECT to dump the DB because the database layer was interacting with the web page and columns from table were visible on screen. same way we can see that a successful login leads to display of the username and password.
This can then be used to dump the database.
Less-11 line number 57 @$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1"; ' or '1'='1 Will work nicely if injected in username and password field. username = '' or '1'='1' AND password = ' ' or '1'='1 ' ' or 1=1 --+ Will also work only in one field. username = '' or 1=1 --+ ' commented out ' or 1=1 # will also work only in one field. username = '' or 1=1 #' commented out
Less-12 Line 57,58,59 $uname='"'.$uname.'"'; $passwd='"'.$passwd.'"'; @$sql="SELECT username, password FROM users WHERE username=($uname) and password=($passwd) LIMIT 0,1";
") or ("1")=("1 Will work nicely. username = (" ")or ("1")=("1 ") AND password = (" ")or ("1")=("1 ") ") or 1=1 --+ Will also work. username = (" ")or 1=1 --+") commented out ") or 1=1 # will also work. username = (" ") or 1=1 # ") commented out
Today we will take it further and discuss the use of outfile function or dumpfile function.
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
USING THE OUTFILE/DUMPFILE
Well if the connection user which is configured to run the queries to the back-end DB has the privileges to write to file system (webroot of server or any other folder under it), then in that case, we can build queries and use the inbuilt function called outfile or dumpfile.
example query: select * from table into outfile "path-to-file/filename"
There are two functions which can be used in this case, outfile and dumpfile. With dumpfile, it dumps only one row without any formatting details. This is specially important if you are playing with binary data. The outfile preserves the formatting, carriage returns, etc and dumps multiple rows.
To practice this you can follow the Less-7 from the labs.
same way we can use mysql to read files from the file system. for that we can use the function called load_file(). By default we cannot execute system commands through mysql, but if mysql is misconfigured, then can lead to upload of User Defined Functions which can lead to a complete compromise of server.
example injection may look like:
' union select 1,load_file("/etc/passwd"),3 into dumpfile "/var/www/test.txt"
Less -7 Line number 31
$sql="SELECT * FROM users WHERE id=(('$id')) LIMIT 0,1";
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
BLIND INJECTIONS
Continuing the SQLI-LABS series, we discussed the Error based injections, and discussed Union type injections and double query injections. In today's post we would be discussing Blind injections. Blind injections got this name because during blind injections, you do not get any help from the application. All the errors are suppressed from the end user.
Therefore complete injection is based on a guess. The tester does not see any error responses to tune his injections.
Blind Injections can be classified mainly into two categories:
Boolean based Blind injections
Time based Blind injections.
Boolean Based
As per wikipedia "In computer science, the Boolean or logical data type is a data type, having two values (usually denoted true and false), intended to represent the truth values of logic and Boolean algebra. It is named after George Boole, who first defined an algebraic system of logic in the mid 19th century".
Well in certain web applications, you can witness that the database does not write any fields on the web page or somehow union injections do not work, and the mysql errors are also not displayed on the page, so technically there is no direct channel through which the database writes on web page. In this case the only option left is to use blind injections. With Blind injections we cannot dump the strings or names directly but need to deduce names character by character.
In general when we were dealing with error based injections, we ask the database questions like, dump us the database name, version, table names etc. In case of blind injections, we change the way we ask questions to database and rephrase questions like is the first letter of the database this? and answer comes out as either yes or no or true or false. Check the video at the end of the post for more detailed explanation.
Less-8 line number 29 $sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
basic injection example: 1' AND '1'='1 -- returns true
1' AND '1'='0 -- returns false
Therefore by evaluating the strings character by character we can dump the complete database.
CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
DOUBLE QUERY INJECTIONS OR SUBQUERY INJECTIONS.
In the last 5 parts of the series we learnt about some basics about the error based injections and used the UNION statements to dump the database using the web application. Well we could achieve it because the database was interacting with web page and some database fields were visible on the web pages. A basic injection looked like id=-1 union all select 1,2,3 --+ and we were able to see the username name and password field displaying value 2 and 3. For detailed explanation watch video's 2 to 5.
In a scenario when the database does not directly display columns on the wep page, then the above technique cannot be used. To understand this better you can check Lesson 5 or 6 of the sqli-labs series.
As we see we just see a generic message "You are in". Therefore in this case, the database is not displaying any files on the page. In this case only way the database is displaying into is through the mysql error. (note: I am interchangeably using the Lesson 5 and 6, only thing different is way to produce error)
So primary objective in a double query injection is to create a query injection in such a way which is syntactically correct (correct at compile time) but produce an error at run time thereby spitting useful information in the errors. In case of MSSQL server cast errors dumps the info but in case of MYSQL, being flexible returns empty rows. Therefore some genius researchers found a combination of use of aggregate functions, group by clause, and use of random functions to produce errors are run time due to dynamic calculations involved in random function and aggregate function like count.
Hope this makes some sence, after all I am a dhakkan.
Less-5 line number 29
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
' or '1'='1 Will work nicely. id = ' ' or '1'='1 ' LIMIT 0,1
' or 1=1 --+ Will also work. id = '' or 1=1 --+' commented out
' or 1=1 # will also work. id = '' or 1=1 #' commented out
Less-6 line number 28,29
$id = '"'.$id.'"';
$sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";
" or "1"="1 Will work nicely. id = "" or "1"="1" LIMIT 0,1
" or 1=1 --+ Will also work. id = "" or 1=1 --+" commented out
" or 1=1 # will also work. id = "" or 1=1 #" commented out
Issue with me is that I have a very unconventional way of self learning and unless the core concepts are clear, things fall logically in place and I have answer to all how and why questions in my head, cannot accept and retain those thopics.
Well for me my good friend Alper has always been there whenever stupid ideas pop'ed into my head and I needed someone to share, discuss and to show me the right path. Pranab has always supported me in the odd hours of research and learning, when we are trying to understand things....
Shashank another good friend of mine pushed me to share my ideas and know how with others.... so revival of my blog is because of him. Not to forget my buddy Neeraj who was with me in all the ups and downs of my life....(Miss you uncle.................)
Thank a ton to all my friends. It is only because of them that I am what I am today.
SQLI-LABS SERIES
So here I am sharing the little I know....
Plans are big. If audience likes the stuff, then I will invest more time to share and bring forward more subjects.....
I started with SQL Injections...... why SQL injections. Well there is a lot talked about on this subject on internet from basic to advanced stuff but no single resource explains the logic behind the scene for all types in 1 place , how it works and why it works and most are like do this then this and then this but why it needs to be done like that is not explained...........
SQLI-LABS is my attempt to explain the basics involved in SQL injections. I tried to be a DHAKKAN during my explainations.... Hope you all like them.
CAUTION:This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.
SQLI-LABS is a test bed of various lessons to explain and learn different types of SQL injections.
Error Based Sql Injections - Union select type.
Error Based Sql Injections - Double Query type.
Boolian Based Blind Injections.
Time Based Blind Injections.
Dumping the DB using outfile / Dumpfile.
POST based Sql injections Error based type - union select.
POST based Sql injections - Double injection type.
POST based Blind injections -Boolian / Time based.
