Mapping the Application

First step of attacking an application.

• Process:
  • Map application functions
  • Examine its behavior, security mechanisms, and technologies used.
• Enumerating an application helps identify the attack surface. Once technologies and behaviors are understood, then an application can be enumerated to find out vulnerabilities.

Enumerating Content and Functionality

• Usually, simple browsing of an application can show most of the functionality.
• Attackers may have to employ more advanced techniques like those shown in the following sections.

Web Spidering

• Process:
  1. Request web page
  2. Parse for links to other content
     • Also parse HTML forms
  3. Request those links
     • If HTML form, submit back using various preset/random values.
  4. Recursively continue the previous steps until there are no new pages.
• By parsing and submitting values into forms, form-based navigation can occur.
• Useful tools:
  • Burp Suite, WebScarab, Zed Attack Proxy, and CAT.
• robots.txt is used on many websites as a blacklist of what paths that spiders can crawl. This can be used to also identify insecure or sensitive paths.
• Issues:
  • Spidering applications may not be capable of handling unusual navigation mechanisms like:
    • Dynamically generated menus
    • Links inside client-side objects like Flash or Java applets.
  • Multistage functionality may not accept data entered, prohibiting further crawling. Form-based navigation mechanisms are likely to use this.
  • Some applications are traversed using the same URL to send many different POSTrequests. Some spiders may ignore subsequent requests to these URLs.
    • This is because they assume the application will respond with the same content that had already been crawled when requesting that same URL.
  • Each page may generate new links that can cause a spider to crawl indefinitely.
  • If a spider 'stumbles' upon administrative functionalities, crawling an application can be detrimental to an organization. For instance, a spider might submit requests to delete users or even shut down servers if improper access control is employed on these functions.

User-Directed Spidering

• A user walks through an application and the resulting traffic is sent to a tool that is both a spider and a proxy. This tool will parse the responses and map out the application.
• Benefits:
  • Can avoid dangerous functionalities, but still enumerate and include them in documentation.
  • Can react to accidental session logouts.
  • Can check for validation requirements.
• Process:
  1. Configure a browser to use Burp or Webscarab as a local proxy.
  2. Browse application.
  3. Review site map generated by tool. Identify content and functions that was not manually browsed.
  4. (Optional) Use the same tool afterwards to automatically enumerate the same content.

Discovering Hidden Content

• Hidden content is common for testing and debugging. Functionalities based on user authorization are sometimes hidden too.

Brute-Force Techniques

• Automated brute-forcing can speed up searches for hidden content after establishing a website map.
• Author Note:
  • Don't assume an application will respond with a 200or a 404response code based on the existence of content. Some applications return a 200 response with a custom error message when requesting nonexistent content.
  • Other examples include redirecting (302), returning a bad response code (400), or unauthorized (401) / forbidden (403) response.
• Process:
  1. Make manual requests for known valid and invalid resources. This helps to establish how the server handles requests to invalid resources.
  2. Use a site map generated by spidering as the basis for automated discovery of hidden content.
  3. Script out requests for common filenames and directories for discovered paths.
  4. Review responses for valid resources; recursively repeat until no new content comes up.

Inference from Published Content

• Base automated searches on an identified naming scheme. Some resources may be camel-cased, snake-cased, or completely lowercase. Usage of numeric values for identifiers can also be iterated through.
• Process:
  1. Create a list of names of sub-directories, file extensions, and file names.
  2. Identify naming schemes employed in this list.
  3. Look for dates and numeric identifiers appended to resources. Use the same resource identifiers and increment or decrement those values.
  4. Look through HTML and JavaScript code/comments for clues about hidden content.
  5. Search for temporary files that developers accidentally created via developer tools or file editors.
     • e.g. .DS_Store or .git

Use of Public Information

• Search Engines
  • Used for searches of cached copies of content and quick indexed searches of specific content.
• Web Archives
  • e.g. WayBack Machine

Leveraging the Web Server

• Use a tool like Wikto to scan for content based on the webserver and software running on it. These type of scanners use lists of default files and directories. They may also come back with inaccurate false negatives. This can occur if certain banners or content used for these default resources are not included.

Application Pages Versus Functional Paths

• Applications may use only a single url for requests. Parameters passed in these requests are used to invoke some functionalities. By looking at the application based on the number of pages requested, an inaccurate representation is formed.
  • In this case, a functional path based method should be used to more accurately represent an application's functionalities.
• Alternatively, REST-style URLs basically have parameters passed as a path. In this way, spiders not only map out the website but also its functionalities.
• Process:
  • Identify where functionality is accessed by passing the name of a function as a parameter.
  • If an application uses this method of accessing functions, then attempt to access invalid functionality to establish how it handles these requests.
  • Create a map of the application's functionalities using functional paths by demonstrating logical paths and dependencies.

Discovering Hidden Parameters

• Try using the parameter debug-true in the query string. If the application handles this parameter, then some input validation checks and access control methods can be bypassed. Additionally, the application may respond with debug information .
• Process:
  • Use common debug parameter names and common 'true' values. Iterate through these to test whether an application function supports debug features.
  • Check all responses for anomalies that shows the processing of the passed parameter.
  • If possible, test this on many different functions and pages.

Analyzing the Application

• After enumerating an application, a penetration tester must be capable of analyzing the application. By analyzing functions, behavior (such as error messages, administrative and logging features, redirects), and technologies used in the application, an attack surface can be established.

Identifying Entry Points for User Input

• Look for the following:
  • URL File Paths
  • Parameters in the query string
  • Parameters in the POSTbody
  • Cookies
  • HTTP headers the application processes
    • User-Agent
    • Referer
    • Accept
    • Accept-Language
    • Host

URL File Paths

• In REST-style URLs, URL paths are functionally the same as parameters. For this reason, one must also consider them an entry point similar to query strings.

Request Parameters

• Some applications have their own custom standard for request parameters. For this reason, delimeters, formats, and markers may differ.
• With custom formats, the probing of an application must be tuned to work for that application.
  • e.g. if an application uses an encoded format of =, then subsequent requests should be changed in order to test all functionality determined by parameters at that URL.

HTTP Headers

• Some applications function differently depending upon the Referer and User-Agent values.
  • Referer:
    • Applications may perform processing based on this header.
    • Examples:
      • Custom response based on search query in referred search engine
      • Dynamically generating content to match frequently searched content
    • So, it may be possible to inject content into the responses of the application.
  • User-Agent:
    • Applications may also present different content based on the user device.
    • Attackers can spoof this header to find additional components of the attack surface. These additional components could have less security testing or additional features.
  • X-Forewarded-For:
    • Applications may use a client's IP address passed in this parameter.
    • Developers may assume this value is untainted.

Out-of-Band Channels

• Definition: Transferring data through a stream that is independent from the main in-band data stream.
• Using an out-of-band channel that the application receives data from.
  • web mail application using SMTP
  • An application accepting content from HTTP of another server
  • Applications with API's usable by User-Agents that are not browsers.

Identifying Server-Side Technologies

Banner Grabbing

• Serverheader: discloses details about server and installed software.
• Software information can also be found in:
  • Templates used for web pages
  • Custom HTTP headers
  • Query string parameters

HTTP Fingerprinting

• A server's software can be identified despite hidden or altered Server header info.
  • To do so, test for information in other headers corresponding to server software.
• Applications like Httprecon attempt to fingerprint the server software.

File Extensions

• File extensions can be used to identify the programming languages employed.
  • asp- Microsoft Active Server Pages
  • aspx- Microsoft ASP.NET
  • jsp- Java Server Pages
  • cfm - Cold Fusion
  • d2w- WebSphere
  • pl- Perl
  • dll- Compiled native code (C / C++)
  • nsfor ntf- Lotus Domino
• By making requests to nonexistent resources while appending file extension, one can test whether the server supports certain languages. If supported, the server may return back a custom error message for that language or framework.

Directory Names

• servlet- Java servlets
• pls - Oracle Application Server PL/SQL gateway
• cfdocsor cfide- Cold Fusion
• SilverStream- SilverStream web server
• WebObjectsor.woa - Apple WebObjects
• rails- Ruby on Rails

Session Tokens

• JSESSIONID- Java
• ASPSESSIONID- Microsoft IIS server
• APS.NET_SessionId - APS.NET
• CFID/CFTOKEN - Cold Fusion
• PHPSESSID- PHP

Third-Party Code Components

• If the server uses third-party code, these are often open source. So, they can be inspected openly so one can understand how the code works.

Process of Identifying Server-Side Technologies:

1. Identify entry points
2. Examine query string format
3. Identify out-of-band channels
4. View the HTTP Server banner
5. Check for software identifiers in custom headers or source code comments
6. Use a tool like httprint to fingerprint the server
7. If versions of software can be identified, then do searches on the software to check for known vulnerabilities
8. Look for interesting file extensions, directories, or tokens that can help identify software utilized by a server.
9. Perform searches of unusual cookies, scripts, headers, and other uniquely identifiable information that may help identify a server's software.

Identifying Server-Side Functionality

Dissecting Requests

• Process:
  • Review names-value pairs of parameters submitted to the application.
  • Rationalize what server-side methods and software utilizes these parameters to elicit the behavior in the responses.

Extrapolating Application Behavior

• Applications are often written by the same developer or under the same standard. For this reason, conclusions made about parts of an application may be applicable to other parts or the entirety of the application.
  • Vulnerabilities found in some parts of an application may extend to other parts as well.
    • If initially a vulnerability is found, but the behavior cannot be analyzed without further or more verbose responses, a penetration tester could attempt the same vulnerability in other parts of an application that provides more verbose responses.
    • e.g. an error message in one part of an application.
      • Some areas of an app may handle errors gracefully while others may crash and return debug information.

Isolating Unique Application Behavior

• Process:
  • Note functionality that does not fit previous standards. For instance, different GUI, parameter naming, navigation mechanisms, etc.
  • Note retrospective changes that are recognized, like CAPTCHA's, debug functions, and third-party add-ons.
  • Review these areas.

Mapping the Attack Surface

• This is the last part of mapping an application: identifying attack surfaces.
• (Rough list provided in WAHH v.2)
  • Client-side validation — Checks may not be replicated on the server
  • Database interaction — SQL injection
  • File uploading and downloading — Path traversal vulnerabilities, stored cross-site scripting.
  • Display of user-supplied data — Cross-site scripting
  • Dynamic redirects — Redirection and header injection attacks
  • Social networking features — username enumeration, stored cross-site scripting
  • Login — Username enumeration, weak passwords, ability to use brute force
  • Multistage login — Logic fl aws
  • Session state — Predictable tokens, insecure handling of tokens
  • Access controls — Horizontal and vertical privilege escalation
  • User impersonation functions — Privilege escalation
  • Use of cleartext communications — Session hijacking, capture of credentials and other sensitive data
  • Off-site links — Leakage of query string parameters in the Referer header
  • Interfaces to external systems — Shortcuts in the handling of sessions and/or access controls
  • Error messages — Information leakage
  • E-mail interaction — E-mail and/or command injection
  • Native code components or interaction — Buffer overfl ows
  • Use of third-party application components — Known vulnerabilities
  • Identifiable web server software — Common configuration weaknesses, known software bugs