Hello and welcome back to the course, identifying Web attacks through logs.
In the last video, we talked about injection attacks and SQL injection attacks.
In this video, we'll talk about another another injection attack called file Inclusion.
Let's see the video objectives.
The video objectives are understanding the local and remote file attacks
and identifying these attacks using Web server logs.
First, let's discuss file inclusion attacks.
As we said before, it's an injection attack.
It's usually caused by incorrectly using input validation. It's common to see directory trans versatile characters
thes air two types, local file inclusion that access and execute the local files or commands and remote file inclusion
that access and execute remote files or commands.
File inclusion is a server side attack.
Here you can see how file inclusion works.
Our request is sent to the server and answered. So it all happens in the same server.
Remote file inclusion is a little different.
The user sends the request through the Web server, and they went on. The Web server
sent the request to another Web server, a remote server.
That's why it's called remote file inclusion. You need to different servers
in our lab. We have a Web application that is vulnerable to the file inclusion, both local and remote.
Here's an example of local inclusion.
Past WD is a file that contains the pass rich for all the users in a Lennox machine.
You can see the directory trans Mursal characters, which change the directories.
The result is the past W D file will be read and displayed in the Web page,
as you can see in the picture.
Now, let's analyze some logs together.
The first logline is a normal request.
The second logline is a direct request to the past WD file and the Web server answer is not found.
The request didn't answer
In the third line, we have a 200 as our answer. So the Web server found the past WD file.
Notice the difference between the two requests.
The next line is the same request, but encoded
as you can see, it worked.
The Web server answered the past WD file
since the past WDs local. This attack is a local inclusion
in these examples, we had access to critical files.
It's also possible to execute commands on the Web server
we have a summary of the most common target files for each personal system.
If you want, pause the video and take some notes
now some directions to help you identify the local file inclusion.
Look for operational system commands and files new files, encoded requests and slash on the requests.
You could go to this website and look from or examples of local file inclusion.
The next is the remote file inclusion.
We'll use the same lab.
The difference between remote and local file inclusion is where the resource is located.
The remote file inclusion needs to access another servers files. In our example, we'll use We will access the Google website from our lap.
you can see that the Google search bar is loaded in the lab Web page.
The remote server is a Google server.
The remote file inclusion accesses remote servers.
Now maybe you're thinking, Well, I don't have access to the remote server.
Can I find the remote file inclusion Attack logs on my Web server?
Yes, you can find the logs of the attack on your Web server.
Access on other Web servers is a consequence of the attack.
Your Web server server
That's why we will have the locks.
So let's analyze some logs.
The first line is the requests to the vulnerable page.
Notice that there are some log fields missing, like user agent I. P. Address and date and time.
They were moved to save space.
In the second line, we have the malicious requests.
Another page is accessed from our Web page,
in this case, the Google Web page.
All the other logs are our Web server. Requesting the Google Web page.
Our Web server is downloading the Google Web page. That's why we have similar locks. Most of them are pictures.
The full log of this request is bigger
here. We only have a small part, but
all the requests are similar.
You can use the same directions toe, identify remote and local inclusion.
Here are some directions more related to remote.
Look for weird requests,
as we showed in our other example.
Requests for another Web server, like outside of traffic, is suspicious.
If the server is accessing a wrote a remote server,
maybe you can see an increase in Web server download traffic
here to look for encoded requests in the user agent.
Look for uncommon user agents or vulnerability scanners.
Post assessment question.
Analyze the Web server, log below and choose the type of attack.
You can pause the video if you'd like.
The answer is number four
Remote file Inclusion.
Let's analyze the log together and see why
we have the I P address date in time and the requested file. And we have to get method.
If you look at the requested file, you can see there's another address in the page. So we have a remote file inclusion because we're trying to access a remote server.
Here is the Sai Buri Web page. All the other fields air. Okay, we have the 200. That means okay,
we have the refer and the user agent.
For the next question,
analyze the weblog below and identify which Web pages vulnerable to file inclusion. Attack.
Here you have the request, and you have a small part of the full Web page. But
you can see the malicious request,
although if you look to the refer, we can see there's no Web page.
Remember that the refer could be crafted to, but sometimes it can help
in this case, it's possible to find the vulnerable Web page. Here's the answer.
In this video, we learned about local and remote file inclusion attack in their differences.
We used it in our lab to generate some Web server logs and analyzing the Web server logs, we identified both types of attacks local and remote file inclusion.
We also gave some directions to identify the attacks like we had requests, encoded requests, user agents, requests with operational system commands or files requests, many slashes and some specific directions for the remote file inclusion like the request to the outside.
In the next video, we'll analyze cross site scripting attacks and will identify the attack using Web server logs.