<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Matasano Chargen - Latest Comments in Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://matasanochargen.disqus.com/</link><description></description><language>en</language><lastBuildDate>Sun, 05 Jul 2009 17:47:33 -0000</lastBuildDate><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-12179666</link><description>Prediction is just a guess of what so ever. . . just move your ass out! i don't believe in that.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bostonmovinghelp22</dc:creator><pubDate>Sun, 05 Jul 2009 17:47:33 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323639</link><description>I think &lt;a href="http://www.aspectsecurity.com/documents/Aspect_File_Download_Injection.pdf" rel="nofollow"&gt;http://www.aspectsecurity.com/documents/Aspect_...&lt;/a&gt; has the potential to change the web application security landscape.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Andre Gironda</dc:creator><pubDate>Mon, 07 Apr 2008 19:07:56 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323618</link><description>As usual guys, very informative.&lt;br&gt;&lt;br&gt;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.  &lt;br&gt;&lt;br&gt;Check this one out &lt;a href="http://www.computerworld.com.au/index.php?id=1410266717&amp;amp;eid=-255" rel="nofollow"&gt;http://www.computerworld.com.au/index.php?id=14...&lt;/a&gt;&lt;br&gt;&lt;br&gt;Keep it up lads, big fan.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">craig</dc:creator><pubDate>Tue, 26 Feb 2008 21:43:22 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323638</link><description>I'm disqualifying cloning, is all.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Fri, 15 Feb 2008 14:26:38 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323637</link><description>For door locks, cloning basic prox cards has been known since at least 2003. More recent TV demonstrations:&lt;br&gt;&lt;br&gt;Jonathan Westhues at the California Capitol&lt;br&gt;&lt;a href="http://www.youtube.com/watch?v=4jpRFgDPWVA" rel="nofollow"&gt;http://www.youtube.com/watch?v=4jpRFgDPWVA&lt;/a&gt;&lt;br&gt;&lt;br&gt;Chris Paget shows a hand-held version at RSA&lt;br&gt;&lt;a href="http://www.youtube.com/watch?v=fDimlEdeGjM" rel="nofollow"&gt;http://www.youtube.com/watch?v=fDimlEdeGjM&lt;/a&gt;&lt;br&gt;&lt;br&gt;Were you unaware of these demonstrations, or do they not qualify?&lt;br&gt;If they don't qualify, is it that you're looking to see widespread "adoption" of the attack by criminals or something else?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Molnar</dc:creator><pubDate>Fri, 15 Feb 2008 00:58:31 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323636</link><description>&amp;gt;My criteria are pretty specific:&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;* The door locks on F-500 companies&lt;br&gt;&lt;br&gt;Josh Perrymon's RFID SQL injection?&lt;br&gt;&lt;br&gt;&amp;gt;* Tolling or mass transit&lt;br&gt;&lt;br&gt;The various attacks on the Dutch Transit Mifares?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave</dc:creator><pubDate>Thu, 14 Feb 2008 03:02:56 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323635</link><description>Chris, 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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Wed, 13 Feb 2008 19:05:34 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323634</link><description>Hi!&lt;br&gt;&lt;br&gt;Your perl prediction already came true in 2007. My colleagues Will Drewry and Tavis Ormandy found a heap overflow in perl's regex parser:&lt;br&gt;&lt;br&gt;&lt;a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5116" rel="nofollow"&gt;http://cve.mitre.org/cgi-bin/cvename.cgi?name=C...&lt;/a&gt;&lt;br&gt;&lt;br&gt;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:&lt;br&gt;&lt;br&gt;&lt;a href="http://scary.beasts.org/security/CESA-2006-004.html" rel="nofollow"&gt;http://scary.beasts.org/security/CESA-2006-004....&lt;/a&gt;&lt;br&gt;&lt;br&gt;Cheers&lt;br&gt;Chris</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Chris Evans</dc:creator><pubDate>Wed, 13 Feb 2008 16:06:27 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323633</link><description>I 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.  &lt;br&gt;&lt;br&gt;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).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jake Brodsky</dc:creator><pubDate>Wed, 13 Feb 2008 14:41:31 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323632</link><description>My 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.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Door locks vs. Keys</dc:creator><pubDate>Wed, 13 Feb 2008 13:19:56 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323631</link><description>CVE-2007-5116</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Umm</dc:creator><pubDate>Wed, 13 Feb 2008 07:30:20 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323610</link><description>segv: didn't mean to sound petulant. Congratulations, quite a find, and looking forward to seeing it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Tue, 12 Feb 2008 16:52:52 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323630</link><description>Thomas: Yes, I know. And I meant what I said. The bug classes we’re kicking around meet all your requirements.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sigsegv</dc:creator><pubDate>Tue, 12 Feb 2008 16:17:21 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323629</link><description>&lt;a href="http://events.ccc.de/congress/2007/Fahrplan/attachments/1038_Smartcard.pdf" rel="nofollow"&gt;http://events.ccc.de/congress/2007/Fahrplan/att...&lt;/a&gt;  - pre pay cards in .ch broken.. Does that fit your criteria for tolling?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">ol</dc:creator><pubDate>Tue, 12 Feb 2008 15:18:46 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323628</link><description>Enjoyed the predictions.  Helps to know the trends.&lt;br&gt;&lt;br&gt;Didn't 2007 seem worse overall in security?  Full disclosure died.  Supply and demand might get interesting in OSS security in 2008.&lt;br&gt;Formated and reads perfect in Lynx browser.&lt;br&gt;2008 year of OSS desktop migration?&lt;br&gt;&lt;br&gt;Love you blog, good stuff.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">2bluesecrets</dc:creator><pubDate>Tue, 12 Feb 2008 13:39:56 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323627</link><description>Dave, thanks for the pointer to the Keeloq DPA attack.  The corrected URL is &lt;a href="http://eprint.iacr.org/2008/058" rel="nofollow"&gt;http://eprint.iacr.org/2008/058&lt;/a&gt;&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Nate</dc:creator><pubDate>Tue, 12 Feb 2008 12:45:51 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323626</link><description>Thomas: 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).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Chris</dc:creator><pubDate>Tue, 12 Feb 2008 11:09:58 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323625</link><description>segv: remember, to qualify, the bug has to:&lt;br&gt;&lt;br&gt;* not be fixable with a patch to the language kernel&lt;br&gt;&lt;br&gt;* require auditing of actual script code&lt;br&gt;&lt;br&gt;* be easy to accidentally create&lt;br&gt;&lt;br&gt;* not be domain-specific (ie, SQL)&lt;br&gt;&lt;br&gt;Obviously, we've been finding serious PHP bugs that don't qualify here for years. &lt;br&gt;&lt;br&gt;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!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Tue, 12 Feb 2008 10:38:25 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323623</link><description>Dave: 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. &lt;br&gt;&lt;br&gt;My criteria are pretty specific:&lt;br&gt;&lt;br&gt;* The door locks on F-500 companies&lt;br&gt;&lt;br&gt;* Tolling or mass transit&lt;br&gt;&lt;br&gt;* Metering&lt;br&gt;&lt;br&gt;One of the three falls in the next 12 months, in a big way. Let's see if it happens. =)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Tue, 12 Feb 2008 10:35:06 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323624</link><description>Ive 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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Chris</dc:creator><pubDate>Tue, 12 Feb 2008 10:31:26 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323622</link><description>Thomas: 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. ;)&lt;br&gt;&lt;br&gt;Non-disclosure FTW.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sigsegv</dc:creator><pubDate>Tue, 12 Feb 2008 08:58:54 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323621</link><description>&amp;gt;KeeLoq totally doesn’t count.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;(Shouldn't you be pleased that your prediction came true? :-).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave</dc:creator><pubDate>Tue, 12 Feb 2008 04:33:33 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323620</link><description>KeeLoq totally doesn't count. Neat hack. Who cares? Nobody thought cars were safe to begin with.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Mon, 11 Feb 2008 22:17:51 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323619</link><description>&amp;gt;within the next 12 months of this post, there is &lt;br&gt;&amp;gt;going to be a public, trivially-reproduceable break &lt;br&gt;&amp;gt;in a security-critical piece of infrastructure. &lt;br&gt;&amp;gt;Even more specifically, it’s going to be one of &lt;br&gt;&amp;gt;three things:&lt;br&gt;&lt;br&gt;How about "a week before this post"?  See &lt;a href="http://eprint.iacr.org/2008/058" rel="nofollow"&gt;http://eprint.iacr.org/2008/058&lt;/a&gt;.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave</dc:creator><pubDate>Mon, 11 Feb 2008 21:39:06 -0000</pubDate></item><item><title>Re: Nate Lawson and Thomas Ptacek: Predictions: 2008</title><link>http://www.matasano.com/log/1021/nate-lawson-and-thomas-ptacek-predictions-2008/#comment-2323617</link><description>Eh, here's hoping your DRM prediction fails.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Phill</dc:creator><pubDate>Mon, 11 Feb 2008 19:48:59 -0000</pubDate></item></channel></rss>