So I haven’t been posting too many tutorials on this blog. I’m taking a different direction with the tutorial. For capstone project, my teammate and I are working on building an intentionally secure web application that incorporates the OWASP TOP 10.
We’re designing the website as walkthrough/tutorial. I think that form factor will be much more easily digestible than just posting a long instructions.
In the meantime, checkout this capstone poster we created.
Whew.. the past few weeks for me have been pretty hectic – it’s mostly work. Posting here on my blog has slowed to a crawl. The tutorials take up a quite a bit of time to write up.
If you’ve been keeping up, you’ll know that I have my Offensive Security Certified Professional Certification and recently earned my OSWE (Offensive Security Web Expert) certification in January. My ultimate goal to achieve OSCE status over the next 18 months.
An Offensive Security Certified Expert (OSCE) requires three certifications to achieve – OSWE, Offensive Security Exploit Developer (OSED), and Offensive Security Expert Penetration Tester (OSEP). I have one of the three.
I decided to enroll earlier this week in OSED. The course work primarily deals with binary exploitation (Stack, Return Oriented Programming, etc) of Windows Executable. It doesn’t really get into heap exploitation, but I’ve been studying up on that through open source materials.
I’m pretty excited about starting the new class and I’ll keep everyone updated on my progress as well trying to post new tutorials.
The above command will clone my repository into your working directory and will checkout the “sqli_poc” branch.
You’ll need to create main working directory of the web app, you’ll need to create a folder named “database” and inside the “database” folder, a file named “db_connector.js”.
Contents of “db_connector.js”:
You’ll need to enter the contents of your username and credentials.
Vulnerable Piece of Code
The vulnerable piece of code is located in the “sqli.js” file:
In this code we are creating an sql query by concatenating user input directly. This is always a bade idea.
Testing out the Vulnerability
We’re going to run the web application:
Then open up a browser and browse to “http://127.0.0.1/sqli/test”:
The web application requires a name, in this case I’ll provide the name of “francis” because that name is currently in the user table in my capstone database. The website will return the following page:
The query return my full name.
Proof of Concept
If we enter the following into the text area:
'UNION ALL SELECT 1,2,3;#
Explanation of the POC:
‘ (single quote) :: the single quote in the beginning “closed off” the single quote in our sql query
Essentially the query became:
SELECT users.userId, users.first_name, users.last_name FROM users WHERE users.first_name = ”
it’s a valid query, but it’s an empty record
UNION ALL SELECT 1,2,3
This will join the previous query with the “SELECT 1,2,3” query.
In the initial query there are three attributes it’s pulling from the DB – userId, first_name, and last_name
SELECT 1,2,3 must match the number attributes pulled, otherwise the union/join will be an error. In SQL Unions between two tables have to have the same number of attributes/columns, hence why we perform SELECT 1,2,3
If the previous query only pulled to records from db, our UNION Select statement would be “UNION ALL SELECT 1,2”
; (semi-colon) :: this signifies the end of an sql statement
#(hashtag) :: everything after this is commented out, it’s not treated as query.
Pulling data from another table in the database
A “UNION” is interesting but not all that useful, however, what it does provide is an indication that the server is vulnerable. With this in mind, it’s possible pull information from other parts of the database.
Recall that our web application was only pulling information from the “users” table. With an sqli vulnerability, we can grab information that we were not meant to see. Example:
'UNION ALL SELECT 1,(SELECT password from credentials where userID=1), 3;#
Here we were able to pull the password attribute from a completely different table – “credentials”.
Anyway I hope this post proved enlightening. I’ll probably revisit this to provide some more detail. I’ve been pretty busy with work lately.
In the next series of posts I’m going to provide a tutorial on how to write and exploit and SQL Injection vulnerability on a web applications. However, before we can get there we need to setup our database.
We could set it up on our local machine, but that would be too easy, instead we’ll use Amazon’s RDS (relation database service) to setup our database.
I’m not going to walk you through creating an AWS account, it’s pretty straightforward. I’m going to assume you have an account.
1 Navigate to the RDS Service Dashboard
If you don’t know how to get to the RDS Service, you can search for it:
You’ll be presented with following dashboard:
II. Create Database
In the Create Database page, we’ll select the following features:
Database Creation Method – “Standard Create”
Database Engine – “MySQL”
Version – 8.0.27
Template – “Free Tier”
DB Settings – Username/Password
Instance Class – Leave Default
Storage – Leave Default
Connectivity – Leave Default
Database Authentication – “Password”
You’ll be re-directed to the following screen:
It will take a few minutes for the server to get created on AWS’ servers. The server is technically created/built at this point, however, we now have to make it accessible from the Internet, i.e. your home computer.
Click on the “database-1” hyperlink to configure
III. Make the DB “Publicly Accessible
Click on “Modify”
In the “Connectivity Section”, Click on “Additional Cofiguration”:
Select “Publicly Accessible” option:
Click on “Continue” at the bottom of the page
Click on “Modify DB Instance” on the next page
We are not yet complete with our configuration. You’re RDS or EC2 instances inside your VPC (Virtual Private Cloud) have NACLS (Network Access Control Lists) and Security Groups (SGs) applied to them:
IV. Quick Lesson on SG and NACLS
Think of Security Groups as Host Level Firewalls. All of your instances running in your VPC must have a Security Group applied to them.
With Security Groups, you set the allowable ports/protocols/services and source addresses.
Network Access Control Lists
NACLs are applied to the subnets in your VPC. Every subnet in your VPC must have NACL associated with it.
All of your instances will belong to a Subnet.
All of your Subnets will have a NACL applied to them.
With NACLS, you can configure based on IP address(es) and Ports
If you have NACLs set to allow “All traffic” through, but your Security Group is “Deny All”, you won’t be able to reach your instance
If you have your NACL set to “Deny All”, but your SG to “Allow All”, you won’t be able to reach your instance
A good strategy with managing NACLs and SG is:
NACLs: Filter only by IP and allow all ports/protocols
Security Groups: Filter by Ports/Protocols
V. Configuring the Security Group
From RDS Dashboard, click on your DB Instances
Select your DB Instance
Under the “Connectivity and Security” menu, select the default security group
Recall that this was left to default when first created the DB
This Dashboard shows which SGs are applied to our RDS instance and we can just follow the links to edit it.
Select “Edit inbound rules”
Add rule to allow “MYSQL/Aurora” traffic type from the drop down
Select “Save Rules”
VI. Configuring the NACL
From RDS Dashboard, select “DB Instances”, then select your running RDS instance
Click on the VPC hyperlink under “VPC”
Click on the hyperlink under “Main network ACL”
mine is “acl-f483728f”
your’s will be different
Click on the “Inbound Rules” tab, then “Edit Inbound Rules”
Add a rule to allow all ports and traffic (0.0.0.0/0)