Now that I’m back from Las Vegas and have had a week to dig out from under email and work tasks, I’d like to share a short post-con wrap-up.

The Black Hat Briefings 2008 were a good time. Just as important as the briefings, I had a lot of fun meeting new people, seeing old friends, and networking with others in the security community. Our industry is really based on trust and trusted relationships, so I always try and get out and mingle at the con.

Both of my DEFCON presentations seemed to be really well received. I was surprised with the large turnout Friday 10am for my web application firewall (WAF) talk, given that my slot was competing directly with the Dark Tangent’s annual DEFCON keynote and Joe “Kingpin” Grand’s talk on the making of this year’s badge. There were a few good questions, so at least someone was awake and paying attention.

My Friday afternoon talk on Snort plug-in development was very well attended. A group of Sourcefire employees were filling out the front row. They didn’t throw any rotten vegetables at me, so I figure I did alright.

Updated presentation materials should be getting posted to the DEFCON site soon. Here are links to the slides for my WAF talk, and slides for my Snort-plug-in development talk. I’m busy adding to my Snort preprocessor for weak SSH2 Diffie-Hellman Group Key Exchange, and should be releasing some new code released in the next few weeks.

I’ll be delivering two talks at DEFCON 16 in Las Vegas this Friday, August 8th. My first talk, The Wide World of WAFs, covers web applications firewalls and some PCI DSS background. In talk that afternoon, Snort Plug-in Development: Teaching an Old Pig New Tricks, I’ll be releasing GPL licensed Snort plug-ins for ActiveX control detection and for detecting OpenSSH clients and servers using a broken Debian OpenSSL PRNG.

I hope to see some of ya’ll out in Vegas!

The Unnamed Police Department (we’ll just call them the UPD for short) is charged with keeping the peace in a major American metropolitan area. For a public safety website, theirs is quite advanced. Visitors can view dynamically generated maps showing the distribution of different classes of crimes, make anonymous tips to the narcotics squad, and even try to sign up to join the force. As those of us that work in information security well know, all that rich web functionality brings increased risk.

This past Thursday afternoon I received a report from a colleague that the UPD public website appeared to be serving up malicious JavaScript injections. The URLs of the injected scripts were consistent with the recent waves of mass SQL injection attacks that have targeted Microsoft IIS sites backed by Microsoft SQL Server databases. The injected JavaScript payloads were consistent with malicious scripts generated using the Neosploit obfuscation tool. The first stage script redirected victims to another script, this one hosted at a domain name registered just the day before with a German domain registrar.

The impact of all this? Visitors to the UPD website were having their web browsers loaded with a witches brew of exploits, potentially leading to complete system compromise. While not all visitors were successfully exploited, enough folks are getting owned with these attacks to make them increasingly popular with the bad guys. Users of a tool such as the NoScript extension for Firefox (or possibly Microsoft’s new XSSFilter being included with Internet Explorer 8) would have been protected.

I immediately contacted the UPD and reported the issue. The conversation was initially pretty humorous, as you might imagine. Fortunately, the department includes a cybercrimes unit and my report was immediately routed to them. The contact at the UPD called me back about 5 minutes later and informed me one of the investigators in the cybercrimes unit had indeed confirmed the problem, and that they were working to resolve the issue. To verify the report, the cybercrimes investigator supposedly browsed to the UPD’s own public website and saw his anti-virus software light up with warnings.

I checked back less than four hours later, and the site appeared clean. I’m impressed with the speed of the response, given previously reported compromises of state and local government websites (credit to Sunbelt Blog: here, here, here, and here). I really thought I had enough time to get home before writing a cron job to keep checking the site for when it got cleaned up!

Unless the underlying SQL injection vulnerability was fixed however, this site is very likely to fall victim again, and soon.

This past Tuesday July 8th was a big day in information security. Accomplished security researcher Dan Kaminsky of IOActive announced a major new vulnerability in the DNS infrastructure underpinning the Internet. What is the vulnerability, you ask? We may all have to wait for Dan to tell us at the Black Hat Briefings security conference, kicking off on Wednesday August 6th.

You see, what transpired Tuesday was a massive coordinated exercise in controlled vulnerability disclosure, pulled off by many of the biggest vendors in IT. It has been attempted (e.g., SNMP), but something like this has never really been pulled off before.

Dan Kaminsky, with the help of Internet pioneer Paul Vixie and US-CERT, pulled all the major players together and got them to actually agree they had a problem. At a closely guarded March 31st meeting on Microsoft’s Redmond campus, the likes of Microsoft, Cisco and the ISC BIND team reached consensus on an aggressive fix to be coordinated among the participants. What’s more, this diverse group managed to effectively keep a lid on their efforts until Tuesday. As Dan said in a podcast interview, they “were very careful.”

Security research is all built upon trust, and the folks involved in this disclosure process proved themselves worthy of ours.

Dan references our very own Joe Stewart’s 2002 work on DNS cache poisoning attacks as helping to form a basis for this new work.

For the less technically inclined, Rich Mogull’s “Executive Overview” does a good job at explaining what all the fuss is about. Otherwise, I’d suggest you go right to the source, Dan’s post at DoxPara Research. And for good measure and referential completeness, US-CERT Vulnerability Note #VU800113 is right here.

I will be delivering a talk on PCI 6.6 and web application firewalls (WAFs) at Summercon this coming Saturday May 31st. If you are going to be in the Atlanta area this weekend, you really ought to come out and join the fun!

There has been a fair amount of controversy as of late surrounding The Race to Zero contest to be unofficially held at DEFCON 16 this coming August. To briefly summarize, contestants are to be given samples of computer viruses/malware and access to a contest portal. The portal will take malware samples submitted by the contestants and run them through a collection of anti-virus engines, checking to see if the samples are detected. The contestants will make modifications to the malware samples in attempts to slip modified samples past the AV engines undetected. In keeping with the mischievous hacker zeitgeist of DEFCON, awards will be given for the “Most Elegant Obfuscation,” “Dirtiest Hack of an Obfuscation,” “Comedy Value” and “Most Deserving of Beer.”

AV vendors were predictably upset by the prospect of this exercise. Most objections seemed to boil down to two main assertions:

1. The contest involves the creation of new strains of malware, which can serve no constructive purpose.
2. The contest will only serve to help the bad guys learn new techniques in their arms race with AV vendors.

Contest organizers have stated their goal is simply to demonstrate the limitations of AV software, information that AV customers deserve to have. Their position is that the contest explores legitimate areas of security research and that investigation of AV bypass techniques is a worthwhile goal. Organizers have also pointed out that new malware is being created 24×7x365 in the wild, while at the contest’s conclusion any new malware samples created will be securely deleted from the contest systems.

I believe the primary arguments against the contest are specious. In order to engineer the effective detection of computer viruses and malware, one first needs to understand how these things function. Creating your own piece of malware will certainly help someone better understand how malware works. It is not at all clear that the creation of a new virus by a security researcher in a controlled environment has no constructive purpose.

There are some valid criticisms of the contest, however. This contest is not truly representative of malware development in the real world. Today’s malware is programmatically generated and engineered to bypass AV detection. Malware authors are no longer manually crafting and testing their creations. The malware ecosystem has moved on to the use of specialized tools for these purposes, written and sold by more highly skilled groups of miscreants.

Despite what the critics are saying, the bad guys are not going to learn anything new from this contest. The groups that develop malware generation kits have gone far beyond the paradigm of hand-crafted AV bypass that is being explored in the contest.

I do believe there are some positives that may come out of this contest. For one, consumers of AV software will gain valuable new insight into AV bypass resistance in a controlled evaluation, albeit a somewhat contrived one. AV software should see improvements as AV vendors that did not fare well feel customer and market demand to improve their products, or face losing business to their competitors. Last but certainly not least, the security research community will learn more about the capabilities and limitations of ubiquitous AV defenses.

My “Race to Zero” prediction? Embarrassing performance from some of the major AV vendors, especially those that haven’t made smart investments in strong heuristic detection mechanisms. Expect these AV vendors to attempt a rear-guard marketing action telling us why we shouldn’t give any credence to the results, followed by some real improvements in future releases of their products.

For any of you that will be in the Atlanta area, I encourage you to come down to the Outerz0ne 4 security conference this weekend. It’s my first time attending Outerz0ne, but I’m told it has a great small conference atmosphere and plenty of end-of-day revelry. This year’s collection of talks looks to be the strongest yet.

I will be delivering a talk about cross-site scripting worms, looking in depth at the Samy MySpace worm, the Orkut worm, and rsnake’s Diminutive XSS Worm Replication Contest. The talk is being taped by the Outerz0ne organizers and will be available on Google Video some time afterwards.

I hope to see some of ya’ll there!

Hey folks, Ben Feinstein here. This past weekend I had the pleasure of being interviewed for “The Squadcast,” a video podcast from Download Squad. The topic of the day was “Security Starts at Home.” Go check out the video! My thanks go out to Grant Robertson and Christina Warren for extending the invitation!

Daniel Peck and I had a great time presenting our Caffeine Monkey tool at Black Hat USA 2007 and DEFCON 15 in Las Vegas last week.

This year’s Black Hat was the biggest yet, and I think the organizers did a good job at maintaining the high quality we’ve come to expect while expanding the breadth of tracks available. Daniel isn’t back from the desert just yet, but I know we both had a great experience and will try and return next year. We met a whole bunch of talented folks (you know who you are) and saw some impressive talks. Until next year!

The following are the presentations and whitepaper we presented during Black Hat and DEFCON:

• Whitepaper of the Caffeine Monkey tool
• Black Hat slide presentation - Caffeine Monkey
• DEFCON slide presentation - Caffeine Monkey. These were the same presentations, but we’ve made both slide decks available for completeness.

Enjoy!

Yet again, we are hearing calls for the creation of a new Top Level Domain (TLD) using enhanced security and safety as the rationale. We’ve seen pushes for these kinds of new TLDs before. .xxx was proposed as a restricted TLD for voluntary use by adult-oriented web sites. Those registering domains under .xxx would be required to abide by certain contractual terms surrounding customer privacy, child protection, unsolicited commercial email, etc. While this sounds all well and good on the surface, what would be the business case from the perspective of a successfully adult-oriented site? From what I can tell, there are only negatives to an adult site moving under .xxx. For one, it is now a no-brainer to block access to your site (and all the others under .xxx). In addition, by registering under .xxx TLD, you’ve just agreed to a slew of new contractual terms, governing everything from communications with your customers, site access controls, use of meta-tagging, mandated privacy policies, etc. Short of top-down governmental coercion, few if any successful adult-oriented sites would be likely to move under the .xxx TLD.

Conversely, .kids was proposed as a restricted TLD for use by sites hosting family and child-friendly content. The argument seemed to be that .kids would represent a kind of child-safe walled garden on the Internet. No need for those pesky content filters; just let the rug rats loose on .kids and all will be well. The arguments against the creation of .kids tended to focus on free speech concerns and the fear that this TLD could evolve into a kind of segregated Internet which would be legally foisted on minors. A .kids TLD might also create just the kind of target rich environment that child predators would be drawn to. Further discussion of the pros and cons of the .kids proposal are not really of concern here.

Our friends at F-Secure are advocating the creation of a .bank TLD as a way to combat phishing and online financial fraud. Whatever organization is entrusted by ICANN with management of the new TLD would restrict domain registrations to “banks and other reliable financial institutions.” Go read the proposals. Their argument seems to be that the creation and use of a .bank TLD will tend to decrease the level of phishing and online financial fraud.

Putting aside the practical difficulties of determining who and what represents a “registered financial institution,” there are a number of problems with this proposal. Mikko Hyppönen, Chief Research Officer at F-Secure, notes that “Right now, customers have no good way of automatically being able to tell whether or not a bank website belongs to the bank.” While I agree with Mikko on this sad state of affairs, I fail to see how a new .bank TLD would demonstratively improve the situation.

When it comes to phishing, confusion is the key to success. A new TLD will simply add to the confusion. Regardless, the phishers don’t currently see any need to use the same TLDs as the banks anyway. Their phishing URL simply has to look “close enough” for at least one person to be fooled.

For example, an attacker using the Rock Phish kit might use links that look something like:

hxxp://secureaccess.example.com6278928login.7host.hk/login.do
hxxp://secureaccess.example.com.134492.login.7host.hk/login.do
hxxp://secureaccess.example.com%2Elogin.7host.hk/login.do

These kinds of URLS are proven to fool enough people to turn a profit despite the fact they are not using the same TLDs. Creating a new .bank TLD will be confusing to many people, who might fall for URLs such as:

hxxp://secureaccess.example.bank6278928login.7host.hk/login.do
hxxp://secureaccess.example.bank.134492.login.7host.hk/login.do
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do

These would typically be caught by the lastest browsers’ anti-phishing functionality, however many people have not, cannot, or will not upgrade. To defeat these, expect attacks using text in image attachements (imagine the image displaying the password in the latest Storm Worm / Peacomm Trojan runs). An image may display text such as:

Login to www.example.bank now!
… but hyperlink to:
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do

If a .bank TLD is created, I’d predict wide spread phishing attacks using announcements of new .bank sites from the financial institutions. In fact, financial institutions would be adding to the confusion if they announce their move to the .bank TLD via email to their customers. It will be difficult to distinguish the legitimate announcements from the phishing attempts. Other attempts at confusing the user would involve the use of JavaScript or browser exploits that set or obscure status bars and hyperlink mouse-overs to display a .bank TLD.

Besides the potential for increased confusion and social engineering, I have some technical reservations with using registration under a TLD as a basis for trust. From a technical perspective, the domain name (or in this case TLD fragment) of a website really tells you nothing about that domain’s identity or trustworthiness. A domain name really just exists as shorthand for an IP address and is typically resolved through DNS. Putting aside arguments over DNSSEC, DNS is a fundamentally untrustworthy system. Don’t get me wrong here, DNS works great and is incredibly useful, but it simply wasn’t designed with security as a requirement.

DNS lookups are susceptible to a variety of attacks (cache poisoning, MITM, spoofing, etc.), and just like any other TLD, .bank would be just another part of the globally distributed DNS system. From a technical perspective, the results from a .bank address lookup would be no more trustworthy than those from looking up a .com address.

The trust a user places in their online session with the Bank of Example has little to do with the domain registrar that sold Bank of Example their “secureaccess.example.com” domain. It matters little to the user whether Bank of Example choose Network Solutions or Go Daddy as their domain registrar, or whether the site is registered under the .com or .net TLDs. Trust in the site’s “identity” really springs from its possession of a valid signed X.509 server certificate issued to “secureaccess.example.com”, and transitively, from the policies and procedures of the issuing Certificate Authority. Short of validating an X.509 server certificate provided by the site, the site’s domain name is really just an untrustworthy assertion.

One can view the .bank TLD proposal and others like it as attempts to “harden” the domain name registration system by raising the financial and bureaucratic bar to entry and by making contractually explicit what is expected of the party registering a domain. A more fruitful approach might involve hardening the organizational linkage between a site and its purported “identity”: the Certificate Authorities and their policies and procedures. That leads us into a discussion of VeriSign’s new extended validation certificates and IE7’s support for the visual indication of extended validation. And that, folks, is for a future blog post…