Hey, everyone.
My name is Casey Dunham.
Thank you for joining me on Pluralsight to learn how to use sqlmap to gain
initial access by exploiting SQL injections. Many teams will find it
useful to use sqlmap For red teams, it simplifies the process of
identifying and exploiting SQL injection flaws.
Blue teams and developers can use it to check that
security controls are working as intended.
This is also an ideal tool to use during the testing phase of
a secure software development lifecycle.
I want to take a moment to acknowledge and thank the creators of
sqlmap. Bernardo Demele and Miroslav Stampar continue to do an
incredible job developing sqlmap.
It's been an often‑used part of my toolkit for a long time. From
myself and the community, thank you for your work.
Sqlmap's capabilities extend beyond only identifying SQL injections.
It removes a lot of the manual and very often tedious
work in exploiting these flaws.
This is especially true when working with time‑based and blind SQL injections.
You can use sqlmap to fingerprint the type and version of the database in use.
You can enumerate the database schema and exfiltrate data.
Under the right circumstances,
you can even use it to gain an initial foothold into the system.
You can find sqlmap releases and documentation on the
sqlmap home page at sqlmap.org.
The sqlmap source code is available on GitHub. Sqlmap will run on any
platform that supports Python 2.6, 2.7, or Python 3.
It is also preinstalled on Kali Linux.
So where does sqlmap fit in on the kill chain? Since sqlmap is an active
identification tool, it fits in at the exploitation phase. Any web
application that you find during the reconnaissance phase may be
vulnerable to SQL injection. You can use sqlmap to detect and exploit
these flaws. In the MITRE ATT&CK framework, sqlmap is a tool that can
provide you with your initial access.
This places it under tactic T1190, Exploiting a Public Facing
Application. Once you gain initial access,
you'll need to turn to other tools.
Sqlmap can help you with privilege escalation or pivoting
further into the target environment.
Let's take a moment to review what a typical attack scenario
involving a SQL injection looks like. The following is a simple
web application architecture. Both the application and database
live on their own servers.
A network firewall sits between the application server and the public internet.
All network connections use HTTPS with modern and secure configurations.
The database also uses at rest encryption.
Consider the scenario where a normal user attempts to
access the data of another user.
The user authenticates to the application and
attempts to view the other user's data.
Now, the user's interaction with the application occurs in
the context of their own user account.
Logic within the application determines what the user can and cannot see.
This is generally based on some form of role‑based access control.
The application implements access control through constraints
it adds to its queries to the database.
The application queries the database using its own
service account and credentials.
This connection is most likely the same, regardless of who the
application user is. Now, a SQL injection modifies the query that
the application sends to the database.
When this happens,
the database has no way of knowing that it isn't what
the application intended to ask for.
All it sees is that the query is coming from the application.
Likewise,
the application has no way of knowing it's
receiving more data than it should be.
This means that if an attacker can exploit a SQL injection flaw,
they could access any data available to the application.
This is because they will often be able to bypass the
application‑level access controls.
It's also worth mentioning that stored procedures and views by
themselves don't provide protections against SQL injections.
A SQL injection may still exist in either of these if they
aren't handling user controlled data properly.
Likewise,
the at rest encryption the database is using is also not a
defense since the data needs to be unencrypted for the
application to make use of it.
One last thing to note is that this is all going to
go unnoticed by the firewall.
The network firewall operates at a level below the
application. It has no way of knowing whether the user has
legitimate access to the data or not.
While a web application firewall can offer some
protections against SQL injection exploitations,
it isn't a replacement for fixing the vulnerable application code.
Now, this is all a simplified view of real life. SQL injections
are generally much more complex to exploit,
but they're almost always exploitable.