I have to say, the hype I’ve heard over the years is well deserved.  The talks that I saw were excellent, registration was quick and smooth, the overall venue was very nice and quite accommodating, and Vancouver is a beautiful city.  I arrived on Tuesday evening before the conference and checked into the hotel.  I ended up with a corner room in the North Tower which had a nice amount of space and was near the conference hall which made it quite convenient to go back and forth between the conference and my room when I needed to work.  I actually did get a fair amount of work done as for some reason a lot of my Clients waited until I was at the conference to email me new submissions, and I was managing another round of development for the ExploitHub and reviewing its latest contracts.

The Tronapalooza party at Five Sixty on Thursday night was ++awesome.  Five Sixty can only be described as a video game bar, with both retro arcade games lining the walls, a line of racing games complete with bucket seats and wheel/petal controllers along one wall, and a HUGE projector screen upstairs for larger-than-life Street Fighter on Xbox.  The bars were open and flowing, there was a decent sized dance floor, and the DJ’s rocked it.  Had the Ms. Pacman machine been set to fast mode instead of slow, it would have been a PERFECT venue in my opinion.

One highlight of my conference experience was the massage room.  I had just spent about four and a half hours up in my hotel room poring over the latest ExploitHub contracts when I finished up and went downstairs to see what talk was currently being given.  It was about halfway through and wasn’t something that I was too terribly interested in anyway, so I decided to walk upstairs and see who was hanging out in the lobby bar.  After the first set of escalators I saw the massage room and thought to myself, “Self, that’s a PERFECT reward for just having spent four and a half hours reading contracts”, so I got myself a massage, and it was fantastic.  Whoever had the bright idea of having a massage room at the conference is a genius.

Anyhow, my notes on the few talks that I did manage to attend are below.

Black Box Auditing Adobe Shockwave – Aaron Portnoy & Logan Brown

I would have named this talk “Adventures in Dynamic Binary Instrumentation” myself, as every few slides Aaron and Logan were solving some problem they had run into using some DBI technique.  While the target of the assessment they were detailing was Adobe Shockwave, I got much more out of this talk regarding the DBI techniques.  I won’t be discussing much of the ZDI-related process info or statistics that they discussed as that bit of the talk wasn’t all that interesting to me, however I must note that those bits were the motivation behind the assessment and why they developed some of the techniques that they did.

The first, and a very important point that they made, was that Adobe Shockwave is NOT Adobe Flash.  While the two products essentially do much of the same thing, and Adobe will shortly end-of-life the Shockwave product line in favor of Flash, they are two distinct and different code-bases.  Also, Shockwave has no symbols when you disassemble it, and functions are exported by ordinal, which makes taking a first look at this product unintuitive.  Also, !heap from WinDBG indicated that this product has it’s own memory manager rather than relying on the operating system’s memory manager.  One of the first things this product does when starting up is to allocate about a Gigabyte of memory from the operating system for it’s own memory manager to manage.  Instead of starting off by reversing an entire custom memory manager, Aaron and Logan decided to use Dynamic Binary Instrumentation (DBI) to hook on read functions and using pre and post-call hooks to identify where in memory data was being stored and then searching those locations for the injected fuzzer data that they were looking for.  The result was a much faster and more scalable method than using breakpoints in the debugger.

An interesting side-quest that they embarked upon during this assessment was when they noticed that the slim version of Shockwave would dynamically go out and download support DLLs for unsupported file formats.  They attempted to compromise this update feature since it’s essentially going out, grabbing executable code, and then executing it, however Adobe was smart for once and were signing these DLL packages with a digital signature including an embedded certificate, so that adventure led to a dead-end.

After fuzzing, Aaron and Logan identified approximately 2500 crashes using simple bit-flipping fuzzing techniques, and about 4000 more crashes fuzzing the RIFF file structure.  They also used another DBI technique while fuzzing to great success, which involved hooking and doing memory allocation as exceptions happened.  When a memory read exception occurred, they would inject code that would allocate memory at the location that was being attempted to be read from, simulate a heap spray by writing heap spray data there, then returning to execution and hoping for a write exception.  This technique is very effective at further verifying that a crash may be exploitable by automatically progressing to feeding the read call malicious data and logging the write exceptions rather than collecting a huge batch of read exceptions and then having to go analyze them manually.

Eventually though Aaron and Logan did have to reverse the custom memory manager but after some initial analysis discovered that it was an off-the-shelf memory manager called SmartHeap.  SmartHeap has five different APIs that all do different things.  This library still had no exported symbols except for one implementation of it for OS X if I recall correctly.  By binary diffing the different implementations against each other and using yet some more DBI techniques to gather statistics on function calls to search for correlations and patterns such as memory allocation functions and memory freeing functions having roughly the same number of calls made to them, Aaron and Logan were able to make a fair amount of progress reversing this memory manager.  It turns out that when you find vulnerabilities in products that use SmartHeap, they are relatively easy to exploit as SmartHeap has no exploitation mitigations like ASLR, heap cookies, etc.

In the end, Aaron and Logan indicated that they had found and fully developed around 20 0day vulnerabilities as well as a number of analysis tools using DBI techniques.

SMS-o-Death: From Analyzing To Attacking Mobile Phones on a Large Scale – Nico Golde and Collin Mulliner

This was a fairly straightforward talk and has apparently been given at previous conferences so I’m not going to go into too much detail here.  I’ve done my own research into the GSM space about five years ago so Nico and Collin’s point about while phone hardware and software being largely proprietary and closed source, the GSM specs being open making research via fuzzing the protocols is approachable I was very familiar with.  They also made a point that I remember well about there being a TON of GSM specs.  Literally thousands and thousands of pages of text.  It was an interesting space to be working in at the time, but the sheer volume of it can indeed overwhelm you.  Anyhow, the result of their research is that after fuzzing over SMS, they identified crashes in every single product that they tested which included a lot of major phone manufacturers and models.

A Castle Made of Sand: Adobe Reader X Sandbox – Richard Johnson

Richard started off his talk with some interesting statistics about Adobe Reader, such as that it has about 30% market share as of June 2010 and that it’s had 358 vulnerabilities in the last 10 years, 278 of which resulted in code execution, and about 22 that were actively exploited in the wild.  It would seem that Adobe has good reason to attempt to mitigate exposure after a compromise via employing a sandbox, and their approach to using sandboxing made it’s debut in Adobe Reader X which not only employs a sandbox but is also hardened to utilize the mitigation technologies provided by the operating system such as ASLR and DEP with the PERMANENT flag.  As a result, it seems that PDF-based attacks fell by about 30% since Q2 of 2010.  Richard did note however that some 3rd-party crypto libraries that Adobe Reader includes do not make use of these mitigation technologies which, if you have Reader load the crypto features, results in about 1.5 Megabytes of non-randomized memory in the Reader process’s address space .  How ironic that loading security libraries actually introduces more opportunity for successful exploitation…

Anyhow, the “Protected Mode” sandbox includes separation of rendering code from initialization and management processes, rendering code is not allowed to write to the filesystem, and API and system calls are filtered through the parent process.  The default configuration of the sandbox includes JavaScript enabled by default although there is a JavaScript API black-list in place, ACLs for file, registry, and process access, and logging is disabled by default.  Given all this, you still have some opportunities for attack and security analysis, such as leveraging a vulnerability in the rendering process which is the most likely attack surface to load an attack DLL and use the attack DLL to attack the broker or parent process.  This attack DLL could be a fuzzer or a more targeted exploit if you’ve discovered a vulnerability in the parent or broker process.  Another interesting configuration of the sandbox is that socket and handle use is not restricted, therefore it could be possible to use a PDF file as a pivot into a target network.  Also, reading files and reading clipboard data is not restricted, so similarly a PDF could be used as a platform for the exfiltration of data.  Finally, the log file, if logging is actually enabled which stated earlier is not by default, is writable.  This makes it possible to potentially cover one’s tracks when performing an attack by wiping or cleaning up the log file.  Overall, it sounds like Adobe is taking some steps in the right direction, however there are still a number of attack vectors present as well as some fairly insecure configurations by default.

Security Defect Metrics for Targeted Fuzzing – Dustin Duran, Matt Miller, and David Weston

This was overall a very well thought-out, performed, and summarized experiment on behalf of the researchers and the extended team that they mentioned in the credits.  That said, due to certain factors like extremely short test periods, a small number of input file formats, small numbers of crash results, and so forth, it was very obviously just that; an experiment.  I would very much like to see this same experiment performed with much larger data sets and testing periods to get a better idea of how biased the results were due to the bounds of the experiment.

First the researchers outlined their motivation for this experiment.  Three challenges with the vulnerability discovery technique of fuzzing were outlined which included the fact that while “dumb” fuzzing is blind and fast, “smart” fuzzing is generally on the opposite end of the spectrum being targeted and more apt to finding crashes, it’s also higher cost in both computing and human resources and due to this could have a much lower ROI, and there really aren’t any current fuzzing techniques that are more in the center of this spectrum.  They also cited that many researchers have a finite amount of resources and time to perform the fuzzing phase of an assessment, and that with most fuzzing approaches today, the process is fairly opaque in that there is limited visibility into the process of fuzzing as well as the code coverage achieved by any particular fuzzing activity.

After outlining the motivation and challenges, the researchers described their approach called “taint-driven” fuzzing, which was loosely defined as dynamic analysis that allows mutative target offset selection based on observing what code affects what memory locations.  Given that with this approach you’re targeting specific functions in code that are reachable via the application’s inputs, they then covered a number of different metrics that could be used for choosing your fuzzing targets.  The team presented five different metrics, the first of which was referred to as Cyclomatic Complexity which essentially meant that the more complex the function is, the more bugs it is likely to have.  Second was a metric based on crash reports from the field.  Microsoft has a fairly robust error reporting mechanism for most of it’s products so that when they crash they offer to send the crash report directly to Microsoft.  These crash reports identify the code that they crashed in, so using these reports for target selection makes absolute sense.  Third was a metric based on static analysis issues such as compiler warnings, use known-problematic sub-functions and system calls, etc.  Fourth was a metric based on the attack surface within the function presented by the instructions in the function that operate on tainted data. The fifth metric was based on perceived exploitability and was  rather interesting as it was to essentially step through every instruction in a target function, simulate a crash on that instruction, and then use WinDBG’s !exploitable logic to indicate whether or not if there is a crash there, if it is obviously exploitable or not.  Collecting the results from these simulations you can calculate a score on how potentially exploitable any given function is, assuming a crash exists.

Finally, the group disclosed their results which included lots of charts and graphs and various different views of the data from differing perspectives.  I’ll leave it to you to go dig into their research if you want the exact details, but in a nutshell, the team tested four binary file formats using five fuzzing engines made up of three that were taint-based and two control fuzzers, 6 different metrics including the five outlined above and a control which was entirely random, and spent five days on each combination of fuzzing engine, metric, and target file format.  The results were somewhat inconclusive other than an indication that the larger the code base, the more applicable taint-based fuzzing seemed to be as it’s results improved over the control fuzzing engines as the application’s code-base grew in size.

The Monday after ToorCon 12 I boarded a red-eye flight at 9:30 PM bound for Newark and then took the connection from Newark to Toronto at 6:45 AM. I was honestly really surprised when I arrived at my hotel at 9:30 AM and they actually had my room ready. I was afraid I would have to check my bag and find something to do for a while until it was ready, but luckily I was able to go up to my room immediately. Having my own space as soon as I arrived helped quite a bit because I actually had a fair amount of work to get done and since landing in Toronto I had a somewhat severe atmospheric-pressure-change headache to deal with. After working for a few hours I decided the only way to kill the headache was to take a nap, and when I woke up it was 4:30 PM. As I’m sure you’ve guessed at this point, I missed the entire first day of the SecTor conference due to unexpectedly needing to work and the headache.

After waking I continued to work for a bit while most of the SecTor attendees were at the reception and speakers attended the speaker dinner.  I caught up with a few people at the Pub following the dinner and was fortunate enough to be introduced to Eric Boyd, the creator of the North Paw project which I intend to build from one of his kits at some point in the near future.  We had some great conversation about sensory and haptic feedback technology and discussed some of his upcoming project ideas.  If you’re interested in that sort of thing, you should definitely follow the Sensebridge site’s RSS feed or subscribe to the Body Hacking list where he will hopefully be posting updates and information on new kits that will become available.  After hanging out at the Pub for a while I headed back to the hotel to work some more before crashing out around 5 AM.

On Wednesday I woke to continue working a while and to participate in some conference calls, and by the time I was finished with that there was no point in even attempting to attend the conference any longer.  Once the conference was over I headed over to the Rapid 7 Metasploit One Year Anniversary party, celebrating the anniversary of Rapid 7‘s acquisition of Metasploit.  I spent a lot of time talking about the ExploitHub at that party, imagine that…

After the Metasploit party I headed over to the first Quantified Self meeting for Toronto which I had found out about the night before.  The format of the meeting was nearly identical to the AHA! meeting format, which ironically enough was happening at just about the same time as the AHA! meeting back in Austin.  This meeting was excellent.  There were lots of people sharing their own experiences and questions with personal tracking and statistics with the group, lots of group participation, and I learned about a number of interesting projects and resources such as CureTogether, which is an online community for people with chronic and not easily identified conditions where the site’s tools assist in potential diagnosis and visibility into what treatments other similar sufferers are trying and how well they are working for those other people.  There was also someone at the meeting with a haptic feedback sonar system which allows the user to detect physical objects at range via modulating the frequency of a haptic feedback pulse.  Another attendee introduced us all to an Android app called KeepTrack, which I’ve been using ever since to keep track of all sorts of things.  You can even have KeepTrack alert you to enter values at specific times with it’s reminder feature.  Overall this meeting exposed me to some really cool stuff and has somewhat inspired me to be a better scientist when performing experiments with and on myself by recording and tracking more personal data during such experiments than I have been.

After the Quantified Self meeting some of the group walked a few blocks to a Pub for some food, drinks, and further discussion, and then I headed back to my hotel as I had to check out of the hotel and head to the airport at the wee hour of 4:30 AM in order to get through customs and catch my flight back to Austin.

Overall, other than actually missing the conference that I was in Toronto for in the first place, I had a really good time.  Toronto is a beautiful city even though it was a little on the cold and rainy side.  Fallen maple leaves everywhere made me smile more than once.  I had a chance to catch up a bit with my local friend and met lots of new and interesting people.  I hope to have the opportunity to visit Toronto again when I have more time and there isn’t so much going on with conferences and unexpected work so that I can spend more time with my local friend and really explore and enjoy the city.

On Friday night I only made it through about half of the reception and didn’t make it to the party that evening as about the time the reception started I was going on about 40 hours without any sleep.  Lately I’ve been going to bed about 5 in the morning and I had to be at the airport to catch my flight at 6:30 AM, so I just didn’t sleep Thursday night at all.  I attempted to get some sleep on the plane flight in but every time I would start to doze off the plane would hit some turbulence and wake me back up.  Anyhow, I crashed out early on Friday night.

Saturday was a good day at the conference with many excellent lectures.  I got to catch up with some folks I hadn’t seen in a while since I had missed the last two ToorCons as well as others who I had seen as recently as BlackHat and DEFCON.  The Microsoft sponsored party Saturday night was good, I had a number of great conversations and even had a chance to dance a bit.  After the party a lot of people went back to h1kari’s room at Hotel Solamar to hang out and chat and of course drink more.  Good times.

Sunday was all turbo-talks at the conference followed by the closing remarks and then the ToorCon afterparty.  I only saw a couple of talks but the ones I did see were good.  After the closing remarks a few of us had a quick bite at a sports bar in the same hotel as the after party and then headed up to that.  Similar to the parties the previous night I met a number of interesting new people and had some good conversations.  Hopefully I’ll see many of these people again soon at other conferences or back again next year at ToorCon 13.

Below are my thoughts on some of the lectures I was able to attend:

Real Men Carry Pink Pagers – Travis Goodspeed & Michael Ossmann

While I had been following this research for a while and saw an earlier talk covering some of the subject material given by Travis at REcon, this talk was full of interesting information and was quite entertaining with Travis and Michael constantly referring to certain types of people  as quiche-eaters and showing some rather funny marketing videos from the manufacturer of the IMMe.

This talk came at the subject from a slightly different direction than the talk I had seen before and had more information deriving from Travis’s more recent advancements as well as contributed by Michael.  They covered how while the radio chip in the IMMe is hardware, it’s about as close as you’re going to get to a software radio due to how flexible and configurable it is.  The radio itself is entirely capable of using a wide range of frequencies other than the few that the manufacturer used for its purpose as a communications toy for girls.  Beyond even that, you can configure the radio’s packet structure so that it can be made to talk to a wide range of devices, even devices that don’t necessarily share the type of radio chip used in the IMMe in common.  If you want to work with this device’s radio for very specific frequencies, TI’s Smart RF Studio is extremely useful and will save you a lot of time.  However, if you want to write an application that employs frequency hopping, or monitoring multiple frequencies at once like Micheal’s spectrum analyzer that he wrote for the device, Smart RF Studio isn’t quite adept at those things, so you’ll want to roll your own or email Travis or Michael for some pointers.

Some interesting tidbits of information that came from the spectrum analyzer project is that some consumer two-way radios that they analyzed, while having 14 “channels”, really only used two distinct frequencies to cover those channels; one frequency for the lower 7 and one for the upper 7.  They speculated that there is something in the radio packet that is sent that indicates which of the 7 channels that are assigned to one of the two frequencies is to be used and the radio just squelches any packets received for the channels it’s not tuned to.  Due to only employing two frequencies, it makes it quite easy to monitor or jam the devices as you can observe or affect 7 channels simultaneously.

Another interesting use they had made of the device was using it to observe and replay garage door opening codes, of which they showed a video of this working.

Travis and Michael then talked about some RF devices used for instant feedback and polling which are becoming popular on many university campuses.  Apparently they use these to take attendance, and to do instant polling during lectures.  The application that they developed to attack these is essentially a monitor to see in real time what answers other devices around you are responding with before you choose your own answer (:

The guys finished up showing Travis’s new case mod for the IMMe which accommodate an opening in the side of the device for an internal GoodFET interface that has a Mini USB Type B socket rather than the older GoodFET USB Type A plug, a number of boards for which they gave out at the end of the talk.  I already have a GoodFET however I also own an IMMe so I went ahead and grabbed a board so that I can duplicate the case mod so that it’s much easier to reprogram it.  They also briefly touched on a Zombie game that they are developing for the device which is to be debuted at the next CCC, so now I have even more incentive to make it out to the next one… I love multi-player games, especially when they involve hardware or gadgets (:

All in all an extremely informative and entertaining lecture.  So cool…  So connected.

Exploiting SCADA Systems – Jeremy Brown

I only got to see the first bit of this talk as about 20 minutes into it I got a phone call and had to duck out of the talk to answer.  Jeremy started off by noting how poor security is on many SCADA systems as many of them run services that you can interface with without any authentication at all, they’re just wide open services that you can have perform actions for you.  Jeremy then went though an amusing story about attempting to disclose a vulnerability to a SCADA vendor who seemed fairly clueless regarding security, what a vulnerability is, whether or not it could be leveraged to do anything, etc.  He then went into some tips for managing the vulnerability disclosure process which seemed like he was getting off-topic a bit and that was the point at which I had to duck out.

Advanced AIX Heap Overflow Methods – Tim Shelton

I had already seen most of this talk on video from Black Hat earlier this year but I wanted to catch the rest and Tim is a friend so I figured as a last resort I could heckle him a bit if things got too boring (:  Things didn’t get boring because he started off the talk drinking and was dipping the entire time, which got quite amusing toward the end of the talk after he’d gone through about half a bottle of liquor (:

As far as the content goes, Tim covered Litchfield’s previous research on the topic from 2005 and explained that technique for achieving code execution using heap corruption.  This context is important because the second technique he detailed was his new research on the topic and without an understanding of Litchfield’s previous research you might not understand how the two techniques differ and under what different process execution circumstances each are used.

In short, Litchfield’s previous research described a technique for abusing heap corruption employing the rightmost() function when memory is allocated and then followed by a free().  Tim’s new technique is a way to abuse heap corruption employing the leftmost() function when memory is allocated and then followed by another memory allocation.  In both cases however you’re overwriting 8 bytes beyond the end of a heap buffer and creating a fake heap frame in memory for your linked list pointers that got overwritten to point to, so without understanding the subtle differences it can seem like the same technique.  All in all, it was some good research in an area that isn’t too well explored that actually advances the current state of the art in that area and provides more options for anyone attempting exploitation against that platform.

How I Met Your Girlfriend – Samy Kamkar

This was a fairly entertaining talk that took the form of a case study in social engineering assisted by various and fairly interesting web application attacks and browser protocol abuse.

The web application attack scenario covered breaking down a site’s authentication cookie into components that could be guessed, harvested,or brute-forced, with the goal of bringing the amount of brute-force work within the realm of possibility.  The example cookie broken down during the lecture contained components such as the user’s IP address, timestamps, etc.

The protocol abuse component covered some interesting properties of text-based protocols that use CRLFs as command or line delimiters.  By abusing the properties of web forms and POST commands, an HTTP client like a browser can be made to connect to other services such as SMTP or IRC servers which are usually resilient enough to ignore the HTTP commands and headers and only start processing commands once it receives commands it recognizes.  By using hidden form fields a user that submits the form can have their browser subverted into connecting to a different remote server and issuing commands, such as sending an email or logging into an IRC server and sending a message.  This behavior obviously gives up sensitive information that the attacker may not already have such as IP address of the connecting client, various HTTP headers, etc., some of which were used in the authentication cookie that was being broken down and attacked during the talk.

Samy also covered a technique for geo-locating someone based on XXXSS combined with Google’s street view tracking of WiFi access points by MAC address.  By causing the victim’s browser to pull the MAC address from the internal side of the victim’s WiFi AP/Router and then send it out to the attacker, the attacker can then  look the MAC up on Google to get a fairly accurate location of where that AP resides in the real world.

Overall this was an informative talk and Samy is an engaging and entertaining speaker.  I look forward to more lectures from him in the future (:

The Carmen Sandiego Project – Don A. Baily & Nick DePetrillo

I had missed this talk the last few times it was given for various reasons, so I was glad to finally catch this even though I was aware of the research Nick and Don were doing well before the first time they gave this talk.  I am into phones, after-all, and I know Nick fairly well so we had been discussing various things relating to this research for a while.  It was good to finally see it all come together and actually be useful for the intended goal though (:

Nick and Don started off covering SS7 a bit and explaining how prevalent it is in the back-end cellular networks and how having access to it essentially gives you the keys to the kingdom to do whatever you want, however access is fairly expensive and if you’re abusing your access your peers will cut you off as they actively detect bad actors in the community.  Part of the point of bringing this up at the beginning was to set the frame that everything they describe doing throughout the rest of the lecture was done entirely with available information and without any special access to data or systems such as SS7 devices.

After setting the stage, and identifying a few acronyms (yes, look this over now…), they first covered using CNAM and HLR information to ID and track someone via cellular tower switching of the person’s cellular devices.  This essentially allowed them to somewhat granularly map MSC areas and where their boundaries are geographically.  Then by using other data points for augmentation such as traffic cameras with publicly available video feeds, reversing flight information from times and dates where cellular devices disappeared and showed up again, and other data, a fairly detailed intelligence profile can be constructed about a given individual.

Watch Primer for Hackers – Nick DePetrillo

This was probably the talk that I found most entertaining of the entire conference, and describing it here won’t even do it justice.  I’m sorry you weren’t there…

Autism and the Coevolutionary Imperative for Cyborgsurvivalism – Amber Lundy

This lecture was a LOT of information that was being compressed down to fit in a 20 minute turbo-talk.  As such the presenter was rushed, but there was really no escaping that for the amount of material being presented.  Honestly it went so fast that I wasn’t able to take notes, so it’s hard to write up a report here.  If you have an opportunity to see the full length talk I would recommend it if you’re into this sort of thing, as I’m sure much more detail would be available than was given here, as this was somewhat high level due to the time constraint.

After this talk I spoke to Amber briefly to see if she perhaps had been subscribed to my Body Hacking email list and had just been a lurker, but she said she hadn’t heard of it so hopefully she’ll join as I feel she likely has a lot to contribute to the discussions there.

Upon arrival at the conference hotel, it was immediately noticeable that the air conditioner was not working.  Had the conference not been in this hotel, and if I didn’t really like being extremely convenient to the conference, I probably would have not even checked in and gone somewhere else.  They assured me that the air conditioning would be fixed “tommorrow”, as they did every day, and it actually was fixed in parts of the hotel over the five days I was there, however it was never fixed in my room.  Luckily I didn’t spend much time in my room as I was attending the conference and going out to the various clubs and bars to socialize with other REcon folk.  Other than the heat issue the conference was excellent.  It’s definitely a contender for my favorite small conference, of which that title is currently held by ToorCon.

Montreal was nice, although predominantly French Canadian, so it was good to have so many friends around that could speak both French and English.  For the most part, in the nicer establishments such as hotels and nice restaurants the people there were usually fluent in both languages, however in the random bars or clubs, or fast food restaurants, it was fairly hit or miss if you would end up speaking to someone that spoke English.  Since I don’t speak French other than a few words that I picked up during my stay, having French speaking friends around was extremely useful.

The first two nights of my stay I overslept due to the alarm clock being set exactly twelve hours off.  The first time I overslept I chalked it up to user error with an unfamiliar alarm clock, but when I overslept a second time, I knew something was amiss.  Due to oversleeping the first two days of the conference I missed a few of the lectures that I had wanted to see in the mornings, however I did manage to catch some of the others.  Below are my notes and impressions from some of the more interesting ones that I did manage to attend.

Jonathan Stuart – DMS, 5ESS, and Datakit VCS II: interfaces and internals

This was a fairly interesting talk about interfacing with various telephone switches.  I used to dabble in this area way back in the day, so some of it was a bit familiar, but not since the mid-90′s have I done much telephony stuff until the past few years and my adventures in VoIP land.  While informative and interesting, the omissions of the “juicy bits” got a bit repetitive.  However understanding the speaker’s background it was understandable.

Dino Dai Zovi – Mac OS X return oriented exploitation

I really enjoyed this talk.  My last couple years at BreakingPoint I wasn’t doing much fully functional exploit development as the BreakingPoint system takes exploitation up to the point of triggering the vulnerability and no farther, so I hadn’t been keeping up with new developments in the exploitation field as much as I should have.  When ROP and borrowed instruction programming recently became all the rage, I gave it a passing glance and understood the concept, but didn’t really dig too much into the details.  This talk was an excellent overview and filled in most of the gaps for me.  Now I’m somewhat motivated to go write some ROP/BISC exploits (:

Travis Goodspeed – Building hardware for exploring deeply embedded systems

Another talk I really enjoyed, Travis covered a bit of time on his GoodFET JTAG interface as well as spoke about reversing some various hardware as well as a clicker device used in academia by students to answer questions, vote on things, etc.  Apparently there may be some legal issues surrounding the disclosure of some of the clicker information, so here’s to hoping that Travis stays out of the pokey (:  I’m also now motivated to finish assembling these two GoodFET boards that I have sitting here…

Ricky Lawshae – Picking Electronic Locks Using TCP Sequence Prediction

Although I’ve seen this talk before at AHA!, it was good to see a prior colleague getting out to speak.  Ricky covered sending unauthorized commands to physical access system door controllers via TCP packet injection.  For a turbo talk it was well organized and he paced it well.  Good job, Ricky (:

Overall I had a great experience at REcon and met a ton of awesome people.  I also had an opportunity to catch up with many of the usual suspects, including Richard Thieme who was keynoting this year.  Richard has a new book that was recently published entitled “Mind Games”, of which I picked up a copy that he graciously scribbled on for me.  So far it is an excellent read and I highly recommend picking it up.

As far as REcon goes, I completely intend to go back again next year as apparently Hugo plans to forgo the bi-annual schedule he’s been on and go annual!  So, I’ll see you all again next year at REcon (:

ad·vanced – /ædˈvænst, -ˈvɑnst/ -adjective
1. ahead or far or further along in progress, complexity, knowledge, skill, etc.: an advanced class in Spanish; to take a course in advanced mathematics; Our plans are too advanced to make the change now.

per·sist·ent – /pərˈsɪstənt, -ˈzɪs-/ –adjective
1. persisting, esp. in spite of opposition, obstacles, discouragement, etc.; persevering: a most annoyingly persistent young man.
2. lasting or enduring tenaciously: the persistent aroma of verbena; a persistent cough.
3. constantly repeated; continued: persistent noise.

threat – /θrɛt/ –noun
1. a declaration of an intention or determination to inflict punishment, injury, etc., in retaliation for, or conditionally upon, some action or course; menace: He confessed under the threat of imprisonment.
2. an indication or warning of probable trouble: The threat of a storm was in the air.
3. a person or thing that threatens.

This term has been around for ages, and means exactly what the acronym’s words mean.  It’s not any single attack, it’s not any trivial or obvious piece of malware, and it’s not the bogeyman that the hot new security product will save you from.  It’s a particular class of threat.  The term gained critical mass being used as early as a few decades ago in the intelligence community where it is used to describe advanced and generally covert modus operandi for ensuring the ongoing gathering of intelligence about an individual or other entity.  The term has been more recently applied, although still at least a decade ago, to Information Security where it is used to describe an ongoing campaign of targeted, sophisticated attacks, or the actors facilitating or conducting said campaign.  In other words, a threat that is both advanced and persistent.

Please, for the love of all that’s holy, stop using “APT” interchangeably with “malware”.  A particular piece of malware may be an APT, or a component used by an APT, but not every APT is malware.  In fact, most of the time malware can’t be considered an APT as the majority of malware is neither relatively advanced nor persistent, and to be APT it would have to be both.

Here’s my April Fools 2010 link roundup:

• Google renames itself to “Topeka”
• Lots of ThinkGeek items, as usual.
• F-Secure’s internal sample management interface joke
• F-Secure’s Rick-roll Protector
• XKCD console interface / MUD (tons of commands…)
• Razer Venom intravenous gaming stimulant
• YouTube text mode
• CERN LHC discovers a “paleoparticle”
• EFF time-travels to support robots’ digital liberties
• Metasploit’s new Cyber Warfare business model
• egypt’s “earsplitter” Metasploit Cyber War module
• Moog Auto De-tune
• L0pht’s Pwr2Own Pwn2Own spoof.
• AMD “lottery core” CPUs
• Solar minimum/maximum vulnerability in Juniper SRX
• Upside down kernel.org
• deadmau5 vs. Felix daHousecat
• Man from the future at the LHC
• Woot.com moves to “choose your own adventure” format
• Fermilab’s “unprecedented day without an outage” (among others)

Over the past few years however, some things have drastically changed in the value and marketability of such vulnerabilities.

There has been a dramatic explosion in the size of the legitimate vulnerabilities market.  I personally did some research into this about five or six years ago, and there wasn’t much of an overt, legitimate market for selling vulnerability information and exploits.  This was about the time that iDefense’s Vulnerability Contributor Program had only been around for a couple years and TippingPoint’s Zero Day Initiative was just getting started.  The market was small, and other than these public buyers (among a couple others), unless you were well-connected and could find the other legitimate buyers that stayed well below the radar, or wanted to sell to organized crime, these buyers were pretty much your only options.

Since that time, the buyer pool has grown dramatically.  I took a fresh look at the market a couple of months ago when a blog post from SourceFire inadvertently drove people on both sides of the equation directly to my email inbox.  I mean really, who at DEFCON other than me fits that description???  I was both surprised and overwhelmed by the amount of interest I got from both buyers and sellers regarding a service that I wasn’t even providing.  Building upon that response, I decided to see how difficult it was to seek out additional buyers, which turned out to be not hard at all.  Finding researchers who want to be paid for their work is trivial.  This is a huge change in attitude and intention since I originally looked into the vulnerabilities market five or six years ago.

Over the period of time between these two bouts of research into the market which both had drastically different results, a lot of things have happened.  Multiple attempts have been made to sell exploits on eBay or create an open vulnerabilities auction site. Multiple private markets now exist. ZDI and iDefense are still going strong. Papers have been published and countless blogs and articles have been written on the subject. Brokers have begun offering their services.  The “No More Free Bugs” movement was born.  Overall, the vulnerabilities market has grown up a little.

While there is now a considerable financial incentive to sell their work rather than publicly disclosing it for a bit of fame and an acknowledgment in a vendor’s advisory, or holding onto their research until a conference comes around where they can win a bit of cash and a trinket or two, I really don’t know how long quality contestants will stay interested in such a contest.  The only thing that sets Pwn2Own apart from the other vendor bug-bounties, “hack our product” contests, and even the ZDI and iDefense programs themselves, is that they have done a decent job trying to provide somewhat reasonable cash prizes that don’t get scoffed at quite so easily alongside the trinkets.  This year the Pwn2Own contest touted $100,000 in cash and prizes, and I’m not trying to demean the prizes given away in the Pwn2Own contest, but when compared with the prices that the individual vulnerabilities used to compromise the two laptops could have fetched, describing iPhones and laptops as “trinkets” is more than appropriate in comparison.  I expect that Pwn2Own will continue to have to keep upping it’s game in the cash department to stay attractive as more and more researchers realize that they can get a much better return on their investment of effort in the vulnerabilities market and as vulnerability purchasing becomes more commonplace.  At least the contest seems to be prompting some vendors into releasing huge numbers of patches just before the contest, which is a good thing.

When it comes to the ethics and risks of such vulnerability sales, everyone must make their own decisions in such matters.  While some believe that disclosing a vulnerability to anyone other than the vendor, or the vendor via an intermediary such as ZDI, is absolutely wrong, others find nothing wrong with selling the vulnerability to the highest bidder, regardless of what that buyer might intend to do with it.  While these are obviously the two extremes, the recent sentencing of Jeremy Jethro for selling an exploit to the convicted TJX hacker who used it for nefarious purposes has set the precedent that selling an exploit to someone regardless of knowledge of their intentions could land you in legal trouble.  The upside to the current state of the vulnerabilities market is that today there are plenty of legitimate buyers to sell to if you put in some effort to find them, and such transactions can be made legally, contractually, without a lot of risk, and to buyers that have been vetted and their intentions are known and clear.  This is where using a broker can greatly assist someone in selling their work, as the broker’s entire purpose is to find their client the best price possible from the types of buyers that the seller is comfortable with.

For now I’m continuing to do more research into the market and vulnerability brokering, however so far the market seems quite viable and a potentially lucrative endeavor, should some random blog someday inadvertently “out” you as a vulnerabilities broker.  In the meantime, I’ll be happy to point anyone that asks, both buyers and green hats, in the right direction.

…
User: Apparently not, because you’re not making much sense.
Cleverbot: Tim? Who said anything about Tim?
User: No one, and now you’re making no sense at all.
Cleverbot: I am smarter than you. A LOT smarter.
User: Doubt it.
Cleverbot: That was pretty rude.
User: Only because it was a response to your rude comment.
Cleverbot: Tough maybe you are not.
User: And clever you definitely are not.
Cleverbot: You already said I was.
User: No, I didn’t.
Cleverbot: Yes you did.
User: No, I didn’t.
Cleverbot: I believe you did.
User: No, I didn’t.
Cleverbot: Are you smart?
User: Define ‘smart’.
Cleverbot: Showing mental alertness and calculation and resourcefulness.
User: That’s a horrible definition.
Cleverbot: I did not answer the phone.

Unfortunately the chat log retrieval only gave me back the last half of the conversation, but the beginning went something like:

User: Hello, how are you?
Cleverbot: I’m fine, how are you?
User: I’m good.
Cleverbot: <something completely unrelated>
User: <my response>
Cleverbot: <something else completely unrelated>

… and so on.  Rest assured, I never once mentioned anyone named Tim.  Maybe they should have named it ArrogantAndConfrontationalRandomThoughtBot.  When receiving the conversation log via the “Thoughts so Far” button, a question at the top of the log page asks “Is this bot clever?”  I’d have to say no, no it’s not.  Not even close.

The problem with smart-phones with touch screens is that they suffer from a similar attack that physical keypad entry systems do; there is a physical remnant that can indicate the digits used in the entry code.  Physical keypads can have their keys worn down over time, so that if a common code is used, it is eventually apparent which keys are more used than others.  Smart-phones with touch screens suffer from a less permanent version of this, being skin oil left on the screen in the form of fingerprints.

A colleague here at work has an iPhone.  His unlock screen uses a number pad, and you enter in a PIN number to unlock it.  As you touch the screen to enter the PIN, your fingers will leave fingerprints on the digits that are contained in the PIN.  Because the digit button locations are static, even with other use of the touch-screen, over time you end up with little clusters of fingerprints on the screen indicating the digits used, which drastically shorten the search time of a brute force attack on the PIN if the user isn’t diligent about wiping down the touch screen periodically.

A friend of mine also has an iPhone, however she uses a different screen locking app, which instead of digits just presents the user with a grid of buttons, and the key to unlocking is to press these buttons in a specific pattern.  This is slightly less secure than the PIN method, as there are no values to the buttons, only their location, which essentially requires that the locations pressed on the screen remain static.  The PIN method could be made more secure in a number of ways, however this method cannot.

The default screen locking method for the Droid is even less secure, as instead of pressing a pattern, it has the same grid of buttons as the last method I described, but has you draw a pattern across the screen linking the buttons in a sequence.  Where before you only divulged the digits contained in the PIN or sequence pattern via individual fingerprints, in this case you leave a nice long smear of skin oil across your screen, not only indicating the button locations used in the sequence, but their order.  At this point you really only have two options to try in your brute force, the sequence starting from one end of the smear or the other.  Guess how long it takes to get that one correct.

Needless to say, I tend to wipe my phone’s touch-screen quite frequently.  Why hasn’t anyone implemented a lock screen that uses a technique like this one?

They’re obviously missing the point, and I suggest that the premise of even trying to calculate such a metric as its accuracy is fundamentally flawed.

The numbers in the article, and really, any numbers you would care to calculate and be able to prove, can only be made using public information.  This means you count the number of exploits publicly known about, compare that to the number of vulnerabilities with a particular rating, and get your percentage.  This is what the article and the people it cites do.  This calculation, and it’s results, are useless.

If you read the “mission statement” from the top of the Exploitability Index page, you will find the following:

The Microsoft Exploitability Index is designed to provide additional information to help customers better prioritize the deployment of Microsoft security updates. This index provides customers with guidance on the likelihood of functioning exploit code being developed for vulnerabilities addressed by Microsoft security updates within the first thirty days of that update’s release.

Nowhere in that statement does it say anything about exploit use or disclosure, because it’s irrelevant to the point of the rating.  The rating is about how exploitable the vulnerability is, and whether or not exploit code is likely to be developed for it within thirty days, not whether or not it’s likely that such an exploit would get used, used widely, put in a product, partially or fully disclosed, posted to milw0rm, or anything else.  Granted, the next section on that page mentions the “release” of exploit code, but what does that actually mean?  It could mean any number of the list of actions that I just mentioned.  Microsoft couldn’t possibly hope to rate (guess, really) whether or not an exploit will surface publicly for a vulnerability and when.  All they have to make a determination with is the technical information about the vulnerability itself which is really only enough to make a determination about how difficult it would be to develop an exploit, not whether or not it will really happen or what the motivations of the person who does so will be toward disclosure after the fact.

Now in addition to all that, if you consider the fact that there are private exploits out there in the big bad scary world, any statistic you care to draw from the public exploit count is completely useless.  Because really, who cares all that much about the public exploits?  Sure they might get used more, but it’s the private ones that I’m far more worried about when considering defense.  Thinking back over the last few months of Microsoft Bulletins, I’m personally aware of a number of those vulnerabilities that have exploits written for them that are still not public, many of which likely never will be.  Granted, I have a more privileged view into this data pool than most people due to knowing some really smart and really talented people, but those people are only a small subset of those out there who are capable, and most of the people I know are not maliciously motivated.  If just my narrow view of what exploits exist shows this obvious difference in public versus private data sets, really, who knows how drastically different these two data sets really are?  How accurate the index is as a prediction is simply an impossible metric to even attempt to calculate.

People should stop trying to use the Exploitability Index as a mystic oracle that can predict the future, and use it for what it actually is, just another metric to consider when prioritizing patches.  Having a metric that indicates which vulnerabilities have a higher probability of having any exploit developed for them, public or private, is useful and is exactly what the index indicates.  It’s an informed classification of what could-be, nothing more.