Archive for the "Application Security" Category

Yahoo sub-domain compromised – 456k passwords dumped

 

Rumors are running around in a few places that a Yahoo! web property was hacked via SQL injection. Looking at the dump file there are a few clues that it is in fact from Yahoo. This will, no doubt cause many users headaches. Here are some statistics of interest that use culled from the dump with Pipal:

Top 10 passwords
123456 = 1667 (0.38%)
password = 780 (0.18%)
welcome = 437 (0.1%)
ninja = 333 (0.08%)
abc123 = 250 (0.06%)
123456789 = 222 (0.05%)
12345678 = 208 (0.05%)
sunshine = 205 (0.05%)
princess = 202 (0.05%)
qwerty = 172 (0.04%)

Password length (count ordered)
8 = 119135 (26.88%)
6 = 79629 (17.97%)
9 = 65964 (14.88%)
7 = 65611 (14.81%)
10 = 54762 (12.36%)
12 = 21733 (4.9%)
11 = 21224 (4.79%)
5 = 5325 (1.2%)
4 = 2749 (0.62%)
13 = 2663 (0.6%)
14 = 1502 (0.34%)
15 = 844 (0.19%)
16 = 575 (0.13%)
3 = 303 (0.07%)
17 = 267 (0.06%)
20 = 187 (0.04%)
18 = 133 (0.03%)
1 = 118 (0.03%)
19 = 99 (0.02%)
2 = 72 (0.02%)
21 = 23 (0.01%)
28 = 23 (0.01%)

Single digit on the end = 47445 (10.71%)
Two digits on the end = 73663 (16.62%)
Three digits on the end = 31106 (7.02%)

Last number
0 = 17608 (3.97%)
1 = 46705 (10.54%)
2 = 24635 (5.56%)
3 = 29233 (6.6%)
4 = 17712 (4.0%)
5 = 17413 (3.93%)
6 = 17899 (4.04%)
7 = 20403 (4.6%)
8 = 17863 (4.03%)
9 = 19922 (4.5%)

Other interesting stats:
.gov: 158
.mil 446
gmail.com: 106,909
yahoo.com: 138,837
hotmail.com: 55,178
aol.com: 24,731

No word yet on if the passwords were hashed or sitting in the DB in plain text.

I feel like 2012 is becoming the year of the high-profile password dump. I’ve had more and more non-security people ask me how I store my passwords. First, just about every web site and service I use has a different password. Second, I am big fan of KeePassX. It’s easy, open source (and well scrutinized), and available on any platform that I need it to be on. I also use two-factor on those sites that offer it (e.g. Google, Facebook, etc.)

-Trevor
@packetwerks

Follow us: @stratumsecurity

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 (http://cirt.net/nikto2)  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 http://python.org. I recommend installing the latest release of Python 2 (currently 2.6.6).

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

python doNikto.py

or you can type:

chmod +x doNikto.py

and call it via

./doNikto.py

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

Old-Trafford:nikto-2.1.3 jmorehouse$ ./doNikto.py
USAGE:
python donikto.py [Host File]
Host file should be in IP,Port format, with one host per line.
(e.g. 192.168.1.1,80)

So a sample host file would look something like:

192.168.1.1,80
some.webserver.com,443
forgotten.tomcatserver.org,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:

http://www.xxxxxx.xxx/banner_ad.php?url=ad.server.com/banners/ad1_small.jpg

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.

Strongwebmail.com Contest Analysis

 

If you are in the security industry you probably heard that Strongwebmail.com held a “hacking” contest to promote their “unhackable” authenticated scheme.  In a nutshell, users authenticate with their user ID/password and are then sent via SMS or voice call a one-time numeric string.  Without the numeric string (or PIN), you don’t get in.  If you followed this story you are no doubt are aware that a couple of security researchers (Lance James, Aviv Raff ,and Mike Bailey) were able to bypass the webmail’s input/output validation on email messages and XSS’d the CEO, gaining access to his calendar and claiming the prize.

Some called the contest a failure; others called it a success as Strongwebmail.com had essentially received a $10,000 pen-test.  However I wouldn’t call it a very good pen-test as Strongwebmail.com still has a few remaining problems:

Directory indexing exposes CodeIgniter tree:

strongwebmail1

Directory of misc. scripts:

strongwebmail2

Paypal scripts:

strongwebmail5

Also, I found what appears to be their webmail interface that is reading my cookie as the user “ceo”:

strongwebmail4

Nothing on the interface worked but still, this is functionality that should not be exposed.

The lesson learned here is that if you are going to evaluate the security of an application, you need to start at the lower levels of the stack and go up.  In Strongwebmail.com’s case, they not only had weaknesses in the application layer (XSS), but on the platform as well.