Application Security

Should states lead the charge for secure application development?

I’m not a big fan of states’ rights, which made a lot more sense in 1791 than they do today (Why should one state’s misdemeanor be another state’s felony? Why is a gay couple married in one state and unmarried when they drive over the state line?).

My 18-year-old son wonders why I vote Republican and sound so much like a Democrat. I guess it’s because I like standards but don’t like government spending a lot of money on what it thinks will improve people.

I also share Gary McGraw’s skepticism about Top 10 lists Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.

So it’s hardly surprising I have mixed feelings about New York state’s plan to use the freshly minted CWE/SANS Top 25 Dangerous Programming Errors list, as a key requirement of its procurement enforcement requirements for software developers.

But while we can quibble over the value of this list or that list, what I do like is that it is incorporated as a component of the Application Security Procurement Language, drafted by New York CISO William Pelgrin and posted on the SANS website. The critical point is that if and when the procurement requirement is adopted, developers of custom software will be held accountable. They’ll be required to demonstrate that security is a core element of their application development lifecycle, from coding thru final pen testing if they want to do business with New York.

What gives me pause, though, is that we’re likely to see a cascade of initiatives in many states, a la the breach disclosure laws that followed California SB 1386 and what we will no doubt see in the wake of the new Nevada and Massachusetts data protection laws. I’d rather see federal standards that can be applied across state borders. The states step into the, ahem, breach, because the feds are slow and/or reluctant to act. California enacted 1386 more than five years ago, and something like 42 states, the District of Columbia and Puerto Rico have followed suit, while a variety of bills have been introduced, debated and left to wither in Congress.

Companies doing business with customers in more than one state (that is, almost everyone except Sam’s Hardware over on Sycamore Street, that Sam III runs since Sam, Jr. retired 20 years after he took over from Sam, Sr.) have had to develop policies and procedures that fit the most stringent of these laws–and they’re relatively straightforward.

What happens when we start to see a smorgasbord of data protection laws (consider that Massachusetts law, which is to go into effect in May is far more demanding than Nevada’s). And secure software development? Now that’s complex. Will one state adopt the SANS guidelines and another, perhaps, insist on incorporating the secure development lifecycle directive being drafted by NIST? Will one state require developers to expunge the SANS 25, another the OWASP Top 10, and yet another an assortment from among the 700 or so errors that can leave code vulnerable?

So, applause to all who try to put teeth into security. Now if it wasn’t like pulling teeth to get everyone pulling together.

Unpatched Internet Explorer 7 flaw under attack

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 asks for help on Native Client security

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.

Inside the Microsoft SDL and threat-modeling process

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.

Penetration testing without the penetration

When the subject of penetration testing and security assessments comes up, it usually conjures thoughts of highly skilled consultants deploying an array of custom tools to gather information on a target network and look for potential weak spots. But there are a number of guys out there doing these assessments who are using less-technical methods and putting the Web’s seemingly boundless stores of information to use instead. Chris Gates is one of those guys, and he gave a fascinating talk on his methods at ToorCon over the weekend, telling the audience that tools like Maltego and Metagoofil can be invaluable in gathering data on a target network.

Maltego, which finds, organizes and displays information on specific networks and reveals the relationships among companies and individual people, can be a tremendous resource, he said. “I can start with mail servers and name servers and get all the domains on those servers and then move onto netblocks,” he said.

Gate also said that programs such as email harvesters can be great sources of information on a company’s employees, as can social networking sites such as LinkedIn, Facebook and MySpace. That’s not a huge revelation, but using information gathered on those sites in conjunction with the other tools Gates talked about can lead to major caches of data on specific employees or companies in general, all of which can then be leveraged to glean more information.

Also, be sure to check out the photos of ToorCon I took this weekend.

Firefox 3 security fixes released

Mozilla has released new versions of both Firefox 3 and Firefox 2 that fix a slew of security vulnerabilities, including at least one critical remote code-execution flaw. Firefox 3.0.2 fixes a weakness in the latest version of the browser that enables an attacker to run code of his choice on a vulnerable machine and even install rogue software. There are also several less severe vulnerabilities addressed in version 3.0.2.

Mozilla also released an updated version of Firefox 2, the older version of the browser that many people still use. Firefox 2.0.0.17 includes fixes for several serious code-execution vulnerabilities, as well as some less-serious flaws.

Are we more secure seven years later?

One of the after effects of the terrorist attacks of Sept. 11, 2001, was a hyper-awareness of security of both our physical and digital environments. This has translated into the creation of new government agencies (DHS, TSA), rafts of legislation and billions of dollars of venture capital investment in new security technologies. Leaving aside the wisdom of some of these laws and policy decisions, I think it’s worthwhile to consider whether all of this focus on, and investment in security technologies has in fact made us any more secure.

Speaking strictly about information security, I think it’s hard to say that things are much better right now than they were in 2001. They’re just bad in a different way. Seven years ago, our big problems were worms and viruses like Nimda, LoveLetter and Melissa and DDoS attacks that were taking down various e-commerce sites. The focus was on ways to improve antivirus protection, better anomaly detection in IDS and IPS systems and finding ways to better filter the traffic coming into your enterprise.

Now, we have an absolute cybercrime epidemic that makes Code Red and Nimda look like a joke. We have organized, well-financed and well-trained gangs of attackers who are using custom Trojans and rootkits to target very specific groups of victims and steal billions of dollars through credit card fraud and bank scams. And we have the little problem of widespread SQL injection attacks that are turning legitimate sites into malware servers. And those are just the big problems. We could also talk about the sad state of security on our critical infrastructure, thanks to the revolving door at DHS, not to mention the lack of education on software security happening at the university level.

How these problems are connected to the post-2001 boom in security investment and the creation of our culture of surveillance and security theater is less clear. But I would say first and foremost that we have been focusing on the wrong problems for much of this decade. While enterprises and vendors were worried about network security, firewall sandwiches and whether NAC would save the world, the attackers were focusing on the simple, ubiquitous flaws in Web apps and back-end systems that they can exploit to their heart’s content. They also were busy building massive botnets with sophisticated fast-flux infrastructures and peer-to-peer communications. Groups like the Rock Phish gang have been constantly honing their skills and testing new methods. What this means is that we are not only playing catch-up with the attackers, we’ve been playing a different game entirely.

I talked to Billy Hoffman of Hewlett-Packard Co. yesterday for the Nameless Security Podcast, and he made an excellent point about this disconnect. His contention was that sure the attackers have gotten smarter, more organized and more sophisticated, but we’ve also allowed them to become lazier by lowering the barrier for them to own a database or plant malware on whatever machine they choose.

So if throwing money at the problem hasn’t helped, what will? I’d say that money certainly can help, as long as it’s applied to the right problem. More funding from the government, private industry and other sources for security education for developers would be a good start, both at the university and professional levels. Ask Microsoft how that investment can pay off. But that’s just the beginning. What else can be done to get things going in the right direction? Let me know.

Security-stuffed Internet Explorer 8 beta 2 now available

Microsoft has just released Internet Explorer 8 beta 2 this afternoon. As I wrote earlier this week, this release of IE is filled to the gills with new privacy and security features, so much so that it looks to me to be as significant an upgrade as Service Pack 2 was for Windows XP. I haven’t had a chance to put it to work yet, but plan to do so this weekend. Like a lot of other people, I essentially stopped using IE altogether several years ago when Firefox 1.0 was released, and I haven’t really looked back since. At the time, Firefox represented a serious leap forward in security and reliability from where IE was. Microsoft has been steadily pushing that security rock back up the hill since then, and it looks like they’ve made some really good progress. And being the paranoid that I am, the privacy feature set in IE 8 looks mighty enticing, so it’s going to get a good tryout. We shall see. If you decide to check it out, let me know what you think.

Microsoft makes privacy a priority in IE 8

Microsoft is planning to add a significant number of privacy enhancements in Internet Explorer 8, including a new private browsing mode called InPrivate. The list of new features addressing privacy concerns is impressive and reflects the growing concern in the industry and the user community at large about the amount of private information that websites routinely collect from visitors, much of it without their knowledge. The most significant addition is the InPrivate browsing mode, which enables users to control whether IE saves a record of their online movements. In this mode, IE 8 will not save cookies, passwords, browsing history or any other record of the user’s browsing session.

As Microsoft’s Andy Zeigler explains:

While InPrivate Browsing is active, the following takes place:

• New cookies are not stored
  • All new cookies become “session” cookies
  • Existing cookies can still be read
  • The new DOM storage feature behaves the same way
• New history entries will not be recorded
• New temporary Internet files will be deleted after the Private Browsing window is closed
• Form data is not stored
• Passwords are not stored
• Addresses typed into the address bar are not stored
• Queries entered into the search box are not stored
• Visited links will not be stored

I love this. Love it. There are ways to accomplish virtually all of these things manually in the current version of IE, but it takes quite a bit of doing and let’s face it, most users are not going to take the time to go in and make all of the necessary adjustments. They’re just not. So giving them all of these features wrapped up in a neat little package is a nice move. The next beta version of IE 8, which is due for release by the end of August, also will include a feature called InPrivate Blocking that tells users when they’re visiting a site that may have some visibility into their browsing habits.

Also coming in IE 8 is a feature called InPrivate Subscriptions, which consumes special RSS feeds from Web sites that specify which content from those sites that IE will block. Obviously it remains to be seen how these features work in practice, but it certainly looks like Microsoft has taken Web privacy to a much higher plain in IE 8.

Pwnie Awards video is online

The guys behind the Pwnie Awards at Black Hat have posted a video of this year’s ceremony, which was full of hilarious moments. The highlight is Dan Kaminsky’s reaction to winning the Pwnie for most overhyped bug for his DNS discovery. Let’s just say he was less than happy about it. The Pwnie video may not be completely safe for viewing at work, at least without headphones. But it’s worth an hour of your time.