How to Exploit “improper error handling” in Web Applications

by | Sep 20, 2022 | Articles, Write up

Join our Patreon Channel and Gain access to 70+ Exclusive Walkthrough Videos.

Patreon

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.

See Also: So you want to be a hacker?
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:

SS1

 

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:

https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-887/version_id-199716/Apache-Tomcat-7.0.68.html

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.

 

 

 

We hope that this write up has taught you something new. If you enjoyed it, the best way that you can support us is to share it! If you’d like to hear more about us, you can find us on LinkedInTwitterYouTube.

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]

Merch

Recent Articles

Offensive Security & Ethical Hacking Course

Begin the learning curve of hacking now!


Information Security Solutions

Find out how Pentesting Services can help you.


Join our Community

Share This