Hi, Michael here,
The following article, ”Major software makers fail security transparency test” caught my eye this morning, because it covers a topic of great interest to me;: companies documenting their security and privacy-related software development practices for the world to critique and perhaps more important, use.
As the article noted, Microsoft’s process has been public for nearly half a decade.
About two years ago I created a short presentation (attached) that asks many of the questions implied by the SD Times article. We support the proposition that vendors should be evaluated by criteria that are closer to the real security properties people want in their systems. Ask your vendors: are you investing in security or certificates?
The industry clearly has a long way to go, both in terms of improving security, and explaining how they achieve or plan to achieve their security objectives.
Hello, Michael Weiss here. Nothing like having two Michaels around to confuse everyone. At least there are only two here. On a previous team, I was one of five Michaels.
Over the next several weeks, I’ll be posting a series of entries to help explain why I do what I do for the SDL team. Today marks the first of them. It’s a twofer, since the first part doesn’t fully make sense until you read the second part.
It’s a wild world out there. When you’re walking through the forest of the Internet, there are hungry bears all around you. The thing is, you can’t outrun the bear. Well, you can, but it’s very hard, not worth it, and not necessary, because you can avoid being eaten without having to outrun the bear in the first place. And contrary to popular belief, simply being faster than the other guy won’t necessarily protect you.
There are two ways you can avoid being eaten. The first is to have little meat, in which case your gross value is low. The other is to be fast enough that it would cost the bear more in energy to catch you than it would gain from eating you, in which case your gross cost is high. In either case, the bear makes a determination of your net value, that is, your gross value minus your gross cost. If the net value is positive, the bear chases you. If the net value is negative, the bear leaves you alone. This graph helps illustrate the point.
The blue line represents zero net value. As long as you are above the blue line, you have a negative net value so you’re safe; if you’re under the line, you have a positive net value so you’re dinner. In software, if you’re the green dot in the Dinner Zone, how can you move toward the Safe Zone? One way is to increase the gross cost to your attackers, by closing off the easy avenues of attack. The SDL was created to provide a mechanism to systematically do this.
While the SDL can move you toward the Safe Zone, it’s not necessarily going to get you all the way there. But that’s OK, because in the real world, you’re not the only bear food.
Let’s assume on this second graph that you are represented by the green dot, and some other potential target (your buddy, maybe?) is represented by the orange dot. You have a more secure system than him (your dot is higher up, costing the attacker more), so the orange dot person gets targeted instead of you. But what about that other person (represented by the red dot)? Sure, you have a more secure system, but you’re also a more valuable target (your dot is farther to the right). Since you’re farther from the blue line than the red person is, the attacker will go after you before working on the red person; you have a higher net value, despite having a higher gross cost.
In other words, just being more secure isn’t enough if you’re also a more valuable target.
Decreasing your gross value is rarely easy. For example, if you’re a bank, you could choose not to have any money. Willie Sutton would certainly lose interest in you. At the same time, your value as a bank is gone, too…hardly a sustainable business model. Besides, attackers rarely know exactly what they will gain from a successful attack on you. Sure, they might get control of your machine, but there’s no telling what’s on it. So, other than under extraordinary circumstances, they can at best make educated guesses. Put another way, attackers gamble based on their belief of your gross value.
In most cases, it takes far less effort to increase the attacker’s cost than to decrease your gross value. This is why most people will buy security systems for their homes before they give up the big flat-screen TVs. Applying the SDL and increasing the attackers’ costs, therefore, is a great way to protect yourself from those bears out there.
Based on what I said thus far, it’s easy to conclude that very few of us would be potential victims. After all, if you’re not a bank or some similar high-value target, you’re not worth attacking, right? Attackers have a weapon that deflates this argument.
In the classic game show Let’s Make a Deal, host Monty Hall gave contestants a choice between keeping an existing prize or trading it for something hidden behind various doors. The contestant had to determine whether it was worth the gamble for an unknown prize.
An attacker would have to do the same, investing the same amount of time on the second victim as on the first, were it not for the magic of amortization. With amortization, an attacker can trade current assets (the investment of time, and maybe some equipment and/or money, to craft the attack) to open not only Door #1, but also Doors #2 through 1,000,000, collecting whatever is behind all of them. It’s an offer no contestant could refuse.
Let’s put this on the graph to see how amortization works.
So let’s assume you are still represented by the green dot, but note your new location. You’re easy to attack, but you’re not really valuable. On Let’s Make a Deal, this would be like giving up the diamond ring for a year’s supply of laundry detergent. Congratulations, you’re in the safe zone, so you don’t need to do anything, right?
Not necessarily. If the vulnerability that you have is shared with others, then the attacker can aggregate all of you at a very small increase in cost. To the attacker, all of the victims aggregate to a single high value at low cost. To the attacker, it’s trading the one diamond ring for a million years’ supply of laundry detergent. The attacker can open a store online to sell the excess and really clean up! Collectively, then, you are represented by the red dot…very high value in aggregate, at a small increase in cost over attacking you alone. So you’re not really in the safe zone at all. You’re deep in the danger zone!
A real world example of this is the use of vulnerabilities in Windows to create botnets. The same vulnerability existed on millions of machines, so even though a single bot is of sufficiently low value as to render the individual machine safe (i.e., where the green dot is), the low additional cost of applying that same attack to millions of machines made the attack worthwhile to an attacker. Collectively, the botnet is represented by the red dot.
But you don’t even need to have exactly the same software across multiple machines in order for amortization to work. An entire class of vulnerability, such as SQL injection, can benefit from amortization. So even if you write your own application, to be used in a single installation, on a singularly low-value machine, you can still find yourself a member of the collective dreaded red dot!
If you’re a member of such a group, increasing the cost to an attacker pays even bigger dividends. By applying the SDL, you can improve your security, pull you out of the group, and therefore move you up the graph. Furthermore, as you increase your differentiation from the herd, you become harder to aggregate, which (from the attacker’s perspective) moves you to the left as well. The rest of the group you left behind can be bear food.
So you can see that it’s not only unnecessary to outrun the bear, but it’s also not necessarily enough to be faster than the other guy. By applying a systematic, thorough approach to security, such as through the SDL, you can become hard enough to attack that you can significantly reduce your risk.
[Bryan here. We have a guest blogger this week: Chris Weber of Casaba Security will be talking about his company’s new free web application security auditing tool, Watcher. We on the SDL team are pretty excited about it, especially because it verifies several SDL requirements and recommendations that we previously had no automated tool support for. We’re also looking at the possibility of incorporating Watcher as a new SDL recommendation in a future version of the SDL.]
Hi everyone, this is Chris Weber of Casaba Security writing a guest blog post to tell you about our new Watcher tool for web-app security auditing and testing. Watcher is a plug-in for Eric Lawrence’s Fiddler proxy aimed at helping developers and testers find security issues in their web-apps fast and effortlessly. Because it works passively at runtime, you have to drive it by opening a browser and cruising through your web-app as an end user. For the developer, the tool can provide a quick sanity check, so you can find problems and hot-spots that warrant further attention. In the hands of a pen-tester it can assist in finding issues that lead to other attacks like XSS and CSRF.
So what does it find? In its first public release we shipped with more than 35 checks. Some of these checks provide coverage for Microsoft SDL requirements and OWASP recommendations. Some are informational and some identify hot-spots that might lead to vulnerabilities such as XSS. It aims to find issues that are obvious but sometimes hidden or overlooked. For example, Moxie Marlinspike recently talked at Black Hat and mentioned the insecurity of hosting an HTTP/S form inside of an insecure HTTP landing page. While there may not be visual indicators for this pattern in the browser, Watcher includes a check to report on it. Watcher looks for issues related to cross-domain mashups, user-controlled HTML (potential XSS), open redirects, insecure handling of cookies, Unicode, and other sources of vulnerability such as:
· Cross-domain stylesheet and javascript references
· User-controllable cross-domain references
· Potential XSS with user-controllable HTML attribute values such as href, form action, etc.
· Cross-domain form POSTs
· Cookies that don’t set the ‘HTTPOnly’ flag
· Cookies set over SSL that don’t include the ‘secure’ flag
· Loosely-scoped cookies
· Open redirects which can be abused by spammers and phishers
· Insecure Flash object parameters useful for cross-site scripting
· Insecure Flash crossdomain.xml
· Insecure Silverlight clientaccesspolicy.xml
· Charset declarations which could introduce vulnerability (non-UTF-8)
· User-controllable charset declarations
· Charset mismatches between HTTP and HTML
· Dangerous context-switching between HTTP and HTTPS
· HTTP pages insecurely loading HTTPS forms
· Insufficient use of cache-control headers when private data is concerned (e.g. no-store)
· Potential HTTP referer leaks of sensitive user-information
· Information disclosure from URL parameters
· Source code comments worth a closer look
· Javascript that uses eval functions
· Insecure authentication protocols like Digest and Basic
· SSL certificate validation errors
· SSL insecure protocol issues (allowing SSL v2)
· Unicode ill-formed UTF-8 byte sequences
· SharePoint servers with insecure configurations
· more….
This tool is planned for release under an Open Source license, and is designed for extensibility so that new checks can be added either in the main source or as individual assemblies. I’m hoping that some people may want to get involved in adding new checks and improving existing ones.
Setup is simple – install and run Fiddler, then launch the Watcher setup installer, or manually drop the Watcher DLL’s in Fiddler’s ‘scripts’ folder. Inside Fiddler, click Watcher’s “Security Auditor” tab and click ‘enable’. At this point the findings will start showing for any domain. To narrow things down, you’ll want to configure Watcher with the domain name you’re concerned about, and add any trusted domains you want to include. By narrowing things down, you’ll actually enable another set of important checks - the cross-domain checks. Domain names support wildcards like *.contoso.com, and even simple regex patterns so you could just type in ‘contoso. For reporting, Watcher writes out to a list view table, including severity levels and a link back to the detailed request/response in Fiddler. The findings can be sorted, filtered, and exported to XML. A screenshot of the reporting interface is below.
You can download the Watcher binaries and sources, access bug tracking, forums, and documentation at http://websecuritytool.codeplex.com/. Be sure to first download the Fiddler tool from http://www.fiddlertool.com/.
I hope some of you can find it as useful as we have – please drop a message on the CodePlex forums, or send an email to me with questions, ideas for new checks, or feedback. Happy bug hunting!
Hi everyone, Bryan here.
Most web application security experts frown on the practice of passing session or authentication tokens in a URL through the use of URL rewriting. Usually these tokens are passed between the server and the browser through HTTP cookies, but in cases where users configure their browsers to not accept cookies, this is impossible. Some web application frameworks – including ASP.NET – will detect this condition and revert to the cookieless URL rewriting method for passing session tokens. For example, a user who requests the page http://www.contoso.com/welcome.aspx would be redirected to http://www.contoso.com/{SID}/welcome.aspx, where {SID} is that user’s unique session identifier.
Again, most web application security people will tell you that this technique is fraught with peril. It can lead to session hijacking vulnerabilities (a man-in-the-middle sniffs the session identifier out of the URL) as well as session fixation vulnerabilities (an attacker creates his own session and tricks a victim into using it). I once identified enabling cookieless sessions as one of the top ten configuration mistakes made by ASP.NET developers. However, if we make one small change in the way we perform the URL rewriting, it becomes a powerful technique for improving security rather than weakening it.
Instead of rewriting the session id into the URL, we keep the session id in a cookie as usual, but add a second unique token (a “canary” token) into the URL. At the same time, we associate this new canary value with the session id and store it in server session state. Whenever the user makes a request back to the server, the request must include the matching canary or the server will consider the request a forgery. Some diagrams might help explain this a little better.
In step one, I make an initial request for a page on www.contoso.com. The Contoso server creates a new session id for me and stores it in the response cookie. The server also creates a new canary value, stores it with the session id in its server-side session state, and writes it into the URL.
In step two, I request a new page. The browser automatically includes the session cookie and the canary value in the request. Before the server processes the request, it checks to ensure that the canary value is present and that it matches its own stored value. The check succeeds, and the server processes the request.
This technique not only helps to prevent the session fixation vulnerability I talked about earlier, but also these dangerous vulns:
· Cross-Site Request Forgery
· Open-redirect phishing
· Some forms of Cross-Site Scripting (XSS)
In the cases of open-redirect phishing and XSS, the canary rewriting technique does not actually fix the vulnerabilities, but it does limit their exploitability. These types of vulns are usually exploited through email: the attacker crafts a malicious hyperlink and then sends it out to potential victims. However, since an attacker cannot include a corresponding cookie value to match the text in the hyperlink (and thus the session id would not match any inserted canary value) the server would reject the request.
For example, let’s say that there is an XSS vulnerability on contoso.com, and the evil hacker Michael tries to exploit it by sending me a malicious hyperlink. Since Michael cannot know ahead of time what my canary token is, even if I do click through the link – which is unlikely, given that I know better than to follow URLs that Michael sends me – the server will still block the request since the tokens won’t match.
There are definitely shortcomings with this technique. One unfortunate side effect of preventing attackers from emailing malicious links is that legitimate users are similarly prevented from emailing benign links, or even from bookmarking links for future access. Also, this defense does nothing to prevent session hijacking through man-in-the-middle attacks. Given these shortcomings, I definitely would not consider using URL rewriting as my only defense against XSS/XSRF/etc, but I think it could make sense as a defense-in-depth measure for sites with high security assurance needs.
If you’re interested in reading more about this idea, I explain it in further detail in the Security Briefs column of the March 2009 issue of MSDN Magazine. I also discuss alternative methods, including a method for implementing a similar defense for stateless applications such as web services. I’ve included C# source code so you can use these defenses in your own ASP.NET applications.
(bryansul standard disclaimer: The methods and techniques discussed in this article should not be construed as official SDL requirements. They are simply ideas that we’re developing to help you create more secure software. If you have any feedback, we’d be happy to hear it.)
Michael here...
Security is a never-ending game of leapfrog as attackers work out ways around our defenses and we defenders constantly update defenses.
At Microsoft, we always try to chose the most appropriate way to place one or more defenses; some defenses are in the Windows operating system, and some are in the compiled code. One well known defense in Visual C++ is /GS <http://msdn.microsoft.com/en-us/library/8dbf701c.aspx>, which adds random data to a function’s stack to make it harder to successfully pull off various forms of stack-based buffer overrun, and in Visual C++ 2010, we have upgraded the /GS heuristics substantially.
Rather than explain it all here, the Security Research & Defense <http://blogs.technet.com/srd> team has written an excellent article <http://blogs.technet.com/srd/archive/2009/03/20/enhanced-gs-in-visual-studio-2010.aspx> explaining how /GS is improved in VC++ 2010.
It’s important to remember that /GS is just one SDL-mandated facet to help secure code:
- Run with least privilege- Use Address Space Layout Randomization- Use NX (aka DEP)- Use safe exception handling- Remove banned APIs and replace them with safer APIs- Fuzz the code
- Much more...