Archive for the "OWASP" Category

Stratum Sponsoring First OWASP Tampa Day


Stratum is proud to be sponsoring the first OWASP Tampa Day this Monday, June 20th. The free event will feature presentations aimed at providing developers and Information Security professionals with an introduction to application security. The event features 4 presentations from application security experts and ‘sold-out’ in less than 48 hours with 76 registered attendees. You can visit the event’s Eventbrite page for more information.

Stratum’s own Trevor Hawthorn will be presenting PCI for Developers: Lessons from the Real World,

Any organization that stores, processes, or transmits credit card data must comply with the Payment Card Industry’s (PCI) Data Security Standards (DSS). PCI can be daunting even for compliance and security experts. If you are a developer, it can be a major headache. Sooner or later the day will come when you (or your developers) will need to integrate PCI into your Software Development Lifecycle (SDLC). During this talk Trevor will discuss what is required to meet PCI compliance, and examine how a wide variety of organizations tackle their compliance obligations.

Stratum is also a sponsor of the OWASP Tampa chapter.

Automate Nikto with doNikto


Nikto (  is an Open Source web scanner that checks for several different types of vulnerabilities, including:

  • Over 6400 potentially dangerous files/CGIs
  • Outdated versions of over 1000 servers
  • Version specific problems for over 270 servers

Nikto was developed by a friend of mine, Chris Sullo (@chrissullo) and now is maintained by Sullo and David Lodge. Version 2.1.3 was released in February of this year after getting back from a lengthy tour of european pubs, or so I am told.

I personally still use Nikto on all of my assessments, as it provides a good supplement to other automated scanning tools. To help automate the process of scanning hundreds of web servers, I wrote a simple python script that takes a specially formatted host file (ip address or  hostname,port) and runs Nikto continuously against them. doNikto generates separate HTML output files for each line in the host file (Nikto_IP/Hostname_Port.html) in the current directory.

To get doNikto running on your system, simply make sure you have Python installed on your system. Snow Leopard and Ubuntu users, you’re good. Windows users, check out I recommend installing the latest release of Python 2 (currently 2.6.6).

Once you have Python installed, and of course Nikto, download here and install it in same directory as You can invoke doNikto by simply typing;


or you can type:

chmod +x

and call it via


Once you have doNikto all setup, it is pretty straight forward to use:

Old-Trafford:nikto-2.1.3 jmorehouse$ ./
python [Host File]
Host file should be in IP,Port format, with one host per line.

So a sample host file would look something like:,80,443,8080

Finally, you can ctrl-break (ctrl+c) doNikto to skip hung servers and proceed to the next server in the host file.

That’s all there is. Pretty straightforward and something I find useful on a regular basis. Let me know if you have any issues or suggestions and enjoy!

OWASP Top 10 2010: Adding It All Up


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 ( 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

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[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″ -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.

Trevor Hawthorn speaking at OWASP Tampa March 24, 2010


I will be giving my Shmoocon talk The New World of Smartphone Security at OWASP Tamapa on March 24th, 2010. If you would like to attend please RSVP to the chapter leader Justin Moorehouse.

More information can be found on the OWASP Tamapa page.