I was pleased to see that OWASP updated their Top 10 Application Security Risks. Over all I think that they are good modifications. I think that the changes represent the ongoing maturation of the space and shows that the industry now has data that shapes the way that we think about application security vulnerabilities. In this post we will look at how the changes to the Top 10 are more relevant than ever.
One of the more interesting updates is A6. The 2007 OWASP Top 10 included “A6 – Information Leakage and Improper Error Handling”. This was dropped for “Security Misconfiguration” in 2010 because:
“Information Leakage and Improper Error Handling. This issue is extremely prevalent, but the impact of disclosing stack trace and error message information is typically minimal. With the addition of Security Misconfiguration this year, proper configuration of error handling is a big part of securely configuring your application and servers.”
In short, most application development frameworks have built-in error handling features that are easy for developers to enable via configuration changes and platform patches. Rather than use an entire list entry on error handling, OWASP is essentially saying, “Flip the secure switches on”.
Application error messages can contain anything from generic stack traces to filesystem paths and internal IP addresses. However these are often downplayed by developers. Some organizations are quick to say, “Well getting the internal IP address doesn’t get you anything. It’s a NAT IP and behind the firewall.”
In our reports, we document an information disclosure finding’s impact as “This finding could be used in the construction of a more effective attack against the application.” This is because a successful exploit usually is the result of several failures within the application or system. No one control is usually responsible for the success for failure of the system.
What follows is a case study that shows that application error messages and information gathering vulnerabilities are very helpful to an attacker.
Stratum Security recently assessed an organization’s primary web property that is in the Alexa top 8,000 sites. We found that the site’s banner ad referral functionality contained a url parameter that defined the URL that the application server should use to fetch the banner ad’s graphic:
This is bad as an attacker could point the url parameter at his own malicious web site that serves up malware or browser exploits, use a full screen iframe to perform a phishing attack that intercepts user credentials, or a number or other well-known attacks.
We examined the finding a bit more and found that if we modified the url parameter that it would make HTTP connections to the host we specified:
Note: the php would only accept the URL value in reverse. In this case, you can see that the web application connected to localhost (127.0.0.1) on port 22, displaying the SSH banner.
Without a nice application error message, this vulnerability may have gone unnoticed.
We also attempted to define other URI’s such as file:///etc/passwd to access local filesystem content but found that our input was always prefaced with “http://”. Fine, we’ll stick to HTTP.
Now, we know that we can force the application to make HTTP connections to devices that we specify, but in order to explore the DMZ network we need to figure out the DMZ’s internal IP space.
To enumerate the internal IP space being used, we scanned the customer’s Internet-exposed web servers for the often seen OSVDB-630, which leaks the internal IP address on IIS servers. We identified an IIS server that was not patched for this flaw and found that the internal IP range was 10.172.85.0/24.
Using our knowledge of the internal IP address, we used cURL to iterate through the DMZ’s internal IP space to search for HTTP servers:
curl http://www.xxxxxx.xxx/banner_ad.php?url=10.172.85.[1-254] -o output.txt
We then parsed the output.txt and identified those devices that answered on port 80. We identified web servers including Cisco switch and router HTTP configuration consoles, JBoss Consoles, Tomcat Managers, default IIS installs and other interesting things. In total we found 28 web servers in a DMZ that only had 11 Internet-exposed web servers. Here are a few examples of things we shouldn’t have been able to see:
Most interesting, a server with directory indexing enabled that contained a large number of directories:
One directory titled “BACKUP” contained a single .tgz file that turned out to be another web site’s entire webroot containing source code, database connection strings, configuration files, etc.
Using cURL, we downloaded the file:
curl http://www.xxxxxx.xxx/banner_ad.php?url=zgt.pukcab/PUKCAB/99.48.271.01″ -o backup.tgz
% Total %Received %Xferd Average Time Time Time Current Dload Upload Total Spent Left Speed
100 43.5M 0 43.5M 0 0 1874k 0 –:–:– 0:00:23 –:–:– 1916k
$ ls –l
45702392 Apr 20 10:17 backup.tgz
We are now downloading files from web servers behind the firewall in the DMZ.
While many rate error handling and information disclosure/leakage findings as a medium or low severity, it is important to consider how all of the findings work together for the attacker. What started out as a single high severity finding, remote file inclusion, ended up being a complete compromise of the DMZ network and firewall-protected systems. None of this would have been possible without some verbose error messages and that pesky IIS Internal IP Address Disclosure flaw.