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.
<param name="AllowHtmlPopupWindow" value="true" />
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
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]