Security and Risk Management Strategies Blog

On Response

Blogger: Eric Maiwald

Prevention is hard. If we want to protect something important, we put it in a locked room. But a thief with a lock pick can defeat the lock. So we change the lock to something hard to pick. That works until the thief shows up with tools and takes the door off. We escalate to a safe with heavy steel construction that is anchored to the floor. The thief shows up with tools to drill the safe and given enough time, the thief will win again.

The same is true about preventing hackers and other criminals from breaking into our computer systems. As Dan Blum noted in last week’s blog "Can't Win the Core Wars," the war of preventative measures versus attack methods escalated at Black Hat 2008 with the publication of techniques to get around Microsoft’s latest protective measures. Prevention is hard.

What else can we do to control negative consequences (and manage risk)?

We can examine how we detect and respond when preventative measures fail. This is not a call to remove preventative controls – they certainly have their place – but we must understand that we will not win a continuing war of escalation. Deploying a greater variety of preventative controls does not reduce our overall risk in the long term (sure – it might in the short term but only until the criminals come up with a new attack technique or find a new vulnerability).

Just about every enterprise already uses response to help manage risk. Think about disaster recovery plans, business continuity plans, backup tapes, etc. All of these security controls are built to help an enterprise respond to an event that cannot be prevented. We cannot prevent hurricanes, floods, earthquakes, and tornados so we build plans and capabilities to respond to the event and limit the negative consequences to the business.

We can do the same things around other events. For example, we can detect a malware infected desktop by monitoring the traffic that is sends on the network. If we see inappropriate traffic originating from a desktop, we can take it off the network and send a team to repair it. (Think about a team in black jumpsuits arriving at an office, “step away from the computer and leave your mouse where we can see it!”) The same type of thing can be done to detect and respond to other types of attacks. We can identify a compromised web server by monitoring it for unauthorized changes. If we see some files change, we can replace them with the correct files or take the server off-line to be reloaded.

Of course, the response must be appropriate to the risk the event poses to the enterprise (don’ forget about the consequences of negative publicity!) and we cannot respond to an event in such a way that we cause more damage than would have occurred had we not responded. Here (yet again), we may be able to better manage risk by understanding the business implications of security events. If we understand when negative consequences begin to occur and how they affect the business, we can create response plans appropriate to the event. We can also weigh preventative measures vs. response plans and determine which is most appropriate to the business risk (there are some risks where prevention is still the most appropriate security posture).

So in the end, don’t always think of prevention as the only way to deal with risk. Detection and response can be an appropriate posture for certain types of risk. In some cases, using response can be more cost effective than installing the latest and greatest preventative tool.

Can’t Win the Core Wars

Blogger: Dan Blum

Core Wars is a game in which two or more battle programs compete for the control of a simulated computer. The battle programs are written in an assembly language. The object of the game is to terminate the opposing program(s), generally by overwriting them, leaving your program in control.

Core Wars also go on in real life. The early 2000s saw a number of notorious worm programs (Nimbda, Code Red, Slammer, Blaster) performing buffer overflow and other memory-overwrite attacks to seize control of Windows computers and spread themselves all over the Internet. Today, the game goes on, and has in fact become a livelihood for burgeoning numbers of cybercriminals.

Facing the attackers are Windows, IE, Firefox, and other third party security programs on the defense. One defensive strategy is to harden legitimate code so that it is more difficult for attackers to overwrite memory and seize control. When Vista shipped, many thought that Microsoft may have won some rounds for the good guys with low level memory-based protections: data execution prevention (DEP), address space layout randomization (ASLR), and the /GS compiler switch for improved stack protection as well as other code integrity checks.

However, at Black Hat USA 2008, Alexander Sotirov and Mark Dowd released the “Bypassing Browser Memory Protections” paper, which announced new breakthroughs against DEP, ASLR, and /GS. In hindsight, the industry should have seen the breakthroughs as more inevitable than we did, and it is clear that we need to do more on defense to keep attackers at bay. But first it is important to clarify what Sotirov/Dowd’s research means, for there has been much confusion in the press, with some saying the sky is falling and others saying its nothing new. The truth lies somewhere in between.

First, some background on the main low level memory protections that can be used with Windows Vista, Windows Server 2008, and (in some cases) XP:

• /GS generates code causing functions to check for overwrite of return addresses on the stack, as might occur during a buffer overflow attack
• SAFESEH triggers validation of pointers to exception handler routines, trying to prevent them from being overwritten (for example, with pointers to exploit code)
• DEP prevents the execution of code in memory pages marked non-executable; this is designed to stop attack code written to the stack or heap from being executed
• ASLR randomizes the addresses where objects are loaded in the virtual address space of a given process; without knowing memory locations in advance, exploits are more difficult to develop

These protections are implemented through a combination of compile/link options, compiled code, OS program loader options, and (in the case of DEP) hardware CPU features.

Sotirov/Dowd described attacks against the low level protection technologies starting with exploit code aimed at the Internet Explorer 7 browser, but the paper also wrote extensively on reusable types of exploits possibly applicable to other Windows programs. The paper claims the authors have demonstrated the following types of exploits against memory:

• From Javascript - spray the Internet Explorer heap with 100 MB of shellcode to bypass ASLR if it is enabled; jump into the shellcode by overwriting the return stack pointer. If the stack is protected by /GS, overwrite an exception handler record and trigger an exception.
• Flash code reuse – if both DEP and ASLR are enabled (in Vista or Windows Server 2008), bypass ASLR by exploiting DLLs which are loaded at a fixed address in the browser address space. Many popular browser plugins, including the latest versions of Flash, are not compatible with ASLR. The exploit bypasses DEP by creating stack frames in a way that causes Windows memory management routines to mark selected heap pages (where shellcode has been written) as executable.
• Java Runtime Environment (JRE) plug-in to IE - Spray the Java heap with shellcode until an out of memory error is caused (after over-writing the exception handler to point into the heap). Memory pages in the Java heap are already marked executable, for compatibility with certain programs.
• Exploit .NET executable binaries that implement some of the UI control functions. It is also possible to spray large copies, or multiple copies of the .NET binaries into the address space so as to defeat the randomization process when ASLR is enabled.

My two big takeaways after reading Sotirov/Dowd are these:

1. We’re not winning the core wars: Low level memory protections in Windows (while useful) were not as decisive as we hoped. While over time more programs will use /GS, DEP, SAFESEH, and ASLR – making these mechanisms more effective in combination with each other– there will still be room for exploits because there are still too many holes in the OS architecture.
2. Don’t put too much trust in browsers: As Burton Group’s Ramon Krikken put it in his “browser is sick” post last week, browsers suffer from bloat and compatibility problems – just like the underlying OS. Sotirov/Dowd cite the degree to which the browser state can be controlled by the attacker, and the extensible plugin architecture of modern browsers as two reasons why they are such juicy targets.

Where do we go from here? For now, the defensive team can’t win the core wars, but when we own the computers under attack we can cheat; we can make the playing field less favorable to attackers.

As a case in point, Sotirov/Dowd wrote that their vulnerability testing all started by exploiting the ANI vulnerability in the Windows animated cursor functionality to get a toehold on the system.

Now I ask: what is the business purpose of an animated cursor? Get rid of all that nonsense and lock down systems so that users have less privilege, fewer programs, and less extensibility.

But the ultimate solution, if there is one, will take more than lock down. First of all, lock down isn’t always possible in business environments. Also, businesses must interact not only with the managed systems they control, but with many unmanaged ones as well.

As a longer term solution, it would be great if OS vendors did more memory segmentation, reduced kernel sizes, and implemented sensible ring transition architectures as well as system integrity requirements for privileged applications. Virtualization - providing memory segmentation between slimmed-down, locked-down virtual machines performing specific tasks – may be the next great hope to help us fare better in the core wars. For an even more radical solution to the endless woes of general purpose OSs see the Slidecast - Security Architecture in a Deperimeterized World.

The web browser is sick … but where’s the cure?

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

Location, location, location. . .

(. . .it’s not just about real estate any more)

[blogger: Trent Henry]

Location services and presence aren’t particularly new. For many years, innovators have realized that where-you-are can be a useful piece of information for delivering consumer IT services. If your cell phone knows it’s in a movie theater, for example, it can automatically turn itself to vibrate or quiet mode. Or, if you make an emergency call, a GPS unit in the cell phone can inform responders where you’re located (the heart of the E911 service). These have been topics of discussion among the converged communication crowd for some time. In fact, even associated security issues have been considered for years: in 1997 Leonhardt and Magee wrote “Security Considerations for a Distributed Location Service.”

However, as with so many things, risk seems to follows utility. That is, vendors have spent considerably more time building location/presence functionality, and dreamers have been thinking about cool uses for it, far more than anyone has pondered the security ramifications.

Enter the iPhone.

Suddenly presence is going to be center stage—not because of newness, but because of ubiquity and richness. With millions of these devices marching around the globe, iPhone 2.0’s Core Location Framework becomes a tantalizing target to consider attacking. And to be honest, as an industry we really don’t understand the threat landscape very well.

I’m not going to create a laundry list of possible security issues here. Without more technical detail, it’s difficult to know what will be feasible and what won’t. And detractors love to argue about a vulnerability being “merely theoretical” (until something bad happens, that is). But we do need to think about WiFi and GPS presence combined with full-featured local applications combined with rich web services. This combination can really change the playing field. How about a microblogging client that automatically tracks and publishes location for you and your 50 closest friends? It’s pretty interesting information to know when 50 people converge on a given location at a given time. Such a service isn’t unrealistic (twitter.com), and it reminds me of concerns about RFID-enabled passports used as bomb triggers (ZDnet report).

The flip side, of course, is using location to augment security. For example, an enterprise might check device location before allowing wireless network admission: “Why is this system trying to connect when it’s not even in my building?” But for now I’m more concerned about possible security holes. In an era of increasing industrial espionage, it would be pretty interesting to know that a key person’s laptop or other device was in-country.

Here’s the fundamental problem: It’s not location/presence security itself that’s insecure—the Apple framework requires user intervention for an app to consume location, and it can be turned off altogether. And a web service that shares location data among groups of people or applications may have adequate protections. But bring these pieces together, and mix in the increasing amount of web-based malware and site hijacking taking place, and we need to pause to consider the new risk.

Who’s responsible for such a high-level view? Well, unfortunately, no one. But enterprises would do well to think carefully about employees’ use of location services. And individual consumers should replace a mindset of “whoa, that’s cool,” with “what exactly am I revealing?”