CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Get our research, blog and event invitations before everybody else!


Your data will stay confidential Private and Confidential

Information Exposure Through Externally-Generated Error Message [CWE-211]

This weakness describes information exposure case where software generates a message with potentially sensitive data and outputs it.

Created: December 10, 2013
Latest Update: August 5, 2015

Table of Content

  1. Description
  2. Potential impact
  3. Exploitation Examples
  4. Severity and CVSS Scoring
  5. Mitigations
  6. References
  7. Latest Related Security Advisories

1. Description

This weakness describes information disclosure case where software performs an operation that triggers an error or diagnostic message in an external component. It is a child element of Information Exposure weakness and should be treated as such.

An example of this weakness is an error generated by the programming language interpreter used by software. The provided error message may contain potentially sensitive information and can be used to advance the attack surface.

This weakness can be introduced on design, implementation or operation stages of software development process and is not restricted to certain programming languages; PHP however is the most common and popular example.

The exposed information can be divided into two groups:

  1. Exposure of system information
    e.g. file system structure, installation directory, installed software and its versions, etc.
  2. Exposure of sensitive data
    e.g. database structure, memory dump, login credentials, etc.

Exposure of error messages is often used to determine vulnerabilities that exist within the application, such as PHP File Inclusion, or SQL injection, and is helpful for performing advanced attacks against the application. Knowledge of web application document root is extremely valuable when exploiting PHP local file inclusions, since it is possible to determine possible log file location to include and execute PHP code stored in webserver log files.

2. Potential impact

An attacker might be able to gain access to restricted information and use it to widen the attack surface. Depending on the disclosed information, it might be possible to escalate privileges within the application or, in rare cases, to gain complete control over the system.

3. Exploitation Examples

Let’s have a look at certain common cases of this weakness.

Example 1
The application uses incorrect credentials to connect to database. The error message generated by PHP exposes database user and database host:
CWE-211 exploitation example

Example 2
The application uses the PHP "include()" function to include non-existent file. As a result, PHP generates an error message that includes full path to the application and certain system configuration.
CWE-211 exploitation example

As we can see from examples above, the application outputs data that can be useful for an attacker to e.g. perform a brute-force attack or gain knowledge of file system structure.

4. Severity and CVSS Scoring

Giving the nature of this weakness and possible triggers it should be scored as "I:P". In cases of remote exploitation the score should be as follows:
5 (AV:N/AC:L/Au:N/C:P/I:N/A:N)

Examples of this weakness:
Installation Path Disclosure Weakness in Flatnux
Installation Path Disclosure weakness in Tribiq CMS

If the weakness is exploited locally:
2.1 (AV:L/AC:L/Au:N/C:P/I:N/A:N)

5. Mitigations

The best way to protect your system against this weakness is to disable any output of error messages. Here are basic rules that should be followed when creating and implementing the application. Be sure that the application:

  • does not generate errors accessible to others
  • does not output debugging information
  • handles errors internally and does not display errors that may contain potentially sensitive data
  • sanitizes all input and does not send unverified data to external components that might trigger unhandled exceptions (e.g. division by zero, fatal errors).

The environment should be also configured not to output additional information.

PHP
Set the option "display_errors=0" in php.ini file or use PHP function error_reporting(0) to disable output of error messages.
ASP

Use the following configuration in web.config.

  1. <configuration>
  2.     <system.web>
  3.         <customErrors mode="On" defaultRedirect="error.htm" />
  4.     </system.web>
  5. </configuration>
Ruby

To disable error output run the server with the "-e production" option. Another way is to set "config.consider_all_requests_local=false" in application environment.

6. References

  1. CWE-211: Information Exposure Through Externally-generated Error Message [cwe.mitre.org]
  2. Full Path Disclosure [owasp.org]

7. Latest HTB Security Advisories with CWE-211


Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.

↑ Back to Top
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Share