Wednesday, May 11, 2011

CMS Exporer in BackTrack 5

Just a quick note that Sunera's CMS Explorer has made its way into the BackTrack Linux version 5 (Revolution) release! So no need to download it separately, just fire it up in BackTrack when you come against one of the supported CMS systems.

You can find it on the menus (which are now aligned by the PTES and OSSTMM standards) under CMS Identification:
BackTrack -> Information Gathering -> Web Application Analysis -> CMS Identification -> cms-explorer
And note that before you use it, you may want to supply an OSVDB-API key:
If you see this message, you need to add your API key.
And just a reminder that CMS Explorer is open source Perl code, so please consider contributing to the project. Additionally, it requires the GetOpt::Long module and LibWhisker--both of which are included in the BackTrack distro.

Put your OSVDB API Key in the $osvdb_api_key variable.

Thanks to the BackTrack team for continuing to enhance the pentesting distro and adding new tools like this (and others)!

Friday, April 29, 2011

4 Tips for Safer Gaming

Did you recently receive an e-mail from the PlayStation Network (PSN) informing you that your personal information may have been lost? If so, you're one of many victims on a growing list for this year. Many hospitals, universities, and major companies such as Epsilon and Sony have all suffered similar data breaches in the first four months of 2011. Although data breaches are spreading to new horizons such as social networking and electronic health records, console gaming and associated processing systems are target rich environments that have been overlooked. This recent PSN breach serves as a wake-up call, drawing attention to the trust consumers put into these systems.
Whether you were affected by this breach or not, if you're a gamer you're probably wondering what you can do to bolster your security while gaming online. Based on our knowledge in network security and risk management paired with our team's personal experiences in online gaming, we've written a list of four potential steps you can take to play online, but keep your personal information as safe as possible.
1) Trust No One
We are being reminded on a fairly regular basis that our assumptions of trust in the online environment are unfounded.  We may use visual indicators like a visually appealing online presence, padlock icons, highlighted urls and ‘hacker safe’ logos to help justify moving forward with online transactions and information submissions, however they are no indicator of *actual* security.  Every single time you submit information to anyone, via phone, web form or jamming your credit card number into your gaming console, please stop and ask yourself “What would a bad guy do with this information?”  If your answer would hurt your bank accounts, credit or present issues with identity theft consider other options.  Specifically concerning transactions, review the alternative payment methods below.  Further, consider having non-critical email account(s) available for more trivial registrations.  The idea is to limit your exposure and risk. You will never eliminate risk entirely, but taking steps to limit damage can go a long way.
2) Utilize an Alternative Payment Method (Reduce your personal risk.)
Based on the recent loss of information, you may be less apt to trust online gaming networks with your information. Although little can be done to protect your contact information, it is possible to limit the exposure of your payment card data. Rather than exposing your card number, authentication code, and expiration data, consider these alternatives. Cards with points or credit in the gaming network can be purchased at many reputable retailers. These cards can be used to purchase items, games, and add-ons in the gaming network without exposing credit card data to them. Furthermore, it may be appropriate to leverage a limited use credit card. These cards may be generated by your online banking provider for one time use. Alternatively, consider using one of the many payment cards available with very low limits or allocated funds. Many banks offer a system in which parents can give their children cards with a certain cash value on them and refill the cards when needed. These cards may be ideal for less trusted vendors.
3) Segment your home network
In many ways, a console gaming system is like a network appliance. You have very little or no control over the software deployed on the system or how it interacts with the environment. In fact, many console systems use the universal plug and play (UPnP) protocol to open your home network up; establishing communications channels and opening ports to the outside. All of this is done with your implicit consent and, if you'd like to continue to participate in first person shooter (FPS) fun, you can't restrict those features.
Systems of this sort are often trusted less than others because they cannot be controlled or secured in the same fashion as PCs. When two distinct trust levels are present on a network, segmentation should be put into place.  This segmentation, or grouping, of systems will help prevent attacks which depend on being in the same logical network as other systems.  These attacks include man-in-the-middle style attacks and traffic analysis.  These types of attacks could be used from a gaming console to intercept sensitive information between your PC and retailers or online banking systems.
Although it would be nice to implement a full featured firewall between your PCs and the gaming systems, an alternative type of segmentation is possible with many home routers. New routers often include segmentation features such as VLANs. You can assign the gaming console(s) in your environment to a VLAN separate from the rest of your systems. This will limit inadvertent exposure of PCs using gaming ports and keep gaming consoles on their own network.  Of course, the underlying assumption here is your gaming console is not used as a media center requiring internal network communication - in which case more advanced preparation and setup may be required.
The following is a list of major, consumer-grade router manufacturers. Consult their website to determine whether or not your router supports network segmentation features, such as multiple VLANs:
  • DLink
  • Belkin
  • Cisco / Linksys
  • If your router does not support VLANs in vendor provided firmware, a custom firmware may be available which will enable this feature. If you are comfortable applying custom firmware (CFW) to your router, consider applying OpenWRT or DD-WRT to enable advanced features.
4) Consider the source of software
At the heart of a gaming console is a computer, one which has been optimized for accomplishing a single purpose, but a computer nonetheless.  As a result, we should treat consoles more like our PCs. If a website were offering a custom version of a popular operating system, such as Windows or OS X, wouldn't you be wary of applying that to your computer? We should apply the same logic to custom firmware and console gaming software available on the internet. A common attack against PCs is to backdoor pirated software or video games and then make the software available on peer-to-peer networks.  This attack vector would be highly effective against console gaming systems by deploying malicious game software or CFW.
Be wary of this software, evaluating and vetting software as much as possible before deploying it. CFW is not a bad thing and should be respected for the capabilities it provides consumers, but it should also be considered carefully by consumers as these CFWs become system level objects on gaming consoles when they are applied. This means that they have control over all aspects of the system.
Confirm the hash values of software against known, good values where possible to ensure that the software has not been changed or corrupted. Try to gather software from reputable sources as applicable.
The simplest answer to securing your information in this venue is to stop gaming online, but what fun is that? Keep these five things in mind to game safer and protect your personal information using a risk based approach.

Thursday, February 10, 2011

When Distros (Sneak) Attack

I was re-testing a list of findings from a prior engagement yesterday and eventually worked my way down to the "SSLv2" enabled list. These are pretty much the universal findings, since seemingly few people disable SSLv2 or weak ciphers when standing up a web server. Also, applying the recommended registry fix in Windows isn't always executed to perfection, so SSLv2 tends to linger.

For quick checks like this, I use OpenSSL from the command line:

steve@swt-work:~$ openssl s_client -ssl2 -host some.ssl.host -port 443


If you get a bunch of certificate information back, the site supports SSLv2. If you get an error, it doesn't. Simple, right? Maybe not. I got errors on the first seven or so sites, and that got my spidey sense tingling. Maybe they actually removed SSLv2 successfully on all these systems, but I remain suspicious. So, I tracked down some hosts known to use SSLv2 and all of them reported the same error.

19669:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:


It didn't seem to be an issue with OpenSSL itself, because connections to SSLv3 sites worked as expected. After a few moments of troubleshooting, I turned to Google. No definitive answer was forthcoming, but I did come across a mail list post that indicated that Ubuntu entirely removed SSLv2 from OpenSSL. I jumped onto another Linux distribution and did some parallel testing. OpenSSL in Ubuntu does not support SSLv2, and "null ssl method" is the only message you get. We reviewed the changelog and verified the change.

openssl (0.9.8o-1ubuntu3) maverick; urgency=low

* debian/patches/no-sslv2.patch: disable SSLv2 to match NSS and GnuTLS.
The protocol is unsafe and extremely deprecated. (Debian bug 589706)

-- Kees Cook Tue, 20 Jul 2010 08:24:13 -0700


At this point, I was upset with Ubuntu for wasting my time, and fired off a tweet to that effect. Since I had another distribution available, I moved on with my auditing from there.

Then one of my co-workers wondered if Nessus SSLv2 scans worked on Ubuntu hosts. After some brief testing on other distributions, lo and behold, Nessus plugin 20007 (SSLv2 Enabled) does not recognize SSLv2-enabled servers. Anyone that has been using Nessus on Ubuntu 10.10 since July 2010 for scanning has been unable to detect SSLv2-enabled servers. That's an issue.

I took to the Nessus discussion forums for some guidance, since those guys are so quick to respond. It took all of 20 minutes for Renaud Deraison to reply:
I really like when vendors think they know better -- if a program wants to use SSLv2 they should not get in the way and decide it's bad, without looking at the context.

This probably means that in the not-so-long term, Nessus will ship with its own version of OpenSSL (as we do on Windows and in the "generic" builds).

So, the good news was that Tenable was planning to work around this distro nannyism by shipping their own SSL. The bad news was that we needed a fix in the interim, or our Nessus scans would be suspect.

I then noticed that Kees Cook came across my tweet and responded. After a brief exchange about the removal of SSLv2, he posted a step-by-step guide to reversing the no-ssl2 patch.

$ sudo apt-get install build-essential devscripts
...
$ sudo apt-get build-dep openssl
...
$ apt-get source openssl
$ cd openssl-*
$ quilt pop -a
...
$ sed -i '/no-sslv2.patch/d' debian/patches/series
$ quilt push -a
...
$ dch -n 'Allow dangerous v2 protocol'
$ debuild -uc -us
...
$ ls ../*ssl*.deb


Most of the instructions were familiar, but I hadn't used 'quilt' before. In this case, 'quilt pop -a' removes all patches, and the 'quilt push -a' adds all the patches in debian/patches/series once the "no-sslv2.patch" entry has been deleted. Then the debs are built and easily installed using the 'dpkg -i' command.

Nessus and the openssl s_client were once again able to connect using SSLv2 with the custom debs installed. I reported this back to the Nessus discussion forum thread, and Renaud once again responded with lightning speed.
Nessus 4.4.1 for Ubuntu 10.10 will ship with its own OpenSSL 0.9.8r. ETA is "very soon". Your solution is fine in the meantime, but it's a hack. In the long term, as distributions start to decide they know best about their users needs, we'll probably start shipping OpenSSL with more and more builds
So, in the long run, this will not be an issue for Nessus users on Ubuntu. In the short term, there is a workaround, but system updates will require extra attention, as OpenSSL needs to be rebuilt after every update.