Honeypot Processors: Access Policy Processor: Incidents - Service Directory Spider

Complexity: Medium (3.0)

Default Response: 1x = 5 day Block

Cause: Originally, embedded HTML technologies such as Flash and Java, were not able to communicate with third party domains. This was a security constraint to prevent a malicious Java or Flash object from performing unwanted actions against a site other then the one hosting the object (for example, a Java applet that brute forces a Gmail login in the background). This limitation was eventually decreased in order to facilitate more complex mash-ups of information from a variety of sources. However to prevent any untrusted websites from abusing this new capability, a resource called the "clientaccesspolicy.xml" was introduced. Now, when a plugin object wants to communicate with a different domain, it will first request "clientaccesspolicy.xml" from that domain. If the file specifies that the requesting domain is allowed to access the specified resource, then the plugin object will be given permission to communicate directly with the third party. The clientaccesspolicy.xml therefore provides a convenient reference for hackers when trying to scope the attack surface of the website. For example, there can be a vulnerable service listed in clientaccesspolicy.xml, but that service cannot be referenced anywhere else on the site. So unless the hacker looks at clientaccesspolicy.xml, they would never even know the service existed. WebApp Secure will inject a fake service definition into the clientaccesspolicy.xml file in order to identify which users are manually probing the file for information. The "Service Directory Spidering" incident will be triggered if the user attempts to request a random file inside the directory the fake service is supposedly located in.

Behavior: Requesting a random file from the directory where the potentially vulnerable service is supposedly located is likely in an effort to identify other unreferenced resources. This could include configuration files, other services, data files, and so on. Usually an attacker will first attempt to get a full directory index (which only takes one request), but if that fails, the only other technique is to guess the filenames (which could take thousands of requests). Because guessing the file names can take so many requests, there are several publicly available tools that can enumerate over a large list of common file and directory names in a matter of minutes. This type of behavior is an attempt to exploit a server for "Predictable Resource Location" vulnerabilities, and is generally done while the attack is trying to scope the web applications attack surface.

Note: For information on the attack types mentioned here, go to The Web Application Security Consortium Web Site and search for the attack name to learn more about it.