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).   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.   Content-Length: 2467

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.       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. 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.           @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.   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.   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.    However, when an email id that does not exist in the system is entered, it may show the following error message.   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.

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

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