This month Aviv Raff is running a month of (third-party) Twitter bugs. The majority of these bugs are XSS or XSRF and allow attackers to send tweets on behalf of a victim. These third-party web sites are effectively offering open relays that provide spammers and malware authors with new distribution channels and as Aviv notes, these vulnerabilities can be used to create twitter worms too.

Of course, this class of problem isn't limited to Twitter. For example, Facebook also has an open API that allows third-party developers to write their own applications that run on the Facebook platform. When the Facebook API first came out, I took a quick look at it and remember noticing that they did a decent job of preventing HTML and JavaScript injection (at least they were thinking about security). Instead of allowing developers to insert arbitrary HTML, Facebook forces them to use FBML. However, that can lead to FBML Injection. Facebook even has its own query language FQL (similar to SQL), which opens the door to FQL injection.

In the end, even if your favorite social networking websites were secure and never fell prey to another vulnerability (yeah, right), we still need to contend with all of the third-party apps that use their APIs. API providers should include documentation about security in their developer guides. Twitter recently added a Security Best Practices page in their developer section, but I'd like to see security documentation in-line (explicitly included with code examples) rather than a footnote or reference section.

Who's reading this blog? The author(s) of Conficker, apparently. Here's the story.

 

Conficker's creators have a Ron Rivest fetish. Conflicker uses RC4, RSA, and MD-6 (details here) all of which are the work of Professor Ron Rivest. Last month we blogged about bugs in SHA-3 reference implementations (MD-6 included). This month Conficker C incorporated the MD-6 fix that Ron's group submitted to NIST.

 

Anyway, hello Conficker crew. F*** you very much for your attention.

Technorati Tags: Conficker SHA-3 MD-6

Over the last few months I have worked with a group of software security experts to develop the CWE/SANS Top 25 Most Dangerous Programming Errors. Working on this project has got me thinking about a key point that we make in Secure Programming with Static Analysis: Most of the people who build software are focused on things other than security (writing code, running test cases, deploying applications, and so on). These people are making security-critical decisions on a daily basis, but they can't afford to become security experts--they've got other things to worry about.

Security is a complicated field and we can't expect everyone to become experts. Software developers and architects, quality assurance testers, and operations engineers all have a wide range of responsibilities. As an industry, our best chance to develop secure software is to get non-experts making meaningful contributions.

We must enable non-experts to get security right. This means arming them with the right processes (building security into the software development lifecycle from the ground up), skills (teaching people to ask "What could go wrong?", not arcane security specifics), and tools (deploying static analysis in development, runtime analysis in QA testing, and active defenses in deployment).

The winds of change are blowing in the right direction. Top universities across the country are beginning to offer courses that either address or focus entirely on software security. Fortify currently works with over 50 universities by helping them incorporate software security into their course offerings and by granting them unrestricted academic licenses for classroom and research purposes. This offer is open to any college or university who wishes to participate.

Despite a sunny outlook, most people building software today have received no formal training on software security. Projects like the OWASP Top 10 and the CWE/SANS Top 25 focus attention on the problems that are causing the most pain, serve as fodder for training programs, and generally increase awareness among non-experts. Let's hope that projects like these continue to carry the banner for software security into the 21st century.

Masochist McGraw has gone and signed himself up for a second podcast: Reality Check. I was an early victim of his original Silver Bullet series: listen here. Reality Check is all about practitioners, and the first interview is with Steve Lipner. Steve runs the SDL group at Microsoft. A strong way to get started.

Java String objects are immutable, so you can't guarantee sensitive data is removed from memory if you put that sensitive data in a String object. Once data is in a String, it's up to the VM to deallocate the object and then put it back into play as something else, and that might happen sooner, later, or not at all.

That's why paranoid Java programmers don't put secrets (passwords, crypto keys) into String objects. Instead, they treat them as arrays of bytes or characters so they can manually zero out the juicy stuff. At first blush, it appears that Tomcat supports this level of paranoia in the org.apache.catalina.Realm interface:

    public Principal authenticate(String username, byte[] credentials) 

But the RealmBase class, the base class that everyone actually uses, just yanks the rug right out from under your feet:
org/apache/catalina/realm/RealmBase.java:

  342       public Principal authenticate(String username, byte[] credentials) {   343      344           return (authenticate(username, credentials.toString()));   345      346       } 

Yup, that's right, it converts your credentials (read: password) from a byte array into a String. It would be unthinking for Tomcat to provide no way to authenticate without using a String, but providing an interface and then intentionally subverting it seems like calculated cruelty.

Microsoft has an excellent security culture. Case in point: Michael Howard posted an in-depth explanation of the latest Internet Explorer bug including the key piece of code involved. Read it. Most organizations go to extraordinary lengths to bury a failure as quickly as possible, but Microsoft seems to understand that they have to really understand their failures if they hope to avoid repeating them.

But the big news here is the bug itself. It was use-after-free caused by a thread safety problem. C++ failed twice in one fell swoop: first, the programmer was forced to do direct memory management, and surprise surprise, eventually an object gets freed while there's still a pointer to it. Second, the use-after-free allowed an attacker to execute arbitrary code. That's a pretty high price to pay for a mistake in code that wasn't supposed to have anything to do with pulling in outside instructions, but that's the way it goes in C++.

But even with a better programming language, thread safety is a tough problem. If you're writing in Java or C# or Ruby a thread safety problem probably won't cause you to end up with a vulnerability that allows arbitrary code execution, but you might inadvertently allow one user to see another user's data, and that's plenty bad. Back in 2005, Katrina Tsipenyuk, Gary McGraw, and I wrote a paper titled Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors. We lumped this kind of race condition together with errors caused by distributed computation and called them problems related to "time and state". In the presentations I gave on the paper, I always referred to Time and State as the kingdom of the future, because we're only headed for more CPU cores, more threads, and more interconnected systems, and that means more opportunities for getting out of sync.

Last week, in a CSO magazine article titled Penetration Testing: Dead in 2009, I said that penetration testing is undergoing a transformation - it's going to die and be reborn as part of a more tightly integrated approach to security. This week Ivan Arce responded in defense of penetration testing in a CSO article titled Twelve Reasons Pen Testing Won't Die. Ivan is a class act, which is why his article isn't titled "12 Reasons Brian Chess is a Ninny." But Ivan doesn't address the core of my original argument, so I'm going to further explain myself here. Let me start by saying this: if you misread the original article to mean "on Jan 1, 2009 all penetration testers are going to go out Jonestown-style", then you need to keep reading.

It's December. For me that usually means my travel schedule winds down, I spend more time doing family stuff, and I start thinking about what I'm going to do next year. This year the travel hasn't let up, and as for the future, all I can think about are the things Gary McGraw, Sammy Migues and I have learned interviewing executives at some the world's top software security programs. We're in the process of building a maturity model out of the data we collected, but some of the stuff we learned is too good to wait. We wrote up a Letterman-style Top 10 Surprises article this month. Check it out.

For me the biggest surprise was about penetration testing. Penetration testing is one of the first things many organizations do when it comes to software security. I believe it to be universally true that if you're not paying attention to security, you have security problems, but it seems most people like to pay a penetration tester prove it to them. Now here's the surprise: as organizations get better at software security, their emphasis on penetration testing diminishes. In most cases it doesn't disappear, but it does get wrapped into a much larger and much more comprehensive approach to improving security. The best initiatives balance the yin and the yang of attack and defense.

We passed an inflection point last year. People are now spending more money on getting code right than they are on proving it's wrong. (More on that here.) This isn't the end of the road for penetration testing, but it does change things. Rather than being a standalone "product", it's going to be more like a product feature. Penetration testing is going to cease being an end unto itself and reemerge as part of a more comprehensive security solution. This kind of thing happens all the time in high-tech. The first PC spell checkers were standalone programs, but the market for stand-alone spell checkers died when they became a standard part of any word processor. These days spell checkers are everywhere (even in my IDE), but there is no market for a standalone spell checker. Proof positive: there aren't even any Web 2.0 or iPhone spell checker startups!

Alright, so why 2009? The time is right because back in 2007, IBM bought a company named WatchFire and HP bought a company named SPI Dynamics. The acquired companies both made web application penetration testing products. IBM and HP spent serious money for these companies'not crazy dotcom prices, but even at HP and IBM you have to have to tell a good story before you get to spend north of seventy million dollars. The good story was that the acquired technology would work together with other products and services to fuel a broad entrée into a rapidly growing software security market. It takes a little while to digest any acquisition, but by now it's been long enough. 2009 will be the year this strategy comes together, and when we look back, it will be the year when most of the world began thinking about penetration testing as part of a larger offering. There will always be boutique security consulting companies with funny names and exotic services, but the industry will grow by integrating security yin and yang. If you'd like a sneak preview of what the future holds, check out the work White Hat Security has done to integrate their vulnerability measurement service with Web application firewalls. This is attack and defense working together in a creative new way.

More than ever before, people understand the software security challenge, and penetration testing deserves credit for helping spread the word. But knowing a security problem exists is not the same as knowing how to fix it. In other words, penetration testing is good for finding the problem and bad for finding the solution. Just like the venerable spell checker, it's going to die and come back in a less distinct but more pervasive form.

McGraw has published his roundup for the software security space in 2007. Lots of juicy numbers. Here it is.

Mark 2007 on your calendar--it was a turning point. It was the first year there was a bigger market for products that help you get code right than there was for products that help you demonstrate a problem exists.

Seems like we security people don’t get to celebrate a victory nearly as often as we get to learn from defeat, so please take a moment to enjoy some good news. I’ll try to prolong the moment by saying this: I spend a lot of time telling programmers that they are no longer in a position where they can pretend that security isn’t part of their jobs, but my message is contravened by most of the training material programmers see. Whether it’s documentation a new framework, library, or platform, the standard play is to pretend that security doesn’t exist. No mention of what you need to do in order to make your code secure. No mention that security is anything other than a user name and a password. I’m happy to say that Apple is bucking this trend.

Apple opened up the iPhone for third party applications last week. That means they’re providing programmers a software development kit and instructions on how to write code for the iPhone. On the home page for iPhone development, they have a list of common coding questions such as “How do I debug my application?” and “How can my application detect motion?” At the bottom of the list is “How do I write secure code?” The answer links to a secure coding guide that discusses topics like validating input and avoiding buffer overflow as well a discussion of the security services the iPhone’s OS provides. Nice.

(In order to browse the links above, you have to register as an iPhone developer. It’s free. Go here.)

Some inspired soul has reworked the New Face of Cybercrime trailer. Watch this. My favorite bit: the cat and the baby.