I’ve been focused on conducting research into the mobile spyware arena these last few months and the results have been very interesting. As I’m sure you are aware, I released a fully functional piece of Blackberry Spyware called txsBBSpy at the Shmoocon security conference in February 2010 and have done a number of interviews and podcasts on the topic. While my research is interesting, other high profile attacks just this week could really make this type of spyware/trojan a lot more dangerous.

At CanSecWest security conference this week, iPhone, Firefox, Safari, and other mobile operating systems and browsers were proven vulnerable to zero day exploitation. (The Register Article). Many people have expressed to me that txsBBSpy doesn’t actually have an infection vector and that mobile devices are secure from attack. I think the results of Pwn2Own clearly demonstrate otherwise. Mobile devices are just as insecure, if not more so than the standard desktop system. What makes it even more dangerous is that researchers who sell their exploits can get between 10K$ and 115K$ depending on the specifics of the flaw. That’s no longer chump change! Why would any researcher have any incentive at all to disclose the flaw responsibly given the big dollars that can be made by selling to a broker.

The only thing really limiting researchers from selling their flaws on the open market is the threat of incarceration. Jeremy Jethro was sentenced this week to three years probation and 10K$ in fines for selling exploit code to hacker Albert Gonzalez who in turn used the code in hacking companies and stealing 90 million credit card and debit card numbers. Gonzalez paid Jethro 60$K for the exploit while Jethro had no indication that Gonzalez intended to use the exploit code in any illegitimate way. Had this gone to court, the precedent that could have been set here is astonishing. Luckily this case was a plea bargain, otherwise the selling of exploit code would essentially be criminalized and we wouldn’t be sure to what degree this really impacts the researcher. If a researcher were to sell his exploit code to ZDI and then ZDI somehow accidentally leaks the code that is then used in an attack, who is to blame and who pays the fines/jail time? If a researcher sells his code to an independent broker who then resells the code to a criminal, who is left holding the legal bag? We do know this much.. it’s dangerous and potentially illegal to sell exploit code that is then used in a crime regardless of your knowledge of the crime. Everything else is still shades of grey.

What does this mean for mobile based Spyware? It means that those vulnerable phone operating systems and browsers are likely to get exploited with previously unknown vulnerabilities and spyware like mine is likely to be the resulting payload. Welcome to the era of malicious mobile attacks.

I applaud Google for coming forward and letting the world know about how they were attacked and what the attackers were after. Secrecy only helps the offense. Most of the time we only hear about attacks when there is public evidence such as a defaced web page, screen shots sourced from the attacker, or there is a prosecution. Since the vast majority of attackers are quiet and not prosecuted the public admission of attacks is a great public service which will help organizations understand their own risk. Other organization similar in size and sophistication to Google are clearly at risk from similar attackers and attacks.

This widespread attack on US high tech companies signals that 2010 is the year organizations will wake up that there are sophisticated attackers after their intellectual property such as source code and hardware designs. All the same attacks used to steal CC#’s and online passwords for financial theft are being targeted at intellectual property.

Attackers are well organized and have command & control in place so that the discovery of a zero day vulnerability can be used to maximum advantage by rapidly hitting a large number of high value targets.

The only solution to running software with latent vulnerabilities is to stop running software with latent vulnerabilities. Anti-virus and IDS won’t help when it is a zero day vulnerability where there is no pattern to match. Software acceptance needs to include evidence that rigorous security testing was performed.

It is time for organizations to take a hard look at the set of client software they allow on their employees workstations and determine how trustworthy that software is. In most organizations these client systems have unbounded risk and are receiving data from the untrusted internet. If this doesn’t change, attacks similar to what happened to Google are going to effect every organization with something of value.

As of July 1, all personal computers sold in China must be pre-installed with content filtering software called Green Dam. The officially stated goal is to protect children from online pornography, but naturally, the technology will also serve to “protect” viewers from offensive text and images such as politically sensitive content. Subsequent to this announcement, researchers at the University of Michigan have published a report detailing several remotely exploitable vulnerabilities in the Green Dam software. These vulnerabilities include:

• Stack buffer overflow in URL blacklisting code due to a fixed-length buffer, triggered by URLs longer than approximately 2064 characters
• Stack buffer overflow in filter file parsing due to a fixed-length buffer used in a call to fscanf()

In addition, the Michigan team noted that the software fails to encrypt or authenticate the filter auto-update process, and the use of unsafe string processing functions is systemic, meaning that other exploitable vulnerabilities may be lurking just beneath the surface.

Upon learning of these vulnerabilities, the Chinese government ordered Green Dam to fix the security holes immediately. But even with those hastily applied patches, it seems likely that the software is probably riddled with additional flaws. In downplaying the severity of the entire matter, Green Dam implies that their development process probably doesn’t include independent, third-party security assessments. If quick fixes of the most severe issues are sufficient to appease the government, that is probably all they will do.

Ironically, by attempting to “protect” Chinese citizens from online content, the government is doing exactly the opposite by reducing the security posture of those PCs and homogenizing the attack surface. You can just envision all the foreign governments and botnet operators rubbing their hands together with glee as they prepare to fuzz Green Dam for some 0-day exploits. The government wants to be perceived as caring about Internet safety (hence the public insistence on the bug fixes) but in reality they are adding a weak link to the chain.

The Green Dam software is available for free download.

As you probably know by now, the pattern of 1s and 0s on the cover of the 2009 Verizon Data Breach Investigations Report contains a hidden message. I decided to give it a whirl and eventually figured it out. No doubt plenty of people managed to beat me to it, as evidenced by the fact that I didn’t get my solution in early enough to win the cash prize — but so far, I haven’t seen anybody write up a walkthrough, so I thought I’d do one.

If you haven’t taken a crack at it yet and plan to, then stop reading — SPOILERS AHEAD, as they say. Otherwise, I hope that this is helpful to anyone who is interested in learning more about basic cryptography.

I started by copying and pasting the binary digits from the cover of the report into a text file. Then, I converted the bits to ASCII resulting in the following text:

$ cat vz|unsplit|bin -d|split 72
EVNTXIGYIMWSNEHEIEFOTXBSCWYHRQMWGUZABVYCBBFREYFBVEDKEVMFRIFNGFNRBFGVKSFP
NBUFZJGCEEEWAKHPXEBTZJCZOWGTBSQGTMIAYDPYDRIRYETKCJRPYHEPWKUOAEKNVTVZHSMZ
NTTIVIKMMRYSNUIAKBRKQMSTYCGCCRLRRIIREFGYTJUBUXHEYSGLEYRVHIYXDEYZCJKVTOSO
IXJEHOXEVMWJBNZMTKWZEFOFCNBWNCUWMYFIUVBKWNPWTYOEYQTIRRYRCMNVFVLRSBNTPWPA
OCZPEKHLFCEERRVWVUYBVJPUVPOAYMIKQQNSWZGHZKDGYLAEGWPKESGCYZFVJDMEPQKSSLNV
SVPUVVRVYERHDTUTYYMQGEVWRMQSZFNPNRJIGGWAJNNJLKOEQHNETRPUQYDFZWCZKVJEXLMC
KCSIFTCTSUTLDRRMIKQTNINPGRPQQXPTZDPAIOTCEUAZFEWDQLLPZRHXLXQGSLRJTBLZRIRV
ISNZIWLMVYADVOHFEVNAKKGORRXSYGXPUMVGBOMRJLCREFCMRQVXTMIYMJJVHXNBTSZMTJEF
KFGKURFLNHXPKCWLEXMIYLGYNNRWAKSEWTHPKGZKKXGAZELLUTAYCIEKWISHUNDKEKWARGBY
ZFGKEPKQGZZSRIMFLGKARTURAINSNGEEUMEXRVEELZXTISUWVZKOYLTPBHZWEOQWNXNPXPKS
SXJHPANCVFPRYADRLROEWEBQEWHZRGATZDGUCEKLFYHZJNNZIJRGNZRVBOCAUYEZGKPSJXJI
ASMVFTDWFXBIDHQZEYKDRTDRIOPPKJRPISSKMCZJFZTBVBJUGEYANJIGJTDCPTZDEOGUTLZP
EKHTNIHTGGUMVGBOMRJLCREFSWFZOCROHEAU

The first thing I tried was Caesar shifts, which is basically ROT-n for values of n from 1 to 25. So for n=1, A is encoded as B, B is encoded as C, and so on, all the way through Z, which is encoded as A. For n=2, A is encoded as C, B is encoded as D… you get the picture. I won’t print out the results of all the decodes because it would take up too much space, but suffice it to say, nothing interesting came out of it.

Next, I tried frequency analysis, which can be an effective way of deciphering a simple substitution cipher (i.e. a given plaintext character is always encoded as the same ciphertext). A simple substitution cipher reflects the tendency of a written language to use certain letters more than others. For example, in English, the most frequent letter, E, appears roughly 170x more often than the least frequent letter, Z, for a sufficiently large sample size. Here’s the frequency distribution from the Verizon ciphertext:

$ cat vz|unsplit|bin -d|split 1|sort|uniq -c|sort -n
     21 D
     21 Q
     24 O
     25 X
     26 A
     26 H
     27 B
     28 L
     28 U
     29 J
     31 C
     32 M
     33 W
     34 F
     34 S
     36 P
     38 I
     40 N
     40 V
     40 Y
     41 G
     42 Z
     43 T
     44 K
     56 R
     61 E

As you can see, the most frequent character, E, was only three times as prevalent as the least frequent character, D, which meant it was unlikely to be a simple substitution cipher, provided the plaintext was English. The frequency distribution was far too different than what we would expect.

Just for kicks, I tried various transposition ciphers, rearranging the 900 characters into an M-by-N grid, for different values of M and N (M*N=900), and reading down the columns instead of across the rows. Frequency analysis already told us that we shouldn’t expect to see any English text, but I thought some visual patterns might emerge. Wrong again.

Around this point, I saw somebody on Twitter mention that there were clues embedded in the body of the report, so I started skimming through it. At the bottom of page 48 is “yr puvsser vaqrpuvssenoyr” which ROT-13 decodes to “le chiffre indechiffrable.” Here’s where I went briefly astray by using Google Translate instead of just Googling the term. The literal French translation is “indecipherable figure” which made me think that the clue was that the whole thing was a hoax and the front cover was just a bunch of garbage. A friend reminded me that “le chiffre indechiffrable” actually refers to a Vigenère cipher, which would have been painfully obvious if I’d used regular Google search instead of Google Translate (smacks self on head). Logically, the Vigenère would’ve been the next target anyway, as it’s just a simple substitution cipher with a twist.

If you’re not familiar with how a Vigenère cipher works, it basically uses a keyword to cycle through different substitution maps. For example, if you were encoding ZZZZZZ with the keyword FOOBAR it would come out as ENNAZQ — the letter Z is encoded differently depending on how it aligns with the keyword. You can see why frequency analysis isn’t useful here.

My first inclination was to just guess the keyword outright. I thought maybe it was something obvious such as VERIZON, VZ, RISK, DATA, BREACH, VIGENERE, etc. I grabbed Crypt::Vigenere and tried each of the guessed keywords, but none of them worked. I even wrote a quick script to brute force all 2- and 3-letter keywords, again coming up with nothing.

Then I took a different approach — trying to guess what the decoded message might contain and work backwards. I speculated that the first word would be CONGRATULATIONS which corresponds to a potential key of CHANGINEXMDKZRP. This didn’t seem right, but the CHANGIN part of it seemed like too much of a coincidence. So I tried CONGRATS as the plaintext, which corresponded to the keyword CHANGING. I thought it was solved at this point, but decoding the entire ciphertext using CHANGING as the keyword still gave me junk. So then I searched through the PDF for the word CHANGING, and sure enough, on page 46, one of the bullet items says “Changing default credentials is key” (clever, huh). So I decoded with a keyword of CHANGINGDEFAULTCREDENTIALS and it worked. The text decodes to the following message:

$ cat vz|unsplit|bin -d|vigenere -d changingdefaultcredentials|split 72
congratsfirsttocrackgetsrewardgotowwwverizonbusinesscomslashdbirhunttocl
aimforeveryoneelsehighlvlstatsforfinsvcsandretailfollowplssharefinsvcsso
urcesexternalnineteeninternalninepartnertwothreatsmalwareelevenhackingfi
fteendeceitfourmisusesixphysicaltwoerroroneerrorsigcontributorinfifteent
opthreehacktypessqlinjectionsevenmisconfigaclssevendefaultcredstwotophac
kvectoriswebapptentopassetisonlinedatatwentysixandallrecordstopthreedata
typesauthcredelevenpiitenpymntcardeightpymntcardwasninetyeightpctofrecor
dstopuuisunknownconnectionssevendiscoverytakesweekstomonthsretailsources
externaltwentythreeinternalonepartnereightthreatsmalwaretenhackingtwenty
onedeceittwomisusetwophysicalzeroerrorzeroerrorsigcontributorinsixteento
ptwohacktypessqlinjectionsevenstolencredsseventophackvectorisremaccmgtei
ghttopassetisposelevenandoverhalfofrecordstoptwodatatypespaycardtwentyth
reepiininediscoverytakesmostlymonths

Had the message not begun with “CONGRATS”, there are some other techniques for attacking a Vigenère cipher, including trying to deduce the length of the keyword by looking for cyclical patterns in the ciphertext. Luckily, it didn’t come to that because I wanted to watch TV.

I visited the embedded URL which said that somebody had already claimed first prize but that I was still in the top three. I later found out that about ten people, including myself, submitted solutions around the same time before the authors could update the congratulatory message. So I didn’t win any money but it was still a lot of fun (and significantly better that the corny FBI challenge).

With regard to the recent Patch Tuesday fix, there has been an issue fixed regarding NTLM Relaying, that has been around for more than eight years.

In 2000, I wrote an advisory about NTLM relaying (CVE-2000-0834). The problem turned out to be significantly larger than I originally suggested in the advisory. The attack extended to other NTLM-based authentications on other protocols and allowed general-purpose credential theft via a man-in-the-middle attack.

The SMBRelay tool was published in 2001 by Sir Dystic of Cult Of The Dead Cow, and that really took it to the next level. The protocol completely fell apart. It kicked off a number of other analyses of the NTLM protocol that finally resulted in this patch. Eight years after it’s discovery.

At least they got around to it. Thanks!

There is apparently a bit of fear going around information security circles that the next big trend in the disclosure wars is going to be “Partial Disclosure”. In the past, the vulnerability research community has embraced the concepts of “Full Disclosure” and/or “Non-Disclosure”. Once those concepts had been sufficiently played out, the general consensus was to move towards “Responsible Disclosure” whereby the security researcher responsibly discloses the discovered vulnerability to the vendor and works in a cooperative fashion in an effort to minimize the risk to the general user populous. This has worked well in the vast majority of cases that I have had the pleasure of managing the disclosure process.

Partial Disclosure – The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure – The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

By now, you probably know that details of the DNS vulnerability have leaked. Halvar Flake speculated on DailyDave and the momentum built from there, despite the fact that his guess was short on a few key details. I don’t need to rehash the full technical details here; by now, they are easy enough to find with a couple Google searches. When Slashdot picks up the story, it’s hardly a secret any more.

What’s more interesting to me, now that I’ve digested the big secret, is how this whole situation has played out in the security community.

The security community has been polarized for the past two weeks, not so much over the technical details being withheld, but about Dan’s plea that people not speculate about the vulnerability. As many pointed out, the “bad guys” won’t stop trying to figure it out just because the “good guys” keep quiet. To be honest, my own lack of public speculation wasn’t because I agreed with the philosophy; I just wasn’t smart enough to figure out the vulnerability myself.

People implied — or stated outright — that Dan just didn’t want anyone stealing his thunder. Considering the timing of the release and the subsequent BlackHat talk, it’s obvious why such accusations were made. Personally, I think it’s a little of each. I believe the coordinated patch effort was undertaken with the best of intentions, but I also think Dan relished some of the glory and media attention as well. It’s hard to blame him for that; if you were in his shoes, wouldn’t you want some recognition too?

By many accounts, dealing with the DNS vulnerability from the operational side has been an exercise in frustration. Plenty of IT people wanted to patch but couldn’t get approval without being able to justify the operational risk. “Because Dan said so” is apparently not a convincing enough argument. Some wondered why the people who were responsible for creating the problem should be blindly trusted to implement an appropriate fix?

Ultimately, vulnerability disclosure is a minefield. No matter how you choose to disclose, somebody will always disagree.

P.S. If you didn’t figure out the title of the post by now, Nate was one of the unlucky few to draw the same timeslot at BlackHat as Dan Kaminsky.

The security community is cynical. So much so, that most of the chatter that’s taken place over the past 24-36 hours has suggested that Kaminsky’s DNS vulnerability was little more than a publicity stunt and that his BlackHat presentation would be an over-hyped rehash of prior art. Granted, one has to suspend disbelief to even consider that something monumental would be discovered in DNS — that’s the protocol itself — but hell, it’s always nice to give a guy the benefit of the doubt.

Faced with nearly a month of criticism and questioning, and understanding the persuasive power of a technical peer review, Dan decided to expand the inner circle, so to speak. Rich Mogull arranged a phone call with Tom Ptacek and Dino Dai Zovi so that Dan could spill the beans and let them decide for themselves whether it was spin or substance. Turns out there was substance.

Now we sit around and wait until August 6th to cram into a ballroom with a thousand sweaty conference-goers to hear the juicy details. And Dan’s presentations are usually packed to the brim even when he’s not announcing anything.

In the meantime… how about patching those servers?

Rich Mogull’s executive overview of Dan Kaminsky’s latest DNS vulnerability fluffed a few feathers yesterday:

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses.

The typical response I heard was “what do you mean, it can’t be reverse engineered? I’ll just look at the diffs!”

In hindsight, after examining the BIND diffs (yes, I did it too) and discussing with colleagues, all most people saw was UDP source port randomization and a better PRNG for generating the transaction ID, the latter of which would appear to be related to Amit Klein’s cache poisoning attack from about a year ago.

What Rich was really saying is that you can reverse engineer the patch until you’re blue in the face, but that won’t reveal the specifics of the vulnerability.

Dan’s blog post this morning appeared to confirm that interpretation:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.

To translate the fix strategy into a more familiar domain, imagine large chunks of Windows RPC went from Anonymous to Authenticated User only, or even all the way to Admin Only. Or wait, just remember Windows XPSP2 :) This is a sledgehammer, by design. It cuts off attack surface, without necessarily saying why. Astonishingly subtle bugs can be easily hidden, or even rendered irrelevant, by a suitably blunt fix.

Nate McFeters appears to think that Tom Ptacek has figured it out. I’m going to go out on a limb and say that Tom didn’t figure anything out yet but still wanted to write a pithy blog post. I think that if Tom had figured it out, he would have written it down privately and posted the SHA-1 hash, as is the trendy thing to do these days.

Speculation aside, the title of Tom’s blog entry, Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!, does make an important point — Dan didn’t sell the details to ZDI, he used his influence and reputation to coordinate a massive vendor patch effort. That’s an admirable move.

We all know it happens, but it is rarely exposed as clearly as Adam Pennenberg did in his article for Fast Company, The Black Market Code Industry. It turns out that this 0day seller was an HP employee:

According to the consultant who snared Marester, his quarry’s skills appear quite sophisticated. His wares, if they performed as advertised, could help a hacker take down machines running that particular software anywhere in the world. His real name is Steve Rigano; he’s a self-employed network consultant from Grenoble, France, who works full time at HP, where he is listed in the switchboard and maintains an hp.com email address. He told me that he saw nothing wrong with offering tools and techniques that targeted the company providing his paycheck.

A self-taught hacker, Rigano says he discovered the vulnerabilities and coded the exploits on his own time, which he says is none of HP’s business. “I have the right to sell what I want,” he says. He told me he attracted mostly Chinese and Russian buyers, but claimed he never found takers for the HP or SAP “vulns” and exploits. He said he stopped selling black-market code in January but didn’t explain why.

Most security companies I have been acquainted with frown on this type of activity, as I am sure HP has. It’s hard for them to sell security products and services when their employees are selling the very tools the company is purportedly defending against.

[Update 7/7/2008: The information in the Fast Company article is being disputed by Steve Rigano. He has notified us that he has taken legal action against Adam Pennenberg and Fast Company.]