How to Exploit “improper error handling” in Web Applications
Reading Time: 5 Minutes
Introduction
In this write up, we will explain of how Improper Error Handling can be exploited.
We will discuss and demonstrate how improper error handling can be exploited in Web Applications. We will also discuss how various types of error handling can introduce various types of attack vectors.
As a bug bounty hunter or penetration tester performing web app auditing, you encounter some errors that are displayed on the page itself, we will show you how to interpret some of them, and understand how these errors can be exploited. We will go through the various improper error handling scenarios that can lead to advanced attacks.
Error Based Injection Vulnerabilities
There are various types of web vulnerabilities, which can easily be exploited due to the errors the web applications throwback in the response. One of the most famous injection-based attacks is SQL. When user input is not sufficiently sanitized, SQL Injection vulnerabilities can take place. SQL errors are returned to the user, in HTTP responses. The following example shows how an SQL Injection vulnerability can be exploited using errors thrown directly into the HTTP response on the page itself.
For example, let us consider the following SQL injection payload used against a purposely vulnerable web application: DVWA (Damn Vulnerable Web Application) that we have installed:
‘http://192.168.0.40:8080/vulnerabilities/sqli/?id=%27%20order%20by%205-+&Submit=Submit#’
Following is the response we get on the page itself:
‘Unknown column ‘5’ is ‘order clause’
As you can see, to a normal user it could just be nothing, some code, but to a hacker, this response tells him that Column 5 does not exist in the table the page is interacting with.
Offensive Security and Ethical Hacking Course
With the same concept, exploitation of other injection-based vulnerabilities can also rely on errors thrown in the response. Let’s consider the following excerpt returned in response to an XML External Entity (XXE) injection-based payload:
HTTP/1.1 500 Internal Server Error
Content-Type: application/xml
Content-Length: 2467
<?xml version=”1.0″ encoding=”UTF-8″?><root>
<errors>
<errorMessage>java.io.FileNotFoundException: file:///test/root:x:0:0:root:x:0:0:root:/root:/bin/bash
As we can observe, a 500 Internal Server Error was thrown, but the requested file /etc/passwd was read and returned an HTTP response.
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
Leaking Internal Software Versions
Improper Error handling is often not directly exploited, but unhandled error display to the user can reveal sensitive information that can lead to further exploitation.
Let us check this error 500, which we sometimes discover, and do not know what it can indicate:
The error in Image should have been handled using a custom error page instead of leaving it as it is. From the error above, we can notice that the version installed on the target is 7.0.68. A quick search on cvedetails.com reveals that Apache tomcat 7.0.68 has several vulnerabilities ranging from high to low. The following link shows a full list of CVEs registered against this version:
As you can see, among the vulnerabilities listed in the link provided above, there is a serious one, an RCE (Remote Code Execution) vulnerability present, which can be exploited under specific conditions. It is a vulnerability in the CGI Servlet which is only exploitable when running on Windows in a non-default configuration in conjunction with batch files.
This means, that if you can study the exploit and demonstrate a working Proof of Concept (POC), you can achieve having remote access to that server directly.
Logical Based Vulnerabilities
There are different scenarios when vulnerabilities such as Apple goto fail, can be introduced due to improper error handling. Apple’s goto fail bug was caused due to a single line of insecure code, that is used for validating ‘invalid certificates’ incorrectly. This can result in an invalid certificate being quietly accepted as valid, in apple software.
Below is an example of that:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
… other checks …
fail:
… buffer frees (cleanups) …
return err;
This code snippet is shown in the example and the excerpt above has ‘goto’ fail lines. The second line always executes leading to an SSL verification bypass. This additional line appeared to have been added to the code by mistake, done by the developer. This simple mistake can lead to a security problem and consequences.
Similarly, many developers try to avoid errors in the development phase to ease the business for their company, by disabling important security features. If the code is moved to production with these changes, it can lead to security vulnerabilities.
Android SSL bypass also can take place, here is another example:
TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
@Override
public X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {};
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType)
throws CertificateException {
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException {
}
}
};
// SSLContext context
context.init(null, trustAllCerts, new SecureRandom());
As you can see from the above code snippet, it will accept any certificate by overwriting the functions `checkClientTrusted`, `checkServerTrusted`, and `getAcceptedIssuers`. This type of coding mistake, to handle errors can also lead to serious security flaws and consequences.
Username enumeration through inconsistent error-based messages
Sometimes, some developers tend to return detailed error messages to a user on login pages.
Here is a known example showing an error when a user attempts to log in with a username that does not exist in its database:
`Username does not exist`
This gives an attacker a hint that the specific username entered, does not exist, it is communicating with the backend’s database to fetch this error message.
The same concept applies if a user enters a valid username, but an incorrect password and the following error message is displayed:
`Password is incorrect`
These types of detailed error messages are great feedback for username enumeration-based attacks such as Fuzzing and Brute-Forcing using these errors in the process.
Another type of error that is commonly seen in features such as `Forgot Password`.
When you use this feature, it allows you to input your email id so it can send you a password reset link, using the message below:
`A New Password has been sent to your registered email id`
However, when an email ID does not exist in the system’s database, it could show the following error:
`Account or Email not found`
Again, such a detailed error message often allows an attacker to enumerate email addresses.
Ideally, a generic error message should be shown when there is a failed attempt to log in and reset emails and passwords, so it will not give more details to an attacker.
Conclusion
Often times you will encounter these types of errors as you perform your assessments or bug bounty recon, either through browsing directly the website or when you perform URL gathering and screenshotting. And now that you have seen what each one means, you will interpret these errors based on follow-up, to see if you can exploit them and earn your bounty.
Knowing how to exploit improper error handling vulnerabilities, and also how to use such vulnerabilities to perform even more advanced attacks, can increase your arsenal of attacks and help you test a web app more effectively using various methods of attack.
Are u a security researcher? Or a company that writes articles or write ups about Cyber Security, Offensive Security (related to Information Security in general) that match with our specific audience and is worth sharing?
If you want to express your idea in an article contact us here for a quote: [email protected]