Secure coding

How to exploit improper error handling

In the previous article, we discussed what Improper Error Handling vulnerabilities are and what causes them. This article provides an overview of how Improper Error Handling vulnerabilities can be exploited. We will go through various improper error handling scenarios that can lead to attacks. 

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Error based injection vulnerabilities

There are several types of web vulnerabilities, which can be easily exploited due to the errors the web applications throw back in the response. SQL Injection is a classic example of such vulnerabilities. When user input is not sufficiently sanitized, SQL Injection vulnerabilities occur. Error Based SQL Injection vulnerabilities occur, 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 in the HTTP Response.

For example, Let us consider the following SQL Injection payload used against Damn Vulnerable  Web Application(DVWA).

http://192.168.1.91:8080/vulnerabilities/sqli/?id=%27%20order%20by%205--+&Submit=Submit#

 

Following is the response.

Clearly, the response tells the attacker that column 5 does not exist in the table the page is interacting with.

Similarly, exploitation of other injection based vulnerabilities can also rely on errors thrown in the response. Let us consider the following excerpt returned in response to an XML External Entity (XXE) injection 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

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

[Redacted]

 

As we can observe, a 500 Internal Server Error was thrown, but the requested file /etc/passwd was read and returned in HTTP response.

Leaking internal software versions

Improper Error Handling is often not exploited directly, but unhandled errors displayed to the users can reveal sensitive information that can lead to further exploitation. 

The preceding error should have been handled using a custom error page. From the error above, we can notice that the version installed on the target is 7.0.68. A quick google search 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

Among the vulnerabilities present in the link above, there is one Remote Code Execution vulnerability present which  can be exploited under certain 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. 

Similarly, other details about the target’s internal resources can be present in the errors which can lead to attacks against the system.

Logical vulnerabilities

There can be scenarios when vulnerabilities such Apple goto fail can be introduced due to improper error handling. The Apple’s goto fail bug was caused due to a single line of insecure code used for validating invalid certificates incorrectly. This resulted in invalid certificates being quietly accepted as valid in apple software.

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

    goto fail;

    goto fail;

  ... other checks ...

  fail:

    ... buffer frees (cleanups) ...

    return err;

 

The code snippet shown in the preceding excerpt has to goto fail lines. The second line always executes leading to SSL verification bypass. This additional line appeared to have been added to the code by mistake, but that simple mistake led to a serious security problem.

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Similarly, many developers try to avoid errors in the development phase by disabling important security features. If the code is moved to production with these changes, that can lead to security vulnerabilities. android ssl bypass. Let us consider the following 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());

 

The preceding code snippet will accept any certificate by overwriting the functions checkClientTrusted, checkServerTrusted, and getAcceptedIssuers. This type of coding mistakes to handle errors can also lead to security flaws.

Username enumeration via inconsistent error messages

Some developers tend to return detailed error messages to the users on login pages. For example, the following error may be shown when a user attempts to login with a username that does not exist in the database.

Username doesn't exist

 

This clearly gives an attacker hint that the username doesn't exist. Similarly, if a user enters a valid username but an incorrect password, the following error message is shown.

Password is incorrect

 

These types of detailed error messages are a perfect recipe for username enumeration attacks.

These  types of errors are also commonly seen in features such as Forgot Password. Such features often let the users enter their email id to send a password reset link with a message as shown below. 

A password has been sent to your registered email id

 

However, when an email id that does not exist in the system is entered, it may show the following error message.

Account not found

 

Once again, such a detailed error message often gives an attacker the opportunity to enumerate email ids. Ideally, a generic error message should be shown when there is a failed attempt on login or password reset pages.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Conclusion

In this article, we have discussed how improper error handling vulnerabilities can be exploited in web applications. We have discussed how various types of error handling can introduce various different types of attacks. In a later article, we will discuss approaches that can be used to mitigate improper error handling related security risks.

 

Sources

1. https://owasp.org/www-community/Improper_Error_Handling
2. https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/
3. https://mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05g-testing-network-communication
4. https://owasp.org/www-project-top-ten/