Welcome to injection floor session.
In this first part, we will focus on threat analysis. We
will take our time to dig into injection, floors details, then,
we will discuss how the system can be harmed. The
impact of successful exploitation, and give
you some insights to identify who may want to harm. Your system
injection is a very broad concept. No
better place to look for a definition then in the
dictionary, unfortunately, we don't get that much
here, but keep in mind that we are talking about something that
is injected.
And so we need a place where to in check. Let's
see what the dictionary still has to offer. Following some links following
the link in the injected word. We get something
far more interesting. What is injected is
something arbitrary or inappropriately in
knapsack this inappropriately. Something is
called payload. In the next few minutes. We
will do our way to find. What is this something? And
to find a place where to inject it. We have
discussed the World Wide Web architecture before
But now I want to look at it from another perspective. In
the image. We call server to the whole infrastructure required
to satisfy client requests, including web application. Firewalls.
HTTP servers, back-end database servers,
and even third party Services note
that data flows through all these systems back and forth to
satisfy client requests. The server is a business
asset in the right place to keep valuable data such as
the, user database, health records, financial data Etc,
direct access to the server.
Over is expected to be reserved to authorize parties.
And attackers are not supposed to be one of them. If
attackers cannot directly access, the silver nor
the data, then the best they can do is behave like a
regular client. Of course, they won't get the gold from your server.
If they are well-behaved.
Traditional login feature is something implemented by the
back end server, which requires user input email and
password provided by a client and the database record
that matches the provided data. If any to
get an authorized access to the system, when requested to
login, instead of a valid email, address attackers will
provide something inappropriately but not arbitrary.
They will provide a special crafted input
which will compromise your back-end or database servers. We
We'll explore this attack scenario in detail, how the attacker
get access to the system using inappropriately? Something
other than a valid email address. What
payload would do it?
First, let's have a look into the database table where authentication credentials
are stored.
There are several types of databases our application.
Use a relational database management system
which SQL support for data management. This
is how an account stable M2 store out. Invocation credentials
would look like this is an
oversimplified example. Nevertheless. This is what we find
quite often on vulnerable applications note.
That passwords are not the actual Secrets, but their
hash, if you are not familiar with the hashing concept,
or with password storage, please read a wasp.
Ford started s*** s***. Following the link below to
retrieve admins record. We need to send the following SQL query
to the database. If we get exactly one record,
then the account exists and credentials are okay. Otherwise,
the email address does not exist in the database or
password is wrong. Again. This
does not comply with the best practices, but it is quite common pattern
found on vulnerable applications.
This is how it works for the admin account. But as a feature, the
email address and password can't be hard-coded and they
should take arbitrary user-provided values.
This is a template for a generic query that will work
for any user provided values. What's enclosed within
square brackets. Should be replaced on every login request
with provided data.
And here we have observed implementation of the login feature
in the backend server responsible for doing such replacement.
Our query template is in the first few
lines, user provided data is available in
the rack dot body object variable and
it will be interpolated with the template string. If
no database match is found. Then record variable
will be new in such case. The never is
thrown in. No access is granted. Otherwise,
the program flow continues and access is granted.
Let's see this in action with two examples.
On a legit admin. Login request. User provides a valid email
address and the corresponding password, the backend server
replaces the valves in the right places and sends the
query to the database server.
What the database server receives is a valid query
and it will look up the accounts table for a record matching,
both email and password values. There
is only one record in our database matching, the query criteria,
the admins account, lets now
attack.
Instead of a valid email address, the attacker provides a partial SQL
query check how it looks like in the back end
server highlighted with the red background on
the right side is what the database server receives again
a valid SQL query. If you look closer,
the search criteria is different from what we had before. We
are now searching for a record with empty mail
or where one is equal to 1.
Everything else after the semicolon does not belong to the first
query. And so this time, no matter will be performed regarding
the password value. Although there's no such record
with empty email, every record matches the one
equal to one condition. Since we're dealing with,
an our matching one criteria will be enough. The
first match record will be returned to the backend server.
The backend Server doesn't know that password wasn't matched. Remind
that the backend server is written in a programming language
other than Sequel and it knows nothing about
SQL since the backend server receives some
data from the database. The variable record won't
be no and access will be granted and
voila.
Admin account is often the first row in the database table in
the first match of malicious queries, like the one we discussed before,
this means that chances are attackers will
be able to log in as that means,
Now we have the answers. We were looking for something.
In this case is a partial sequel, query, our
payload.
And the place where the payload is injected, is in
the back, end server in the SQL query template.
There are several types of injections what we have discussed until
now is called SQL injection. But injection vulnerabilities
are often found in no SQL queries
held up XPath operating system, commands,
XML parsers in many, many more other
places. They all work, the same way. The
back end has a template to which external data is appended and
the results sent to an interpreter.
Every day to Source represents a potential attack
Vector. Environment variables are something, we
tend to assume to be safe but on a compromise system,
they are as critical as any other dating put parameters
are more obvious since they come from the client site.
Whether they are provided by a user on
a web form or by a native mobile app. Always keep
in mind that they are all external to the system. The
same is valid for web services and third-party services in
general, even Services provided by bigger.
Operations are subject of the techs handle data gathered from third
parties. As being potential, harmful users
are most of the time, the main system actors, whether
they are external or internal to the organization. Keep
in mind that there are different motivations in that they
can change over time.
We can just focus, the technical impact since the business
impact is specific to the business and each organization will
have to decide how much security risk. It is willing to
accept as we have seen in Jackson's may
lead to an authorized access to the system depending
on the attack motivation and application functioning injections,
may give attackers read-only access to the internal data or
read-write access leading to complete data loss or corruption.
If attackers are able to compromise authentication
or authorization systems.
Then you may lose access to the application. In
the worst case. You may even lose control over the system. Servers threats
agents are application in business specific to
identify who the threat agents. Are. You should
ask yourself a few questions focus on
the impact to enumerate who would benefit from compromising the
system to whom is your data valuable.
Enumerate profiles of who has the knowledge to
perpetrate the attack. And what benefit they take from it.
Don't forget to look inside your organization. Sometimes
were too much focused on external threats,
and then the attack comes from the inside.
You'll find this table in the WASP top 10, pause
the video, and take your time to carefully, read it.
In the next part, we will exploit an injection flaw
in our intentionally vulnerable application.