Hello, everyone, and welcome back to the course, identifying with attacks through logs.
In the last video, we talked about brute force attacks.
This is module to Episode four, and in this video
we'll start talking about injection attacks.
The first injection attack will be SQL injections. So to start, let's check the video objectives
first. A brief introduction of injection attacks
or review SQL Tax Sequel injection attacks,
followed by performing Web analysis toe Identify SQL injection attacks.
Injection attacks are related toe. Oh, wasp talk a one
in 2007, it was a top vulnerability
Injections air so common that OAS classified it as a top vulnerability in 2010 and 2013 as well.
Here's the definition from a wasp
injection. Attacks occur when the central request contains some unexpected data
and this data is executed by the Web server.
the Web server doesn't care about the request, and if the request is malicious, the Web server will still process it.
SQL injection is one type of injection attack. There are many other injection attacks.
Here's a list of some of that
SQL injection file injection and others, but in this video, we'll focus on SQL injection
because of the multi layer Web application architecture. ER, the client should Onley access the Web server
in a SQL injection attack. The client sends the request the Web server, but the Web server will send the request. The database in the database will process it
depending on the request. Database can execute unexpected commands,
and these commands that come back to the database server can impact the Web application.
SQL Injection is considered a critical vulnerability. It directly affect the database server.
Here we have a comic strip joke about SQL injection
here. The impact was losing all the data base of the students. This could be fun, but
if this happens in a production environment, the consequences could be tragic.
So let's talk about SQL injection.
Here are some considerations to keep in mind with SQL injection attacks
it needs to use SQL or the database won't process it.
Usually it's caused by incorrect user input validation, like allowing special characters in the form.
It's an old attack. We've known about it since 1998.
It's also more common on legacy applications.
It's a server side attack, and it has some types like blind classic Union based and Air based
in our lab, there's a Web application vulnerable to SQL injection attacks. It's simple. It's just a form with only one text box toe. Put the user ID.
If we try the number one, we have the admin user information.
Here you have the request made to the Web server.
It's a simple request.
You can see that the i. D. Has the number one the admin I'd
the information about the admin has shown. But if we don't say a number,
This is an example of a malicious request
to summarize this user. I d request you say to the database. I want all the user I. D. S that are equal to a or one equals one
one equals one is always true. So the database will send all the user names.
This is the result of the request all user names and information about the user names.
Now maybe you're thinking,
Can the Web server logs identify SQL injection attacks?
Let's analyze both request web server logs.
The first is the I. D. Number one request in the second logline is a malicious request.
Notice that whatever you put in the user i d. You'll be sent to the Web server and the database server.
Another important thing is that this request is encoded.
After decoding, we'll see the same request that we used
because of the SQL. It's easy to see encoded requests during SQL injection attacks.
It's important to notice that the Web server answered both requests, and this includes the malicious requests.
Depending on your Web application,
this would mean that your application is vulnerable to the SQL injection.
let's analyze these three log lines.
These lines were generated by the SQL map tool.
SQL map is a well known tool used to perform vulnerability scans
or to perform SQL injection attacks.
Many of the vulnerability scans can execute SQL injections,
so during the vulnerability scans, it's possible to see SQL injections. And depending on the policy of your company,
you can classify the attack as a vulnerability scan or as an SQL injection attack.
the user agent can help you in identifying the attack.
Analyzing the logs, you should see SQL related words or comments like and select case when union and others
always check the response of the Web, Sir,
on the previous slide. The answer was 200 so the Web server answered the request.
In the three log lines, we have 32 to the right direction.
Sometimes you need to correlate more than one logline toe. Understand the entire attack
for further information. Here are the same three lot lines but
If you don't know about SQL comments, you can ask your database. Admin. Ziff. These comments are malicious or could impact the database server
in the next slide will analyze tomb or log lines.
again. We used the SQL map, but we change the user agent.
You can notice encoded requests and many SQL words.
The second logline. You have the wear and the exact comments.
Taking a better look. You can find more comments in words but related toe Linux operational system
like CAT and F password. And in this slide,
the decoded request.
What about post requests
to analyze post requests? You need more logs from other sources.
A good source is the back capture.
For example, this is a Web server log for a post request.
The Web server log on Lee shows the post request to the log in page.
There's no information about the request, but in the package capture, you see the http request and all the form data that was sent.
Notice that this request is similar to our examples, although it's not that easy to get a package capture.
But if it's possible, you should try and ask for them
How do you identify the SQL injection
first? SQL commands like from Select Where and others
look for in Cody requests.
Also, remember the look for user agents and the operational system related comments or words.
Now let's do some post assessment questions to practice
in the first question.
Analyze the log below and identify the Web application attack
after choose the option with the correct attack,
you can pause the video if you want.
It's easy to see that this log is big, contains a lot of encoding. In addition, it's easy to find the SQL words like select and count on others.
So this is an SQL injection attack.
For further information,
here is the decoder request showing the SQL request.
Now check this affirmation.
Web server logs will show all information about user actions.
Is this affirmation. True or false,
This affirmation is false.
If the Web application uses post or if the Web server log and configuration is wrong, maybe the law can't help you.
If this happens, you need to ask for the right configuration or for other logs.
In this video, we talked about the type of injection attacks. SQL Injection attacks some directions to identify SQL injection attacks on the Web server logs like SQL Comments and Cody requests user agent and operational system comments
after we showed the difference between post and get requests showing an example of a package capture with a SQL injection attack
we'll keep talking about injection attacks.
We'll discuss file injection or file inclusion and the two types of inclusion local and remote file inclusion.