Nate Lawson and Thomas Ptacek: Predictions: 2008
Thomas Ptacek | February 11th, 2008 | Filed Under: Industry Punditry
We’re more than a month delayed on this post, and it’s mostly my fault, but to compensate:
You’re not reading this post alongside every other lame predictions post, and
Our predictions are good until February of ‘09.
I note with satisfaction that the TSA has made my ‘07 prediction of laptop searches come true, albeit belatedly.
And so, on to Nate and my 2008 (or, “trailing twelve months from February 2009”) predictions!
Nate: Predicted! Hardware hacks go mainstream
Exciting developments are bringing hardware hacking to the security community. Cheap FPGAs, free JTAG libraries, tutorials, Xbox timing attacks, and open information about silicon all mean the era of software-only protection is over. The Trusted Computing TPM spec says “… to spoof the modifier to the TPM requires more than just a simple hardware attack but would require expertise and possibly special hardware.” That expertise and hardware will see widespread use in 2008.
Thomas: All that reversing work has to go somewhere
A dirty secret: most embedded systems are much less complicated than a PC running Windows. No embedded system gets the attention the Windows X86 runtime does. And when your code runs directly alongside the system scheduler and memory manager, there are entire new classes of vulnerabilities that need to be tested for; for instance, preemption and reentrancy. This is a long-winded way of saying, of course I agree. We’re long past “peak oil” for Windows vulnerabilities; hell, Aitel predicted that two years ago. It’s long past time for the research community to start extracting from the tar sands of peripherals and hardware. I’ll even extend your prediction: the iPhone doesn’t count.
Thomas: Predicted! A hardware hack my mom will understand
Let’s be specific: within the next 12 months of this post, there is 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:
a published break in one of the RF door lock or time card systems that get employees in the doors at multiple Fortune-100 companies,
a published break in a toll or billing system, like a mass transit card, mass-market affiliation card, or open lane tolling system (denial of service counts!), or
a published break in a deployed advanced metering infrastructure system for a common home utility.
The qualifying vulnerability will be based on fielded hardware (or the protocols they speak, such as RF modulation schemes). It will not be based on some Internet-exposed controls software hosted on an HP box in a data center rack.
Nate: Real-world destruction by hacking still only happens in the movies
Despite all the scare about SCADA, we’ll still avoid any major catastrophe in 2008. Like network security, actual damages end up being kept to a manageable level as protection advances. Sometimes hackers are ahead, sometimes defenders are. Occasional local areas of pain will still appear as disgruntled employees push the Big Red Button, although damage due to mistakes will still far outweigh anything intentional.
Nate: Predicted! Public vulnerability disclosure disappears
In the wake of payola (semi-legit and black market) and hassle, litigation, and lawmaking by companies, system vulnerabilities will cease to be publicly and freely disclosed. Sure, there will still be XSS galore, but systems-level vulnerabilities will only appear in 0days or Microsoft patches. In its place, expect PR-disclosures being used to sell IPS/IDS updates, which are the only place legitimate money is to be made in finding security holes. Flaws in popular devices like the iPhone and minor applications like Facebook Bingo will continue to be publicly disclosed due to notoriety and no one caring, respectively.
Thomas: Not a chance. Vulnerabilities aren’t worth enough.
For this to come true, payola schemes would have to offer enough to counterbalance the reputation benefit that accrues to published researchers. You’re not even following the money: no competent researcher makes more at auction than they can from their base comp. If you’re good enough to rack up enough frequent flier miles with TippingPoint to make car payments, you’re good enough to land an excellent job at any of the major security companies. And that’s just the money; the reality is, if we just wanted to make bank, there’s 10 other technology jobs that pay better that vulnerability research —- like designing social network pet calendars. Too much of this field is about ego and gamesmanship for it to be taken underground by payola. And I don’t think that’s a bad thing.
Thomas: Predicted! No new major web vulnerability class
A vulnerability class is something you have to audit all deployed software to track down and kill. Overflows are a bug class. Integer mishandling is a bug class. In web apps, XSRF is a bug class, as is SQL injection and cross-site scripting. And speaking of those three: 12 months from the time this is posted, these three problems (and Internationalization, which amplifies them) will still be the mainstay of every web app penetration test. Here’s what doesn’t count: exploit techniques like Prototype Hijacking. 12 months is a long time, and Tavis Ormandy and Stefano Di Paola are going to come up with plenty of cool web tricks. But none of them are going to fundamentally change the landscape of web security.
Nate: The old ones are still everywhere
I’m not a big Web guy so I honestly don’t track the prevalence of known bugs. But, a quick browse of recent Bugtraq archives shows that they’re still appearing at the historic rate. Since I think most new software development is in web-based applications, that’s likely the place the most bugs are being introduced by emergency hires that happen to have Rails on Resume.
Nate: Predicted! Watermarks first used successfully
Everyone thinks watermarks are a failed technology, and they are in their current form. However, people have recently been talking about forensic marks, where the method of embedding data is content-dependent and the detector is kept private. This is different from the previous approach, where the detector is present in every piece of equipment and the default is “play if watermark not detected”. Such systems are obviously permanently broken since you can take a piece of content and make small random modifications until it finally plays.
I predict that forensic marks will be successful in 2008 where watermarks failed. By succeed, I mean have some slight limiting effect on piracy from a given source due to a perceived threat to anonymity. If you knew that Apple embedded an encrypted version of your user ID in each song you downloaded (but not where), it would definitely make you think twice before posting that song online.
Thomas: You’d know better than I would
Every time I try to play the “analog gap” card in arguments with you, you bust out with forensic watermarking.
You have an interesting point: the major breaks in watermarking schemes (at least, the schemes that we know about) have all happened on the attackers’ turf: the system told you when you beat the mark. And, like the SPDC VM in BD+, you’d think that watermarking schemes are painlessly renewable; as long as the system isn’t using them to allow playback, but only to help the lawyers track you down on BitTorrent, it feels like this one gets fought on the defenders’ turf.
Thomas: Predicted! The year of the uninitialized variable vulnerability
You clearly can’t call this a new vulnerability class, because it’s many years old. But as an attack vector, it’s undervalued. Here’s a trick for reading specifications, standards, and documentation like a security researcher: when something has an “undefined” value, that means “a value defined by your attacker”. Here’s a perfect storm of software insecurity: a shortcut taken by virtually every developer in every C/C++ project ever fielded, an obvious-in-retrospect means of exploiting it, and just enough mitigation (compiler warnings) to throw casual researchers off the scent. Here’s what I think: the people who excel at inventing bug classes aren’t the same people who excel at using those inventions to find flaws, and the best hunters aren’t the same people who excel at writing exploits. Those stars will align this year, and the same people who comb Freshmeat looking for KDE video player software to bust shells with will have enough sample code to start exploiting this problem everywhere.
Nate: Not until fuzzers for it become more common
I don’t think you’ll see widespread exploitation until there’s a recipe. Just like with buffer overflows, then integer overflows, uninitialized variable attacks still need more tools for automated discovery, say with a modified Valgrind. You not only need to find uninitialized use of a variable but also a trace of memory fingerprints to find how you can fill that area with your own data. Then, you have to figure out what you can do with that variable. I’m not saying it’s too hard, just that the tools haven’t caught up yet to make this a fruitful area. Maybe in 2009.
Nate: Predicted! Ed Felten wrong about DRM
Every year, Ed Felten predicts that DRM will fail to prevent widespread infringement. He’s been right up to this point, but 2008 will change that in one area. So far, the Blu-ray content protection (BD+) has prevented high-def rips of Fox discs from hitting BitTorrent. The ones that have appeared have been sourced from HD-DVD, which only has a traditional encryption/revocation protection scheme. In 2008, we’ll see the first released BD+ titles cracked (probably by SlySoft, who has already invested four months in analyzing those titles) but new discs will continue to be protected for the key release window. Rips of just the main feature via direct video capture will be the main source of piracy for protected titles (see watermarking prediction above.)
Thomas: I know you have a dog in this hunt, but DRM is going to fail elsewhere
The best “breaks” of iTunes Fairplay barely qualify today (audio capture? Come on). Within 12 months of this post, there will be a freely downloadable tool that converts protected M4P audio files to unprotected AAC files, without decoding and playing sped-up audio.
Thomas: Predicted! A game-over bug class in a scripting language kernel
It has to happen. People have been claiming that high-level languages like Perl are immune to runtime security vulnerabilities —- most notably memory corruption —- for the past 14 years. People like us have been saying they’re wrong, but we’ve had precious little ammunition to back up that argument. Here’s what a game-over scripting kernel bug class is:
something that occurs commonly, that a “competent developer skilled in the art” is likely to accidentally introduce
something you have to audit bulk Python, Ruby, or Perl code to eradicate
something that isn’t easily fixed by patching the language kernel
something that isn’t domain-specific (for instance, SQL Injection doesn’t qualify)
Within the next 12 months, someone is going to disclose a bug that totally screws over Python, Ruby, or Perl devs. If I was looking (and I’m not), the first two places I’d pay attention to are regular expression engines and threading.
Nate: Bug of the Year… if it happens
Sounds impressive and feasible, but not likely to happen this year.
Nate: Predicted! first Facebook app 0day
I consider Facebook the proverbial canary in the coal mine when it comes to Web 2.0 valuations. As soon as startup companies figure out they’ll never make money porting 1980’s text games to Facebook, we’re at the start of the next dotcom crash. Anyway, just like the Myspace worm, a popular Facebook app will have a 0day bug that tries to steal passwords or other important private information. Making private profiles public does not count as we’ve already seen that numerous times.
Thomas: This is a lay-up
We’re already feeling the tremors on this one; look what happened to Google’s Orkut social network. A simple web vulnerability in an Orkut feature, the ability to use Orkut to send email teasers to your friends list, and boom. Mass casualty. What’s better is, your Facebook password is probably the same as your Yahoo Mail password. This is too tempting a target. Sometime within the next 12 months, one single social network vulnerability is going to compromise between 500,000 and 1,000,000 web email accounts, and because they’re all searchable, multiple percentage points of those accounts are going to be converted into bank account compromises.
Thomas: Predicted! The death of the Network Access Control “market”
Do you know anybody who is rolling these products out network-wide? Here’s the pitch: you deploy, oh, I don’t know, 100 crappy new 1U security boxes across your network, and in return, your VP/Sales can’t get to the CRM server anymore. Also, you get fired. Even if this technology worked well, it wouldn’t solve much: the host-level vulnerabilities enterprises care about now are clientsides, and we find too many of them every month for anyone to believe that some 4-person “research team” at a 10MM/yr NAC startup is really going to keep on top of them. The drumbeat of IT security is now how many times a year you have to medevac the last version of Adobe Reader, and while pure-play NAC vendors promise the moon here, none of them lessen that customer pain. Meanwhile, the big problems in security are moving towards the web; no NAC vendor has any answer to the Big Problem, which is that any XSS vulnerability in any internal web app probably hands an attacker every other web app, including payroll.
I do have a point: within 12 months, two (2) NAC startups —- I’m not naming names, but I’m definitely thinking them —- are going to turn the lights out: no major product announcements or customer wins for 4 months. NAC will underperform Data Loss Prevention this year, and next year, and every year after that, leaving aside whatever Cisco and Juniper bake into their gear.
Nate: Agreed, but NAC will be reduced to an integrated feature, not disappear
There’s no reason to deploy some small company’s NAC boxes, absolutely. But IT people have a thing for control and policy. You don’t see the death of AV file scanning even though floppies are no longer how you get viruses, email is. This kind of vantage point tends to survive longer than its importance. So I agree that a lot of the startups will disappear, a few will be acquired, and NAC becomes merely a feature of edge switches with the heavyweight clientside logic left to the AV companies.


grey
February 11th, 2008 7:33 pmack, carriage returns are nice!
comment
February 11th, 2008 7:42 pmUnreadable in its current formatting.
required
February 11th, 2008 7:51 pmThat is impossible to read, thanks for taking all the time to write it.
grammarnazi x 2
February 11th, 2008 7:59 pmugh, paragraph formatting would aid in readability 10000%
John
February 11th, 2008 8:16 pmCan you repost this with some sort of sensible formatting? I don’t need bleeding eyes this early in the morning…
Thomas Ptacek
February 11th, 2008 8:30 pmI blame WordPress.
Phill
February 11th, 2008 8:48 pmEh, here’s hoping your DRM prediction fails.
Dave
February 11th, 2008 10:39 pm>within the next 12 months of this post, there is
>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.
Thomas Ptacek
February 11th, 2008 11:17 pmKeeLoq totally doesn’t count. Neat hack. Who cares? Nobody thought cars were safe to begin with.
Dave
February 12th, 2008 5:33 am>KeeLoq totally doesn’t count.
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? :-).
sigsegv
February 12th, 2008 9:58 amThomas: You’re already right about the “game-over bug class in a scripting language kernel” prediction. In fact, it’s been kicked around since mid 2007. We’re just not telling anyone yet.
Non-disclosure FTW.
Chris
February 12th, 2008 11:31 amIve been doing a lot of language binding audits. While not specifically mentioned in your scripting language prediction, I can tell you they are one of the less audited areas.
Thomas Ptacek
February 12th, 2008 11:35 amDave: the KeeLoq hack is cool. But they could ship exactly the same car door lock for the next 10 years, and the incidence of car theft won’t substantially increase.
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. =)
Thomas Ptacek
February 12th, 2008 11:38 amsegv: remember, to qualify, the bug has to:
* 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!
Chris
February 12th, 2008 12:09 pmThomas: Totally agree. Binding vulns are easily patched. I’m just stating I think we will see a lot more vulnerabilities in those perl/ruby/python kernels in the years to come. They have been largely ignored for awhile (with the exception of PHP I suppose).
Nate
February 12th, 2008 1:45 pmDave, thanks for the pointer to the Keeloq DPA attack. The corrected URL is http://eprint.iacr.org/2008/058
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.
2bluesecrets
February 12th, 2008 2:39 pmEnjoyed the predictions. Helps to know the trends.
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.
ol
February 12th, 2008 4:18 pmhttp://events.ccc.de/congress/2007/Fahrplan/attachments/1038_Smartcard.pdf - pre pay cards in .ch broken.. Does that fit your criteria for tolling?
sigsegv
February 12th, 2008 5:17 pmThomas: Yes, I know. And I meant what I said. The bug classes we’re kicking around meet all your requirements.
Predictions Galore: Analyst vs. Researchers | securosis.com
February 12th, 2008 5:48 pm[…] the other side are the more-technical predictions by Nate Lawson and Thomas Ptacek. These two researcher powerhouses range from digital watermarking and DRM, to NAC and new […]
Thomas Ptacek
February 12th, 2008 5:52 pmsegv: didn’t mean to sound petulant. Congratulations, quite a find, and looking forward to seeing it.
Umm
February 13th, 2008 8:30 amCVE-2007-5116
Door locks vs. Keys
February 13th, 2008 2:19 pmMy impression (a year or so out of date) is that the prox cards used to operate the doors of corporate facilities are significantly less secure than the vehicle immobilizer transponders. Typically these are unencrypted RFID devices, some operating at standard frequencies. Of course, it’s entirely possible that larger companies are moving to cryptographic devices, but again, most of the devices on the market are identical to (or variants of) the transponders originally developed for use in vehicle immobilizers.
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.
Jake Brodsky
February 13th, 2008 3:41 pmI hope you’re right about SCADA. The problem is that everything moves a lot slower when you’re carrying the heavy risk analysis and validation baggage that SCADA systems usually have. It’s going to take years to get truly secure in SCADA. We may not have that much time.
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).
Chris Evans
February 13th, 2008 5:06 pmHi!
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=CVE-2007-5116
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.html
Cheers
Chris
Thomas Ptacek
February 13th, 2008 8:05 pmChris, I’m a Tavis Ormandy fan, but that bug doesn’t qualify. To qualify, the bug has to not be fixable with a simple language kernel (interpreter/compiler) patch. In other words, it has to necessitate auditing of actual Perl code to eradicate.
Dave
February 14th, 2008 4:02 am>My criteria are pretty specific:
>
>* 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?
David Molnar
February 15th, 2008 1:58 amFor door locks, cloning basic prox cards has been known since at least 2003. More recent TV demonstrations:
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?
Thomas Ptacek
February 15th, 2008 3:26 pmI’m disqualifying cloning, is all.
craig
February 26th, 2008 10:43 pmAs usual guys, very informative.
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=1410266717&eid=-255
Keep it up lads, big fan.
Slysoft “quebra” proteção de filmes Blu-Ray, BD+ « Maximum Tech
March 26th, 2008 11:39 pm[…] trabalhou no formato, mais realista, previu no mês passado que os primeiros títulos protegidos teriam sua proteção quebrada este ano. Lawson mencionou que a quebra provavelmente seria realizada pela Slysoft. Ele ainda […]
Andre Gironda
April 7th, 2008 7:07 pmI think http://www.aspectsecurity.com/documents/Aspect_File_Download_Injection.pdf has the potential to change the web application security landscape.
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.
Leave a reply