BlueHat Security Briefings

Hi, Charlie Miller here.  I was asked to come out to BlueHat to participate in a panel discussion about the vulnerability economy and selling exploits and such.  Hopefully the folks who sat through us arguing for an hour got something out of it.  I enjoyed it.

When I'm not out shining a light onto the dark world of exploit sales, I'm usually spending my time looking for bugs in software, particularly with fuzzers.  BlueHat was a great opportunity for me to talk to some guys on the Microsoft fuzzing team.  BlueHat’s reason for being is to bring Microsoft employees together with security researchers, or "hackers".  It can be a really interesting dynamic because traditionally, we are rivals.  People like me try to find and exploit vulnerabilities, and people at Microsoft try to eliminate vulnerabilities or make them harder to exploit.  One thing for sure, it’s definitely easier and more fun to be on the attacking side than the defending side!  But anyway, the funny thing about BlueHat is that there are guys like me trying to figure out how Microsoft people work, how they test their software, how they run their fuzzers, and so on, in order to think of better ways to attack their software--while people from Microsoft are trying to figure out how researchers think, to better defend their software.  It's great fun and everyone benefits, I think.

Hello all, Nate McFeters here to give you a recap of all the fun at Microsoft BlueHat v7.  If you don’t know me, I work for Ernst & Young’s Advanced Security Center and I also blog over at ZDNet’s Zero-Day Security Blog.  You may have also seen me on the conference circuit, as I’ve spoken recently at such prestigious events as Black Hat and ToorCon.  This time around though, I wasn’t brought in to speak at a conference; Microsoft had Rob Carter (also from EY’s ASC) and I come in to discuss some recent vulnerabilities that we’ve discovered with a few third-party vendors with whom Microsoft has tight relationships.  Actually, that’s worth a shout out to Katie Moussouris for being awesome and putting Rob and I in touch with the proper people to get our issues fixed AND bringing us in to BlueHat for our efforts.

Coming to Seattle is always a treat for me.  The hacking/security research community is represented in Seattle like no other place that I’ve been to.  Of course, Seattle did not let me down once again!  On Wednesday, I got a chance to attend the iSec Partners party, celebrating the opening of their new Seattle office, so congrats to all those guys.  After the iSec party, I rolled over to the BlueHat speaker’s party with Billy Rios (former EY ASC guy, now a Microsoft employee, and a BlueHat Speaker) and got a great opportunity to drink free beer and hang out with some industry leading figures, such as Alex (kuza55), Fukami, Sowhat, and Manuel Caballero.

After a long first night, I took care of some work-related stuff and relaxed most of Thursday… that is, until the BlueHat party.  It was a great premise: Put a bunch of hackers in a bar and feed them free booze until closing time… the night before the big show!  Good thing these guys are professionals!

The highlights of the talks for me were:

1.)         Getting to see Alex (kuza55) discuss browser insecurities to a packed audience.  This guy has some really progressive stuff, but what really stuck to me was Alex’s mature understanding of the greater picture, which was truly impressive, even more so from a 17-year-old.  He discussed the need for more transparency from vendors on the standards that the browsers depend upon… nowhere was this more interesting than in the case of Cross-site Cooking and his FindMimeFromData attack.  Alex explained how dangerous the lack of understanding of these technologies are, and how, unless the security community is given more of the bigger picture, we can expect these issues to lay dormant until discovered, and of course, we have no guarantee that it will be a good guy finding it.

2.)         Watching Billy Rios’ and Nitesh Dhanjani’s phishing discussion, which was by FAR the most entertaining and enlightening talk that I’ve ever seen.  The talk was basically a recap of research that Billy and Nitesh got involved in over a year ago, where basically they joined up to the phishing community and realized that it’s not just about phishing, it’s really about identity theft.  They discovered that phishing was just one means of supply to fill the demand for identities in the identity theft ecosystem.  They were able to discover phishing sites, the kits that phishers use, and the sites where phishers sell stolen identities… truly unbelievable.  The saddest thing was realizing just how tech un-savvy these phishers truly are, and then further realizing how huge an impact they’ve caused to the Internet.  If you have not seen this talk, you should absolutely go catch it at Black Hat Vegas. If you have, I’m sure you’ll be seeing it again.

3.)         Manuel Caballero discussed something that originally didn’t catch my attention.  It initially sounded like the same research that’s been put into cross-site scripting attack frameworks, which basically involved using XSS to create a bi-directional communication channel between victim and attacker for exploitation of XSS.  Then I realized what Manuel was really talking about.  Resident scripts have put the fear of God into me.  Whereas a normal cross-site scripting attack vector is great for the site that was cross-site scripted, it stopped there; it couldn’t follow you off-domain.  Manuel’s can.  Scary. 

After the presentations, I was fortunate enough to get included in the IOActive Limo Race after party.  I’ve never been involved in an event that led to as many hilarious pictures as that one.  Specifically, the pictures of Dan Kaminsky, David Hulton, and Andrew Cushman are priceless.  Thanks to Josh Pennell and all the IOActive crew for putting that on -- it was outstanding fun.

All of that and I closed off the week by coming home to Chicago and proposing to my long-time girlfriend, Melissa Radocha (she said yes, thank God!), so it was probably one of the best weeks of my life.  Sorry to all of the media guys like Ryan Naraine and Rob McMillan who I’m sure wanted to join me, but keep in mind, I wasn’t here for media coverage… I just got lucky to steal an exclusive by having some research that Microsoft was interested in!  J

-Nate

BlueHat is not just an event, it’s a community, a network based on relationships developed over time, an integral part of our engineering science and outreach security efforts at Microsoft. As part of the team 'shipping' BlueHat, I spent some time in the speaker lounge – the room where speakers, community and Microsoft folks gather and meet during the conference. It was both fascinating and surreal and we look forward to bringing you more commentary about the event along with video podcasting via the blog in the coming weeks.

BlueHat is rewarding to me because our team is able to help virtual teams form out of traditional rivalries.  Observing Adobe’s response team in discussions with Fukami – a Flash researcher notoriously at odds with the company. Participating in lively discussions about Mark Dowd’s latest research paper. Watching ”aha!” moments happen as product teams and researchers from all over Microsoft met with the researchers focusing on their products. CERTs, major guidance providers and security researchers breaking bread together. Community members (such as, several members of the TESO board of directors) greeting each other in person for the first time, after knowing each other virtually, for years. Legendary researchers in the community engaging in dialog with new up-and-comers like Alex K.

BlueHat also brings home how much security work is ahead of us and the how the asymmetry between attack and defense continues to widen. Bryan Sullivan’s talk highlighted that although we have made outstanding progress securing the operating system, we now have to make that same outstanding progress in the Web space. An environment with development cycles measured in weeks versus years, and one that presents challenges to the application of the traditional SDL. Billy Rios and Nitesh Dhanjani kept us entertained while confirming that phishing is easy, prolific, money-driven and not as funny as your father’s maiden name. All the panelists reminded us that researchers continue to look for vulnerabilities and there are many 3^rd party attack vectors, apart from the OS and core shipped components, even including security products.    

We recognize the need for community-based defense (researchers, guidance providers, CERTs, etc.) as we continue to introduce new folks into the BlueHat network. Thank you to all of the speakers, guests and passionate supporters of BlueHat– we look forward to continuing to evolve and add value to this important community.

It’s our planet – let’s secure it!

Sarah Blankinship

Senior Security Strategist

Cesar Cerrudo of Argeniss here. I was thinking what to write about in this blog post and I decided that this would be a good opportunity to acknowledge Microsoft security efforts by highlighting Microsoft improvements, and also to compare how security is currently handled by the other big software vendors.

While I don't like some Microsoft policies and how some security issues are handled by Microsoft sometimes, Microsoft is currently the software vendor that cares the most about security, and this can be seen in the increased security of their software. It has improved a lot in the last few years. Of course nobody is perfect, and Microsoft software will continue to have security vulnerabilities, but they will continue improving.

My team and I have been finding and reporting hundreds of vulnerabilities to major vendors for the last 6 years, so I guess I have some experience in the subject.

Let’s talk about two of the biggest software vendors. I’m not going to mention their real names. Let’s just say they are Vendor A and Vendor B.

First we have Vendor A. This vendor talks more than it acts. They are always talking about how much they train developers in security, how much they care about security, how they use these wonderful products that find all security issues, and even make and serve coffee while doing it, and blah, blah, blah. But reality is far different from what they say.

Let’s take an example: You report X vulnerability in Y functionality to them, and they will take their time to fix it (and it could take a couple of years sometimes). Furthermore, they just fix the X vulnerability in Y functionality. They don't investigate whether the same vulnerability is present in Z functionality. But that's not all, they only fix your reported attack vector. They don't look for other attack vectors. But wait, that's not all -- the developer will produce a fix that can't even prevent a variation of the reported attack and this fix goes straight to production. I really wonder how this vendor determines when a fix is ready to go into production, since not enough testing seems to have been done.

Nobody seems to notice that the fix sucks, then when the fix is ready, the vendor will inform you they have produced a fix for the vulnerability in software version 1a, 2a, and 2b, and that they will release it at some future date. When the fix is released, you test the fix in the corresponding versions and then you realize that there is no fix at all in version 1a and that the fix on version 2a and 2b only works when trying to exploit the vulnerability in the exact way you reported. If you change the exploit slightly, then the fix doesn't work, so you contact them again.

You go through the same process one more time, and then a new fix is released. With the new fix, you find out again that the fix in version 1a is not present, and the fix in version 2a works well, but the fix on version 2b still doesn't work with exploit variations. The same process goes on again and again, until some day after 2, 3, or 4 fixes, the vulnerability is finally fixed on all the affected software versions.

Unbelievable, eh? Well, that is how Vendor A is currently producing security fixes. Vendor A is clearly many years behind Microsoft when it comes to security.

Let’s talk now about Vendor B. This vendor has a lot of experience producing software, and like Vendor A, it is one of the big vendors. Vendor B seems to produce good fixes for security vulnerabilities, but they have a bigger problem. It seems their developers are not very familiar with security.

For instance, the latest version of one of their most popular software packages still has stack overflows that you can find in 5 minutes. It also has everything open by default, and by changing just one byte in software protocol packets you can easily crash the software.

You can tell that some developers don't really get security and that they have the final decision when to produce a fix. If you report a vulnerability related to some functionality that's accessible to all users by default, and that can be abused to perform evil actions, they will just respond that the functionality is used by their customers and that it can't be abused. And that's it, developers don't realize that their competitors’ software has restricted the same functionality by default for security reasons a long time ago. Vendor B doesn't seem to have a security response team, since most of the time, reports are handled directly by developers or software managers. I could continue with more examples, but I think you get the picture. What is weird is that Vendor B some time ago acquired an important security consulting company that had really skilled people. I wonder why these people are not helping to improve their own software security, instead of doing cool research on new attacks on software from other vendors and providing external consulting services in order to help other companies. Weird.

Again Vendor B is clearly many years behind Microsoft when it comes to security.

I have criticized and pointed out Microsoft security problems many times and I will continue doing it when it's necessary, but I really think that Microsoft is ahead by many years in security, compared to other vendors. Microsoft is leading security efforts in the software industry.

I have seen Microsoft make huge improvements over time. Some Microsoft products’ previous versions had dozens of vulnerabilities, but now the newest version has almost no vulnerabilities. I haven't seen that in any other products from other vendors, and this is something really amazing that nobody seems to notice.

I think other vendors will improve over time and that Microsoft is indirectly helping them with the knowledge and research it generates. By looking at Microsoft, these other vendors could get an idea on how to get better at security.

BlueHat is another innovative way Microsoft has developed to improve security. If you have something to say that will help to improve security in its products, then Microsoft will listen to you.

As I always say: “Vendor A and Vendor B are very lucky because they never had a worm.”

-Cesar

Hey, Andrew Cushman here.

BlueHat v7 May 1^st and 2^nd has another great lineup of leading external security researchers and internal Microsoft engineers.  This spring’s event is titled Up High, Down Low, Too Pwned and has two themes – web application insecurity and architectural security challenges. We kick it off Thursday with the exec day, then follow that on Friday with the general sessions for engineering, support and sales teams.

The web app/browser track includes a session from Alex "Kuza55" K. of SIFT in which he shares his thoughts about "Web Browsers and Other Mistakes." A star in the security research community and new to Microsoft, Billy Rios makes an inaugural BlueHat appearance with his talk, "Bad Sushi: Beating Phishers at Their Own Game."  And Manuel Caballero has joined forces with the inimitable Fukami to pull back the cover on Silverlight in the talk: "A Resident in My Domain, plus, Unweaving Silverlight from Flash.”

Cesar Cerrudo anchors the architectural challenges track. His talk “Token Kidnapping” demonstrates how hard it is to get everything right in complex systems. We’ll also hear “Attacking Anti-Virus” from Sowhat of Nevis Labs.

We’ll wrap up the day with a couple of special sessions. We have a number of diverse guests lined up for a panel discussion on the Vulnerability Economy. Following that, Bryan Sullivan, who joined Microsoft about 6 months ago, will talk about his impressions and experiences and respond to the allegation that working in security at Microsoft is the sixth worst job in the world. He will go so far as to state that it is in fact the second best.  J  You’ll have to tune in to the upcoming video podcast interviews to find out what else made his top ten list.

The goals for the seventh edition of BlueHat remain the same:

- Expose senior product leaders and front line engineers to the threats, attack tools and methodologies used in the real world; taking the security threat from the theoretical/intellectual level of, “I understand what a buffer overflow is,” to “OMG that’s what it’s like.”  BlueHat connects with execs and engineers at a visceral level and *really* brings the message home.

- Expose security researchers (and the security community) to Microsoft engineers and business leaders. BlueHat gives us a chance to open up on our home turf and give researchers an opportunity to interact with all levels of the organization. They get to experience first-hand that Microsoft does have smart, passionate engineers that do care about security.

We continue to expand the BlueHat blog and the TechNet site to keep you up-to-date on the happenings at the conference. We’ll update both regularly with new blog entries and video podcasts.

-Andrew

Hello!  My name is Vinnie Liu.  I am a BlueHat speaker, and the Managing Director at Stach & Liu, a security consulting firm whose primary practice area includes helping organizations establish effective application security programs.  A key component of every application security program is the use of tools and experts.  In this post, we discuss the relative strengths and weaknesses between tools and experts, and by doing so, we also learn how these software security resources are best applied in an organization looking to become more proactive with their secure software development lifecycle.

As an organization builds their software security program, they will inevitably find themselves asking the question, “do I hire a consultant or do I buy a tool?”  Unfortunately, the simple act of asking this question is limiting – it poses a false dilemma as the two options need not be mutually exclusive.  Our recommendation, and what we’ve seen from our smartest clients, is the use of both tools and experts.  To understand why, we need to look at what we’re up against and what we’ve got going for us.

Let’s start by saying that we want to assess an application that we (magically) know contains three vulnerabilities.  In our example, we’ve plagued our application with the following:

1. Directory indexing has been enabled.

2. SQL injection exists within the password reset workflow process.

3. A password reset design issue exists.

A couple more pieces of information are needed here.  First, the last two vulnerabilities occur on the same page, and this page cannot be reached without first passing through a previous series of pages.  Second, there are several design issues in the password reset page, and we’ll leave it as an exercise for the reader to identify the password reset design problems.

When examining our available resources, we can break down our first category, tools, into two varieties – inspection tools and functional testing tools.  Inspection tools perform software inspection at the source code level, e.g. Ounce and Fortify, while functional testing tools perform application review against a live production site, e.g. WebInspect and AppScan.  Our second category is the human brain, which we won’t be breaking down in this article.  So how well do these three tools perform when trying to identify our three security issues?

 Application Functional Testing Tool – The functional testing tool will quickly and reliably identify the directory indexing issue.  However, because the SQL injection vulnerability requires the application state be at a certain point in order for the issue to expose itself, the scanner would likely have difficulty identifying this issue on its own.  The functional testing tool would never detect the password reset design issue.

Software Inspection Tool – Our static analysis tool will be able to quickly identify the data flow path from source to sink for the SQL injection vulnerability despite it being embedded several pages deep into the application.  However, it would never detect either the directory indexing or design issue.

Expert Software Analysis – An expert analyst would be able to detect all three of these issues, and she should be able to detect the software design issue immediately upon seeing it.  Unfortunately, the time required for the analyst to reliably identify the directory indexing issue would be several times more than that required by our functional testing tool.  The same time issue would apply for our SQL injection issue.  Though manually tracing through the code from sources to sinks is possible, it would be extremely time consuming – with expert analysis, time is money, so this approach becomes financially infeasible.

If we look at how these vulnerabilities can occur in our software development lifecycle, we see that they are introduced in three distinct areas – essentially whenever something is being built or created.  Combining our knowledge of where an issue manifests itself with the tool best-suited to identify it, we notice the following:

Broadly, we can conclude that functional testing tools are best used to identify misconfiguration problems and perform brute-force tasks like testing for directory indexing, unnecessary files, and so on.  These tools can reduce the amount of time necessary to perform an assessment by taking care of the tedious but necessary iterative tasks.  Inspection tools are best used to build dataflow representation of the software and to identify certain vulnerabilities, which tend to be issues such as SQL injection and XSS, whose root cause is input validation.  Expert analysis is well-suited for identification of design level issues.  In addition, expert analysis is a must for validating the results from the functional testing and inspection tools.  This is because automated tools can generate errors – false positives and false negatives, and by design these tools can never be free of errors (a discussion far longer than this one). 

Our expert is also necessary because she can synthesize the software’s intended functionality and contextual information – a process which the current tools are not capable of performing.  Yet despite the necessity of the expert, using purely expert approach is infeasible because experts take longer at many tasks than automated tools do.  Like digging a well with a toothpick, you shouldn’t be paying a consultant to guess file names in a browser window or to manually recreate dataflow diagrams of an application.  Instead, tools should be used to automate these repetitive tasks.

By analyzing the relative strengths and weaknesses of tools and experts, we come to the simple realization that yes, you should use both types of tools alongside expert analysis in order to develop an “effective” software security program.  You’ll need a functional testing tool, but don’t expect it to find issues in areas that it’s not designed to find.  You’ll need an inspection tool as well.  You need to have an expert in the loop, but apply where needed and not in excess.  

The right tools, the right way, at the right time.

Cheers,

Vinnie

Hey everyone, h1kari here. Katie invited me to do a guest post on the BlueHat blog and so I thought I'd rant a little bit on some ideas I've had with how crypto best-practices relate to other areas of security that may hit closer to home for you guys.  My current interests are in finding areas of computing that would be a lot more useful if they could only be run faster, so I'd like to hear from you about your experiences and what takes up all the idle time on your processors. Please send me feedback on these ideas and let me know if these ideas are useful or just a bunch of BS.

COMPUTATIONAL FEASIBILITY

Many people who are familiar with cryptography know that ciphers are rated by their bit-strength. This is an easy metric to determine which algorithms are appropriate for the data that you're trying to protect. In many ways, other areas of threat modeling are approached similarly, estimating the worth of what you're protecting, the cost for the attacker, and meeting a balance somewhere between security and functionality.

When it comes to cryptography, there are only two ways to break a crypto system:

* Find a shortcut

* Try every possible key

Good crypto systems force you to only use the latter method and make sure that there are enough possibilities such that it's improbable for an attacker to try all of them before the data isn't important anymore. This, however, is measured by the amount of time the data should be kept secret and the data's perceived value to the attacker.

With crypto we end up with computational power doubling every 18 months according to Moore's Law and also the value of the data usually diminishing as time goes on. This is a standard security model that many people rely on but don't really realize. Some of the problems with systems that rely on this model are that:

* They don't even realize that they're using this type of model

* They don't employ a high enough bit-strength to thwart attackers

Here are some examples:

FUZZING

Many software applications are fuzzed every day and many stand up to the fuzzing just because the attackers only run their fuzzers for a few days and then give up. Occasionally, attackers will randomly stumble upon a bug, but how many are missed in the whole process? Nowadays, with more intelligent fuzzers that use constraint solving and tracing to get good code coverage, you oftentimes need to apply many rules to limit the scope of the states in the program that you're testing. With many applications it's nearly impossible to get 100% coverage in a reasonable amount of time.

If you were able to get full coverage of all possible program states, would more bugs be found? If an attacker were able to do this, would this suddenly be a threat? Also, if you ended up in a state that you weren't sure was exploitable, what if you could solve whether it was or not? If we had nearly unlimited computational power, would we be able to mathematically prove the security or insecurity of an application?

IDS/VIRUS DETECTION

Most of the IDS market consists of software that requires an updated list of signatures to see if a payload looks like a known exploit. Some companies have experimented with solutions that will simulate the payload running against the target and use intelligent heuristics to determine if the payload behaves maliciously or not. Most of the effective solutions use some amount of processing between these two extremes to try to detect known static, dynamic or polymorphic, and/or 0-day payloads. Usually with large enterprise-class networks, the best that you can do is to run a signature-based IDS system in order to keep up with the demand of the speed of the network.

If we were able to thoroughly analyze all payloads that came into the network, would attackers still be able to exploit our systems? Could we 100% prove on the fly whether a payload was malicious or not if we had enough computational power? If we solved the first fuzzing problem and applied it to all of our network-exposed software, would IDSs even exist anymore?

REVERSE ENGINEERING

Oftentimes reverse engineering requires much more computation than engineering. Many applications that use obfuscation require a lot of analysis to determine what actually goes on internally. This also applies to hardware where chips are assumed to be secure because it would be difficult to reverse engineer chips.  However, many companies out there are nowadays using image processing techniques to reverse-engineer wafers and circuits for even the most advanced chips out there.

Most of the anti-reverse-engineering measures rely heavily on security through obscurity, which has long been proven to be a bad countermeasure that mostly relies on an assumed lack of determination on the part of the attacker instead of using an actual computational metric. Many products’ anti-reverse-engineering measures fail because a determined attacker only takes a matter of hours to figure out the obfuscation technique and break the entire system.

How long do you want your IP to stay secure? How much would it cost your company if your IP were to be reverse-engineered? How long would it take a single determined attacker to reverse-engineer it? What sort of budget would the attacker require?

CONCLUSIONS

With all of the security models in use, there is an inherent trade-off between what you think th