1 / 46

Exploiting Information Disclosure

CH14. Exploiting Information Disclosure. Vincent. I ntroduction. In this chapter, we will try to extract further information from an application during an actual attack . This mainly involves I nteracting with the application in unexpected and malicious ways

vita
Download Presentation

Exploiting Information Disclosure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CH14 Exploiting InformationDisclosure Vincent

  2. Introduction • In this chapter, we will try toextract further information from an application during an actual attack. • This mainly involves • Interacting with the application in unexpected and malicious ways • Exploiting anomalies in the application’s behavior in order to get information that is useful

  3. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers.

  4. Exploiting Error Messages-Script Error Messages • Error arises in an interpreted web scripting language, such as VBScript, the application typically returns a simple message disclosing what happened, and possibly the line number of the file where the error occurred

  5. Exploiting Error Messages-Script Error Messages • Eg. The input should benumeric , and wehave supplied non-numeric characters First,we should know that nothing is to be gained by submitting non-numeric attack strings as this parameter, and wewill be better off targeting other parameters.

  6. Exploiting Error Messages-Script Error Messages • Eg. The input should be numeric , and we have supplied non-numeric characters Second,wecan gain a better understanding of the logic. Because we know the line number where the error occurred, wemay be able to confirm whether two different requests are triggering the same error or different errors.

  7. Exploiting Error Messages-Script Error Messages • Eg. The input should be numeric , and we have supplied non-numeric characters Third,we can try to determine the sequence in which different parameters are processed, by submitting bad input within multiple parameters and identifying the location at which an error occurs. Finally,bysystematically manipulating different parameters, wemay be able to map out the different code paths being executed on the server.

  8. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers.

  9. Exploiting Error Messages- Stack Traces • Most web applications are written in languages that are more complex than simple scripts Java, C#, and Visual Basic .NET. • When an unhandled error occurs, it is common to see full stack traces being returned to the browser in those languages.

  10. Exploiting Error Messages- Stack Traces • Stack trace is a structured error message that begins with a description of the actual error. • The top line of the call stack shows the function that generated the error, • the next line shows the function that invoked the previous function, • and so on down the call stack until the hierarchy of function calls is exhausted.

  11. Exploiting Error Messages- Stack Traces

  12. Exploiting Error Messages- Stack Traces Information from stack trace • It often describes the reason why an error occurred. This may enable us to adjust our input to avoid the error condition and advance our attack. • The call stack typically makes reference to a number of library and third-party code components .We can …. • review the documentation for these components to understand their intended behavior and assumptions. • create our own local implementation and test this to know potential vulnerabilities.

  13. Exploiting Error Messages- Stack Traces Information from stack trace • The call stack includes the names of the proprietary code components being used to process the request. The naming scheme for these and the interrelationships between them • may allow usto infer details about the internal structure and functionality of the application.

  14. Exploiting Error Messages- Stack Traces • The stack trace often includes line numbers. As with the simple script error messages described previously, • these may enable us to understand the internal logic of individual application components. Information from stack trace

  15. Exploiting Error Messages- Stack Traces Information from stack trace • The error message often includes additional information about the application and the environment. • In the preceding example, you can determine the exact version of the ASP.NET platform being used. • This enables us to investigate the platform for known or new vulnerabilities, anomalous behavior, common configuration errors, and so on.

  16. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers.

  17. Exploiting Error Messages- Informative Debug Messages • Some applications generate custom error messages that contain a large amount of debug information. • These are normally implemented to facilitate debugging during development and testing, and • often contain rich detail about the runtime state of the application

  18. Exploiting Error Messages- Informative Debug Messages

  19. Exploiting Error Messages- Informative Debug Messages • commonly included in those debug messages: • Values of key session variables that can be manipulated via user input.eg:login status • Hostnames and credentials for back-end components such as databases. • File and directory names on the server.

  20. Exploiting Error Messages- Informative Debug Messages • commonly included in those debug messages: • Information embedded within meaningful session tokens (see Chapter 7). • Encryption keys used to protect data transmitted via the client (see Chapter 5). • Debug information for exceptions arising in native code components,including the values of CPU registers, contents of the stack, and a list of the loaded DLLs and their base addresses (see Chapter 15).

  21. Exploiting Error Messages- Informative Debug Messages • When user can see these information, it may signify a critical weakness to the security of the application. • By those information,we can • further advance our attack, and • find ways to manipulate the application’s state and • control the information retrieved.

  22. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers.

  23. Exploiting Error Messages- Server and Database Messages • Informative error messages are often returned by some back-end component such as a • Database, • Mail server, or • SOAP server. • When error occurs, the application will typically respond with an HTTP 500 status code, and the response body may contain further information about the error.

  24. Exploiting Error Messages- Server and Database Messages • In other cases, the application may return a customized message to the user, • sometimes including error information generated by the back-end component .

  25. Exploiting Error Messages- Server and Database Messages • Database error messages often contain information that you can use to advance an attack • For example, they often disclose the query that generated the error, enabling you to fine-tune a SQL injection attack:

  26. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers.

  27. Exploiting Error Messages- Using Public Information • Because of the huge variety of web application technologies and components in common use • wecan often obtain further information about the meaning of the message from various public sources.

  28. Exploiting Error Messages- Using Public Information • Often, an unusual error message is the result of a failure in a specific API. • Searching for the text of the message may lead us to the documentation for this API or to where the same problem is discussed. Those from public information

  29. Exploiting Error Messages- Using Public Information Those from public information • Many applications employ third-party components to perform specific common tasks, such as searches, shopping carts, and site feedback functions. • Any error messages that are generated by these components are likely to have arisen in other applications, and to have been discussed elsewhere.

  30. Exploiting Error Messages- Using Public Information Those from public information • Some applications incorporate source code that is publicly available. • By searching for these unusual error messages, we may actually discover the source code which implements the relevant function. • Wecan then review this and think how we may be able to manipulate the application to exploit a vulnerability.

  31. Outline • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary Sometimes web applications give away sensitive data is by actually publishing it directly and there are various reasons why an application may publish information.

  32. Why an application may publish information can be of use to an attacker • By design, as part of the application’s core functionality. • As an unintended side effect of another function. • Through debugging functionality that remains present in the live application. • Because of some vulnerability, such as broken access controls.

  33. Potentially sensitive information that applications often publish to users • Lists of valid usernames, account numbers, and document IDs. • User profile details, including user roles and privileges, date of last login, and account status. • The current user’s password (this is usually masked on-screen but is present in the page source). • Log files containing information like sernames, URLs, actions performed, session tokens, and database queries. • Application details in client-side HTML source, such as commented-out links or form fields, and comments about bugs.

  34. Outline Application may not show any data to you directly, but it may behave in ways that enable you to reliably infer information that is of use. • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary

  35. Using Inference- examining other categories of common vulnerability We had learned before • A registration function that enables you to enumerate registered usernames on the basis of an error message when an existing username is chosen (see Chapter 6). • A search engine that allows you to infer the contents of indexed documents that you are not authorized to view directly (see Chapter 11). • A blind SQL injection vulnerability in which you can alter the application’s behavior by adding a binary condition to an existing query,enabling to you extract information one bit at a time (see Chapter 9).

  36. Using Inference- examining other categories of common vulnerability And more now • By different lengths of time of operatings • Retrieved quickly from the server’s local cached copy, retrieved more slowly from the relevant back-end source. enabling a skilled attacker to enumerate accounts that have been accessed recently by other users.

  37. Using Inference- examining other categories of common vulnerability And more now • Request may depend upon whether a submitted item of data is valid. • Valid username • Retrieve account information • Update the audit log • Perform computationally intensive operations to validate the supplied password • Not valid • Reject • Attacker can detect this timing difference, he may be able to exploit it to enumerate valid usernames.

  38. Using Inference- examining other categories of common vulnerability • Functions may perform an action on the basis of user input which will time out if an item of submitted data is not valid • Eg. application may use a cookie to store the address of a host located behind a front-end load balancer • Attacker may be able to manipulate this address to scan for web servers inside the organization’s internal network • not part of the application infrastructure,immediately return an error. • nonexistent address is supplied, may time out attempting to contact this address, before returning the same generic error And more now

  39. Outline There are various relatively straightforward measures that can be taken to reduce information leakage to a minimum and to withhold altogether the most sensitive data that can critically undermine an application’s security if disclosed to an attacker. • Exploiting Error Messages • Script Error Messages • Stack Traces • Informative Debug Messages • Server and Database Messages • Using Public Information • Gathering Published Information • Using Inference • Preventing Information Leakage • Use Generic Error Messages • Protect Sensitive Information • Minimize Client-Side Information Leakage • Chapter Summary

  40. Preventing Information Leakage- Use Generic Error Messages • The application should never return error messages or debug information to the user’s browser • When an unexpected event occurs (such as an error in a database query, a failure to read a file from disk, or an exception in an external API call), the application should return the same, generic message informing the user that an error occurred.

  41. Preventing Information Leakage- Use Generic Error Messages • If it is necessary to record debug information for support or diagnostic purposes, then this should be held in a server-side log which is not publicly accessible, and an • index number may be returned to the user, enabling them to report this when contacting the helpdesk, if required

  42. Preventing Information Leakage- Use Generic Error Messages • Most application platforms and web servers can be configured to mask error information from being returned to the browser: • Application platform • In ASP.NET, • In the Java Platform • Web server • In Microsoft IIS • In Apache

  43. Preventing Information Leakage- Protect Sensitive Information • Application should not publish information that may be of use to an attacker, including usernames, log entries, or user profile • If there is a need for certain users to access this information, it should be protected by effective access controls and made available only where strictly necessary. • Existing data should not be disclosed where it is not necessary.eg. • Stored credit card numbers should be displayed in truncated form, • Password fields should never be prefilled, even if masked on-screen.

  44. Preventing Information Leakage- Minimize Client-Side Information Leakage • Removed or modified to minimize the disclosure of specific software versions, and so on • Steps of this measure are dependent upon the technologies in use Eg. • Microsoft IIS, the Server header can be removed using URLScan in the IISLockDown tool. • later versions of Apache, this can be achieved using the mod_headers module.

  45. Preventing Information Leakage- Minimize Client-Side Information Leakage • All comments should be removed from client-side code that is deployed to the live production environment, including all HTML and JavaScript • Such as Java applets and ActiveX controls,no sensitive information should be hidden within these thick-client components. A skilled attacker can decompile or reverse engineer these components to effectively recover their source code

  46. Thanks for listening!

More Related