On Chains, Meshes, and Defense in Depth

Thomas Ptacek | March 29th, 2007 | Filed Under: Defenses, Uncategorized

Interesting discussion taking place over Nate’s most recent post, clarifying the difference between “mesh” and “chain” design.

The confusion here seems to stem from the similarity between “mesh vs. chain” to “defense in depth”. I’ll argue that the concepts are somewhat orthogonal.

Imagine any one security feature takes 1 person-week to implement, and in your release cycle you have 12 person-weeks to spend on implementing security features. The sum of these features is your security design. Imagine an attacker has to spend a person-week to beat any one of these features.

Here’s a “chain” design:

Obviously, if any one of these checks fails, you’re toast.

The classic example of chain designs is antivirus. A release ships with N “signatures”, each tuned to a specific type of virus (at varying levels of genericity). If you can take a virus and change it just enough to beat the signature that’s tuned for it (like Consumer Reports did), the system fails catastrophically.

This system sucks; you spent 12 person-weeks, and an attacker only has to spend one. Don’t design chain systems.

Here’s a “defense in depth” design:

Again, you spent 12 person-weeks. Clearly, now an attacker has to spend three person-weeks to win.

A good example here is network and systems security: firewall, IPS, and patching. A missed firewall rule (one chink of the first chain), a rusty IPS signature (a chink of the second), and an unpatched network service (the third), and you’ve lost.

This system also sucks (12 defender weeks to 3 attacker weeks), but it is sometimes the best we can realistically do —- although far less often than we assume.

Here’s a “mesh” design:

Every check depends on every other check. It takes 12 attacker-weeks to beat this design. This is the ideal we’re aiming for when we design security systems. Yeah, this isn’t really a full mesh, it’s a biconnected graph; shut up.

I’ve worked a little with Nate on systems that are transitioning from “chained” designs to “mesh” designs, and I’ll point out that the idea works outside of cryptography (though perhaps not outside of software development).

6 Comments

Lindstrom on SSL

Dave G. | March 27th, 2007 | Filed Under: Industry Punditry

Pete Lindstrom muses about whether SSL has outlived its usefulness:

You know, at some point we should really re-evaluate the use of SSL in our Web architectures. Let’s face it, it hasn’t really done much for us:

1) Users read way too much into its functional value.

That’s true. But that is mostly because websites overhyped them. Also, I don’t think that user expectations is a good reason to get rid of one of the only security technologies that actually works to make transactions more secure on the Internet.

2) The threat model for sensitive Web data has never been one of sniffing traffic. There are still way too many accessible websites for this to be the case.

It is true that the primary means of sensitive web data theft has been through active attacks on websites rather than sniffing. Isn’t this where you thank SSL? Moving away from SSL just increases the odds that you are going to add sniffing back into the threat model.

3) If you are going to compromise some device, you might as well compromised the host and not some intermediate device.

Unless, of course, the intermediate device is less protected. Also, why should we trust every hop in between two hosts on the internet (any more than we have to).

4) The bad guys are now leveraging SSL more and more to shield their activities from good guy sniffers.

It is true that SSL can muck with IDSes. But ‘good guy sniffers’ are just one tool in the arsenal. SSL is another tool in that arsenal. In the rock-paper-scissors of security protections, I’d bet on SSL over IDS.

Quick reader poll: What are enterprises doing to detect attacks over SSL?

26 Comments

ChiSec 9 is NEXT THURSDAY (April 5)

Thomas Ptacek | March 26th, 2007 | Filed Under: Gatherings, Uncategorized

Two announcements:

First, ChiSec 9 is Thursday, April 5. Same time, same place. There is no need to RSVP; just show up. If it’s a typical meetup, expect 20-30 people by the middle of the evening.

Second, the reason you didn’t know this was that I, uh, blew up the ChiSec mailing list. On the plus side: now I can’t spam you with ChiSec announcements. On the minus, if you wanted chisec announcements, now you have to resubscribe; just send an empty message to chisec-subscribe@sockpuppet.org.

1 Comment

Disabled Comments For The Evening

Thomas Ptacek | March 25th, 2007 | Filed Under: Uncategorized

We’re in the middle of a server migration and don’t want to lose data.

Update 8:30 CST: Things seem to be reasonable now, turning comments back on!

3 Comments

23 Reasons Why Windows Can’t Possibly Be More Secure Than Linux, From Slashdot, Asshole.

Thomas Ptacek | March 24th, 2007 | Filed Under: Industry Punditry, Slashdot Rounddown, Uncategorized

From the +4 comments. I may have skipped 4 of them.

• Because patches don’t make operating system more secure, you idiot: “Wait…I’m supposed to think that fewer patches makes for a safer operating system?”

• Because Microsoft can’t be trusted to patch anything, so nobody knows how many vulnerabilities Windows has, retard: “Retarded. It relies on the trust that OS vendors always patch all holes they’re alerted to, AND announces every one they’ve patched or been alerted to. Trust like that is the beginnings of security problems in the first place.”

• And, “Windows had the most trivial and easy to fix vulnerabilities that they have fixed with a few number of patches, from possible an unknown number of undiscovered vulnerabilities”. Jerk.

• Also, “I could stop patching Windows forever and it will be the bestest Operating System EV-ER! Like OMGWTFBBQ!” ROTFLMAO LULZ!

• Also everything in Windows runs in the kernel because I like, totally read that somewhere, jackass: “Redhat particularly, but also Mac, bundle more software. This means you have many more lower priority vulnerabilities because you have more LOC in userspace.”

• Plus come on, Symantec is in Microsoft’s pocket, fool: “Symantec (who makes all of their profit from selling security products for Windows) says Windows is the way to go.”

• And Microsoft is evil! “Further, Linux folks release a patch when they see a problem, M$ releases a patch when forced to by someone who’s published exploit code.”

• Symantec shill! “This is a Symantec marketing campaign disguised as a press release disguised as a research report.”

• Also, Linux does more, and that has to count for something you asshole. “Windows XP Pro’s standard install media doesn’t include 2 RDBMS packages…”

• You’re a criminal. “Bot herders has named Windows as the most reliable operating system for hosting botnets and spam machines.”

• Patch time doesn’t mean anything, bitch: “Maybe OS X’s average patch time is higher because the vulnerabilities they had were less important to patch?”

• You fail. The only way to measure security is to see if people actually break in: “. It seems like a truer test would be to set up a machine (or rather, a statisically significant bunch of machines) and measure the average time to system compromise.”

• Computers are all insecure. That’s why I use Unix for security, moron. “As always, the most secure computer is the one that is turned off, and unplugged from the network. No security model is perfect, but I’d take any *nix for a web facing server any day.”

• What about 1999?!?! “This only covers the last 6 months. Why only 6 months? Surely a more representative sample would be years. In this case, MS doesn’t look so good. Didn’t BSD have it’s 2nd bug in a decade recently?”

• Doublespeak. “Windows is the most secure operating system. Windows has ALWAYS been the most secure operating system.”

• How could you not know that Symantec is a Microsoft puppet? “Symantec has invested millions to get in bed with Microsoft and gain insider information into the workings of the OS.”

• Didn’t you see that Windows mbuf bug? “A lot of the security fixes seen in OS X are related to applications, things like “a maliciously crafted quicktime movie could lead to elevated privleges”. This is a whole world different than “a buffer overflow in the TCP stack allows remote code execution”.”

• You can’t even install Windows securely, traitor: “My usual response to that is to challenge the speaker to do a base install of Windows and a base install of Linux or MacOS with a machine plugged into the raw internet. Then measure how many times each OS has been pwned before it’s done installing.”

• At least Linux boxes all auto-update for security patches: “Microsoft didn’t allow me to download the SP2 images from my Linux box either. They didn’t like my web browser.”

• My hand-rolled Gentoo distribution doesn’t even run statd! “Not every OS opens up all sorts of services by default, you know. A decent Linux workstation will have sshd, if anything.”

• My cat smells like cat food! “If we assume that the vast majority of people who find security holes do the right thing and notify the vendor, then we can conclude that the vast majority of security holes should not be exploited prior to it being patched. From this, we can conclude from the relatively high zero-day-flaws-to-patch-count ratio that the vast majority of known Windows security holes probably remain unpatched, thus making the above numbers dramatically understated. Just a hunch.”

• Linux would win if your mom would just install her fucking compiler: “Oh dont forget Visual studio 2005 and all it’s plugins as redhat out of the box has a full development kit installed.”

• I blame America: “Well… I think you should talk to that norwegian bank wich was down for a week (11,000 PC’s and 1,000+ servers) a couple weeks ago about how secure Windows is… so no, not really “All quiet”.”

6 Comments

DRM Secrets Revealed At Nate Lawson’s Blog

Thomas Ptacek | March 24th, 2007 | Filed Under: Uncategorized

Nate Lawson (blog rated: M for Mandatory) continues his series on software protection —- DRM, copy protection, and client security.

Yesterday he gave a capsule summary of “Media Binding”, the techniques used to make sure content delivered on a plastic disk is always read off that same plastic disk using a real plastic disk reader. He breaks this down into “verification” (ie, using timing quirks to detect emulated or modified readers), “encoding” (ie, using nonstandard plastic disk formats that off-the-shelf readers can’t handle), and “attack” (ie, injecting metadata into the format the blows up off-the-shelf reader software).

Today he’s moved on to “Protection Code”. The challenge with writing code that tries to protect itself is that almost any intuitive code will devolve to a few critical “if” statements:

  if(everything-ok)

     go-on

  else

     a-splode

The problem with “critical if statements” is that an attacker can alter them with a single byte, for instance by changing a JZ opcode to a JNZ. It is one of the really satisfying things about software cracking, which many people learn in high school, to locate the one or two bytes in a whole program image that you need to change to totally negate a protection scheme.

Nate outlines two strategies for defenders here:

• Obfuscation: change the program image so that it implements the same core logic using an expanded, permuted, convoluted equivalent sequence of instructions. You have two closely related aims: make the logic extremely expensive to unravel, and defeat any off-the-shelf tools (or even algorithms) the attacker might be relying on.

• Encryption: completely conceal program logic (or, better yet, the data the program relies on —- ie, the underlying assets) using an encryption algorithm.

Other blogs have covered attacks on IDA Pro. Nate mentions a few more techniques. I’ll add: the 80% solution here is to defeat cross-referencing, the disassembler feature that tells us which functions are used by which other functions. Even without symbols, a list of functions and their cross references is an strong foothold; take that away and now I have to actually read all those functions. You can beat IDA cross referencing without modifying your compiler output.

Nate’s encryption stuff is really cool. The problem with encrypting code or data is, you gotta store the key somewhere. Any place you can get the key, the attacker can get it, too. The attacker doesn’t even need to read code; she just scans memory for randomized key-sized blocks.

What you do here is called white-box encryption. The idea is straightforward. Instead of taking a standard AES implementation and feeding it your data and a key, you embed the key directly into the AES code. In the process, you introduce a huge amount of noise, abetted by a custom encoding scheme.

Your AES code used to look like this:

 plaintext = aes(ciphertext, key)

But now it looks like this:

 encoded-plaintext = aes+key+noise(encoded-ciphertext)

Think of the embedding of the key into the algorithm the same way you would a SecurID token, which is itself an AES key and implementation embedded in a piece of hardware. That’s called “specializing” the AES implementation on the key.

White-box schemes don’t just embed the key; they do so in a way that makes the resulting algorithm hard to analyze, essentially by injecting key-dependent noise (bijections —- random lookup tables) into the AES rounds. This makes the resulting code bigger, much slower, and much, much harder to analyze; ostensibly, way outside the boundaries of what the XBox hackers or DeCSS people are going to attempt.

The scary thing about Nate is that he has all the details behind all of this, and I suggest we start poking him to fill us in.

4 Comments

It’s The Nate Lawson Show!

Thomas Ptacek | March 22nd, 2007 | Filed Under: Uncategorized

Got a newsreader? Stop what you’re doing right now and subscribe immediately to Nate Lawson’s new blog. As with Halvar, the more you click on Nate, the more he’ll write. And I want him to write more, so please get clicking.

If you’re not familiar with Nate, here’s a rundown:

• Busted root with Sun binmail, for Bugtraq, in 1994. I graduated from high school in 1994 (my first finding wasn’t until 1995!).

• Designed and implemented the first rev of RealSecure, the first commercial network IDS.

• Built the first rev of Decru’s kernel SAN protocol implementation at SAN-encryptor Decru (now NetApp).

• At Paul Kocher’s Cryptography Research, co-designed and implemented the SPDC DRM scheme used by Blu Ray’s BD+ protection. AACS is busted; BD+ still stands.

You may also remember Nate from such previous blog posts as, “RSA Signature Forgery Explained”. Right now, he’s plotting out a series on software protection (from anti-rev-eng through DRM schemes), using Commodore 64 game copy protection as his teaching aid. You have no business not reading every one of these posts and I forbid you from commenting here until you do.

3 Comments

Matasano: We are still hiring!

Dave G. | March 21st, 2007 | Filed Under: Matasano

No Comments

George Ou Goes All-In On Dave Maynor’s WiFi Findings

Thomas Ptacek | March 20th, 2007 | Filed Under: Apple, Disclosure, Uncategorized

In a ZDNet post today on Dave Maynor’s wireless finding from last year’s Black Hat, George writes about the “length Apple would go to and try to destroy the reputation of two security researchers.” Apple PR Director Lynn Fox, “the puppetmaster from start to finish”, demanded a “public confession” from Dave Maynor —- and George has her in email to Dave’s employer at the time, SecureWorks:

Please confirm that you’ve received this and will post it without text changes on your blog and front and center on SecureWorks’ news & events page tonight. The placement of this post should be as prominent as the initial announcement of the exploit demo at Black Hat.

The money quote from what Maynor, Fox, SecureWorks and Apple apparently “agreed” on is this:

The MacBook is not inherently vulnerable to the attack, and I [Maynor] never said that it was.

George tracked Lynn Fox down. “Fox refused to speak on the record. But the bottom line is that Lynn Fox played […] the Mac press/blogosphere like a violin…”. Apple infamously went on to publish an out-of-band patch for their wireless drivers, “presumably for vulnerabilities that didn’t actually exist”.

The “smoking gun” here is the email message from Lynn Fox. Running in the manner of a news story on ZDNet.com, private email between SecureWorks and Apple does seem like a bombshell. But this mail doesn’t actually say anything.

George has now repeatedly gone on record arguing Apple orchestrated an unethical attack on innocent researchers. I happen to be on record agreeing with those points. But the sustaining confusion regarding last year’s Black Hat debacle lingers around Apple and SecureWorks refusal to document precisely what happened. That hasn’t changed:

• Apple hasn’t confirmed that Maynor and Ellch provided them with documentation of the vulnerability they found.

• Apple hasn’t published anything that can be directly traced back to a finding by Maynor and Ellch.

• Maynor and Ellch have yet to verifiably repeat the demonstration they taped for Black Hat in 2006.

What we have confirmation of today is that Apple pressured SecureWorks to suppress Maynor’s claims. But that doesn’t actually mean anything. The pressure Apple brought to bear is exactly what you’d expect —- demand, in fact —- of the PR group at a public company that believed it was being damaged by slander.

There remain several crucial unanswered questions about this episode:

• Precisely what information did SecureWorks provide to Apple in order to document their finding, and when was it provided? Apple could simply be lying. Apple’s internal communication could be awful, disconnecting Security from PR. Maynor and Ellch could have found something, but communicated it so poorly that nobody at Apple could verify it.

• Why did Maynor agree to deny that he had a finding in the native Apple drivers, when he’s clearly documenting having those findings today? The crux of Ou’s article today is that Apple slandered Maynor and Ellch by orchestrating a backlash based on a phony “admission” —- that the Black Hat talk relied on third-party drivers —- that SecureWorks had been saying all along. But that obviously isn’t what Maynor actually believed.

• If Dave Maynor and John Ellch didn’t find the driver vulnerabilities Apple patched, who did? Ou states outright that these are Maynor and Ellch’s findings, uncredited by Apple. But that’s not the only possible explanation. Take Maynor’s own talk at its word —- like I do —- and there are a myriad of vulnerabilities in driver code; findings in Apple’s (relatively complex) 802.11 drivers were thus inevitable.

• Why hasn’t the 2006 presentation been repeated and verified by experts? At every step of the way since Black Hat 2006, new disclosures about Maynor and Ellch’s presentation have left more questions than answers. For example, the most recent authoritative disclosure, Maynor’s “once and for all” presentation at Black Hat, crashed his target instead of taking control over it. Sometimes that’s a relevant distinction, and sometimes it isn’t.

The most damning evidence against Apple uncovered so far is the patch, which appears to corroborate Dave and John, resisting Dave’s scripts only many weeks after his Black Hat talk. I believe Dave, but as a professional, I have to acknowledge that other people could have found those problems as well, in the window of time between Dave’s talk and the patch. After Black Hat, HD Moore wrote a trivial Ruby 802.11 fuzzer and crashed his PPC Mac drivers (with a different vulnerability) in a manner of minutes.

What bugs me most here is this: if Apple acted on Maynor’s advisory by patching flaws but slandering the researchers, they’ve acted disgracefully. But if Apple acted on their own internal research, and, in the middle of a PR maelstrom over wireless security flaws managed to expedite important patches anyways, they acted nobly —- far exceeding the standards set by the most responsive vendors today.

So, which is it, George? I’m asking point-blank: do you have further evidence to suggest that Lynn Fox should have known she was acting dishonestly when she coerced SecureWorks into posting a release so that she could have Apple pundits attack it? Or could a reasonable person instead conclude that Fox was acting to minimize the damage from a false security announcement?

You’ve directly accused Apple of unethical behavior. You might be right (it’s easy to see the case we’ve made about this). But making this accusation ups the stakes. I call. Show your cards.

67 Comments

Symantec Says: USA is the Malwariest!

Dave G. | March 20th, 2007 | Filed Under: Slashdot Rounddown

Overcoming stereotypes of American laziness, Symantec’s research has shown that our malware authors are more productive than any other country! From Preston Gralla @ ComputerWorld:

The latest Internet Security Threat Report released by Symantec says that the highest percentage of malware originates in the U.S., with some 31% coming from U.S. networks. China is a distant second, with 10%, and Germany was third with 7%.

I am really interested in seeing how these stats will change over time

• Will we see other countries grow?
• Will we see Malware Outsourcing?
• What does this really say about America?

Finally, have they collected these stats before? Anything we can compare against?

5 Comments