Vulnerabilities > CVE-2018-17961 - Information Exposure Through an Error Message vulnerability in multiple products

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes any stack traces produced by error messages. Fuzzing techniques involve sending random or malformed messages to a target and monitoring the target's response. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to cause the targeted application to return an error including a stack trace, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash. The stack trace enumerates the chain of methods that led up to the point where the error was encountered. This can not only reveal the names of the methods (some of which may have known weaknesses) but possibly also the location of class files and libraries as well as parameter values. In some cases, the stack trace might even disclose sensitive configuration or user information.

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. Fuzzing techniques involve sending random or malformed messages to a target and monitoring the target's response. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash. By observing logs and error messages, the attacker can learn details about the configuration of the target application and might be able to cause the target to disclose sensitive information.

An attacker is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an attacker is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an attacker is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key. Any cryptosystem can be vulnerable to padding oracle attacks if the encrypted messages are not authenticated to ensure their validity prior to decryption, and then the information about padding error is leaked to the attacker. This attack technique may be used, for instance, to break CAPTCHA systems or decrypt/modify state information stored in client side objects (e.g., hidden fields or cookies). This attack technique is a side-channel attack on the cryptosystem that uses a data leak from an improperly implemented decryption routine to completely subvert the cryptosystem. The one bit of information that tells the attacker whether a padding error during decryption has occurred, in whatever form it comes, is sufficient for the attacker to break the cryptosystem. That bit of information can come in a form of an explicit error message about a padding error, a returned blank page, or even the server taking longer to respond (a timing attack). This attack can be launched cross domain where an attacker is able to use cross-domain information leaks to get the bits of information from the padding oracle from a target system / service with which the victim is communicating. To do so an attacker sends a request containing ciphertext to the target system. Due to the browser's same origin policy, the attacker is not able to see the response directly, but can use cross-domain information leak techniques to still get the information needed (i.e., information on whether or not a padding error has occurred). For instance, this can be done using "img" tag plus the onerror()/onload() events. The attacker's JavaScript can make web browsers to load an image on the target site, and know if the image is loaded or not. This is 1-bit information needed for the padding oracle attack to work: if the image is loaded, then it is valid padding, otherwise it is not.

An Attacker, aware of an application's location (and possibly authorized to use the application) can probe the application's structure and evaluate its robustness by probing its error conditions (not unlike one would during a 'fuzz' test, but more purposefully here) in order to support attacks such as blind SQL injection, or for the more general task of mapping the application to mount another subsequent attack.

Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection. For example, an attacker may try entering something like "username' AND 1=1; --" in an input field. If the result is the same as when the attacker entered "username" in the field, then the attacker knows that the application is vulnerable to SQL Injection. The attacker can then ask yes/no questions from the database server to extract information from it. For example, the attacker can extract table names from a database using the following types of queries: If the above query executes properly, then the attacker knows that the first character in a table name in the database is a letter between m and z. If it doesn't, then the attacker knows that the character must be between a and l (assuming of course that table names only contain alphabetic characters). By performing a binary search on all character positions, the attacker can determine all table names in the database. Subsequently, the attacker may execute an actual attack and send something like: