The “Mobius Defense” is a somewhat novel defense model proposed by Pete Herzog, founder of ISECOM and lead author of the Open Source Security Testing Methodology Manual (OSSTMM). Before continuing to read the following post I suggest you take a few minutes and breeze through the slide deck linked here. It’s an easy and interesting read so get to it…

Mr. Herzog suggests in this presentation that the “Defense in Depth” strategy, with regards to network defense, is ineffective and antiquated, and needs to be replaced with a new and updated defense model. His proposed model is called the “Mobius Defense”.

The basic tenet of this defense is one in which each individual asset should be protected as if it were the only asset in the model as opposed to forming lines of defense to secure the entire asset base as a whole. Two important facets are stated in his presentation:

• Network security is a zero sum game in which a single compromise is all that is required to “win”
• The network perimeter is truly nonexistent

If we take the above two statements to be true, then there really are no clearly defined lines of defense in which we can accurately create a defense in depth model and instead we should secure the individual asset by limiting its in and out dataflow, minimizing trust, and implementing a minimal interconnectedness policy across the board. Distilled, the Mobius model creates a network security design that disregards network boundaries and theoretical demarcation lines in favor of “guerilla defense” in which every actor fends for themselves.

So what does this mean for the application security landscape? If what Mr. Herzog presents is reality, then the application layer truly is the last, and best, line of defense (pardon the pun). With the degradation of the network perimeter, thanks in part to the iPhone, Blackberry, Web Browser, and other assorted peripherals and client based designs; there is a new found urgency to secure each individual network touch point to the best extent possible. It’s with this urgency in mind that application security assessments should move upward in the prioritization of security spending. While I don’t suggest that defense in depth should go away and die, I do suggest that we should focus on securing the most common target of attack, the application layer. If the paradigm of the network has changed shouldn’t our defense models change as well?

It was an integer overflow.

I guess it is never too late to fix a bug. Don Hodges used the old video game firmware and a MAME machine to debug and fix a problem which has kept expert Donkey Kong players from ever getting past level 22. If you have seen King of Kong you would know that one of the challenges of getting a high score is getting as many possible points before a software glitch causes the game to end abruptly at level 22. This is because the time is calculated incorrectly and there is not enough time to complete the level.

In his diagnosis, How High Can You Get, Don Hodges determines that the level counter is multiplied by 10 and then has 40 added to it which overflows a single byte (max is 255) value causing the time to be incorrectly calculated. Don then goes on to implement a fix. The article is a good read for low level code and arcade game junkies.

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.

Vaserve, a UK webhosting company says that 100,000 of its customer sites were wiped out in what looks like a zero day attack on HyperVM, a virtualization application they used. The HyperVM was a product of lxlabs.

I checked out the lxlabs product documentation and website and could not find any reference to using a secure development lifecycle. I did find this rather disturbing post to their forum as the first post on a new topic “Security” in April 10, 2009. It was not replied to until yesterday.

http://forum.lxlabs.com/index.php?t=msg&th=11197&start=0&:

Lxadmin/hyperVM has become popular enough that people are SPECIFICALLY targeting these softwares now, and so we are now redoubling our focus on security.

If anybody knows about any vulnerability in hyperVM or lxadmin, please contact lxinfo at lxlabs.com, and we can negotiate a payment if you can demonstrate it clearly.

Of course, after we fix the bug and update the softwares, we will absolutely disclose it publicly too, since we believe in 100% openness, but we need to know about vulnerabilities before it can impact our clients.

Thanks.

This is obviously not a good software security strategy. The owner of the IP is responsible for testing for security flaws. It was obviously too little too late for lxlabs. The industry can learn from this lesson. Don’t wait until your software reaches critical mass and raises the attention of blackhat researchers before you start to think about application security.

The bigger issue and one that Vaserve should be asking itself is why did they place so much trust in software that clearly didn’t have a software security process behind it. Vaserve should have looked for evidence of a 3rd party security review before they accepted the risk of an application that has the potential to bring down their whole company.

Hosting and cloud provider customers need to ask themselves how they vet the providers they use. Have their providers demanded evidence of 3rd party security reviews of the products in their infrastructure stack? Until customers start requiring this evidence these disasters will continue. Evidence of a security review has to start with the end user customer and work its way up the supply chain to hosting/cloud provider and then to the software vendor.

It has been announced that President Obama will pick his new cyber czar tomorrow. This will likely be a position reporting to the National Security Advisor, similar to Richard Clarke’s position under President Clinton.

This position will be critical for organizing the government’s fragmented information security efforts, both for the government sector and the country’s infrastructure, which is largely privately owned. Many of the security tasks that must take place to improve our nation’s security posture are well known. They are employed by forward thinking and risk averse sectors such as the financial industry. The challenge is rolling out those security tasks to a varied and diverse infrastructure operated by the US government and the critical sectors such as energy and telecom. Some of these tasks are deploying hardened OSes, modern patch management and vetting applications as they enter an organization before they are deployed.

Some of the challenges facing the new cyber czar include dealing with technology that is increasingly developed in India and China and attacks that frequently are sourced from overseas. There is a need to reach out internationally as the technology and infrastructure of the Internet is global. Any new regulations imposed need to be thought of as global in nature. The US cyber czar must take a lead in forging new international relationships to deal with cybercrime and the threat of cyberterrorism which may emanate from the same countries that are providing the US with the technology we use to run our Internet. Knowing who is friend or foe in the cyberworld gets more challenging every day in our increasingly globalized software and services economy. How do you work with internationally owned companies to get them to do the right thing to prevent cyberattacks from terrorists or nation states when the expense will hit their bottom line?

I look forward to a cyber czar that can take a global view to protect our infrastructure and a risk management view to understand the cost tradeoffs of protective technology and processes.

In lieu of actual technical content, and inspired by Jeremiah’s blog post, 8 reasons why website vulnerabilities are not fixed, I started thinking about all the different manifestations of reason #8, “No one at the organization knows about, understands, or respects the issue.”

I polled the Veracode research group, most of whom have been security consultants at one time or another, and ask them about the best responses they’ve heard from customers that reflect a lack of understanding or respect for a pen test finding. These often start with the proclamation, “that’s impossible…” followed by one of the statements below.

Developer doesn’t understand how the web works

• “Users can’t change the value of a dropdown”
• “That option is greyed out”
• “We don’t even link to that page”

Developer doesn’t understand the difference between network and application security

• “That application is behind 3 firewalls!”
• “We’re using SSL”
• “That system isn’t even exposed to the outside”

Developer doesn’t understand a vulnerability class

• “That’s just an error message” (usually related to SQL Injection)
• “You can’t even fit a valid SQL statement in 10 characters”

Developer doubts attacker motivation

• “You are using specialized tools; our users don’t use those”
• “Why would anyone put a string that long into that field?”
• “It’s just an internal application” (in an enterprise with 80k employees and a flat network)
• “This application has a small user community; we know who is authenticated to it” (huh?)
• “You have been doing this a long time, nobody else would be able to find that in a reasonable time frame!”

Developer cites incorrect or inadequate architectural mitigations

• “You can’t execute code from the stack, it is read-only on all Intel processors”
• “Our WAF protects against XSS attacks” (well, clearly it didn’t protect against the one I’m showing you)

Developer cites questionable tradeoffs

• “Calculating a hash value will be far too expensive” (meanwhile, they’re issuing dozens of Ajax requests every time a user click a link)

So that’s what we came up with in about half an hour, and I know there are dozens that we’ve forgotten about in our old age (you know, over age 30). This drives home the point that education is one of the largest gaps in most SDLCs. How can you expect your developers to write secure code when you don’t teach them this stuff? You can only treat the symptoms for so long; eventually you have to attack the root cause.

Submit your best “that’s impossible” lines in the comments! I know there are some good ones out there.

If you visit this article on the New York Times website, you’ll get immediately redirected to the website containing the original content of the article. [UPDATE: they fixed it, so it won't redirect you anymore]

Why does this happen, you ask? Apparently the New York Times ingests various third-party news feeds, wraps the article in the New York Times template, and serves it up. Here’s an example of an IDG article that was served up in similar fashion — note the word /external in the URL. When importing the article, the New York Times allows the external feed to include HTML markup. Going back to the McAfee article from ReadWriteWeb, the text includes a little tutorial on how HTML Injection works:

<p><span class="bold">How To: HTML Injection</span></p></p><p>
<ol>
<li>Go to the McAfee <a href="http://www.mcafeerebates.com/promocenter/mcafee/">Rebate Center</a></li>
<li>Click on Get Rebate</li>
<li>Include this line of code into the 'Date Purchased' field: <br/>
  <span class="italic">
    "<meta  HTTP-EQUIV="refresh" content="0; URL=http://readwriteweb.com">
  </span></li>
<li>Click on continue</li>
</ol>
</p><p>This is a very basic redirect that will take you to ReadWriteWeb.</p><p>
</p><p>And voila - you've just effected your first HTML injection.</p>

The New York Times shoves this content right down the pipe to your browser, and the META tag triggers a redirect to http://readwriteweb.com. Harmless, but confusing if you’re the reader.

What this behavior indicates is that any third-party news feed used by the New York Times can probably inject arbitrary HTML content, such as XSS attacks, into nytimes.com. Oops!

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

If you’re at RSA this week, be sure to check out this panel discussion, featuring Veracode’s Chris Wysopal along with Jerry Archer, Mary Ann Davidson, and Brian Chess. Abstract as follows:

The growth of Web 2.0 has highlighted two significant trends in application security. First, as the network has hardened, attacks against applications have dramatically increased. Second, an explosion in use of dynamic code has resulted in serious security problems. This panel will discuss these problems and provide software assurance through use of source code versus binary code analysis.

The session is AND-105 and it’s happening on Tuesday, April 21 at 1:30 PM in Purple 310.

The Ontario Lottery and Gaming Corp. is in a bit of hot water after refusing to pay a $42.9 million jackpot:

According to the statement, Kusznirewicz was playing an OLG slot machine called Buccaneer at Georgian Downs in Innisfil, Ont., on Dec. 8 when it showed he had won $42.9 million.

When the machine’s winning lights and sounds were activated, an OLG floor attendant initially told Kusznirewicz to go to the “winners circle” to claim his prize, according to the statement. But other OLG employees immediately arrived and told him that the corporation would not be paying, because there had been a “machine malfunction.”

They offered him a free dinner for four at the casino’s buffet.

In a press release, OLG described the malfunction as follows:

“The single Buccaneer-themed slot machine in question is a two cent per play machine with a base game reward of $300 and an absolute maximum payout of $9,025,” the release states.

“The $42 million figure is not a possible award given this machine’s configuration and pay table settings.”

Of course the lawsuit will probably be thrown out, or OLG will settle with the guy for a lesser amount. But from a technical perspective, it’s amusing to think about what happened to cause this scenario. You can imagine the slot machine software looking something like this:

void do_spin() {
  spin_reels();
  if (winning_combination) {
    unsigned int winnings = calculate_payout_in_cents();
    send_to_display("You've won $%u!n", winnings/100);
    add_to_balance(winnings/100);
  }
}

int calculate_payout_in_cents() {
  int rv;
  if (rv = lookup_payout_amount())
    return rv;
  else
    return -1;
}

For some reason, something caused lookup_payout_amount() to return NULL, which meant calculate_payout_in_cents() returned -1, signifying an error. Then, in addition to implicitly casting the signed result to an unsigned type, do_spin() fails to check for the error condition! It assumes success and announces the payout via the slot machine’s display. In this case, the -1, represented as 0xFFFFFFFF in two’s complement, gets interpreted as an unsigned number, 4294967295, due to the implicit cast, and the display prints “You’ve won $42949672!”

Today’s lesson: remember to check your error conditions!