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.]

DWR 2.0.5 addresses an XSS vulnerability that is likely to be exploitable in most 2.0.4 installations. If your web application uses DWR’s Ajax implementation, download and install this update now!

As an aside, I’ve been a fan of DWR for a while now, not only because of its ease of integration but also because it was the first Ajax framework to offer built-in CSRF protection. You could tell that Joe Walker was taking security seriously. For this particular vulnerability, I e-mailed him on a Saturday night, and within 12 hours, he had confirmed the problem, patched the code, and built a 2.0.5 release candidate. Granted, it was a tiny code change, but I’ve still never seen a response that fast. Less than a week later, the official 2.0.5 release was tested and available for download.

That’s it for now, but I’ll be referencing this example again when I get around to writing Part 2 of my Minimizing the Attack Surface post.

Yesterday, Dave Lewis over at LiquidMatrix Security Digest cried foul at Core Security for releasing too much detail about a recent DoS vulnerability they had discovered. His specific gripe was that they provided an IDA Pro excerpt that showed where the vulnerability was triggered. The excerpt is short, so I’ll even copy/paste it here:

.text:00405C1B mov  esi, [ebp+dwLen]  ; Our value from packet
...
.text:00405C20 push edi
.text:00405C21 test esi, esi          ; Check value != 0
...
.text:00405C31 push esi               ; Alloc with our length
.text:00405C32 mov  [ebp+var_4], 0
.text:00405C39 call operator new(uint); Big values return NULL
.text:00405C3E mov  ecx, esi          ; Memcpy with our length
.text:00405C40 mov  esi, [ebp+pDestionationAddr]
.text:00405C43 mov  [ebx+4], eax      ; new result is used as dest
.text:00405C46 mov  edi, eax          ; address without checks.
.text:00405C48 mov  eax, ecx
.text:00405C4A add  esp, 4
.text:00405C4D shr  ecx, 2
.text:00405C50 rep  movsd             ; AV due to invalid
.text:00405C52 mov  ecx, eax          ; destination pointer.
.text:00405C54 and  ecx, 3

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!