CEH MASTER : Module 13 Web Application Attacks

CEH MASTER : Module 13 Web Application Attacks

Module 13 – Web Application Attacks

 

Topics in This Chapter:

  • GUI Web Hacking
  • URL-Based Attacks
  • Common Web Application Vulnerabilities
  • Web Application Attack Tools
  • Google Hacking
  • Methods to Enhance Web Security
  • Web Password Cracking Techniques

Web applications are programs that run on web servers like http://vncert.gov.v/ and are categorized by their functions such as forums for information sharing, CMS/blogs for content management, social networking sites, business management applications, customer relationship management, or e-commerce.

Hackers are particularly interested in websites of large organizations or government agencies like .gov.vn domains in Vietnam. Additionally, modern hackers, besides showing off their skills, often act for economic motives, so they prioritize e-commerce sites where important information like customer credit card details and online banking accounts can be found.

After attacks, hackers often display their achievements on the zone-h website at http://www.zone-h.org/, which is considered a “hall of fame” for hacked websites. The following image shows a list of .vn domain websites that have been attacked and potentially not yet patched or detected.

[Image 13.1 – Vietnamese websites attacked and published on zone-h.org]

Most web applications today operate on a client/server model with web browsers like Firefox, IE, Chrome as web clients and web servers like Apache, IIS, TomCat on the server side. Common technologies for building websites include ASP, PHP, JavaScript… Each technique has its own strengths and weaknesses, so when attacking, hackers must carefully research to accurately identify the operating systems, web servers, and website deployment technologies to develop an effective attack plan.

The common forms of web application attacks we need to know are:

  • Direct manipulation of the application through its visual web interface (GUI) called GUI Web Hacking.
  • Exploitation using the Uniform Resource Identifier or URL (URL Hacking)
  • Exploiting HTTP components that are not in the URL

GUI Web Hacking:
This involves directly manipulating the web application interface or using website auditing tools like Havji, WebAcunetix… which we will present in later lessons. You can see an illustration of an exploit to find SQL Injection vulnerabilities on FoundStone’s sample website in the following image…

[Image 13.2 – GUI Web Hacking]

In the illustration, attackers directly enter the value ‘OR 1=1– to bypass the application’s control mechanism if the validation of INPUT values is not fully implemented. This is one of the most common vulnerabilities that websites often have and attackers are very interested in.

Example scenario using the lab model:
On the Kali Linux machine (CEH-Master), an attacker could use a tool like sqlmap to perform GUI-based SQL injection against a vulnerable web application running on the Metasploitable 2 target. The command might look like:

sqlmap -u "http://[Metasploitable 2 IP]/mutillidae/index.php?page=user-info.php&username=admin&password=password&user-info-php-submit-button=View+Account+Details" --dbs

This would attempt to enumerate the databases on the target system through the vulnerable web interface.

URL-Based Attacks:
HTTP methods are actions performed on the web application and web client. The HTTP RFC defines these actions, and the WEBDAV application on Windows IIS servers adds some additional methods, but generally web applications use two main functions: GET and POST. GET is used to request information, while POST is used to send information. Both POST and GET can send information to the server with one important difference: GET puts data in the URL while POST puts data in the body of the request and does not display it in the URL. Therefore, POST is used to submit data to web applications, such as when we provide name and address information when registering for online purchases. However, the non-display of POST information does not necessarily protect data better than GET, which is often a point of confusion for users, as finding information hidden by POST is not too difficult for hackers.

[Image 13.3 – Illustration of URL-based attack]

HTTP headers are often used to store extended information such as transport protocols or related security elements including:

  • Authorization determines whether or not security mechanisms accompany the request such as Basic authentication, Certificate…
  • Cache-control determines whether to cache these requests on an intermediate server or not.
  • Referer Lists the source URI.
  • Cookies are used to store tokens in client session-based authentication.

Here’s an example of functions used by the netcat tool connecting to www.test.com server on TCP port 80 (standard port for HTTP protocol; HTTPS is TCP 443), and the request of this connection is to retrieve the file /test.html. The full path of this request is http://www.test.foo/test.html.

www.test.foo [10.124.72.30] 80 (http) open
GET /test.html HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 04 Feb 2002 01:33:20 GMT
Server: Apache/1.3.22 (Unix)
Connection: close
Content-Type: text/html
<HTML><HEAD><TITLE>TEST.FOO</TITLE>etc.

In this example, you can see the GET function in the client request used by netcat and the response returned in the server header is Server: Apache/1.3.22 (Unix), while the response body data is in the TEST.FOO frame.

Example scenario using the lab model:
An attacker on the Kali Linux machine could use curl to perform a URL-based attack against a vulnerable parameter on the Metasploitable 3 (Windows Server) target:

curl "http://[Metasploitable 3 IP]/vulnerable.php?file=../../../../windows/system32/drivers/etc/hosts"

This attempts a directory traversal attack to read the hosts file on the Windows target.

However, regardless of the attack methods hackers use, as mentioned, their main goal is still the information contained in these web pages, which could be important documents or customer information like email lists, credit card numbers. And to achieve this goal, hackers need to follow the attack process in the correct order as follows:

  • Scanning: Scan for website vulnerabilities, search for useful information about the server.
  • Information Gathering: Focus on key information.
  • Test: Try out some options.
  • Planning Attack: Plan the attack method such as which proxy to use, what tools to use for the attack.
  • Launching Attack: Start the attack

[Image 13.4 – Auditing website with W3AF]

Note that this illustrative video is for training and research purposes only. Do not apply in practice. Watch the demo here: http://www.youtube.com/watch?v=ugIxUtbFH-o&feature=youtu.be

Common Web Application Vulnerabilities:
There are many dangers that websites can fall into, the top threats we often hear about are SQL injection, XSS, Authentication Hijacking… In the role of CEH, we need to understand the meaning of these vulnerabilities and some popular exploitation tools:

  • Cross-site scripting: This vulnerability allows hackers to execute malicious code snippets through website input fields such as search boxes.
  • SQL injection: A vulnerability with a very high rate of exploitation by hackers, allowing hackers to run SQL statements from the browser and view the contents of tables and columns containing important information. You can refer to the illustrative video attached in the section above.
  • Buffer Overflow: A large amount of data sent to the web application through forms causes buffer overflow.
  • Cookie poisoning and Authentication hijacking: Hackers steal cookies from a session between the web client and web server, then access the user’s private area. Demo: http://www.youtube.com/watch?v=zLdB3UgDi_I
  • Directory traversal / Unicode: Hackers query the file system and system directories through web browsers or Windows explorer.

Here is a list of web application security vulnerabilities that hackers often exploit as published by the CEH document, led by XSS (Cross-Site Scripting) related vulnerabilities, followed by SQL Injection, Parameter Tampering, Cookie Poisoning…

[Image 13.4 – Commonly attacked web application vulnerabilities]

In addition to the above list, you can refer to more information about the top 10 common security vulnerabilities compiled by OWASP at https://www.owasp.org/index.php/Vietnam. In this reliable list, we see some differences in the rates between vulnerabilities that are likely to be affected, such as SQL Injection (called code injection) ranking at the top, but in general, vulnerabilities related to SQL injection, XSS, authentication mechanism corruption and session management are concerns that you should prioritize.

[Image 13.5 – List of top 10 web application vulnerabilities]

Web Application Attack Tools:

  • Acunetix Web Security Scanner: The top application to mention is Acunetix Web Scanner, a commercial program used to find website security vulnerabilities such as XSS, SQL injection, Directory Traversal…
  • Havji: An automated SQL injection exploitation program that we have illustrated through instructional videos. This is a free tool used by most hackers today to attack and view information in databases.
  • Burpsuite: Includes many powerful tools from website vulnerability scanning to proxy functions, intercepting data during transmission, then modifying and sending it back to the server.
  • BlackWidow: Can scan and create website diagrams.
  • Teleport Pro: Has the ability to download the entire content of a website for offline viewing.

Example scenario using the lab model:
On the Kali Linux machine, an attacker could use Burp Suite to intercept and modify requests to a vulnerable web application on Metasploitable 2:

  1. Configure Burp Suite as a proxy (e.g., 127.0.0.1:8080)
  2. Set the browser to use this proxy
  3. Browse to a vulnerable page on Metasploitable 2
  4. Intercept the request in Burp Suite
  5. Modify parameters to inject malicious payloads
  6. Forward the modified request to test for vulnerabilities

Google Hacking:
Google hacking is an advanced search skill with Google’s search engine to identify sensitive information of the target. If not configured tightly, information such as login passwords, private documents can be stolen by hackers with just the Google search application. There are many documents on this topic mentioned on the website http://johny.ihackstuff.com or the specialized page http://www.exploit-db.com/google-dorks/ providing search phrases to identify sensitive points of the website.

[Image 13.6 – Website providing search phrases used for exploitation]

Methods to Enhance Web Security:
Previously, Microsoft organized a contest allowing hackers to attack the application system and web server built on the company’s platform such as SQL Server database, Windows operating system, ASP programming platform. This contest was called Open hack and after a short time of launching the contest, the organizers recorded more than 40,000 attacks, but hackers could not penetrate the server system or damage the target websites that the organizers had set up. So how did they use the process of perfecting security for web applications that brought such stability? All of this has been revealed by Microsoft engineers in the guide to enhancing security for web applications called “Improving Web Application Security: Threats and Countermeasures” at: http://msdn.microsoft.com/en-us/library/ff649874.aspx, which is also the document I used to guide in the web application security program for EVN Group in Do Son, Hai Phong at the end of 2011.

Here are some guidelines to enhance security for web applications that we need to pay attention to:

  • Cross-site scripting: To prevent this type of attack, we need to check the validity of input data, cookies, query requests or hidden information carefully. Use specialized website scanning tools like Web Acunetix Scanner to detect XSS vulnerabilities on the website.
  • SQL injection / Command injection: Play the role of a hacker to scan for SQL injection vulnerabilities on the website with tools like W3AF (Web Application Attack and Audit Framework, download at http://w3af.sourceforge.net/). And strictly check user variables, apply special character filtering mechanisms through .htaccess files or specialized modules for SQL injection prevention.
  • Cookie poisoning: Do not store passwords in cookies, set appropriate expiration times and authentication mechanisms for cookies.
  • Buffer overflow: Check the size of user-provided variables so that the program does not exceed control capabilities, have full exception handling to prevent hackers from taking advantage of inserting malicious instructions.
  • Authentication hijacking: Use SSL to encrypt transmitted data.
  • Directory traversal / Unicode: Need to install patches and update fully, set strict directory and file access permissions according to the least privilege principle (only grant sufficient permissions to users based on needs)

Example scenario using the lab model:
To enhance security on the Metasploitable 3 (Windows Server) target:

  1. Install the latest security updates
  2. Enable Windows Firewall and configure strict inbound/outbound rules
  3. Use IIS URL Rewrite module to filter malicious requests
  4. Implement proper input validation on all web applications
  5. Use Windows Authentication instead of Basic Authentication where possible
  6. Enable logging and regularly review logs for suspicious activity

Web Password Cracking Techniques:
As a CEH, we need to understand some techniques that hackers often use to crack web application passwords. This includes authentication methods used by web applications, what a password cracker is, as well as identifying and classifying password-cracking techniques to have appropriate preventive measures. We will discuss these concepts in the following section.

Web Server and Web Application Authentication Types:
Web servers and web applications support many different authentication methods. The most common is HTTP-based authentication with two forms of HTTP authentication: basic and digest. In the basic authentication model, the HTTP authentication process will send account and password information in cleartext (unencrypted) while with digest authentication, the HTTP authentication model will hash the account information. Additionally, a challenge-response step needs to be performed between the client and server to enhance the security of the transaction.

Clearly, when information is sent in cleartext, the security is very low and hackers will easily steal passwords along with usernames using sniffer tools.

In addition to these two methods, the authentication model of web servers and applications also supports NTLM (authentication model based on Windows operating system), using digital certificates as when we use the https:// protocol or using tokens, and the most advanced is the biometric authentication mechanism based on user identification features such as fingerprints, voice, retina…

Among these authentication mechanisms, NTLM uses Internet Explorer and IIS webserver. Because this mechanism operates on the Windows platform, it is very suitable for checking processes in internal systems or intranets using Windows operating systems. For server systems like Windows Server 2000/2003/2008, Kerberos can be utilized to enhance the security of the authentication process of applications or web servers. Meanwhile, authentication based on digital certificates or certificates uses x.509 certificates to implement public and private key pairs. Here we do not go deep into this technology, but you need to note that this is one of the popular technologies in authenticating users with servers or web applications.

As for token-based authentication like SecureID that we often see deployed at banks in the online transfer process, whenever we need to log in or perform a transaction, we will receive a code sent or randomly generated on a hardware device, and only when entering this information correctly can we log in or process the transaction. For example, the SecureID device of TechComBank.

What is a Password Cracker?
Password crackers are programs designed to crack passwords or disable the application’s checking mechanism. These tools often use dictionary-based password guessing techniques or use brute-force techniques to crack passwords.

In the process of cracking passwords through dictionary crackers (we use this term instead of hackers), a list of potential passwords will be created in the dictionary data, through password dictionary creation programs or downloading pre-made dictionaries from the internet. Then these passwords will be encrypted or hashed with hash algorithms commonly used in the process of hashing passwords such as MD5. And to crack the application’s password, the processed passwords in the dictionary are compared with the actual password until a match occurs (server or application authenticates successfully), then the cracking process is complete. Cracked passwords are often taken from the SAM (Security Account Manager) file or the /etc/passwd file on web servers using the Linux operating system (when hackers attack websites, they will upload trojans like c99, rv57 to download this file).

But this dictionary guessing method is difficult to succeed with strong passwords, because it is impossible to gather enough necessary data and the time to conduct is not practical. In those cases, the password guessing method using brute-force technique will be applied. Brute-force will try all possible combinations of characters to create passwords. For a simple example, if the password is only created from 3 characters 1,2,3 then there are only a maximum of 8 results, so the tool only needs to compare a maximum of 8 times to find the original password. However, in reality, passwords will be much more complex, so the cracking process takes long or short depending on the strength of the algorithm and the hardware configuration of the server used for cracking. Common programs in this field often mentioned in CEH are L0phtCrack, John the Ripper, Ophcrack… Powerful applications often combine both password guessing methods above and this technique is called Hybrid.

Example scenario using the lab model:
An attacker on the Kali Linux machine could use John the Ripper to crack passwords from the Metasploitable 2 target:

 

  1. Extract password hashes from Metasploitable 2:
ssh user@[Metasploitable 2 IP] "sudo cat /etc/shadow" > shadow.txt
  1. Use John the Ripper to crack the hashes:
john shadow.txt

This would attempt to crack the password hashes using both dictionary and brute-force methods.

Summary:
In this chapter, we have discussed the top threats to web application security through statistics from CEH documents and OWASP’s top 10 list of dangers. For each dangerous threat or attack type, there needs to be specific remediation methods, but first, we need to perform hardening for server systems to perfect web application security.

Regarding password cracking techniques, you need to distinguish between two main scenarios: dictionary-based cracking versus brute-force cracking. And to prevent password cracking, administrators need to apply strong password policies with a minimum password length of 8 characters, combining uppercase, lowercase, numbers, and special characters. Additionally, appropriate audit modes and logging must be enabled to detect attack situations. Especially, back up carefully to ensure that in case of risk, data can still be recovered, bringing the system back into operation quickly.

Additional considerations for the lab environment:

  1. Vulnerability Scanning:
    Use tools like Nmap and OpenVAS on the Kali Linux machine to scan both Metasploitable targets for open ports and known vulnerabilities. This helps identify potential attack vectors. Example:
   nmap -sV -sC -O [Metasploitable IP]
  1. Web Application Firewall (WAF):
    While Metasploitable systems are intentionally vulnerable, in a real-world scenario, implementing a WAF like ModSecurity on the web server can help mitigate many common web attacks.
  2. File Integrity Monitoring:
    Use tools like OSSEC on the Metasploitable systems to detect and alert on unauthorized file changes, which could indicate a successful attack.
  3. Network Segmentation:
    In a production environment, you would want to segment your network to isolate web-facing servers from internal resources. This limits the impact if a web server is compromised.
  4. Regular Penetration Testing:
    Use the Kali Linux system to regularly perform penetration tests against the Metasploitable targets. This helps identify new vulnerabilities that may arise due to configuration changes or newly discovered exploits.
  5. Secure Coding Practices:
    While not directly applicable to the Metasploitable targets (which are intentionally vulnerable), in real-world scenarios, implementing secure coding practices is crucial. This includes input validation, output encoding, and proper error handling.
  6. Continuous Monitoring:
    Set up logging and monitoring solutions on all systems. For example, you could use the ELK stack (Elasticsearch, Logstash, Kibana) to centralize logs from both Metasploitable targets and analyze them for security events.
  7. Incident Response Plan:
    Develop and regularly test an incident response plan. Use the lab environment to simulate various attack scenarios and practice your response procedures.
  8. Security Training:
    Use the lab environment to train IT staff on recognizing and responding to various web application attacks. This hands-on experience is invaluable for building a security-aware culture.

Remember, while the Metasploitable targets are designed to be vulnerable for learning purposes, in a real-world environment, the goal would be to secure these systems as much as possible while still maintaining functionality. The Kali Linux system serves as both an attacker’s platform for testing and a defender’s toolkit for identifying and mitigating vulnerabilities.

By regularly practicing in this lab environment, security professionals can stay up-to-date with the latest attack techniques and defense strategies, ultimately improving their ability to protect real-world web applications and infrastructure.

Back to blog