The current buzz in the technology industry is all about this idea of Cloud Computing. It goes by many many names but we’ll just stick with this one to eliminate confusion. Sure, it’s a great idea and vendors are talking about “moving your data to the cloud” where someone else can manage your data, provide better uptimes, manage the patching process, etc. Unfortunately, as a security guy, I tend to look at the idea of cloud computing from a risk perspective…and it just isn’t fluffy cumulus clouds that I see…it’s more like the picture you see here.

From the security perspective, it appears to be nothing more than a matter of risk transference, very similar to what any good insurance policy will do for you. Companies are trying to be quick to market with their Cloud Computing Security Strategies, but I’ve yet to hear anyone truly identify the risk that this will solve. At the end of the day, it comes down to two simple questions that either your CSO or Legal Department will most assuredly ask:

Who ends up being liable for the data that’s stored in the cloud when it’s breached?

Who’s name and signature is going to be at the end of the Breach Notification letter you’ll send to your customers?

I’ve been doing a lot of research on the topic of “cloud computing security” the last few weeks, as I prep for my session at TechEd North America 2009 entitled “Securing the Cloud”. I have to tell you, I don’t see a lot of companies agreeing to become liable if your data gets breached on their network. I’m not sure how this really differs from putting your money in a bank, rather than in your mattress. The bank (through the powers of the FDIC) ensure my money up to a certain amount. Will my cloud vendor do the same?

Of course, with all new things, old problems still exist.  How is that 3rd party auditors going to successfully conduct an external audit of your data, when the data and controls aren’t even on the premises? “Well, Mr... Sarbanes-Oxley Audit Master, I’d love to show the controls that we have in place to remain compliant with 404, but the data isn’t actually here. Perhaps you can contact our cloud provider to find out the controls they’re using to keep my customer data secure.” That probably isn’t go to go over to well. Remember, you can delegate authority, but not responsibility.

I just want to be sure that we are all really giving this a lot of thought before we start dumping our data up to some unknown entity in the clouds. There are plenty of positive things that cloud computing provides, but at what cost? I’ll take the extra time to patch my enterprise’s servers if it means keeping my data close.

As someone who travels extensively talking to security professionals, I learned long ago that I don’t have all the answers….and this is no exception. Let’s start a dialogue through the comments. What risks do you see with regard to moving to a cloud computing infrastructure and is your business headed that way? 

Also, before I forget….I’ve found a really great cloud computing security blog called http://cloudsecurity.org. Two thumbs up! Check it out.

Friends, as a part of Microsoft’s second round of restructuring, my position was eliminated yesterday and my employment with Microsoft has ended. While there were many rewards that came from my job, the most satisfying element was knowing that our time spent together helped improve everyone—whether at conferences or through this blog, I’ve learned as much from you as you’ve learned from me. Sharing information, debating positions, and doing the right work for the right reasons are all very important and I’m honored and humbled to have been trusted by so many of you.

I’m certainly not disappearing. While I won’t be at TechEd North America this year (yes, I’m truly sad about that), I’ll remain involved in the security industry. You can find me on LinkedIn at http://www.linkedin.com/in/steverileysea. And I’ve got a new blog at http://msinfluentials.com/blogs/steveriley/default.aspx, where I promise I’ll start writing more. Please check in there for updates, and I’ll be sure to let you all know where I land next.

After launching yesterday, the Beta for Microsoft Security Essentials has filled up – see the screenshot below.  This first Beta was limited to 75,000 participants within some targeted geographies and it is encouraging to see this target achieved in such a short time.

Well, I've been in the Xbox Live team for the past 3 days and my head is swimming!  I had never thought about all the work that goes into keeping Xbox Live up and operational, but now that I'm here and get to see it, it's pretty remarkable.  There is a large team working around the clock to make sure that gamers around the world can get on their Xboxes and have a troublefree experience whenever they want to.

Anyway, I'll have more to post down the road, but right now I'm still focusing on getting my feet underneath me so I can start contributing.

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 :