Exploiting Information Disclosure

Exploiting Error Messages

  • Web applications may return informative error messages for unexpected events
  • Some applications may have been tested, but will still give verbose debugging info upon a certain odd error condition.

Script Error Messages

  • Usually contain the reason and the line number of the error.
  • May not be useful in getting sensitive data, but still useful for getting information about the status of a current exploit attempt.
  • Can help discern the logic of the application.

Stack Traces

  • More complex languages may end up returning an entire stack trace.
    • An error message with the description of the error and series of lines giving the state of the call stack
  • Extremely useful because it gives an exact reason for the error, may include library and third-party code component info, demonstrates naming schemes, and line numbers, and may show the environment information.

Informative Debug Messages

  • Implemented most of the time during development and testing
  • Contain information about an application's given state.

Server and Database Messages

  • Using Information Disclosure to Advance and Attack (ch.9)
    • Often contain information about queries.
    • Can fine tune SQLi attacks based on this information.
  • Cross-Site Scripting Attacks Within Error Messages (ch. 12)
    • In the HttpServletResponse.sendError() call used by Tomcat, the error data is part of the response header
    • Most frameworks automatically HTML-encode data, but as shown in Chapter 12, one can still perform a cross-site scripting attack in an HTTP response.
  • Decryption Oracles in Information Disclosure (ch. 7, 11)
    • Encrypted information can sometimes be sent in an application function, like error messages, to automatically decrypt it.
    • Author example:
      • By swapping encrypted parameter values, an error message helped show that one value was an SID and the other was a file path.
  • Process:
    • When fuzzing an application, monitor to identify error messages with useful info
    • Search these responses for specific keywords like the following:
      • Error, exception, illegal, invalid, fail, stack, access, directory, file, not found, varchar, ODBC, SQL, SELECT
    • Check whether the original response contains these keywords to reduce false positives

Using Public Information

  • Search for text of unusual error messages
  • Review search results
  • Use Google code search to find publicly available code that may cause this error message
  • Search for names of libraries and third-party code components found in stack traces

Engineering Informative Error Messages

  • Leveraging open database connectivity (ODBC) error messages
    • Can be used in an SQLi attack to get information about database queries
    • Can cast a password to an integer to force an error message with the password hash printed in it.
  • Creating user-defined functions in Java
    • Book example:
      • Try-catch block, where it would print the output of ls as the first line of a generated exception

Gathering Publishing Information

  • Reasons for published info:
    • Designed that way
    • Unintended side effect
    • Debugging functionality left in production
    • Broken access controls
  • Process
    • Review app mapping exercised from Ch. 4 and identify server-side and client-side functionality/data that may be useful for getting info
    • Identify where sensitive data is transmitted in a given application process
    • Identify techniques for extracting sensitive information

Using Inference

  • May not get direct info, but can infer based upon error message
  • Example:
    • Can enumerate usernames based on error message returned back for existing usernames.
    • Can discern in some applications if accounts or data recently accessed because load times dramatically differ if already cached.
    • Can tell if data submitted was valid based upon processing time.
      • May take no time at all
      • May timeout

Preventing Information Leakage

Use Generic Error Messages

  • Never return verbose error messages or debug information
  • Can be usually avoided using proper configuration:
    • ASP.NET: Using a customerrors element of the Web.config file
    • Java: Using the error page element of the web.xml file.
    • IIS: Specify custom error pages for different HTTP codes using the Custom Errors tab on the website Properties tab.
    • Apache: Using ErrorDocument directive in httpd.conf:
      • ErrorDocument 500 /generalerror.html

Protect Sensitive Information

  • Never publish sensitive information like usernames, logs, or profile information.
  • If necessary, limit disclosed information to that which is needed.

Minimize Client-Side Information Leakage

  • Remove or modify service banners to minimize disclosure of software versions, etc.
    • Apache: Use the mod_headers module.
    • IIS: Use the URLScan in the IISLockDown tool
    • Subject to change based on versions and technology, so consult server docs.
  • Do not hide sensitive information in browser extension parts like Java applets or ActiveX controls.

results matching ""

    No results matching ""