Several web applications provide functionality to pull data from other Internet facing Web Applications for either internal use or to verify application availability. We see this in the form of applications pulling images using user specified URLs, applications showing server status for user specified URLs, applications pulling feeds, XML and manifest files etc. An attacker can abuse this functionality to send crafted queries to a remote web server using the application that provides this functionality. The responses can be studied and in the case of unique responses, can be abused to do a blind port scan on any Internet facing device or even on internal local networks and the same server/host.
In this paper we will see how this commonly available functionality in most web applications can be abused by attackers to port scan other servers, or perform a Cross Site Port Scan (XSPS). I found this issue with Facebook, where I was able to port scan any Internet facing server using Facebook’s IP addresses. Consecutively, I was able to identify this issue in several other prominent Web Applications on the Internet, including Google, Apigee, StatMyWeb, Mozilla.org, Face.com, Pinterest, Yahoo, Adobe and several others. We will take a look at the vulnerabilities that were present in the above mentioned web applications that allowed me to abuse the functionality to perform port scans on remote servers using predefined functionality.
An attacker can abuse this by specifying URLs in the form of http://servername:<portnum> to the application and review the response obtained. I have seen three unique responses based on port and service. The following are the different errors/response messages obtained:
1. For an open port running an HTTP service, the error/server response is specific to the call. An attacker may see HTML content or a function specific message like “Image not found” or “Invalid data stream”
2. For an open port running a service other than HTTP (like SSH, TELNET, SMTP or RDP), the error/server response is mostly generic like “Invalid data stream”, “Expected content-type was invalid” or “Received HTTP error code -1 while fetching source feed”
3. For a closed port, the errors/server responses are often descriptive like “HTTP/1.1 503 Service Unavailable”, “[Errno 101] Network is unreachable” or “DOWNLOAD_ERROR_CONNECTION_REFUSED” etc.
Based on these error messages, which are unique for every server tested, we can conclusively identify closed and open ports on remote servers. Even better in some cases, the application displays the actual responses received in raw format allowing us to use it for banner grabbing.
Cross Site Port Scanning is a technique that allows an attacker to abuse perfectly common functionality, like fetching a file or data from a remote server, to perform blind port scans on Internet facing servers. An application which accepts user input as a URL, fetches content from the user supplied URL and displays non-generic errors, is vulnerable to XSPS. An attacker can also enumerate ports on the server that makes the HTTP request on behalf of the user by providing a localhost as the URL with a port parameter.
Simply put, an application that accepts a URL like http://site/images/derp.jpg fetches the content on the server side and displays the image, is vulnerable, if it displays port status or connection specific errors when a user requests the following URLs:
http://site:22/images/nonexistentimage.jpg
http://site:23/images/nonexistentimage.jpg
http://site:3128/images/nonexistentimage.jpg
http://site:3389/images/nonexistentimage.jpg
An attacker would then be able to analyze the error messages and identify open and closed ports based on unique error responses. These responses may be raw socket errors (like “Connection refused” or timeouts) or may be customized by the application (like “Unexpected header found” or “Service was not reachable”)
