Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-Day Vulnerabilities

Video thumbnail (Frame 0) Video thumbnail (Frame 2369) Video thumbnail (Frame 4141) Video thumbnail (Frame 6537) Video thumbnail (Frame 7416) Video thumbnail (Frame 8315) Video thumbnail (Frame 9568) Video thumbnail (Frame 11772) Video thumbnail (Frame 12645) Video thumbnail (Frame 13829) Video thumbnail (Frame 16023) Video thumbnail (Frame 18694) Video thumbnail (Frame 19857) Video thumbnail (Frame 21215) Video thumbnail (Frame 23158) Video thumbnail (Frame 25791) Video thumbnail (Frame 26739) Video thumbnail (Frame 28744) Video thumbnail (Frame 30009) Video thumbnail (Frame 36679) Video thumbnail (Frame 39196) Video thumbnail (Frame 41647) Video thumbnail (Frame 46435) Video thumbnail (Frame 50059) Video thumbnail (Frame 51972)
Video in TIB AV-Portal: Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-Day Vulnerabilities

Formal Metadata

Title
Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-Day Vulnerabilities
Title of Series
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2013
Language
English

Content Metadata

Subject Area
Abstract
"Good programmers write code, great programmers reuse" is one of the most well known truisms of software development. But what does that mean for security? For over 30 years software engineering has focused on writing the perfect code and reusing it as often as they can, believing if they can just get the bugs out, the system will be secure. In our talk we will demonstrate how the most prominent doctrine of programming is deadly for security. Analysis of software vulnerability data, including a full decade of data for several versions of the most popular operating systems, server applications and user applications (both open and closed source), shows that properties extrinsic to the software play a much greater role in the rate of vulnerability discovery than do intrinsic properties such as the actual software quality. We show that (at least in the first phase of a product's existence), software vulnerabilities have different properties from software defects. Our analysis of attacker tools and popular exploits shows that the attacker's learning curve determines when and which particular products are likely to be attacked. Improvements in those tools affect the frequency of attack, and the ultimate result is point-and-click usability. We will present several examples from both the defender and the attacker perspective illustrating how dangerous familiarity is for security. We will demonstrate that the more familiar an attacker is with your product, the more likely you are to be attacked and the more likely an attacker will succeed. Sandy Clark (Mouse) has been taking things apart since the age of two, and still hasn't learned to put them back together. An active member of the Hacker community, her professional work includes an Air Force Flight Control Computer, a simulator for NASA and singing at Carnegie Hall. She is currently fulfilling achildhood dream, pursuing a Ph.D. in Computer Systems and Security at the University of Pennsylvania. Her research explores the vulnerability lifecycle, human scale security and the unexpected ways that systems interact. A founding member of Toool-USA, she also enjoys puzzles, toys, Mao (the card game), and anything that involves night vision goggles. Brad Haines (RenderMan) is a Whitehat by trade, Blackhat by fashion. A very visible and well known member of the wardriving and hacker community, he does whatever he can to learn how things work, how to make them better and to teach people the same. A firm believer in the hacker ethic of openess , sharing, and collaboration. Never afraid to try something new, he can usually be found taking unnessecary risks for the sake of the experience. Author of several computer security books and a frequent presenter at hacker, security and privacy conferences, he can usually be found investigating something interesting, scanning the air for any WiFi data, and trying to find new and interesting beers.
Machine code Multiplication sign Hypothesis Sound effect Word Voting Personal digital assistant Different (Kate Ryan album) Software testing Right angle Elektronische Wahl Resultant Vulnerability (computing) Physical system
Point (geometry) Curve Graph (mathematics) Software engineering Multiplication sign Field (computer science) Product (business) Software bug Number Software Software Right angle Metropolitan area network
Programming language Perfect group Electronic mailing list Sound effect Mereology Software bug Compiler Product (business) Sound effect Software System programming Video game Right angle Cycle (graph theory) Softwarewiederverwendung Information security Information security Typprüfung Vulnerability (computing)
Curve Vulnerability (computing) Multiplication sign Sound effect Mass Bit Bit rate Software bug Sound effect Frequency Software Software Revision control Video game Software testing Cycle (graph theory) Quicksort Vulnerability (computing)
Trail Statistics Server (computing) Mobile app Multiplication sign Mereology Product (business) Software bug Number Revision control Frequency Bit rate Different (Kate Ryan album) Computer programming Information Vulnerability (computing) Physical system Server (computing) Software developer Electronic mailing list Counting Variance Mass Correlation and dependence Product (business) Frequency System programming National Institute of Standards and Technology
Multiplication sign Median Variance Revision control Sign (mathematics) Frequency Frequency Software Term (mathematics) Order (biology) Negative number Negative number Position operator Vulnerability (computing)
Point (geometry) Sound effect Median Number Formal language Sound effect Sign (mathematics) Frequency Software Fuzzy logic Right angle Software testing Typprüfung Resultant
Operations research Mobile app Machine code Open source Server (computing) Multiplication sign Closed set Source code Open source 1 (number) Product (business) Software bug 2 (number) Sound effect Expected value Sign (mathematics) Frequency Software Single-precision floating-point format Software System programming Integrated development environment Physical system Vulnerability (computing)
Computer program Game controller Multiplication sign Software developer Cybersex Drop (liquid) Cartesian coordinate system Product (business) Formal language Sound effect Category of being Type theory Frequency Number Explosion Internetworking Malware Software Bit rate Different (Kate Ryan album) Software System programming Operating system
Curve Machine code Machine code Open source Closed set Closed set Source code Open source Product (business) Software bug Hypothesis Revision control Frequency Frequency Different (Kate Ryan album) Software testing Quicksort Data type
Area Curve Machine code Multiplication sign Software developer Curve MIDI Sound effect Set (mathematics) Water vapor Hypothesis Product (business) 2 (number) Software bug Revision control Frequency Type theory Bit rate Software ECos Drum memory Arithmetic progression Vulnerability (computing)
Sign (mathematics) Frequency Machine code Frequency Open source Open source Fault-tolerant system Total S.A. Vulnerability (computing)
Curve Machine code Arm Multiplication sign Product (business) Software bug Sound effect Category of being Befehlsprozessor Frequency Software Computer programming System programming Cuboid Information security Operating system Vulnerability (computing)
Point (geometry) Slide rule Dynamical system Group action Metric system Machine code Multiplication sign Adaptive behavior ACID Field (computer science) Software bug Sound effect Mathematics Bit rate Term (mathematics) Software Category of being Information security Metropolitan area network Position operator Vulnerability (computing) Form (programming) Curve Execution unit Email Software engineering Binary code Sound effect Category of being Message passing Word Frequency Software Order (biology) Video game Cycle (graph theory) Game theory Information security Metric system Resultant
PowerPoint Implementation Process (computing) Line (geometry) Real number Video game Sound effect Website Office suite Communications protocol Implementation Traffic reporting
Standard deviation Slide rule Implementation Mobile app Injektivität Divisor Multiplication sign Process capability index Web 2.0 Revision control Frequency Encryption Authorization Software framework Data conversion Äquivalenzprinzip <Physik> Vulnerability (computing) Proof theory Injektivität Standard deviation Software developer Mathematical analysis Process capability index Plastikkarte Line (geometry) Cryptanalysis Backtracking Process (computing) Software File archiver Data conversion Communications protocol Äquivalenzprinzip <Physik>
Point (geometry) Standard deviation Slide rule Machine code Divisor Multiplication sign Image resolution Modal logic Control flow Revision control Web 2.0 Vector graphics Computer hardware Energy level System programming Software framework Äquivalenzprinzip <Physik> Wireless LAN Injektivität Authentication Curve Machine code Standard deviation Software developer Plastikkarte Usability Staff (military) Exploit (computer security) Vector space Grand Unified Theory Order (biology) Software framework Wireless LAN Communications protocol Asynchronous Transfer Mode Äquivalenzprinzip <Physik>
Suite (music) Installation art Multiplication sign Execution unit Set (mathematics) Disk read-and-write head Software bug Computer configuration Encryption Bus (computing) Information security Position operator Vulnerability (computing) Arm Software developer Gradient Entire function Arithmetic mean Process (computing) Computer configuration Uniformer Raum Telecommunication Configuration space Website Quicksort Procedural programming Cycle (graph theory) Figurate number Asynchronous Transfer Mode Point (geometry) Trail Implementation Vapor barrier Open source Divisor Patch (Unix) Adaptive behavior Virtual machine Student's t-test Product (business) Number Supercomputer 2 (number) Frequency Term (mathematics) Computer hardware Energy level Software testing Firmware Installation art Inheritance (object-oriented programming) Plastikkarte Database Cryptography Logikanalysator Loop (music) Integrated development environment Software Universe (mathematics) Faktorenanalyse Key (cryptography) Game theory Online game Wireless LAN Communications protocol
a couple years ago some of you may remember I gave a talk on hacking voting systems and it was while we were hacking the voting systems that we came across a question for which we we just didn't have an answer and the question is um if these voting systems are such crap and they're so easy and to exploit every everywhere you throw a dart there's another exploitable vulnerability why is it that there hasn't been a single documented case a voter fraud because somebody has exploited one of these vulnerabilities there isn't one case and we looked so we started thinking about this because this isn't right somebody it's not like us elections don't matter it isn't like there's a not a hell of a lot of money going into this so if you had a hundred thousand dollars would you pay for advertising or hire somebody to make the election go your way um and nobody's done it so far so the only clue that we had the only difference between a voting computer and any other about three days a year in other words people haven't had time to learn them so this makes a great hypothesis but I'm a scientist and you have to test a hypothesis so what I'm going to talk to you about today are the result of my trying to test to see whether or not this works or whether or not this hypothesis was actually correct now I
don't know how many of you write software or how many of you are software engineers but the whole idea of software reliability finding bugs and fixing bugs has been at the center of software engineering pretty much since the field has began um the bug lifecycle is highly predictable this graph is from the mythical man month and if you know anything about software engineering this is the Bible um in 1975 when this book was published he Brooks created the I came up with the idea that when you release the piece of software it's got a lot of bugs in it and some of those bugs are easy to find and those easy to find bugs get found really really early and then you fix them and then they get a little harder to find and you fix those and they get a little hard to find and eventually the curve gets pretty low and at that point you know your software is fairly reliable right um bugs are overwhelmingly discovered really immediately after the software is released and then the curve drops right and this is remarkably
stable over time this from 2000 the the actual numbers of bugs found were higher than Brooks predicted they would be but the curve is exactly the same so even if we can't fix the bugs we do know that this aspect of the software defects this is well understood but you know we're
security people right we don't really care about bugs per se unless they become vulnerabilities that we can exploit so here are some just a list of some some conventional wisdom some assumptions that we all make the first is that vulnerabilities are bugs right there just have really really nasty side effects um the second really common assumption is that if we reuse software software that's been out for awhile software that's been tested and has had a lot of its bugs removed that makes the system more secure right it's new software that introduces new bugs and the third assumption that we make is that if we can just approve the quality of our software then we'll make it less vulnerable if we can use the perfect typesafe programming language and if we can find the perfect compiler if we can just build those then we'll have secure software right um well no this is what
we found that at least not in the early part of the life cycle of a product or a release of a product this doesn't seem to apply so here's what we did we looked
at a bunch of vulnerabilities and we looked at just the early life cycle of after each one and in a nutshell what we found is that there's this honeymoon period it's immediately after release software has this little bit of time that protects it and this is going to have some really important implications that we'll discuss later on so it
actually looks like this instead of the way that that the bug lifecycle looks with a curve starting high and then dropping down on the curve actually starts really low and speeds up um low hanging fruit or not easy to find vulnerabilities are not software seems to enjoy some sort of protection from attack in the time immediately following its release and that's what we're calling the honeymoon effect so now I'll get into a few of the details for you
this is what we did we collected 30,000 vulnerabilities from and correlated them with all the major vulnerability people bug track secunia NIST NBD owasp and then we looked at a list of the most popular programs whether they were operating systems or server apps or user apps and we ended up with 700 different releases then all we did no fancy statistical analysis at all all we did was count the number of days the number of days from the official release of the product or a version of a product to the days of its first vulnerability its second vulnerability its third vulnerability and its fourth vulnerability and that's when we discovered that the at the earliest part it seems to be safer here so when I'm
talking about a honeymoon period on this is what I mean I mean that it's it's the time he's a writer lunch by the way this is one of the co-authors of though this work this is matt blaze professor at University of Pennsylvania um so the honeymoon period is that time from the initial release to the first vulnerability but there was a rather high variance because different products different developers release a different race and fix at different rates so in
order to normalize the data we use a ratio we compare the release of the first vulnerability against the first vulnerability of the second and if the time from release to to V 0 is greater than the time from these 0w one that's what we're calling a positive honeymoon okay somebody you'd be using the term positive honeymoon and negative honeymoon a lot o if if the honeymoon period is shorter than the time from v-0 v1 that's a negative honeymoon ok now it's also important to realize that we're not preparing version 1 against version 1.5 we're only looking at the bowl of vulnerabilities within version 1 and comparing them against each other and we're only looking at within version 1.5 against each other each release is looked at independently over the other and this is important because of software quality issues so here's what
we discovered in sixty-two percent of the releases we looked at the honeymoons are positive that means it takes longer to find the first this is exactly opposite of what is true for software reliability and not only that the time it takes to find the personal durability and not only um it does it take longer to find the first one to the second but but it oma is
almost twice as long the median overall honeymoon ratio is 1 point 5 40 it does find a second um okay so there's a
honeymoon effect big deal what does it mean well at first we thought that this was a result of soccer in there there's absolutely no denying that things like the use of typesafe languages um fuzz testing there's any number of things that make software that is written in 2010 of a much better quality than software that was written in 2001 right so we broke it down by year and this is
what we found it didn't matter doesn't matter what we look at we have consistently positive honeymoons and remember that our software reliability models tell us that we should find mostly negative honeymoons we shouldn't find that that there there's fifty percent or greater positive honeymoons no matter how we look at it um so we
broke it down every single way we could think of we looked at just operating systems consistently positive honeymoons we looked at just server apps same thing user app same thing we compared open source code to close source code and it didn't matter it takes longer to find the first vulnerability than it takes to find the second vulnerability um so just for a second let's consider the implications of this the fact is every software release is likely to enjoy a honeymoon from attack in the period immediately immediately after it's released even though not a single one of the bugs that it's ever going to have have been fixed yet this is contrary to our expectations based on so on what we know about bugs we'd expect that the newly released software is at its weakest every single bug it's ever going to have even the easy ones even the low-hanging fruit are still there yet it's precisely at this time precisely when it's at its weakest that its least likely to have an exploit discovered okay so this this got us a
bit confused and we tried to figure out why and what we discovered is this
soccer has properties that are intrinsic to it and probably better intrinsic properties are the things that make a difference to software quality they are how the initial product is designed but what type of language you choose to write it in the skill of the programmer creates an it is important to the intrinsic properties of the software but they're not important to whether or not it's vulnerable that is related to the extrinsic properties the things that the programmers that any developers themselves cannot control and the extrinsic properties are legion um they're everything from the operating system it's running on from the network interfaces from what other applications or products are running on the system at the time from they have to do with the black market and the economics what does what does a loner ability for this particular product sell for um there's so many of them we don't know what they are and we don't know how to measure them but we do know that a lot of these extrinsic properties are growing at a rate faster that we can measure things are getting worse so if most of these extrinsic properties were responsible for the honeymoon period period drop to zero because they are getting worse but the honeymoon period is still consistently to add fifty percent or greater so most of the properties that are extrinsic to whether or not your software is going to be exploited don't matter to the honeymoon period at all um what does matter we got
our first clue when we compared major releases to minor releases major releases of a product are intended to sell a new product they contain the most new features they have the most new code um this is the primary difference because minor releases excuse 900 minor releases are mostly bug fixes um and while they do occur with a lot more frequency than major releases they don't have nearly as much new code this implies that there's some sort of learning curve going on here um and then our second clue came when we compared
the difference between open source code to close source code what's really interesting here is that open source code has a longer honeymoon period but it has a shorter honeymoon ratio what that means is that it takes longer to find the first one then the second one but it also takes relatively long to find the second one and what that seems to imply is that when it comes to attacking open source code the attackers are not climbing the learning curve quite as quickly and we think this is because open source code releases versions rapidly and they're changing the code more rapidly um but we're not sure about that Andrew and we're going to be running some other tests to see what we can find but this is our hypothesis this
is what we think is affecting that um it takes the longer it takes the attacker to climb your learning curve the longer you've got that's your honeymoon so what we think what the reason we think there's a learning curve is because and the reason we think that the rate speeds up after the first vulnerability is found is because that the knowledge gained from from attacking something and successfully weapon or even an exploit allows you to build a set of tools that you can reuse it allows you to find vulnerabilities that are similar without expending nearly as much resources and we think there may also be something like a blood in the water effect going on here if someone announces that they found an exploit in Z everybody else starts looking at products d because they want to find an exploit there too and so that's what we think that's going on so the last convincing piece of evidence that we got that that made us think that that the honeymoon effect is the learning curve k when we realized
that that very first vulnerability the one that destroys your honeymoon there's actually two types of of these and and most people forget this and I'm not sure and an area people pay much attention to but we as engineers as coders as developers tend to believe that we introduce new bugs with new code we're human we write that eco we know that so we expect that every time we do there's any problems with it okay so that a coded of our a bub that is introduced in a new piece of code that's what the column of progressive but the second kind of vulnerability that can be the very first vulnerability in a brand new release of a product is something that we're calling a regressive over that is the product may be making the products at version 4 and a new vulnerabilities town but it also affects version 3 and version 2 and version 1 that means but the baggage self laid dormant until it was discovered in version four we call this regressive now because we're trained to believe that new software and from our own experience I mean software i write as budget one would expect that most of the first polar abilities found will be that those easy to find low-hanging fruit progressive on their abilities but that is not what we found what we found is
that seventy-two percent of the first vulnerabilities ever found in a brand-new um eighty-three percent for open source 59 for clothes horse and what's really interesting is here there's still the owner ability after them so i think what i want to say here is new code is better than old code
even if it introduces new vulnerabilities you get a grace period a safety period um and you get a significantly long on places long honeymoon period the more new code you can get so new code is a trial it forces
attackers to relearn your system it makes your tools no longer work it makes them extend the resources it costs them time it costs them money it's exactly what you need to do to up your side of the arms race so early on in a product extrinsic properties matter more than the quality of the software itself and more importantly the discovery of a new vulnerability appears to depend on how familiar the attacker is with the product software even weeks software even insecure programs are protected by this learning curve and for our sake
what does that mean it means not the same as buzz and no I do not shame because they're extrinsic properties are different the extrinsic property of a software bug are static they are fixed at the time of the software release it needs this operating system is not granted is this cpu they are so well defined and well understood that they are printed on the box when you buy the software the extrinsic properties of that relates to vulnerabilities I don't even know what they are yet they are not well defined how they are not well understood the security community hasn't even delineate adalah yet all we do is say we know this is problem you know this is a problem we know these this is a problem but we don't know what they are yet how we measure them um so what makes nothing
you want to affect important and this is why I'm not your Thursday is because we need to develop a way to tell people here's where you are in the vulnerability lifecycle here's what you can expect and here's how you can protect yourself in other words we need metrics if um I don't know if you know that that seat is secure is all the extrinsic properties that can crack a safe from an arc torch to to hammer and chisel to acid to whatever you can put on it I know that if it's got a UL 30 ratings it will it is safe from attack for 30 minutes so i make my security by having my guard walk we don't have those kind of metrics for software yet and that's what that's what we think the honeymoon effect might help us develop recognizing that this ultimate effect is a result of familiarity um means that that okay what can we do to increase the attacker learning curve throw it all out start over okay that that's that is not going to happen um but we can do other things how about some form of code code obfuscation there are definitely problems of that they dusted your fork you mail and gmail as far as I know has no there are also things like dynamic execution go ahead man so I kept on it for the implications of Sandy's research which I'm enormously proud of you know in terms of the the so what essentially the message of what we looked at from the data and you know we can't explain why this is true but i want to emphasize the single point here is that everything taught in software engineering school when you go to software engineering school you know the first thing they tell you is code reuse is good reuse your code bugs are bad and what we've discovered is that in practice the software engineering wisdom actually makes software less secure its that code reuse and and emphasis on the bug life cycle that actually pushes the vulnerabilities out in front in new releases so essentially the so what that that isn't on sandy slide is we have to rethink the way we teach software engineering for security purposes the the basic precepts of that field seem not to be working at all for security so sorry for that introduction voice for my advisor I'm proud huh anyway so the other thing that we can do we've got to develop some technique that build into software anything that can create that can increase the attackers learning curve um I've been looking at research into dynamic execution and I think that that looks interesting can you change can you make functionally the same and but but execution alee different binaries that's a possibility what I'm also looking at now is adaptability rates and I hope to have a paper coming out on this in a week or two a position paper on um so that if you're the defender how fast you need to release your changes in order to stay ahead of the game so look for that soon at this point I'm going to turn the time over to renderman he's been looking at things from the attacker side and he's got some interesting ideas and examples of what he thinks are practical practical demonstrations of the honeymoon in action so we're going to switch here all
right Oh first thing I have to switch my hat here I Oh Scott moult in a favor so
I thought I'd wear his hat in the talk um Oh apparently speaker notes don't translate from open office to Microsoft PowerPoint apparently microphones working now um so when I first heard about this paper from mouse I started thinking about it like I do everything that she tells me because she's always got something cool um I start looking at for practicals practical examples of this in my own life I deal a great deal with wireless you know everybody knows it's my thing but problem was attacker tools are not well documented she was pulling cv see bae reports missed all those other sites um a lot of the attacker tools you don't know when they specifically implemented things because it's the underground economy it's not you know the whole formal process because it wasn't some lab that came up with it so it's really hard to pin down some of these initial dates when things happen but even if you honor this rough timeline you can you know do approximate guesses when things came in you can start to see this honeymoon effect in real life in everyday things so I'm not an academic I'm a rubber meets the road but I play one on TV yeah but I'm a rubber meets the road kind of guy I want to see how does I so often will read an academic paper and like okay how does this actually affect me what is the the real world implementation of this and I actually found a whole bunch of it within my own life and I thought was really mean so I started looking what I
started looking at web for those of you quick timeline here was originally ratified in September of 1999 and she used rc4 oh ok now it's just throwing me off so as originally ratified September 1999 used the rc4 ciphers there's a first major crypt analysis was 2001 autist of 2001 eres Nora was first released this is what most people consider the first practical weapon tech web attack practical is in quotes because really it was like 10 million packets need to be collectives like a whole day's worth of traffic and even then it was kind of a shot in the dark it was never anything that I ever found truly practical but it was the first it was an implementation of the crypt analysis where the rubber really hit the road was in 2004-2005 when Chris divine first released aircrack I can't find an exact date for its first release but archive.org says it's about 2004-2005 around December now the interesting thing was the apple airport released in july of 1999 this had a really high price tag was like over five hundred dollars when it first came out the linksys wap 11 that came out in 2002 had a much cheaper price tag though I think was about a hundred bucks off the start and now down 50 and I mean now you can get these things dirt cheap anywhere and I'm thinking these are the wrong slides that you loaded up for some reason I'm assuming I think I might be missing some slides here so once aircrack was
released features were added very easily you know arp injection chop-chop you had a framework to work with so now attackers they're looking at web you know starting to poke and prod at this new thing that's seen was starting to permeate the rest of all of our lives start speaking of development it's easy to now just add a new feature aircrack-ng picked up development after Chris divine just vanished there's an extrinsic factor for you you know if your author just suddenly disappears what are you gonna do about it yeah I don't have any of my time lines in this I'm not sure where you got these other slides but okay oh okay um but by 2007 web is fairly idiot-proof to break I mean spoon web came out you know it's included backtrack there's a whole bunch of point-and-click WEP cracking apps you know it's now you can literally teach your mother to do it and if you probably taught your mother to do it but it's interesting because by 2003 WPA had completely superseded web according to the I Triple E they had said web we know it's got vulnerabilities we've got problems don't use it anymore so this is even before aircrack came out this is even before the tools the framework started coming around fully deprecated in 2004 but as anybody who's doing wardriving or any wireless analysis knows it's stuck around web it's the thing that would not die for the longest time the PCI standard started treat started Battin in web as latest 2009 so you've got this this almost five-year gap between when vulnerabilities were found and when it was finally dealt with within industry and somebody was saying you must change out this protocol or else you can't you know process payment cards TJX was the the vulnerability that just kept on giving for guys no wireless community it was initially penetrated in march of 2005 this is actually just after aircrack came out but this is long after there was initial problems being shown they didn't start their conversion until almost six months later in October so there's this weird thing that they tools are out there industry knew that they were out there but they never did anything this is I'm basically calling the divorce period where you've got your your honeymoon is set it your honeymoon is their initial vulnerability comes out okay there's a problem you know things aren't aren't the greatest but you know that if you assume a positive honeymoon all the time you know the plaza amount time you know your best days are behind you suddenly the next thing is going to come along and probably put that nail in the coffin is going to be a much shorter timeline this is where you need to start divorcing yourself from this problem software thinking about maybe upgrading to the next version or even just seek counseling in some way of mitigating this problem yeah always by your IT
staff beer and pizza you know I say that so many like different conferences but there are the guys that know this is the system that's like three versions behind it's out of date you know it needs to be dealt with that it's like the best investment you possibly make so there's this long honeymoon for practical attacks I'm talking in the order of years you know some of your data you're saying we're talking before you only had a resolution of one day for microsoft stuff you could probably count you know the minutes but on the protocol level how do you change out you know a billion access points if suddenly the the protocol is broken you can't do that easy spoken with the chairman of the IETF who was actually on the committee for 802 11 I when they're implementing wpa2 they were absolutely terrified of masked obsolescence that's the reason that the first version WPA the interim used rc5 you know that uh excuse me RC for that was already implemented on the hardware it was something that they could just graft onto the existing stuff you can't just suddenly gut a billion routers and just dump them in the trash that'd be stupid but it was something that you need to to think about get ahead of that curve if you know that by the time that first point hits it's only going to get worse well assume the worst and keep going the cost of equipment is a huge external factor if you know it's a five-hundred-dollar device I'm probably not going to buy it and tear it apart and see how it works but if it's a hundred dollar device that's easier to to get past your budgets get into you know throw it on lap take it apart I mean we've all bought stuff and taking it apart and wondered okay where was that warranty card or that instruction put it back together but the framework once you've got an existing framework like aircrack development just starts snowballing but at the same time is that you've got increases in adoption increases in interesting places that start implementing wireless bigger businesses retail outlets stuff like that but that you just know things are going to get worse 1999 to 2005 WEP was considered suitable though week you know they admitted it but post aircrack the attack vectors multiply increases WEP is just no longer suitable so you can look
at other things like code reuse in these protocols because you know like 802 11 I is just an addendum to the whole you know wireless protocol standard you know they're still using underlying things so things like D authentication attacks still work even when you're using a WPA to network the WPA TCAP attacks reuse the chop-chop attack which is originally developed for web you know see one thing helps another because you now already have an exploitation framework the other thing that again I don't know what happened with the slides but what I had also found was that as you go along and you start looking at okay here's when things were ratified here's where things were released you know here's where aircrack came out there's other things like the monitor mode drivers that air snort introduced there was the air jack injection drivers that were around then you know you had all these little pieces that added up and people start integrating them into these frameworks then you had all the pieces necessary for a complete tool to you know break wept in 60 seconds other external
factors in other things that we're all familiar with PlayStation 3 you know Sony comes out with this wonderful thing and they've got you know this install other OS and everything they seem to be playing nice saying you know people wanting to use this thing for research how many universities bought these things ewing by the palette to set up cheap supercomputers i know that a u.s. i think was the US Navy has like 1700 of these things that they're using a for parallel processing so in March of 2010 jus hot found that wait I might be able to use this install other or less thing to get direct access to the hardware to do other cool stuff Sony's reaction was to pull the install other OS option through a firmware update so either you didn't update your machine and you couldn't play online or you up late played online and you lost this option it had been several the unit had been out for several years by this point and suddenly the you know nobody had any real practical attacks on it suddenly they pull this rug out from developers who've been using these things I mean I wonder what that happens with the Navy when I have to send on these things in for warranty you know do they get back a reflashed one with the new firmware that doesn't support this so by December of 2010 this is only like nine months later initial weaknesses were shown in was a 25 c 3 in europe but by January of 2011 I should be an 11 gio hot basically found the master keys that allows you to sign any software you want to run any things and ran with it so a hell of an extrinsic factor is don't piss off your customer base you know if you've got a whole bunch of people really pissed off that you change their product out from under them you're pointing a big target on the back of your head so how many you know companies do you see the do contests or it's like oh we're our products hack-proof will you know put it out there for tests and everything like that I mean you are just asking for things to happen I mean Sony Lowell second on it's like they have painted like the biggest target on their head that I can possibly imagine but it's a matter of thinking okay you've got this initial release you know it's going to be a while before the tools come about to exploit this when they start coming together you know that the best times are behind you you got to figure out how okay how do we mitigate this do we need to upgrade do we need to flash a new firmware on whatever upgrade protocols procedure or something but understanding that that where that point is likely to be before it gets really bad and you know and you know you can teach your mother to own a device that's where a lot of the value of this research came in for me I've been doing some work with the Aruba Networks they're implementing suite b encryption on their products for doing secret level stuff over wireless it's basically an NSA developed and supported set of configurations for wireless gear so suddenly you can you know have wireless on base at A and use an iPad to access things are theoretically secret I'm willing to get out and say because this stuff is only being implemented at the higher level you've got like a thought you know several thousand dollar price point that you're going to have to break through that is going to be a major barrier to entry so for several years you know X years you're going to have no major attacks against this but as soon as there's an open source implementation when I can load like sweet be level encryption on like a linksys router or something like that and interact with it at home suddenly I'm sure within like X minus 1 years like so however long it takes for those before that open source implementation comes out it's going to be a much shorter period meaning there's gonna be a positive honeymoon it's gonna be a shorter period before somebody figures out some sort of vulnerability or way to manipulate or abuse this so research like this for me proved that okay maybe all those academic papers that I was ignoring because I didn't think they were applicable actually do and I would hope the rest of you would look at your environments and think okay how can I apply this what do these numbers tell me and can I plan ahead and sort of get an idea of when things will go bad so thank you you bring up some interesting points and there's something I'd like to conclude with um by calling to mind how many of you have played around with smart cards um smart cards honeymoon is just about over and the reason it's over is because it's cheap now to get out um I have with me I have a 16-channel logic analyzer right here that i can plug all sorts of wonderful little wires into and stick the rest of them onto whatever device whatever bus I'm trying to snoop and suddenly I have complete access to communication I'm a grad student and i can afford this um um now that hardware tools are cheap enough hardware honeymoon is over um no one can rely on cost or obscurity anymore the entire economic environment ecology if you want to think about it in a biological term has changed it's no longer disgruntled teenagers in their parents basements it's highly financed um organized crime it's nation-states training up on their children to be tools or to be weapons or two or to know how to use the tools and weapons and that changes the honeymoon as well and these are extrinsic to the quality of anything whether it's hardware firmware or software and that's a scary that keeps me awake at night because I don't know how to solve this problem yet what I'm hoping that you'll take away from this is that we have to the way that we fix software now is broken we cannot rely on the patch and pray cycle anymore we have as security people to models for how we protect ourselves we use the Center for Disease Control model which is that you inoculate yourself against everything that you know that's out there and then you stick yourself out there and you wait to be attacked and then when you do you clean yourself off and you go into detox for a while and you do it again and the only other model that we've got is the military model which is um the castle and moat anh you dig a huge mode around yourself and you put up really high walls and you carefully control the ingress and you carefully control the egress and you stick yourself out there and you wait until you're attacked and that's it we can't do that anymore in we're losing this arms race every piece of research that I could find with from from anybody from Symantec disick uni anyone that 20 wasp to Brian Krebs to anyone that watches vulnerabilities and that watches exploits and that watches the marketplace the attackers are winning this game and it's because we patch our software and we fix our hardware the same way we fix our bugs and we're not learning from that and that's what we're going to have to change so I really appreciate your attention and I'll take any questions yes um the the honeymoon paper a familiarity breeds contempt was published a tack sack in 2010 so it's available on their website on the position paper about adaptability should be out on Krypto calm within about two weeks um all of our data is publicly available it's from from the nvd database than this database owasp but Doug trap bug track secunia so you can just run the numbers the same way we did um in a way I am or at least run as fast as they do so here's what his comment was it sounded like we're advocating a third model which is outrun the attacker and that may be our only defense because we're you can't win a defensive war anyway right all you can do is maintain the best you can do is maintain a status quo so or at least stay inside your enemies ooda loop if any of you are military people and know that term so well thank you very much
Feedback