The recent release of the “Securing Cyberspace for the 44th President” report spawned a flood of analysis and criticism, and much of it was positive and complimentary. I’ve written before about the idea behind this report and the fact that many, if not most, of the recommendations in it can also be found in the National Strategy to Secure Cyber Space, which was released nearly six years ago. That document has been largely ignored and we have all been paying the price in the interim. The federal government’s virtual abandonment of cybersecurity policy in the last eight years has left all of us more vulnerable, and will end up costing the government, and taxpayers, far more money in the long term.
In reading the various analyses of the report, I found that many people were commending the commission for suggestions that either have failed in the past, or have little chance of working now. I ran across Steve Bellovin’s blog post on the report and it came as no surprise that his analysis was right on the money. Bellovin’s as smart as they come, and it’s worth the time to read through his entire post on the report, but in the meanwhile, here are a few key points:
The analysis of the threat environment is, in my opinion, superb; I don’t think I’ve seen it explicated better. Briefly, the U.S. is facing threats at all levels, from individual cybercriminals to actions perpetrated by nation-states. The report pulls no punches (p. 11):
America’s failure to protect cyberspace is one of the most urgent national security problems facing the new administration that will take office in January 2009. It is, like Ultra and Engima, a battle fought mainly in the shadows. It is a battle we are losing.
That’s it exactly. In fact, it’s a battle we’re not even fighting right now.
The most important technical point in this report, in my opinion, is its realization that one cannot achieve cybersecurity solely by protecting individual components: “There is no way to determine what happens when NIAP-reviewed products are all combined into a composite IT system” (p. 58). Quite right, and too little appreciated; security is a systems property. The report also notes that “security is, in fact, part of the entire design-and-build process”.
It should be, but that hasn’t been the case in many systems for far too long. Bellovin then skewers what has been the dominant federal strategy for remedying this problem:
The discussion of using Federal market powers to “remedy the lack of demand for secure protocols” is too terse, perhaps by intent. As I read that section (p. 58), it is calling for BGP and DNS security. These are indeed important, and were called out by name in the 2002 National Strategy to Secure Cyberspace. However, I fear that simply saying that the Federal government should only buy Internet services from ISPs that support these will do too little. DNSSEC to protect .gov and .mil does not require ISP involvement; in fact, the process is already underway within the government itself. Secured BGP is another matter; that can only be done by ISPs. However, another recent Federal cybersecurity initiative — the Trusted Internet Connection program — has ironically reduced the potential for impact by limiting the government to a very small number of links to ISPs. Furthermore, given how many vital government dealings are with the consumer and private sectors, and given that secured BGP doesn’t work very well without widespread adoption, U.S. cybersecurity really needs mass adoption. This is a clear case where regulation is necessary; furthermore, it must be done in conjunction with other governments.
Bellovin also criticizes the report for calling on the Obama administration to protect online privacy without providing any guidance as to what that means or how to do it. But he leaves the best for last: the omission of any mention of software security and its cascading effect on system and network security.
The buggy software issue is also the problem with the discussion of acquisitions and regulation (p. 55). There are certainly some things that regulations can mandate, such as default secure configurations. Given how long the technical security community has called for such things, it is shameful that vendors still haven’t listened. But what else should be done to ensure that “providers of IT products and systems are accountable and … certify that they have adhered to security and configuration guidelines?” Will we end up with more meaningless checklists demanding antivirus software on machines that shouldn’t need it? Of course, I can’t propose better wording. Quite simply, we don’t know what makes a system secure unless it’s been designed for security from the start. It is quite clear to me that today’s systems are not secure and cannot be made secure.
The Internet Explorer vulnerability saga continues to unfold. Microsoft late Thursday released more information about the unpatched XML flaw in IE, and confirmed that the vulnerability in fact affects all supported versions of IE, not just IE 7 as previously thought. Microsoft Malware Protection Center officials said the company has seen exploits against the vulnerability in the wild, including attacks against both home and enterprise users.
The exploit sites we’ve seen so far drop a wide variety of malware — most commonly password stealers like new variants of game password stealers like Win32/OnLineGames and Win32/Lolyda, keyloggers like Win32/Lmir, Trojan horse applications like Win32/Helpud along with some previously unseen malware which we generically detect as Win32/SystemHijack. We fully expect the variety of malware being dropped by this exploit to broaden as the exploit code starts to circulate around the Internet underground.
This issue could impact you even if you avoid surfing questionable sites. Over the past few months, we’ve seen a surge in SQL injection attacks which enable miscreants to inject content onto trusted sites (we even blogged about the technique a few months ago). This class of attack, along with other more classical forms of website intrusion, mean that even trusted sites can end up serving malicious content causing you to get infected.
Microsoft’s Security Response Center has added more information about the attacks and workarounds to its advisory, as well.
We’ve also added additional workarounds to the advisory and updated our guidance to recommend that you evaluate implementing two of the workarounds together for the most effective protection. Specifically, we’re recommending both setting the Internet zone security setting to High and using ACLs to disable Ole32db.dll. Our research so far has shown that these two steps together provide the most effective protections for this issue.
Microsoft has released a security advisory with a suggested workaround for protecting vulnerable machines against attacks on the unpatched XML vulnerability in Internet Explorer 7 that came to light earlier this week. The advisory suggests that customers at risk from the attacks do several things: enable DEP, set the Internet and intranet security settings to high, and configure IE to prompt the user before running active scripting, or disable active scripting altogether in the Internet and local intranet security zones.
Microsoft said it’s seen limited attacks against the vulnerability, and there are numerous reports or working exploits being seen in use. In its advisory, Microsoft confirmed that IE 7 on Vista and Windows Server 2008 is vulnerable to this attack, as are machines running XP SP2 and SP3 and Windows Server 2003. However, the company also said that running IE in protected mode mitigates the vulnerability. Microsoft did not rule out the possibility of issuing an out-of-band patch for the flaw.
We are actively investigating the vulnerability these attacks attempt to exploit. We will continue to monitor the threat environment and update this advisory if this situation changes. On completion of this investigation, Microsoft will take the appropriate action to protect our customers, which may include providing a solution through a service pack, our monthly security update release process, or an out-of-cycle security update, depending on customer needs.
If the attacks continue to build, Microsoft may issue an emergency fix, given they just released their patches for December and it will be nearly a month before the next set of regular fixes are released.
Window Snyder, the head of security at Mozilla, is leaving the company to help found a start-up venture unrelated to security. Snyder has been at Mozilla for more than two years and has been the driving force behind the company’s effort to make security a top priority in its popular Firefox browser.
Snyder’s departure is a blow to Mozilla, a small organization that counts on participation from the open-source community for much of its work. Snyder has helped raise the company’s profile in the security community and made transparency about security issues a key initiative. The company currently is working on a security metrics project with security analyst Rich Mogull of Securosis that is designed to measure the relative security of Firefox in a number of different ways.
It’s unclear who will be replacing Snyder, whose official title never evolved beyond the “chief security something-or-other” she came up with when she was hired. Snyder said she is not yet ready to talk about her new venture, but said it is something she is passionate about. When she joined Mozilla in 2006, Snyder was already one of the more visible personalities in the security community, having spent several years at Microsoft and at @stake before that. During her time at Microsoft, she was one of the key players in the development of Service Pack 2 for Windows XP, a massive security upgrade that was one of the first results of the vendor’s Trustworthy Computing program. After leaving Microsoft, Snyder did a short stint at Matasano Security, a consultancy.
Mogull, who has been working on the metrics program with Mozilla for several months, said he’d been impressed with the way Snyder had worked to make security a priority within the Mozilla community. “I think she’s done a great job. I mean, think about the challenge she faced going into that,” he said. “It’s an open-source project and she’s trying to put in a structured security program in an open-source environment. It’s not the same as a commercial software company where you have very rigid processes. It’s a very engaged community and that’s one of the reasons I was so excited to work with her. She broke new ground in combining the technology for developing secure software with a project like this.”
On the same day that Microsoft patched a slew of vulnerabilities in Office and other products, including Internet Explorer, the tubes were abuzz yesterday with news of a new exploit for IE 7 that was being used against fully patched Windows XP and Windows 2003 systems. Early reports of the attack said that it was affecting mainly users in China and other Asian countries. But there are now reports of it moving into other areas as well, and it’s likely to spread quickly.
The attack is related to the way in which IE handles XML. Microsoft is investigating the issue right now. From the excellent analysis of the attack and exploit by H.D. Moore:
The exploit can be broken down into three parts. The first part is a set of three functions used by the exploit. The first function provides the equivalent of a sleep() call, the second sprays a string into the process heap using a common technique, the third returns a string of a specific size and is used by the heap spray code. The second part of this exploit is the shellcode. Without getting into too much detail, this shellcode downloads the real payload – a Windows executable. The third part is the actual vulnerability trigger.
Exploiting this flaw relies on two core requirements; being able to force the instruction pointer to the location of the shellcode and being able to execute the shellcode once the instruction pointer has been set. The first requirement boils down to being able to allocate memory at a known location with arbitrary contents. If it is possible to control the exact location where memory is allocated, a large buffer that doubles as a nop sled is no longer necessary. The second requirement depends on the operating system, configuration, and hardware of the target system. Many of the articles that discuss browser exploits recommend that users enable Data Execution Prevention (DEP). This setting essentially breaks common heap overflow techniques by preventing shellcode from executing in memory regions that are considered “data,” such as the Internet Explorer heap. Unfortunately, DEP is not enabled in Internet Explorer 6 or 7, so unless DEP is manually enabled, it does the target little good.
Microsoft has shown a willingness recently to issue emergency out-of-band patches for critical vulnerabilities, but it likely will be several days at least before we know whether that’s going to happen.
Google has been working on a new technology that is designed to help developers create more secure and interesting Web applications that can run on any platform. Known as Native Client, the technology is still in the development stages, but Google is now making it available to developers and security specialists in the hopes that they’ll kick some holes in it and help make it more useful.
Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system. The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly. With reliable disassembly as a tool, it’s then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself.
Interesting approach from Google. One thing that’s important to note here is that Google obviously isn’t doing this out of the goodness of their hearts. Just as Microsoft for years has focused its efforts on getting as many developers as possible working on Windows-compatible projects, Google is interested in Web developers writing browser- and OS-independent applications. Google has its own browser now in Chrome, and while it doesn’t yet have an OS in the wild, it has just about everything else, including persistent rumors of an OS in the works.
So there’s motivation aplenty here and Google continues to do pretty well on the transparency scale. But there’s certainly a number of other security issues facing the company. Malicious search results continue to be a major problem, as does click fraud. But those aren’t solely Google’s problems either.
After being criticized for years for being completely opaque and obtuse about virtually everything that goes on inside the walls in Redmond, Microsoft has swung pretty far in the other direction lately, at least when the topic is security. The company has been very open about the processes and tools that it has used in its Trustworthy Computing effort, to the point of releasing books on its software security practices and inviting outside experts in for its semi-annual Blue Hat confabs. Microsoft’s latest effort in this long, drum-banging, kimono-opening, insert-evangelism-cliche-here process isa series of videos recorded during the invitation-only Blue Hat meetings. The company has posted a number of them on its TechNet site, including a video on Microsoft’s threat-modeling process, starring Adam Shostack.
The video, which also includes a segment with Danny Dhillon, a senior security consultant at EMC, explaining the company’s threat-modeling program, has a pretty good, if quick, overview of Microsoft’s program. Shostack spends much of his time in the video comparing Microsoft’s and EMC’s programs, which he says are “remarkably similar.” The companies have different terminologies and structures, but the basic ideas and goals are the same. The great thing about this video, as well as the others Microsoft has posted, and the other assorted content it’s been churning out related to its SDL and other processes, is that it can serve as a nice, free education for developers. For the vast majority of development organizations without the resources that Microsoft has, this content can be a great foundation for further investigation. Think of it as the technical equivalent of those free online courses from MIT.
Video of the rest of the sessions from the fall Blue Hat meetings are online as well, so take advantage of Microsoft’s legwork and largess and feed your mind.
VMware on Wednesday issued two security advisories, including one that fixes a critical memory corruption vulnerability that affects a wide range of the company’s products. The memory corruption vulnerability allows an attacker to send a malicious request from a guest operating system to the virtual hardware on a vulnerable machine, which could give the attacker the ability to write to uncontrolled physical memory, according to VMware’s advisory. The flaw affects ESX, ESX1, Fusion, ACE, Player, Workstation and VirtualCenter.
The second update VMware issued is a new version of the service console package bzip2. In vulnerable implementations, the flaw can cause applications to crash when they’re decompressing malformed archives. This problem affects several versions of ESX, the company said.
After a few delays, ICANN has officially transferred all of the domains that formerly belonged to registrar EstDomains to another registrar in response to EstDomain’s president being convicted of several crimes earlier this year. ICANN, which governs the use of top-level domains and accredits domain registrars, said it is transferring the domains that had belonged to EstDomains over to Directi Internet Solutions. The action comes more than a month after ICANN originally notified EstDomains of its decision to de-accredit the regitsrar, which is based in Estonia. The company has been linked to a number of malware distributors and has been a target of security researchers and antispam activists for years.
EstDomains was informed on 28 October 2008 that ICANN was terminating the company’s accreditation due to its president’s conviction for credit card fraud, money laundering and document forgery. ICANN stayed that termination following correspondence with EstDomains. However, after further investigation, ICANN decided to go ahead with the termination, effective yesterday, 24 November 2008.
In accordance with the De-Accredited Registrar Transition Procedure, ICANN put out a request for statements of interest from registrars interested in receiving a bulk transfer of the names formerly managed by EstDomains.
As part of that procedure, EstDomains is permitted to designate a gaining registrar. It chose to use that option and identified ICANN-accredited registrar Directi. ICANN reviewed that request and approved it.
Earlier this year, Directi was implicated as helping to control EstDomains, but that report was later dismissed and Directi and the group that put out the report, HostExploit, have been collaborating on actions to try and stop domain registry abuse.
More than a month after releasing an emergency patch for the MS08-067 RPC vulnerability, Microsoft on Tuesday warned that it is seeing increased levels of attack activity against the flaw. The company said there is a new worm, being called Win32/Conficker.A, which is exploiting the RPC flaw and spreading in both enterprises and in home-user environments. Conficker opens a random TCP port between 1024 and 10000 and then starts exploiting the MS08-067 vulnerability on other PCs on the network.
Once the remote computer is exploited, that computer will download a copy of the worm via HTTP using the random port opened by the worm. The worm often uses a .JPG extension when copied over and then it is saved to the local system folder as a random named dll. It is also interesting to note that the worm patches the vulnerable API in memory so the machine will not be vulnerable anymore. It is not that the malware authors care so much about the computer as they want to make sure that other malware will not take it over too.
This is the second piece of automated malware that has cropped up to attack the MS08-067 weakness. In the days immediately following Microsoft’s release of the patch last month, a worm called Gimmiv appeared and began exploiting the same flaw. The level of attacks against this particular flaw aren’t surprising, given the fact that it exists in every supported version of Windows and was severe enough for Microsoft to issue one of its unusual out-of-band patches.