-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
>going to be a public, trivially-reproduceable break
>in a security-critical piece of infrastructure.
>Even more specifically, it’s going to be one of
>three things:
How about "a week before this post"? See http://eprint.iacr.org/2008/058.
Why not? It seems to match your criteria perfectly, it's an RF lock, based on fielded hardware, and attacks the modulation (or at least a side-channel). The fact that it recovers the manufacturer key makes it particularly scary.
(Shouldn't you be pleased that your prediction came true? :-).
Non-disclosure FTW.
My criteria are pretty specific:
* The door locks on F-500 companies
* Tolling or mass transit
* Metering
One of the three falls in the next 12 months, in a big way. Let's see if it happens. =)
* not be fixable with a patch to the language kernel
* require auditing of actual script code
* be easy to accidentally create
* not be domain-specific (ie, SQL)
Obviously, we've been finding serious PHP bugs that don't qualify here for years.
I'm also going to exempt bindings, Chris: bugs in bindings are really C code bugs. To my knowledge, there's no external SWIG-style dep in Python, Ruby, or Perl that everyone uses. More importantly, most binding bugs can be fixed with patches. The game-over bug requires audits. Ouch!
DPA attacks (unless based on RF emissions) require physical access to the device. So if someone, say a valet, has access to your keys, they can clone them. That is valid, but unsurprising.
The more interesting one is the DPA attack against the receiver. Apparently they retrieved a manufacturer global key from this. Again, the DPA attack is nice but incremental, but the fact that Keyloq uses a global mfgr key is a huge design error.
Didn't 2007 seem worse overall in security? Full disclosure died. Supply and demand might get interesting in OSS security in 2008.
Formated and reads perfect in Lynx browser.
2008 year of OSS desktop migration?
Love you blog, good stuff.
Again, this is an area where the security responds to the threat. Since transponder cloning /has/ been a financial concern in the automative world, the technology has led vs. corporate security where the threats are more nebulous and hypothetical (and anyway, door cards are a thin layer of security-- and most facility security managers probably realize this). Of course, cloning isn't the only threat, etc. etc. But again, it's hard to imagine that building security is going to really lead in this area.
That said, I agree with your assessment that more damage will be self inflicted than externally inflicted. In fact, if you take note of how many attacks came from disgruntled employees or contractors, the number is damned close to zero (no matter what the CIA says).
Your perl prediction already came true in 2007. My colleagues Will Drewry and Tavis Ormandy found a heap overflow in perl's regex parser:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=C...
The general concept of nailing a supposedly buffer-overflow-proof server-side environment goes back further. For example, here's a bug I enjoyed in Sun's JDK JPEG parser, found in 2006; disclosed in 2007:
http://scary.beasts.org/security/CESA-2006-004....
Cheers
Chris
>
>* The door locks on F-500 companies
Josh Perrymon's RFID SQL injection?
>* Tolling or mass transit
The various attacks on the Dutch Transit Mifares?
Jonathan Westhues at the California Capitol
http://www.youtube.com/watch?v=4jpRFgDPWVA
Chris Paget shows a hand-held version at RSA
http://www.youtube.com/watch?v=fDimlEdeGjM
Were you unaware of these demonstrations, or do they not qualify?
If they don't qualify, is it that you're looking to see widespread "adoption" of the attack by criminals or something else?
Love the statement on NAC. It dead set has the be the most overhyped / under-delivered so called *security* technology of the decade. Been reading posts everywhere saying that people are simply getting nailed anyway.
Check this one out http://www.computerworld.com.au/index.php?id=14...
Keep it up lads, big fan.
You'll probably claim that this is just a simple HTTP header injection - "already been done". Today and in the past, most responses to typical URL redirection and/or HRS vulnerabilities are "we use SSL so we're not vulnerable". File download injections will popularize HTTP header injections so that they are looked for with the same fervor as XSS, SQLi, and CSRF.
On the surface, it looks trivial. But when you dig deeper, I think you'll come to the conclusion that this is a lot nastier than it appears at first.