Microsoft BlueHat Blog

BlueHat v9 brings the looking glass to you

BlueHat — Fri, 11 Dec 2009 18:13:00 GMT

Celene here from the MSRC Ecosystem Strategy Team. BlueHat v9: Through The Looking Glass ended just over a month ago and the success of the con lives on due to the outstanding training and networking between Microsoft employees, external speakers, and guests. I'm happy to say that the speaker video interviews and selected recorded presentations are now live on the BlueHat TechNet Page. As promised, we have posted talks from every track block. The samples available are from the e-crime, cloud, mobile and fuzzing content blocks. Check out the MSRC Ecosystem Strategy Team Blog for more stats from BlueHat v9!

Mark your calendars! The next BlueHat is October 14-15, 2010. See you all there.

-Celene Temkin, BlueHat Project Manager

*Postings are provided "AS IS" with no warranties, and confers no rights.*

Know thy Enemy

BlueHat — Fri, 06 Nov 2009 18:23:00 GMT

I recently attended BlueHat for the second time and spoke about the SMS vulnerabilities Collin Mulliner and I discovered and exploited this summer. BlueHat is an interesting speaking venue because the audience consists entirely of Microsoft employees. Some people might think security researchers speaking at Microsoft is like speaking before the enemy, but that is not the case (an actual example of that would have been when I talked about exploit sales at CERT a few years ago). The people I spoke with at Microsoft seemed genuinely interested in listening to what I had to say, learning how I look for bugs, and generally, how the adversary thinks. I think this is a good sign they take security pretty seriously, at least on some level. Hopefully, they got some value in listening to how I attack applications.

From my perspective, BlueHat is always very rewarding. I get a chance to speak with the folks at Microsoft who are in charge of product security. This year, I sat down with a large group responsible for the security of Windows Mobile. It’s always fascinating to hear what they are planning to do, what they were thinking when they made various decisions, what tools they have at their disposal, etc. However, just like I don't tell them all my secrets, I'm sure they keep a few of their own, but I got the feeling that they were willing to tell me more about how they work than the last time I was out there, which is another positive sign.

There is the old Sun Tzu quote that goes 'know thy enemy'. It’s not clear that this is entirely appropriate here, but BlueHat does provide a way for Microsoft employees to sit down and talk with top security researchers and I think both groups benefit from it by gaining insight into how the other group thinks. Now if only I could get them to stop automatically rebooting my computer and corrupting my IDA Pro databases....

-Charlie Miller, Independent Security Evaluators

The lighter side of the cloud

BlueHat — Wed, 21 Oct 2009 16:00:00 GMT

Billy Rios here. I’m giving a talk this week along with Nate McFeters entitled, “Sharing the Cloud with Your Enemy.” It’s a fun, realistic talk on security in the cloud. Why cloud computing?

Cloud computing, software as a service, infrastructure as a service, platform as a service… with so many different terms and so much hype, this cloud computing stuff can be confusing and understanding security in the cloud can be even more confusing! Nate and I will break down some of the most relevant security challenges we see for the cloud “Barney” style so that even my nine-month old daughter (or your average everyday CSO) can understand them. How are we going to do this, you may ask? Well, up until this point, we’ve seen a lot of theoretical scenarios related to cloud security.

In our presentation, we’ll cover some important cloud security concepts and back them up with some real-life vulnerabilities we’ve discovered. These vulnerabilities are neat but more importantly, they highlight some hard hitting, real-life issues anyone considering adopting a cloud computing platform needs to consider. We’ll cover some questions that every business should be asking their cloud provider and we’ll also use some of the vulnerabilities we’ve discovered to highlight areas cloud providers can improve on (there are plenty of areas). The content we’ve put together is appropriate for all audiences, but especially geared towards cloud providers and those wishing to implement cloud solutions for their business.

Come in from the Seattle rain, grab a cup of coffee, and join us for an entertaining, yet stimulating talk on cloud security. The cloud providers we’ve chosen to highlight are some of the biggest in the industry, the vulnerabilities are real, and the presenters are some of the sexiest on the planet… what more could you ask for?

Attacking SMS

BlueHat — Mon, 19 Oct 2009 17:05:00 GMT

This year at BlackHat USA in Las Vegas, we presented on the topic of attacking Short Message Service (SMS). Our presentation focused on the different ways in which SMS can be used to compromise mobile security. We’re excited to give an updated version of our talk at the upcoming BlueHat v9 conference later this month, and thought the BlueHat blog readers who will not be able to attend might enjoy an overview of some key material from the presentation.

Why attack SMS – When we first started looking at SMS, two things immediately leapt out to us that made it an interesting attack surface. The first was that there is far more functionality delivered via SMS than the simple text messages that everyone is familiar with. For example, SMS can be used to reach other rich attack surfaces such as graphic libraries and video codecs. These are two areas which have contained extensive vulnerabilities in the past. The second item which makes SMS interesting to analyze is that it is always turned on (and ready to be attacked). SMS messages are delivered to mobile phones via the paging channel that the network uses to notify the phone of important information such as an incoming call. Therefore, it is extremely difficult to tell a mobile phone to not receive an incoming SMS as the phone always needs to listen on this interface. Additionally, the network is built to make a best effort to deliver an SMS to a recipient, which makes attacking even easier. If the target is offline or out of range it does not matter to the attacker, as the network will typically store the attack message until the target comes online and then will deliver it.

Attacks – In our presentation, we break down the attacks we discuss into three categories: Implementation, Configuration, and Architecture.

The first category of attacks we discuss is implementation flaws in the messaging software on mobile phones. We started with the assumption that any crash we triggered would likely be localized to the messaging application. We were surprised to find that crashes commonly occurred at a much lower layer that would knock the phone's radio interface offline. This would then prevent the phone from placing or receiving calls and SMS traffic, sometimes even across multiple reboots of the device.

The second category of attacks we discuss is a case study of a configuration flaw that affected a number of mobile devices. Those of us working in application security are used to one vendor having direct responsibility for a product. In the mobile world, things operate differently. Instead of each application being the responsibility of a single vendor, there are three main players: the carrier, the hardware OEM who makes the device, and the operating system vendor. When a vulnerability is found in a given piece of software, the responsible vendor ships a patch for that vulnerability. As has been shown with multiple real-world devices, one of the parties can make a change to the configuration of the device that results in the final product shipping with an insecure configuration.

The final category of attacks we discuss relates to the security architecture of SMS. As we mentioned before, there is a lot of administrative functionality on mobile phones that makes use of SMS. A straightforward example of this functionality is voicemail notifications - a carrier can notify a subscriber that they have a voicemail message waiting by sending a specially crafted SMS to their mobile phone. Most phones respond to this message by executing an administrative action, such as popping up a notification to the user. Obviously, an administrative message type such as this should only be generated and sent by the carrier’s equipment. During the course of our research, we found that there are a number of administrative SMS message types that we were able to send as a peer device on the carrier network. Some of these message types can have significant security implications to the mobile phone, unlike a simple voicemail notification.

Conclusion - SMS and mobile devices in general offer an intriguing area for future security research, especially as mobile devices store increasingly sensitive information. We are looking forward to spending time at BlueHat doing a much deeper dive into the topics we have begun to introduce in this blog post.

- Zane Lackey (iSEC Partners), Luis Miras (Independent Security Researcher)

Babel Hacking

BlueHat — Tue, 13 Oct 2009 17:48:00 GMT

Hello world! Remember Mad Libs? How about Scrabble, when you'd try making up words that sound legit just to be de-bluffed by your friend. Playing these games provides endless hours of fun with words and letters. In software and the Internet, words, letters, and text are everything. Whether you're up in the cloud, down in the code, or consuming the content—written language is the information that’s central to it all.

Unicode provides a set of standards for representing most of the world's languages and scripts within a single framework. It’s pretty awesome really—the ability to capture the world’s scripts past, present, and future. Where else would you find a character set that encodes everything from ASCII (Latin) to the symbols of the ancient Phaistos Disc, such as this PLUMED HEAD:

Unicode has come to be the de facto system for representing and encoding characters across any computing platform. It's central to most modern operating systems, programming languages, and applications. But, similar to a networking protocol stack, most software developers don't want to wrangle with the details. It should be good enough to know that your strings are handled as Unicode, so you can build your software without sorting out the complex details of charset transcoding, normalization, etc.

Still, there are attacks and countermeasures that should be known. In my BlueHat presentation I intend to cover two broad categories—one around visual perception attacks, and the other around character transformations. In the cloud, URL's rule. Okay, URI has superseded URL and, with Unicode, we should be talking about IRI (Internationalized Resource Identifier). But anyway, with the growth of Internationalized Domain Names (IDNs), IRIs have just as much a place as do URIs. What I'm really concerned with are the domain names, the IDNs. We saw early visual spoofing attacks as early as 2002, and again with Eric Johanson’s Paypal spoof in 2005. Times have changed since then and the browser vendors and registrars have gotten smarter about IDN.

However, the attack vectors continue to emerge. I plan to demo some of these and describe the current landscape of IDN, especially as it relates to the IDN revisions that are soon to be standardized. These revisions, dubbed IDNA 2008, bring important changes, both good and dangerous. On the one hand, we've moved to an inclusion-based model, from exclusion-based for allowed characters. On the other hand, we'll have edge cases where a single domain name could resolve to two different IP addresses under the new and old IDN standards. Can your cloud-based services be spoofed?

Moving along, we'll take a closer look at how character transformations can be used to exploit software. Some characters really do have split personalities much like Dr. Jekyll and Mr. Hyde, which affect you whether your product parses text and wants to prevent buffer overflows, or its a Web-app looking to defend against XSS attacks. Through subtle manipulations, attackers could send you strings that expand by factors up to 18x when normalized. In attempts to evade XSS filters, an attacker could inject characters such as the U+0130 LATIN CAPITAL LETTER I WITH DOT ABOVE which when lower-cased change to a U+0069 LATIN SMALL LETTER I.

In other situations, processing of special Unicode characters such as the BOM might also open up exploits. Because many assigned characters have special meaning and properties, their usage outside of their intended scope may require closer attention.

I’m happy to be going over these issues with you and the Blue Hat crowd at my talk, Character Transformations: Finding Hidden Vulnerabilities, aimed at developers and testers. I want developers to see some of the issues, and I want testers to see some new inputs and test cases.

-Chris Weber

Co-Founder, Casaba Security

Collaborating on RIA Security

BlueHat — Tue, 06 Oct 2009 19:14:00 GMT

Microsoft and Adobe frequently work together on security. At this year's BlueHat, we will come together to share our security research in the area of Rich Internet Applications (RIAs). While we independently place considerable thought and effort into our respective security models, attackers often look for methods in which to combine technologies for an attack. In addition, developers might combine two technologies without knowing the risks associated with mixing content. By sharing research and consolidating information, we can ensure that developers have the essential knowledge necessary to provide a secure experience for end-users regardless of the technologies that are combined to create that experience.

A single Web page may be a composite of the efforts of many different development teams, each utilizing different technologies. If you are responsible for the overall security of a site, then you need to have a clear picture of how content will interact in order to understand the risks. Without a clear mapping of permissions granted to each piece of content, an attacker might be able to find subtle paths through your defenses.

For example, I have been looking at many of the newly developed cross-domain permissions and hypothesizing how developers might make mistakes in deployment. My co-presenter, Jesse Collins, has already published on how cross-site scripting attacks due to coding flaws can lead to attacks on cross-domain XHR2/XDR implementations. On the other hand, I have been researching how architectural designs might lead to unintentional cross-site permissions. For instance, let's say that woodgrovebank.com provides cross-domain XMLHttpRequest Level 2 (XHR2) permissions for their site to adatum.com. The adatum.com site also serves interactive third-party SWF advertisements that are provided with JavaScript access via the allowScriptAccess parameter. If the third-party SWF advertisement has access to the JavaScript on adatum.com and adatum.com’s JavaScript has cross-domain access to woodgrovebank.com, then the third-party advertisement has access to woodgrovebank.com. This may not have been what woodgrovebank.com had in mind when they provided cross-domain access to adatum.com.

As part of our research, we are supplementing our concepts with real world examples. For instance, the hypothetical example above is an abstracted variant of the recent renren.com worm. The writers of the Renren worm started with sharing a link to a malicious SWF file hosted on a third-party domain. Unfortunately, the renren.com HTML was providing that remote SWF with an allowScriptAccess permission of “always”. The “always” permissions allowed the remote SWF to have script access into the renren.com HTML. The SWF itself would do nothing more than play a Pink Floyd video (Rick Astley would be too obvious) and use its scripting permission to inject a SCRIPT tag into the hosting HTML. The SCRIPT tag would then load the malicious JavaScript that was responsible for driving the complex attack. The worm propagated by sending messages to the victim’s friends. To accomplish that task, the malicious JavaScript needed to collect information from different sub-domains of renren.com. Fortunately for the attackers, renren.com already utilizes cross-domain AJAX calls to those sub-domains as part of their architecture. Therefore, the attackers were able to initiate the attack by taking advantage of the excess permissions granted to the SWF content. They then leveraged the existing cross-domain AJAX infrastructure to collect all the information necessary to identify the victim's friends and propagate the attack.

Combining research makes it easier to communicate common risks with deploying RIA technologies. The attacks in the above examples could also occur if the content were based on Silverlight and granted the EnableHTMLAccess permission. As the webmaster responsible for the overall site, you may not be an expert on each RIA technology. However, if you understand the common risks shared across RIA technologies, then you will know to ask whether the SWF or Silverlight content has access to your HTML’s DOM during your security review. Understanding the common risks will allow you to draft security requirements that can be flexible enough to address different RIA technologies.

During the presentation we will be providing guidance on how to secure your site against these and other RIA attacks. It is our goal to communicate some of the important commonalities and differences between RIA platforms to enable developers to understand the breadth of RIA's capabilities Architectures that mix content from diverse sources will need to build holistic views of their content. Data flow diagrams detailing where cross-domain communication occurs can help identify where unintended paths into sensitive areas may exist. By understanding the capabilities of RIA technologies and by tracking the flow of those permissions, developers will be able to accurately manage their risks and provide users with a rich Web experience.

Peleus Uhley

Senior Security Researcher

Adobe Systems, Inc.

[Editor's note: Check out Bryan Sullivan's post on the SDL blog titled "Cross-Domain Security" discussing the existing SDL requirements around cross-domain access security and the implications of Peleus' research on these requirements - coming soon.]

Can we secure cloud computing? Can we afford not to?

BlueHat — Mon, 28 Sep 2009 20:50:00 GMT

There have been many disruptive innovations in the history of modern computing, each of them in some way impacting how we create, interact with, deliver, and consume information. The platforms and mechanisms used to process, transport, and store our information likewise endure change, some in subtle ways and others profoundly.

Cloud computing is one such disruption whose impact is rippling across the many dimensions of our computing experience. Cloud – in its various forms and guises -- represents the potential cauterization of wounds which run deep in IT; self-afflicted injuries of inflexibility, inefficiency, cost inequity, and poor responsiveness.

But cost savings, lessening the environmental footprint, and increased agility aren’t the only things cited as benefits. Some argue that cloud computing offers the potential for not only equalling what we have for security today, but bettering it. It’s an interesting argument, really, and one that deserves some attention.

To address it, it requires a shift in perspective relative to the status quo.

We’ve been at this game for nearly forty years. With each new (r)evolutionary period of technological advancement and the resultant punctuated equilibrium that follows, we’ve done relatively little to solve the security problems that plague us, including entire classes of problems we’ve known about, known how to fix, but have been unable or unwilling to fix for many reasons.

With each pendulum swing, we attempt to pay the tax for the sins of our past with technology of the future that never seems to arrive.

Here’s where the notion of doing better comes into play.

Cloud computing is an operational model that describes how combinations of technology can be utilized to better deliver service; it’s a platform shuffle that is enabling a fierce and contentious debate on the issues surrounding how we secure our information and instantiate trust in an increasingly open and assumed-hostile operating environment which is in many cases directly shared with others, including our adversaries.

Cloud computing is the natural progression of the reperimeterization, consumerization, and increasingly mobility of IT we’ve witnessed over the last ten years. Cloud computing is a forcing function that is causing us to shine light on the things we do and defend not only how we do them, but who does them, and why.

To set a little context and simplify discussion, if we break down cloud computing into a visual model that depicts bite-sized chunks, it looks like this:

At the foundation of this model is the infrastructure layer that represents the traditional computer, network and storage hardware, operating systems, and virtualization platforms familiar to us all.

Cresting the model is the infostructure layer that represents the programmatic components such as applications and service objects that produce, operate on, or interact with the content, information, and metadata.

Sitting in between infrastructure and infostructure is the metastructure layer. This layer represents the underlying set of protocols and functions such as DNS, BGP, and IP address management, which “glue” together and enable the applications and content at the infostructure layer to in turn be delivered by the infrastructure.

We’ve made incremental security progress at the infrastucture and infostructure layers, but the technology underpinnings at the metastructure layer have been weighed, measured, and found lacking. The protocols that provide the glue for our fragile Internet are showing their age; BGP, DNS, and SSL are good examples.

Ultimately the most serious cloud computing concern is presented by way of the “stacked turtles” analogy: layer upon layer of complex interdependencies predicated upon fragile trust models framed upon nothing more than politeness and with complexities and issues abstracted away with additional layers of indirection. This is "cloudifornication."

The dynamism, agility and elasticity of cloud computing is, in all its glory, still predicated upon protocols and functions that were never intended to deal with these essential characteristics of cloud.

Without re-engineering these models and implementing secure protocols and the infrastructure needed to support them, we run the risk of cloud computing simply obfuscating the fragility of the supporting layers until the stack of turtles topples as something catastrophic occurs.

There are many challenges associated with the unique derivative security issues surrounding cloud computing, but we have the ability to remedy them should we so desire.

Cloud computing is a canary in the coal mine and it’s chirping wildly. It’s time to solve the problems, not the symptoms.

I look forward to diving deeper into these details with the folks at BlueHat next month in my session titled Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure.

/Hoff

Black Hat USA Spotlight: ATL Killbit Bypass

BlueHat — Tue, 28 Jul 2009 04:59:00 GMT

There are only a few days left before Black Hat USA, and we, like most other speakers, are in the midst of the last-minute push to have all the materials finalized in time for our presentation. Our presentation this year, "The Language of Trust," features a lot of material related to attacking software interoperability layers, and focuses on Web browsers as case studies. Some of the vulnerabilities we will be disclosing affect Microsoft software and have resulted in Microsoft releasing an out-of-band update on July 28^th. The updates included in this release are the result of a lengthy and largely successful collaboration between us and Microsoft, particularly individuals from MSRC including Steve Adegbite, David Midturi, and Dustin Childs. Microsoft has had the unenviable task of dealing with the issues surrounding the fixes for these problems, and they have worked diligently to do so in a timely manner. We decided to put together a blog post discussing the problems that needed to be contended with to get this update out in time, and plug our upcoming Black Hat presentation.

The update addresses some issues we uncovered in the Microsoft Active Template Library (ATL). Released in 1997, the ATL is actually distributed as source code with Visual Studio and is aimed at simplifying various programming tasks for developers. It provides, among other things, helper functionality that is utilized by most ActiveX components, which is where the vulnerabilities we are disclosing reside. Anyone who has utilized the relevant ATL code in their ActiveX controls for the past twelve years may have inadvertently incorporated these vulnerabilities into their own products. Microsoft has been getting a considerable amount of criticism for the amount of time it took to patch the Video Control vulnerability; however, the issue is much larger than it first appears and this fact, along with why detection is so difficult, will be discussed further in our presentation.

There are a few unique problems that needed to be dealt with for the ATL bugs. The first problem is efficient enumeration of vulnerable applications. When you contrast issues within the ATL against issues within application code, a number of differences become apparent. Generally, problems within application code are localized to a single source file, and require the recompilation of a single program. However, with issues in the ATL, any application that includes code from the ATL may be vulnerable. Furthermore, successful detection of vulnerable ATL code usage is a complex and error-prone process, and is difficult to achieve with standard static analysis tools. The reasons why detection is difficult will become clearer after our presentation, when we discuss the details of the bug.

The second issue that needed to be addressed was that of vendor coordination. As previously stated, other vendors that use ATL code in their ActiveX controls are potentially vulnerable. As such, Microsoft charged themselves with the arduous task of tracking down as many potentially vulnerable vendors as possible, and coordinating with each of them. Coordination involved explaining a bit about the potential problems, how to determine if a given control is vulnerable, and mitigation steps that can be taken to fix identified problem controls. This is a process that obviously takes time and effort, and Microsoft has been working around the clock with a number of vendors trying to minimize the risk to end users.

So, the mitigation work is done, the update is out and the presentation is going ahead on schedule! We would like to use the rest of this blog to shamelessly promote the presentation, which is quite broader than bypassing kill bits, and give a little insight into some of the issues we will be discussing. Primarily, our presentation intends to address three issues:

1. Interoperability layers in software do a lot of complicated work behind the scenes, and provide a vast and largely unexplored attack surface.

2. Throughout the course of our research, we discovered that unique bug classes exist due to the specialized tasks that marshalling code must perform. We intend to unveil these bug classes during the presentation. We will show how various data structures and APIs utilized for marshalling in the two dominant browser architectures lend themselves to misuse, creating the potential for subtle vulnerabilities that attackers may target. We will give practical examples for code constructs we have identified as vulnerable.

3. When two disparate components are given direct communication channels to each other, trust is implicitly extended between the two components. This trust relationship can be useful to attackers wishing to bypass various security features present in one component, by abusing features of another.

We are hoping this information will be useful for developers and security professionals alike, and look forward to seeing you all there! Our Black Hat presentation is slated for Wednesday, July 29^th, at 3:15pm PDT, in the Augustus Ballroom 5-6.

-Ryan Smith, Mark Dowd, David Dewey

Securing our Legacy

BlueHat — Fri, 19 Jun 2009 17:38:00 GMT

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 :

Stainless steel bridge

BlueHat — Mon, 15 Jun 2009 19:03:00 GMT

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>

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>

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 :

Getting a business degree as part of Security Research?

BlueHat — Tue, 02 Jun 2009 19:00:00 GMT

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 :

Dune Busting and Browser Fun at HITB – Dubai

BlueHat — Wed, 13 May 2009 19:00:00 GMT

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 :

Token Kidnapping finally patched!

BlueHat — Tue, 14 Apr 2009 20:22:00 GMT

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 :

!exploitable Crash Analyzer Now Available

BlueHat — Wed, 01 Apr 2009 20:19:00 GMT

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 :

Gone is the era of yes/no questions

BlueHat — Wed, 04 Feb 2009 16:57:00 GMT

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