Microsoft BlueHat Blog

Hi, this is Scott Stender from iSEC Partners. I recently had the privilege of speaking at Microsoft's BlueHat event in Brussels on the topic of securing legacy systems.

With all of the recent coverage on the need to secure our networked systems -- national, corporate, and individual alike -- I felt that the BlueHat event was a good time to shine the spotlight on those little-loved, perhaps little-known systems that keep our plugged-in society working. Those are the legacy systems, the giants on whose shoulders we stand in order to build the rich computing environment we enjoy today.

I had hoped to discuss, perhaps defend, the following points with the attendees:

· Legacy systems will always be with us. After all, we create more of them with every completed software project.

· The attacks leveraged against our systems are always changing and growing more sophisticated. Those of us on the defensive side will need to be equally sophisticated and tireless in our response.

· We software engineers need to develop and improve the means to secure our existing systems, just as we already do when developing for new systems.

· Those who maintain the budget for software systems not only need to plan for the effort required to build secure systems, but also to plan for the effort required to secure and maintain these systems throughout their lifetime.

However, as is often the case in these gatherings, I was surprised by the diversity of opinion in the room.

What I thought were going to be the most challenging statements did not stir the attendees. Most notably, it seemed to have been accepted that we will need to evolve the security of our existing systems rather than "start from scratch" for the majority of our systems. The benefits of starting anew are often far exceeded by the drawbacks. For instance, there is potentially a large amount of acquired wisdom in a system (learned through hard years of bug fixes and real-world operation) that could be lost when starting anew.

Instead, the attendees challenged me with the following topics:

· How do we show progress and demonstrate value for the resources spent on securing our legacy systems? After all, it is hard to make the case that we need to spend money on something that was deemed "completed" years before.

· How do we manage tightly-regulated systems, where certifications limit the changes that can be made? Attackers move faster than certifying agencies, and that opens a window for attackers.

I am afraid that easy answers to these questions are elusive, and those found are unlikely to hold in the general case. That is what makes venues like BlueHat important; because by discussing our experiences with peers in the industry, we come closer to understanding the potential solutions to our hard questions and the scenarios in which these potential solutions could be applied.

It is my hope that I made a good case for the need to secure our systems at their core, and that perhaps a few attendees were moved by this software engineer's view of how to address our quickly shifting attack landscape. I left BlueHat with a greater appreciation for the experience of those who work in different industries than I do, under different regulatory pressures, and with varying levels of support for security initiatives. Together, continually improving software combined with technology to help us improve security immediately, we may be able to address the challenge of securing our legacy.

- Scott Stender, iSEC Partners

Share this post :

Hi! Manuel Caballero here.

I had the pleasure of penetration testing (pen-testing) the previous versions of Microsoft Silverlight, and now, for the last three weeks, I’ve been playing around with the beta version of Silverlight 3. When I say, "the pleasure", I really mean it. Playing with Silverlight means to play with a plug-in that, from a security point of view, was born being already mature. It is obvious that the Silverlight team invested a great amount of time building Silverlight in such a way as to avoid a lot of security issues that other plug-ins had in the past. No question about that.

When you read about the security in Silverlight, undoubtedly you will find the term "Transparency" in reference to the Transparency Model (a concept borrowed from the .Net Framework 2.0). However, I want to borrow the term "Transparency" and use it from a completely different point of view.

I’ve been playing with the communication between Silverlight and its host, and the word “Transparent” came to my mind almost on every try. Let me explain why. When speaking about communication, Silverlight seems to be as secure as its host. My pen-test was done using Windows Internet Explorer 8 as the host and the plug-in was the Silverlight 3 Beta.

From a communication point of view, having the Silverlight plug-in on a page is like having another piece of JavaScript code. How safe is the JS code executed using Silverlight? It is as safe as executing JS straight from the browser. That’s why I say that the communication between Silverlight and its host is transparent -- because it is as if Silverlight were doing nothing at all, except for executing JS code just like the host would do.

Even if that seems to be obvious, it is not. Let’s take, for example, a well known plug-in: Adobe Flash. Flash has many ways to communicate with the host (ExternalInterface.call, fsCommand, Get/SetVariable, etc.) but legacy methods like getURL remain there, ready to use. Now, what is the problem with methods like getURL? The getURL is a method to load a URL in a window, frame, or IFRAME. The historic problem was that the implementation (the binary code used to load the URLs) was parallel to the one used by the browsers. It means that Flash bypassed the safe-implementation of the browser to load URLs, making the restrictions imposed by the host useless. For example, popup blockers could be bypassed using the getURL because the method to open a new window was not in the complete control of the host. In other words, using the Flash getURL method completely fooled the browser, bypassing a lot of the restrictions. Here’s a short example of an xDomain:

getURL("javascript:alert(document.cookie)", "IFRAME_NAME", "POST");

The getURL’s JavaScript code was executed inside the IFRAME with no domain restrictions at all. The xDomain policy of the browser was completely bypassed allowing the evil site to access the full DOM of the foreign (good guy) site.

This version of the xDomain worked great from Flash 7.x to Flash 9.0.115.0. It was fixed by Adobe when patching a different issue with the same root cause, but the bug comes long before Flash 7: a simple variation (GET instead of POST) used to work in older Flash versions.

To make the story short, the plug-in introduced a way to execute JS in the browser that was independent of the browser security policies. In fact, it bypassed many restrictions imposed by the browser. So why do plug-ins need to introduce new ways to load a URL when the host itself already has safe-methods to do that?

The getURL would have been much better if it only called the original browser method to load URLs, and not a native one. That, IMHO, would be transparent -- like not being there at all.

Now, what is the difference with Silverlight? The difference is clear: Silverlight calls the safe-browser methods straight, except in some rare cases where it parses the data before calling those same safe-browser methods. From a communication point of view, Silverlight is just a servant of the browser. If the browser is safe, so is Silverlight.

Let’s see two clear examples:

Example 1

One of the ways to access the host with Silverlight is through the HtmlPage class. For example, an HtmlPage.Window.Alert ("Hello") in Silverlight will call the alert method of the window object in the browser. It will not call the User32!MessageBox nor the MessageBox.Show of the .Net Framework. It will really call the alert method of the browser. In fact, if we override the original window.alert() in the host, Silverlight will call the new/overridden version of it. That’s good. That means that Silverlight is doing exactly what it has to do -- call the alert method and nothing more. No checks, no reinventing the wheel, no funny stuff. Just call the alert method that is already coded in the browser!

So, if we override the alert method in the browser using JavaScript:

window.alert = function(strText){document.write(strText);}

And then call the alert method through Silverlight:

HtmlPage.Window.Alert("Hello");

The result will be a document.write("Hello") in the host window. Exactly what is expected from a “Transparent” plug-in. The same happens with other methods such as Eval, Prompt, etc.

Example 2:

Now, to see how far this goes, let’s consider a scenario where the communication between the host and Silverlight is closed. We can do that by setting to false the enableHtmlAccess param in the OBJECT tag:

<object data="data:application/x-silverlight," […]>

<param name="enableHtmlAccess" value="false" />

</object>

Imagine that Silverlight is in a banner ad. So when the user clicks on it, the advertiser wants to open a popup window with their homepage inside. Because communication is closed, you can’t call the host native methods. However, Silverlight developers added a simple way to allow the plug-in to open a popup window (besides the HyperlinkButton which is a different story). It is the HtmlPage.PopupWindow() that works only when the AllowHtmlPopupWindow param is set to true or html access is permitted.

<object data="data:application/x-silverlight," […]>

<param name="AllowHtmlPopupWindow" value="true" />

<param name="enableHtmlAccess" value="false" />

</object>

From now on, the Silverlight object can call and successfully open a popup window using the HtmlPage.PopupWindow() method.

In this scenario, it seems that it would be logical for the Silverlight team to open the popup using a native method (just like the getURL in Flash) bypassing browser restrictions. I mean, step in the shoes of the guy who coded the HtmlPage.PopupWindow method. I’m sure the idea of forgetting about security for a second and "just open the damn popup window with whatever handy method I can" was in his mind. However, the Silverlight team has chosen once again to lessen the chances of new security bugs being introduced in the host by using the browser method.

Check it by yourself. Let’s override, via JS, the open method of the window object:

window.open = function(a, b, c){alert(a + ", " + b + ", " + c);}

Now disallow communication between the host and Silverlight, set to true the AllowHtmlPopupWindow, and then call the PopupWindow() from Silverlight:

HtmlPage.PopupWindow(new Uri("http://www.cracking.com.ar"),

tbHyperLinkTarget.Text, new HtmlPopupWindowOptions());

Enjoy the alert instead of the popup J.

So even when all bets are off, Silverlight plays by the rules and does only what is necessary to get the job done. That, IMHO, is very good!

Manuel Caballero.

Independent Security Researcher - http://www.cracking.com.ar

Share this post :

What a great time to start thinking of travel – the weather is fairing up, June is here, and fortunately for me, I have a chance to take the driver seat again at another BlueHat conference! This time it’s in Brussels and I’m really looking forward to talking again about one of my favorite topics (eCrime – technology and business), as well as networking with the Microsoft gang and their European counterparts.

Talking about technology and business, dealing with computer security these days has never been more challenging than when looking at how a business should protect itself. In these days of proliferation of Web 2.0 applications, and on the other hand the relative standstill of the major security vendors in terms of innovation when it comes to mobile and dynamic code, the security gap is only widening. When a business takes the time to look at what kinds of threats it needs to deal with, and with the available precautions and protections it applies to these threats, the picture is pretty grim.

Nevertheless, just this step of mapping out the threats is probably more than what most businesses do (the common M.O. is unfortunately, “ignorance = bliss”). Having said that, there still are a lot of solutions available that can provide an answer to the gap that has been created between the threats and their security solutions, they just aren’t available yet from your common AV vendor who used to be the one to provide the all-encompassing anti-X miracle drug for your security issues.

Let’s take a closer look at both sides of the fence – the threats and the solutions required to counter them.

Threats first – as mentioned earlier, eCrime has become a major economic force to be reckoned with. The reason for the pervasiveness of this threat is the fact that eCrime has adopted businesslike operating models, and as such, ditched the older ad-hoc attack models employed by early attackers on the Internet. With an improved operational model, and a clear target in mind (ROI), the eCrime groups have managed to create a lively market for knowledge, tools and goods (e.g., stolen data that could be used for profit making). From there on, it was just a matter of time for such a mini-economy to grow and evolve a threat model that surpassed most countermeasures on the market. Especially in times when the common means of protection have been highly commoditized and were made available for the developers of the attacks for testing. This situation was a practical petri dish for technologies such as dynamic code obfuscation (huge during 2007 when it bypassed all AV tools), IFRAME injections (building on the notion of invisible layout elements with malicious code in them), malicious XSS (or cross-site scripting) in search engines, and attacking popular sites (based on the latest fad) to hit many potential victims. With a distribution network that is incentive based, and attack technology that is driven to stay one step ahead of the available protections, eCrime managed to position its Web threat as the most useful attack vector, bypassing the long time leader – e-mail. Having a huge victim pool to choose from, these eCrime groups have been highly focused and are still very regional in their operations – lending on the fact that financial fraud is essentially different from country to country. Last but not least, as the individual “consumer” targets have been commoditized by eCrime in the past 12 months (seen in the volume of raw consumer credit-card and bank accounts traded in the black market), businesses started to show up as the more lucrative issue. Still, with a decent potential for the more classic keylogging and banking threats, businesses also have assets that are highly prized by eCrime such as financial reports, documentation, correspondence, plans, etc… which have been proven to be a target that is sought after by competitors in the same market in which the business operates.

Having reviewed the threats the Internet presents us with today, let’s take a look at the solutions. Dealing with Internet threats has always been the task for two industries – the antivirus and the Web filtering (or categorization) vendors. Through a combination of both, a new market segment has been created to address the Web-borne threats – called “secure Web gateway” or SWG. Lending mostly upon the URL filtering vendors, this market has struggled to find the right mixture of old-technologies from the established vendors, and innovative approaches to address the problem. Vendors of the URL filtering solutions have been moving steadily in recent years to the realization that they are only applicable as a policy governing tools – focusing on productivity and acceptable use regulations inside a company. The antivirus vendors, on the other hand, have been steadfast on leveraging the same old technologies for dealing with executable threats and have been trying to extend the lifespan of such solutions as much as possible – with marginal success in light of the new more elaborate threats. The SWG market has grown several new technologies that deal with Web threats at the gateway in real-time – a requirement that is profound in a threat vector that is based on dynamic, ever-changing code that adapts itself to who is going to be exposed to it.

With the new SWG definition in place, eCrime seems to have finally met its match; although it would take time for a clear industry leadership to grow that would be based on the “right” solution. Businesses should then look for solution providers from the SWG market that put a premium on investing in forward-looking research, and products that provide the real-time gateway scanning that is adept to dealing with modern threats. Additionally, businesses should look for solutions that are more than just “the next AV,” but are also capable of dealing with new threats related to Web 2.0 application control, which is no longer supported by URL filtering because of the dynamic nature of Web sites, and the requirements by businesses to control functionality and not just access to specific sites.

Looking forward, Web 2.0 is not the real threat. It’s just a technology (or an “umbrella” for several technologies). The real “fun” begins when Web 2.0 technologies meet usability, and suddenly most of the functionality that has been usually the realm of an operating system is moving to the Web. The Web as the next OS is a concept that has been developing in labs over the past few years, and is starting to finally get traction in the real world with offerings such as offline Gmail, ZOHO applications (office applications on the Web, which are available offline as well), Adobe Air™ applications that are semi-installed locally, etc… This “browser-OS” is a new paradigm for which even the SWG market does not have a real answer yet, and a lot more research and innovations is still to come on that front.

Final words – not to leave with a bitter taste, one should note that the situation is not as direct as it seems. Software vendors are starting to realize that they are a part in this game as well, and are quickly adapting to the kinds of threats that have emerged. Even law enforcement is showing signs of learning and enabling themselves to cope with eCrime on the legislative side as more indictments are sought for eCriminals. Once these two worlds finally formalize their relationships (e.g., vendors and LE), after years of ad-hoc cooperation, eCrime will finally have a worthy adversary that would either force it out of business, or force it to change its business model. Taking into account that modern security research is also putting the business model in focus, that would mean that consumers and businesses will have much better means for dealing with eCrime than they ever had before.

-Iftach Ian Amit

[Editor's note: Interested in more information about the BlueHat Security Forum, EU Edition?  Take a look at Celene Temkin's introduction on  the MSRC Ecosystem Strategy Blog]

Share this post :

Hi, Billy Rios here, I was recently invited to speak at Hack in the Box (HITB) in Dubai. While at HITB, I participated in two different talks, but I’m going to focus on the talk Chris Evans and I co-presented: “Cross Domain Leakiness.” Chris Evans is a security lead for Google’s Core Security team. Some may find it strange to see a Microsoft and a Google employee sharing the same stage, but regardless of the corporate logos we wear on our t-shirts, it is refreshing to have collaboration between passionate engineers on security issues.

We divided the talk into two central themes. First, we presented some browser bugs we had discovered over the last year. For the second piece, we focused on the browser and Web application scenario where a user joins an untrusted network, more commonly known as the “Starbucks scenario.” In this scenario, the attacker has control over the network utilized by the user. As Internet access becomes more ubiquitous, the scenario in which a user joins an untrusted network is becoming more and more common. Many business offer Wi-Fi access to their customers as a convenience and there are even some cities that have “gone online”, offering its residents free Wi-Fi access in city parks and business centers, all these circumstances fall within the “Starbucks scenario.

While most of the threats in a “Starbucks scenario” can be mitigated by simply using Secure Sockets Layer (SSL) encryption, certain Web application designs and browser behaviors can weaken the protection provided by SSL. Chris and I talked about some of these designs and behaviors and provided some examples on how various browsers handle mixed content, the ability of non-SSL pages to write Secure cookies, and how browser plug-ins can complicate matters. If you’re interested in reading about some of the items we spoke about at HITB, you can find the materials here. Protecting an application in a hostile environment is difficult. It requires a solid understanding of what can be trusted (not much) and what cannot be trusted. It is vital that today’s applications consider the “Starbucks scenario” in their threat models and design reviews. Administrators of such networks must understand where the trust boundaries end; otherwise they may find users losing their data before their first cup of coffee!

After the conference, it was time for some “Dune Busting”. A few of us loaded up into air-conditioned 4x4 Toyota Land Cruisers and hit the dunes of Dubai. It was loads of fun blasting through the sand dunes, racing through the desert, nearly tipping the vehicle over several times as we egged our driver on over the dunes. Dubai is a marvelous city, full of amazing sights and attractions. HITB was loads of fun. Thanks to Dhillon K for inviting me out!

-Billy Rios

[Editor's note: check out the MSRC Ecosystem Strategy Blog for another Microsoft perspective on HITB-Dubai]

Share this post :

Here I am again writing on MS BlueHat blog, this time about Token Kidnapping.

The first time I talked about Token kidnapping was a long time ago and now after a year the issues detailed in the presentation are finally fixed.

Let's see what happened.

Before the first public Token Kidnapping presentation I talked to MS about the topics it included, I mentioned that there were design issues and that some issues were already known. I gave details to them about the Windows XP and 2003 issues (the ones that were already known, at least for some people and for MS too I guess) but I didn't give to them details about the Windows Vista and 2008 issues because I didn't want to give expensive research for free to MS. They would get the research together with general public.

It's very important to have in mind that these are not critical issues; these are elevation of privileges issues that can only be exploited in certain scenarios. These issues need some level of privilege to be exploited, so it's highly unlikely that they will be exploited to mass compromise servers and home computers. It's also important to note that in the scenarios that the issues can be exploited if these issues wouldn't exist then it could be also possible to elevate privileges in a different way. Because of all of this I decided to publish the Token Kidnapping details without any patch available since for me there was no real threat. These are security issues but the impact is very low.

It was only after the presentation and the press attention that MS fully understood the issues and realized that they needed to patch them but as most of them were design issues it would take a lot of work to get a patch ready.

Token Kidnapping had (and still has) a great media coverage this is something that doesn't make MS to look good and it also scares MS customers, MS knew it so they worked hard to fix these issues in a patch instead of a service pack were it would have been more appropriate to fix most of the issues. It took them a year but hey, given the complexity of the fix I think it's not that bad.

Microsoft had a hard time and instead of giving excuses they produced a fix, a bit slowly, but hey nobody is perfect.

The moral of the story?  MS put a lot of effort to get things fixed as soon as possible. MS really cares about their customers and of course about PR too. But the PR didn’t really make the fix come faster.

-Cesar Cerrudo

Share this post :

At BlueHat v8 in October 2008, Dave Weinstein, Jason Shirk and Lars Opstad presented the topic of when it’s okay to stop fuzzing (Fuzzed Enough? When It’s OK to Put the Shears Down). As part of that presentation, Dave talked about a technique used within Microsoft for triaging and categorizing crashes. By “Bucketizing” the crashes, developers and testers can quickly see how many actual crashes they are dealing with, and understand any security implications each crash may have.

Dave also announced that Microsoft would be releasing the tool publicly before the end of June 2009. Several days ago at CanSecWest, Dave and Jason presented the topic “Automated Real-time and Post Mortem Security Crash Analysis and Categorization.” They also released the !exploitable Crash Analyzer publicly, which is open source under the Microsoft Public License (MS-PL).

The tool performs two functions: it groups similar crashes together in order to cut down on looking at duplicates; and it assigns an exploitability classification of “Exploitable,” “Probably Exploitable,” “Probably Not Exploitable,” or “Unknown.”

This tool runs as an extension within the Windows Debugger (WinDbg.exe), called MSEC.dll. To run the tool while in the debugger, just type !exploitable and you’ll get something that looks like this:

In releasing this tool publicly, we hope to help developers and testers working on windows platforms to manage their bugs more efficiently by understanding what’s a duplicate and what’s a security problem that may put users at risk.

Please visit http://www.microsoft.com/security/msec for more information, and a link to download the tool from CodePlex.

Enjoy, and Happy Fuzzing!

Jason Shirk, Microsoft Security Engineering Center

Share this post :

It used to be easy to be in the security industry. All you had to do is develop products that needed to say “nay” or “yay” on a given content and “bless” it to be secure or not. That is so 2007… As we have been witnessing during a turbulent 2008 (and yes – it actually started in 2007…) nowadays the ability to decide whether a given content (note the distinction between content and file…) is malicious or not is much more complicated. Let’s take a look at some of the elements that used to help us how to walk down the decision tree of security software logic:

- Source. If the content came from a website that’s up to no good (catering for hacker forums, storing malicious files, and even hosted in a foreign country – or with a less than appropriate top level domain such as .cn or .ru), security software used to be able to say “nay”. The content was immediately deemed too suspicious even to start handling, and the whole transaction would be blocked. Back to the present – we see most of the malicious content and attacks come from .com sites, hosted in the US, and most likely on a legitimate site that started attacking its users one day.

- Looks. Web based threats used to be a relief for security scanning software – no need to decompile or work in a low-level language – everything is plaintext, and it is easy to figure out what a piece of code is trying to do just by “looking” at it and finding all these bad calls that make a piece of JavaScript malicious. Reality – enter obfuscation. Most (if not all) malicious code seen nowadays on the web is obfuscated to a level where a standard language driven algorithm would just shoot itself. The vast capabilities endowed on browsers these days, make it very easy to hide malicious code in a scrambled (almost encrypted mode) and dynamic fashion, such that standard security software won’t be able to see it.

- Distinction. Back in the day, if something looked suspicious, it was blocked. Reality – legitimate and malicious content are intertwined and exist in the same context of most modern web attacks. It’s hard to just say “nay” to a page full of legitimate content when it has a few pieces of malicious content. Security software has to play the news editor role these days and cut out parts of the web so that it can be safe again. Simply blocking sites and pages do not work, especially when (as noted above) most of the attacks come from legitimate sites who’s content still needs to be served to the client.

I’m not writing this to paint a grim picture – on the opposite, we are facing a new era, an era of innovation, of change (I knew someone said that before me so I’ll just ride on the wave of success), and of better security. This new reality will move us as a community and as an industry to new realms, where we no longer have to answer simple-minded yes/no questions. Welcome to the era of empowerment, of providing all the new tools, technologies and content to whoever wants them – securely. No longer are the days of “no facebook at work”, welcome the days of “facebook at work is great – but no messaging, chat or game applications between 9 and 5.” Welcome to an era where all websites are treated equally, and access is “always on,” but we’ll work to keep the bad parts out.

Welcome to the change. I know that we are not the only ones embracing it – so get ready for it!

-Iftach Ian Amit

Director, Security Research, Aladdin

Mike Andrews here. With a very broad brush, the vulnerabilities we see can be split into two categories -- flaws and bugs. Flaws are inherent problems with the design of a system/application – Dan Kaminskys’ DNS vulnerability would be a good example. Bugs, on the other hand, are issues with the implementation of the software, and the classic example would be a buffer overflow. It’s not a perfect taxonomy and we can start splitting hairs in some instances, like the CSS stuff Gareth Heyes, David Lindsay and Eduardo Vela Nava showed at BlueHat (is it a flaw in the spec that allows such abuse of functionality, or a bug in that browsers shouldn't be executing such code), but generally one can place a vulnerability in one of these categories quite easily.

Another distinction is the one between vulnerabilities and exploits, and this is a much easier one to make. A vulnerability is an issue (flaw/bug) that allows a bad thing to happen (e.g. a buffer overflow), while an exploit is what can be done with it (e.g. crash a machine, escalate privilege, execute foreign code). It's usually one-to-many relationship – a single vulnerability can be exploited numerous ways.

2008 was an interesting year for security. Although, I posit, a good number of the vulnerabilities that have been disclosed, talked about, and garnered a lot of press in the past year were, in fact, simply more creative exploits. While the underlying vector of many vulnerabilities haven’t changed (injecting foreign code into a webpage, for example), what can be done with them has been advanced (CSS history stealing, javascript-based internal network scanning, clickjacking, etc, etc).

The thing is, however, that although better exploits advance the field in some ways, like how a particular mitigation, update or architecture doesn't really protect us, it seldom "adds" anything to the conversation. What was once broken, then fixed, is now broken again; we scratch our heads and go back to square one, learning little from our mistakes. Nate Mcfeters’ previous post about old issues becoming new again couldn't be more spot on -- the past appears to be a fruitful ground and many "old" vulnerabilities are finding a new lease off life with better exploits. The recently disclosed research of creating a fake CA certificate from MD5 collisions proves this point. We knew this specific attack was possible back in 2007 (and thus most CA’s changed to SHA1) – I guess sometimes it really takes an exploit to force some into action. [Ed: For Microsoft's recommendations on this issue, see these MSRC and SVRD blog posts].

We're never going to get rid of bugs or flaws as software development is a human process and we make mistakes or overlook things. Software is getting more and more complex as well, which means there is more opportunity for vulnerabilities and ways of exploiting systems. However, I believe we are missing a huge trick here; other than those of us who are really into software and security, how much attention does the wider community learn from an exploit versus understanding its root cause? It causes panic, a rush to create/find a patch, and then when we are “safe” again, often it’s forgotten. If you don't already, subscribe to the Microsoft Security Vulnerability Research & Defense blog (at http://blogs.technet.com/swi/default.aspx) for an in-depth look at the details behind vulnerabilities, what they affect and why they came about in the first place. I can't recommend studying this kind of information enough.

So, my call for 2009 is for us to not focus as much on the exploit, even though that is difficult to do (who doesn't like a good magic trick, hack, example of why software is flawed). Focusing on the why, rather than the what, is what I believe makes software better and there’s (still) so much to learn from previous mistakes.

-Mike Andrews

Principal, Foundstone professional services

Hello everyone, Celene Temkin here from the MSRC Ecosystem Strategy Team. BlueHat v8: C3P0wned ended a month ago and the success of the con lives on in the outstanding training and networking done between Microsoft employees and external speakers and guests. I'm happy to say the speaker video interviews, podcasts, anecdotes and archives are live on the BlueHat TechNet Page. As promised, we recorded all of Day Two's presentations and we've published them on TechNet for the first time publicly for all to enjoy--so grab your popcorn, 'fluffi bunni' slippers and get to viewing!

As you know by now, Day One sessions were a hybrid of content from in-depth technical security issues to innovative techniques and best practices to use in the information security realm. Day Two focused on the SDL where the Microsoft Security Development Lifecycle (SDL) team hosted sessions emphasizing secure development and testing practices, as well as how to develop with security in mind from the beginning of the software development lifecycle. The BlueHat SDL sessions focused more on proactive and secure development strategies and less on attack techniques.

Notable keynotes included Jon DeVaan, opening the conference on Day One discussing how BlueHat focuses on security and privacy issues facing the entire ecosystem; Day Two was kicked off by Scott Charney, who discussed how to leverage the SDL to discuss not just the threats, but implementing engineering solutions.

Mark your calendars! The next BlueHat is October 22-23, 2009. See you all there.

-Celene Temkin

BlueHat Project Manager

I spent a lot of time trying to think about what to write for a BlueHat pre-conference blog entry and had a pretty hard time focusing on one topic. To handle this, I decided to comment on the state of security.

While I've found plenty of things to be excited about with security, including improved awareness, enhanced vendor responsiveness to issues (although some still lag behind), increasing global awareness of security concerns, etc., I've still found plenty of things to be concerned about.

Security problems of our past rarely disappear for good. You have new progress all the time... new types of bugs, new ways of combating old problems... but you also have old problems coming back into play.

See the GIFAR/Content Ownership stuff, multiple blended threats, hypervisor-based attacks, Clickjacking, Dowd's null pointer exploit, etc., as new attack vectors. ASLR/DEP (whatever else you want to call it) memory protections as a new defense (and of course, Dowd and Sotirov's mad hotness to bypass these mitigations).

See Dan's nasty DNS vulnerability, the SNMP vulnerability, IP stack flaw, etc., as examples of old concerns coming back into play (in dramatic fashion as well). Shoot, there was even a directory traversal flaw recently on Apache Tomcat that reminded me of the old Unicode IIS flaw.

It's concerning that we can't get passed the vulnerabilities of our past. Of course, things keep moving on as well. New technologies have created a wider threat landscape than ever before. Mobile devices, virtualization, and technologies of the future will provide us new challenges. I recently had a client plead with me about virtualized environments saying, "If we can't even secure our physical machines that we can see and touch, how the heck are we going to secure a virtual one that could actually be removed from our company via the network?" A great question, to which I had little in the way of answers.

I will say that while I'm concerned about the cyclical nature of security vulnerability and the potential for even greater vulnerabilities in new technology, I won't be the one to stop innovation, and I'm excited about all of these new technologies. As security researchers/professionals/consultants/whatever, we have to remain vigilant and strive to find vulnerabilities before those who would use them against us. I'm very excited about what I see with security research from a global aspect. I was fortunate enough to speak at Black Hat Japan in Tokyo this year. Beyond the wonderful hospitality of the people of Tokyo, I was also impressed by a few of the native Japanese speakers and what they brought to the table. Some of the discussion around Japanese-based character encoding brought up some interesting research thoughts for myself.

I doubt that research and new defense technologies will ever outpace the growth of new technology and new threats. I also doubt that we'll be able to prevent old concerns from coming back to life, but we're on the verge of making major strides here. Security is, as always, an arms race... it's one we might never win completely, but maybe we can catch up a good deal if we stay vigilant.

-Nate Mcfeters, Ernst & Young

Hello,

This is Scott Stender and Alex Vidergar from iSEC Partners, and our topic for BlueHat is Concurrency Attacks in Web Applications.  Database administrators, computer architects, and operating system designers have spent decades solving the problems that arise from concurrency as they apply to their respective technologies, so this should be old, boring stuff, right? 

If you are a web application developer, let’s start with a quick question:  Is accessing session variables in your web application framework thread-safe?  If you don’t know the answer off the top of your head, don’t worry – you are not alone!

Web application developers are caught in the middle of two powerful forces:  productivity and abstraction. 

Developer productivity reduces costs and can be credited with removing drudgery from programming tasks.  In the web application world, the pursuit of productivity has yielded a parade of easy-to-use web application frameworks.  No longer do the web developers of the world manage connections and thread pools, they can focus on the creative aspects of their profession.  Modern frameworks require the programmer to implement a single function using a handful of APIs, and presto, a fully interactive web page is born. 

In order to achieve this, however, we need abstraction.  All of the "plumbing" that goes into making a web page work has to be hidden in the web application framework and web server, which means that the average web developer does not have to worry about it, or know it is even there.  Furthermore, most of those frameworks are written in an object-oriented manner, meaning that abstraction is more than just a luxury, it is a key tenet of the programming environment. 

There’s the problem:  When abstraction of such resources is a requirement of the programming environment, we should expect trouble.  Because of abstraction, developers can be unaware of resources shared across threads, processes, or servers and will fail to protect them. 

As you may have guessed, we have found more than a few instances where well-meaning developers can easily introduce concurrency flaws into their web applications. The problems themselves are difficult to identify, reproduce and can carry a hefty security impact.  Our goal is to provide guidance for developers and testers to identify and address this class of flaw.  And, with a roomful of people responsible for creating the very technologies we are discussing, we anticipate a healthy discussion on how this problem can be best addressed by security analysts and developers alike.

-Scott Stender and Alex Vidergar, iSEC Partners.

Working to find bugs in the software security industry is much like prospecting for natural resources. An engineer takes a high level view of an unknown piece of territory to determine the lay of the land and narrow down the geography into a few key locations of interest using intuition, experience, and macro-scale information. Next, they use analysis instruments to collect data that eventually tells them where to apply human resources to dig for GOLD! Or Oil. Or bugs!

Now, back before there were things such as accurate soil analysis instruments, there was still prospecting. It just wasn’t all that efficient. Just like in security, we’ve been finding bugs through laborious and often gut-instinct driven processes that are simply inefficient. Lately, I’ve been thinking hard about this problem and pooling resources with professionals in the security field as well as academics in the visualization field. I recently had the honor of participating on a panel at VizSec, which is held at MIT, and had presenters and attendees that stretched the globe bringing their heads together to see where visualization is going. The observation I made was that the network security folks are thinking a lot harder about visualization than those specializing in software security and I think I understand why: network data has many concrete properties that are readily consumed by existing data analysis functions and data visualization software. That is to say, they know some of the trends they’re looking for and those values are typically very literal, such as who is sending packets where and of what type, etc. I found myself trying to create parallel scenarios that would fit software security and program analysis and there certainly are some to be found (such as reachability on a graph), however for the most part, software security analysis is facing different problems due to a lack of metrics that can be plugged into functions that find trends. 

So, what does this mean to software security prospectors like us in the context of visualization? It means that we need to define metrics that can be measured and then presented visually, of course! There are some good articles you can dig up from ACM on the topic, but one basis for my work has been Matt Miller’s paper titled “Improving Software Security Analysis using Exploitation Properties”. Matt’s paper introduces the concept of exploitation properties which are specific metrics that can be interpreted together to get a sense of whether an area of code is at higher risk of exploitation if a bug is present – you’re going to exploit the stack overflow that isn’t protected by GS before you try to work around the one that is protected with GS, right? Expand this concept a bit and you can begin to collect metrics beyond exploitability that may help improve software security or maintainability. 

So my upcoming talk at BlueHat will focus on two areas of concern: what do these metrics look like and what do proper visualizations of multi-dimensional data look like. We have some interesting challenges because not all of our metrics are as reliable as others. In fact, off-the-shelf bug finding tools are often heuristic based and can be highly unreliable, but that just means we have a unique opportunity to take large data sets and correlate them to find out where the real gold is buried.

-Richard Johnson, Security Software Development Engineer, Trustworthy Computing, Microsoft

Another six months has passed – must be time for BlueHat, Microsoft’s internal security conference.

This one is shaping up to be an interesting one.  The early BlueHats were all about the raw technology – Shok blowing out the memory manager, Brett Moore facepalming over yet another file format vulnerability.  But determining vulnerability requires more than just understanding technology.  At the end of the day, there are bad guys, and bad guys don’t necessarily have to take the geekiest of routes to get what they want.  So there’s an interesting thread that appears to run through many of the talks this year, linking what we are capable of doing as engineers, with what attackers have been doing as criminals.

For my part, I’ll be talking (unsurprisingly) about the DNS vulnerabilities that made a bit of noise earlier this summer.  That was quite the experience, and indeed, continues to be.  DNSSEC is making astonishing progress – there’s no question about that.  It’s also not going to be deployed on 99% of authoritative servers anytime soon – even .GOV is looking at two years to get coverage across their bailiwick.  And the numbers for the pragmatic fix (Source Port Randomization) continue to be astonishingly good.  But there is indeed demand for better, and one of the interesting things I’ll be able to discuss is:

What now?  What should the next interim fix look like?  What is the full set of scenarios that needs to be covered, to justify going through another patch cycle?  What sort of real-world deployments do we need to be compatible with?

And why do we have to fix this, anyway?  Why are so many things broken, to the point that they fail trivially when attacked by a basic man-in-the-middle?

These are hard questions.  The answers to them are not all to be found in DNS, or even just in technology.  What has been a clear and fascinating realization is that not just this one vulnerability, but all the major vulnerabilities of 2008 have all been linked to a complete failure to authenticate.  Whether it’s Mike Perry finding that many (most?) SSL sites leak their authentication cookies out to unencrypted parties, or it’s Mike Zusman finding that many (most?) SSL-VPN’s don’t actually validate that they’re encrypting their payloads to anyone in particular, or it’s Wes Hardakar finding out that SNMPv3 barely makes a user authenticate at all – a remarkable number of problems are all being found that trace back to us having no idea who we’re talking to.

Identity is not, and never will be, merely a problem of technology.  It will take tech to fix – but it will take something more, too.  It will take some work to figure out exactly what that something will be – but we have at least one significant data point showing a shocking number of companies expending a tremendous amount of effort, all in pursuit of doing the right thing for themselves and for their customers.  We can, and should, learn from this experience, and I look forward to exploring this all at BlueHat.

Dan Kaminsky, IOActive

The Wikipedia page for Natural Language Processing (not the Darren Brown stuff) describes it as “a subfield of artificial intelligence and computational linguistics.” So why am I discussing this on the BlueHat blog? If, like me, you sucked at linguistics in school, you might think that it has no place in IT security. However, the more I play with NLP, the more excited I get about the possible applications it could have in information gathering -- and thus in IT security.

For the past 18 months or so I have been pouring my heart, my mind and my wallet into Maltego, a framework that is used for information collection. Maltego consists of ‘entities’ and ‘transforms’ – and allows you to convert (or transform) one type of entity to another. As a simple example you might think of a DNS Name entity and an IP Address entity, where a Transform would simply resolve the DNS Name to an IP Address, or the reverse, resolve the IP Address to a DNS Name. It turns out that information is a lot more connected than I originally thought and as of now we’ve created more than 100 transforms on about 15 entities types. To take the DNS/IP address example further, an IP address is located within a network which has ‘whois’ information (and geo-location information) which leads to names, e-mail addresses, and phone numbers which lead to persons, domains (from the e-mail address) and geo-locations, which in turn lead to other entities and so on and so forth – to a never ending mesh of loosely related chunks of information that can be visualized on a graph as a set of inter-connected nodes.

Anyhow – back to NLP. I spent last week fiddling with NLP transforms for Maltego, specifically building Information Extraction into Maltego. Information Extraction is a specific application of NLP and if you integrate it into a framework where automation and correlation is possible, then it becomes very interesting. For the first time I get the feeling that I can actually discover information that’s ‘hidden in plain sight’.  At the moment the stuff is still unstable and eats CPUs and memory as fast as a pre-lunch snack but we’re working on making it more stable and production ready.

Information extraction is used to extract ‘entities’ from text. As an example, it will be able to look at a web page and extract all the person names from the page. It can also extract the organization names and the location names. In fact, it can extract anything that can be programmatically described from text. Given time, it will even be able to extract the ‘facts’ from the page. This means that if you have four web pages that basically say the same thing NLP will be able to connect the pages. And for the first time, I have the ability to give ‘human-like’ functionality to a transform.

Again – why is this interesting for security people?

Let’s look at a very concrete example. Suppose you are doing a footprint for a multi-national company. We all know these guys could have thousands of domains. Let’s assume that you have some method of collecting the odd 500 domains which you think might be associated with the organization. These domains are in multiple countries, each registered at a different registrar, and each registrar has its own method for formatting ‘whois’ information. So even if you manage to collect all the ‘whois’ information, you have no way of properly formatting the information so that you can easily grep for the target organization. Using NLP you don’t need to worry about it, you can tell your Information Extractor to simply extract organization names from the collected data. Without NLP, you will either need to write a parser for every format or you need to eyeball every ‘whois’ result.

Not convinced? Sure – perhaps you’ve never experienced the joys of doing a footprint. So let’s look at something else. Let’s say you want to know who are the key figures associated with a specific phrase. Your phrase could be something like “High ranking diplomats” or even a company name. You can feed the phrase to your favourite search engine and get a list of URLs where the phrase appears (in the first example you’ll want to restrict the results to a specific domain or country). Next, you can feed all the text on the resulting web pages to your Information extraction engine – it will neatly ‘parse’ the text into person names. And voila – within minutes you have a list of names. If you use something like Maltego to do this you can now get an idea who is the most prominent (or most vocal) person is – as some names will be mentioned on more than one page.

So let’s try it – the proof of the pudding etc. Let’s run the process on a phrase where we can verify the results. Using the phrase ”BlueHat conference” as a starting point, we end up with a graph that looks like this:

From the graph we quickly see all the usual suspects. Of course the program cannot give any kind of context to results. For instance it won’t tell you that Ryan Naraine is a reporter that covers IT security and that Andrew Cushman organises the conference. Also, the graph is littered with false positives, but this is a mere annoyance as it disappears as white noise when looking at the frequency of extracted entities.

You may say ”but I knew these people were key figures at BlueHat – what’s the big deal?“ Well – consider that you can enter ANY phrase into the system and minutes later know who the key players are. When we combine this kind of functionality with other gathering techniques for open source information, it becomes a bit frightening. Consider a process that subsequently looks up these people’s e-mail addresses and start sending custom crafted malware (although, the list above would hardly be good candidates) or perhaps automatically resolve social network memberships, and where possible, create fake identities. Bottom line – if you are looking to attack individuals connected to a certain ‘phrase’ in an automated fashion you first need to know who they are.

Real life, practical hacking is really all about collecting information. The people who have been doing this for a while will tell you that an exploit is really only 5% of the entire exercise. Of course you don’t need to always have the evil bit set, mining the Internet for information is very useful for law enforcement, intelligence agencies or anyone that simply wants to gain insight into a subject.

In the past you could have hoped to fool e-mail address harvesters by writing your email address as roelof at paterva dot com. With NLP you can run...but you can’t hide.

R.o.e.l.o.f  T.e.m.m.i.n.g.h

PS: NLP implementations are hairy beasts that breathe fire, with sharp teeth, complex eyes and many legs. I think of it as a big black box filled with magic -- but as long as I can get a slice of magic, I am quite happy.