Why pick on poor helpless donkeys. They can't defend themselves... or can they?! Donkey On Trial. In this wonderful example of the United States legal system a donkey has been presented as a witness at a trial. Sadly no outcome resulted as the two disputing parties settled their differences while the jury deliberated.
Attacks have come a long way since the "target of chance" Internet that many of us grew up in. Attacks, and attackers, have evolved drastically. Long gone are the days of running a scanner for a particular vulnerable service and then hitting it with a recently downloaded exploit. In other words the script kiddies are going the way of the dodo bird. If they aren't going extinct, they certainly aren't the major thorn in the info-sec teams side any longer.
I don't tend to follow virus and trojan trends very closely. I usually live in the application space and not in the post compromise and/or malware world (yet). That being said I just read this very interesting post at The Symantec Security Blog by Elia Florio. The amount of resources and level of expertise it takes to work through the creation of a trojan/virus of this nature is not trivial. This particular piece of malware includes p2p networking, bot net management, spam sending, DDoS attacks, data gathering, and continued distribution of the trojan itself. Those things aren't ALL that impressive or new, but the fact that the latest variant includes the ability to detect and shutdown virtual machines (honeypots or malware analysis sandboxes), a new rootkit driver using randomly generated names, and process injection using XOR obfuscation leads me to believe this is being created by organized crime of some sort as opposed to your common bored teen. (*I've been wrong before and since this isn't my area of expertise I welcome comments that state otherwise*).
Needless to say there is clearly some money to be made in the area of malware creation, management, and distribution. I guess this is nothing new to most of you, but sometimes it helps to state the obvious. The world of the attacker has certainly evolved a long way over the last 10-15 years. These are now the days of targeted attacks, exploit the weakest link, possibly extort some cash, and $pr0f1t$. I wish the information security operations people the best of luck, you are going to need it.
I find myself repeating a certain description to the majority of my clients. That is:
"Penetration testing is a function of time. An attacker has the luxury of infinite time, and a penetration tester only has as much time as the clients resources will allow. Finding vulnerabilities ends up being a curve, discovered vulnerabilities over time, in which there is a ramp-up phase, a steady incline to a peak, and finally a drastic drop. The point at the top of the curve (and possibly just after it) is the point of of diminishing returns. This is where the amount of resource investment outweighs the chances of finding additional vulnerabilities. THAT is the amount of time the client should want me to test the application."
So that being said. How does one determine this exact point of diminishing returns. Is there a way in which we can quantify the size and features of the application accurately enough to predict the height of this curve in man hours?
This concept is sometimes easier to grasp if we focus on one particular application type and then attempt to extrapolate those same ideas to other targets. Let's look specifically at web applications.
In the past I have seen people attempt to use the number of static and dynamic pages to estimate size and thus time. This is a good idea, but falls down when those pages have a large number of input fields making the scope grow significantly and without warning. Alternatively there could be hundreds of pages, but those pages contain a minimal amount of dynamic functionality and little to no input fields. Now we end up with a gross over estimation of the size of the application. I've also seen people attempt to determine size and time by taking a high level swath at the amount of functionality within the application. Questions such as "how many sections of independent functionality are there in the application?" end up with vague estimates that can be wildly off the mark as well. This method also relies upon the scoping person's experience level to know what "Application foo has 3 sections of functionality, funds transfer, account management, and profile management" really means in terms of time. Last, but not least, I've also seen the LOC (lines of code) attempt at determining amount of testing time required. When analyzing an application for amount of time required for testing, lines of code usually doesn't play that much of a part. I've seen applications with a huge LOC number that really doesn't have much of a threat landscape and I've seen code that is extremely dense (aka low LOC) and has an immense amount of functionality. However, LOC can many times be used to determine a rough guesstimate of application complexity, and as we all know code complexity has been proven to have a direct correlation to vulnerability density (take this research with a grain of salt).
Now that I've rambled on for quite a bit, I want to know if any of you lovely readers have an idea for a way to properly quantify application size in an attempt to ACCURATELY determine the amount of time it will take to get to that sweet spot of diminishing returns. I'm tired of overcharging some clients one week and then not delivering a complete test because we ran out of time the next. My initial thoughts are a mix of all of the above crunched numerically to determine a length of time estimate (hopefully an accurate one). Any takers?!
It has now been shown that 17 is the least random number! Figure that one out. OK.. so I admit it, I'm messing with you contextually here. This website talks about two interesting reports (Here is one example) that notes that human beings are very poor at picking random numbers. After sampling 347 (not nearly enough I know) people, the most commonly picked number is "17" with second place being "7". The website also shows that more people will pick an odd number than an even number. People also tend toward prime numbers. Isn't it funny how the human brain is wired?
So what does this have to do with security? Passwords and PINS. We all know that passwords and PINS are typically easy to guess and/or brute force. This might actually be a useful piece of knowledge when attempting to automate PIN and password guessing attacks. It's also demonstrates a possible way to automate attacking systems that allow users to choose "reminder values" for when they forget their password.
OMGWTFBBQ is an understatement. I guess it never really occurred to me that putting "Donkey On A Waffle" in conjunction with "Penetration Testing" into the Interwebs would bring weirdos to my site. I checked my referrers today and someone actually searched for "Donkey Penetrations" and came to this site!. This site has nothing to do with "Donkey Penetration" you sick freak. Go find your beastiality fix somewhere else!
I made my plans to go to Shmoocon about a month in advance. I picked up a ticket from Jodan who had already purchased a ticket before he was roped into working the Hack or Halo competition with my brother wxs. [Thanks Jordan!!]. I picked the ticket up for $150 and, for that price, the conference was great. If I had to pay much more than that out of my own pocket I may have actually forgone the talks and just hung out for the parties. I was able to spend a fair amount of time with previous coworkers, current coworkers (who I don't get to see very often), and a number of folks that I communicate via email/blog/irc/silc only. I won't list them all here by name, but it was great to see the faces for the first time and/or once again.
Impressions:
My overall impression of the conference this year was that it was somewhat low on the technically inclined talks. There seemed to be an overwhelming lack of highly technical presentations this year. This could be a function of my level of understanding having grown in the last year or quite possibly we, as a community, are getting to the point where we are exhausting the interesting research for presentation at conferences such as this. Hopefully it's the former. We also might be seeing the effect of the commercialization of the market as a whole and people doing their research for companies instead of "hacker" conferences and self promotion. Ideally, we will see a reversal of this in the next year (*crosses fingers*).
Having attended all three Shmoocon conferences I can deffinitly say that this was the largest conference to date. The rumour mill said attendence and tickets sales broke 1100 people. I'm not entire sure of this number, but it doesn't sound far off from what I saw. The venue is a fantastic hotel right in the heart of downtown Washington DC. The location has every ammenity known to man (none of which I took advantage of) and a great conference area. This year they put the Shmoocon talks in an area all it's own so that we wouldn't have to mingle with the non-infosec related folks. We still managed to overrun the hotel bar and ended up spilling into the streets in front of the hotel in mass numbers. The conference security team was top notch, the periferal events were all great to see (Hack or Halo in particular), and in general the mingling and networking was loads of fun. I tried to make as many sessions as I could and even managed to get up at the latest 8:30AM each day of the conference. The talks will eventually be released as torrents for free download. I'll use them to catch up on any speakers I didn't get to see this time around.
Sessions:
Some of the thoughts for each attended session are listed here.
3:30PM - Bruce Potter Shmoocon Introduction and Mini Rant
-Nobody cares about security other than security people. This was the general takeaway from Bruce's introductory rant. By and large I believe he may be correct. The only people that really care about security in business today are the people that are tasked with it. The people that HAVE to care. That includes your security administrators, your CISO, and in general anyone who has to deal with security on a day to day basis. Now don't get me wrong, CEO, CIO, Marketing, ... they all care about security as well, but again ONLY when they have to. When their name hits the cover of the New York Post, they care, when they are required to divulge details of a huge identity theft occurance, they care, but when it comes to daily activies and the security of their data, they really couldn't care any less. This is quite a sad state of affairs, but to recognize this reality will allow us, as security conscious people, to work around the political issues and generate awareness and fix problems in other ways. If we recognize the business reality of today, hopefully we can use that reality to our advantage.
4:00PM - h1kari (Dave Hulton) - Hacking the airwaves with FPGAs
-This talk boils down to using FPGAs to increase the cracking speed for crypto cracking. Demonstration of jc-aircrack to crack WEP in very short times. When cracking RC4 keys using a 15 cluster of FPGAs you can reach speeds of 180 million cracks per second. This can result in a 40 bit key being cracked in < 100 minutes (even less with birthday paradox). He also demonstrated cracking of FileVault encrypted stores on MacOSX using FPGA for speed bumps up to 200/sec to 3,000/sec. Bluetooth pin cracking in seconds to minutes using FPGAs. Overall this was a great talk. Financially, this solution is out of range of your average security hobbiest, but is deffinitly within range of dedicated attackers who need rapid cracking of encryption.
4:30PM - Eoin Miller and Adair Collins - Auditing Cached Credentials with Cachedump
-Cached domain creds stored in the registry.
-Left part way through. Didn't appear to be anything cutting edge or new, just simply dumping the cached passwords and then cracking them using Cain & Able or John the Ripper. This just wasn't my area of focus.
5:ooPM - Adam Shostak - Security Breaches are Good For You
-Does disclosure impact stock price? Is disclosure of a breach a bad thing or a good thing for A> The Company disclosing B> The companies stock price C> The general public. Discusses some myths of security data. The 80% insider assumption? Is it real? Nobody knows. Interesting talk, but there is still lots of research to be done in this area. Quantitative data is difficult to come by.
5:30PM - Johnny Long - No Tech Hacking
-The usual fantastic Johnny Long talk. Johnny once again wows us with the easy and baffles us with bullshit. I'm just kidding. Johnny is an amazing speaker, and as I mentioned to him after the talk, he could be up there talking about a "terd in a punchbowl" and everyone would be riveted. His talk pointed out painfully obvious no tech hacking techniques. These techniques can be as effective (if not more so) than the high tech attacks, and require a far lower number of effort points. Johnny demonstrated via photographic show and tell, many of the ways to identify people, gather intel, and generally understand more about your surrounding environment. I highly recommend you see Johnny Long next time his circus comes to your neighborhood.
10:00AM - Vulnerability Disclosure Panel
Katie Moussouris Symantec Vulnerability Research
Rohit Damankar - ZDI
Chris Wysopal - Veracode
Dave Aitel - Immunity Sec
Window Snyder - Security Something or other Mozilla
-Excellent discussion but as always when disclosure is the topic there was not a single answer. Mayhem ensued and topics were flying. Ratholes were found (as expected) and no hurdles overcome. The talk was one of the best non-technical discussions at the conference, however it could have gone on for at least a half a day. Having seen the moderators list of questions ahead of time, I really wish it would have gone on for at least a half a day. One of the questions that wasn't addressed due to time was "how is running a vulnerability sharing club" a safe, ethical, and moral business practice. I really wish we could have seen Dave Aitel address that one directly in front of the crowd. Otherwise, this talk was fantastic and a great way to spend an hour!
11:00AM - Web Application Incident Response
-Presmike, Cygnus, F1sh
-Again I'm prejudiced as I did a pre-read of this talk for f1sh et all the night before. In their defence they were accepted to speak a whole 4-5 days before the conference started. That's not nearly enough time to pull together a super-preso. They did a great job with the time they had. The overall idea was, like any incident response situation, being prepared will make all the difference in the world. The question then becomes, how do you prepare differently for a web application incident than a typical host/network forensic experience. Logs, logs, logs! That was the biggest takeaway from this talk. There were a whole mess of other good points too, but make sure you have good and secure logging! You can't live without it.
1:00PM - Billy Hoffman - Spi Dynamics - Javascript crazyness
-This was one of the more hyped up talks of the conference. Billy's discussion was essentially a mashup of known (and somewhat new and novel) javascript based attacks against the client browser. The new and cool thing was the tool, Jikto, that he created to esentially make it all seemless and easy. In a nutshell it allowed an attacker to create and control a "bot-net" over the web (I'm way over simplifying here). The hype came from a few blogs, the week before his talk, essentially calling Billy out for releasing a tool that could only be used for nefarious purposes. In the bloggers eyes Billy was doing an injustice releasing a tool of this nature and should reconsider it's publishing. He "accidentally" showed the link to the location of the tool when viewing some page source, so I'm sure it was downloaded at least once or twice during the course of his talk. I thought the talk was interesting and the concepts were pretty slick. Job well done Billy!
2:00PM - Raven - Fuzzing Backbone Protocols
-Raven discussed some backbone protocol fuzzing she has done/is in the process of doing. She isn't far enough along in her research for this talk to be truely fruitful. What I did gather out of the talk, however, is that there hasn't been nearly enough fuzzing of the protocols to date. If FX can fiddle a single bit while goofing around and find a big DOS, there has to be a lot more low hanging fruit out there. This could be worthwhile in a year or two.
3:00PM - Windows Mobile
-This talk should have been named cracking 101. The main thing I learned was a bit about the underlying hardware of his test devices. The talk itself was more about basic software cracking than about anything specific in Windows Mobile. I have given the same talk, just focused on win32 binaries in various venues. I didn't stay for the whole thing, so maybe he got a bit more detailed at the end. If he didn't, don't watch this talk expecting to see anything really windows mobile specific.
10:00AM - Home-grown Crypto aka Taking a Shiv to a Gun Fight
This talk was focused on real world crypto implementations in products on the market today. Many times the developers have had broken implementations of crypto, home rolled their own crypto, and/or had horrible keys and key management strategies. This was a very interesting talk. Having done a number of product and application penetration tests I have seen many of these same issues in the wild. The general takeaway from this is two fold. Don't roll your own crypto and pay detailed attention to the implementation of your algorithm of choice.
Conclusions:
The overall conference left me wanting for something technical, something interesting, and something new. Shmoocon just didn't have that this year. However, many of the talks I saw were both thought provoking and interesting. They may not have been overly technical or difficult to grasp, but they deffinitly gave one food for thought. I look foward to seeing what some of these presenters have up their sleeves in a year or two down the road. Shmoocon again ended up being an excellent long weekend and I look forward to the next chance to party with you all.
