:: extra ::

Secure code for the iPhone

Fri, 14 Mar 2008 14:49:33 -0800

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.)

Bye-Bye Disk Encryption

Thu, 21 Feb 2008 22:00:44 -0800

Ed Felton and the gang at Princeton have struck again! This time they've figured out how to defeat the disk encryption schemes built into Vista, MacOS X, and others. The attack works because the values held in RAM don't disappear instantly when a computer is switched off. They decay slowly over a period of seconds, and that can be extended to minutes with a little bit of coaxing. That's long enough to boot up a second OS and read out the contents of memory. After that, it's just a matter of extracting the crypto keys, and the game is over. Awesome work. Read about Cold Boot attacks on Encryption Keys. If there's a lesson to be re-discovered here, I think it's the amazing way we end up building security systems on what seem to be solid ground (as in "computers forget stuff when you turn them off"), and only when it's too late do we find out that our premise was strong enough for trying to explain computers to someone like your old uncle Hugo, but not strong enough to adequately secure your data. It appears to me that this attack is still too sophisticated for the average thief who steals laptops in coffee shops, but it's plenty easy for the forensics guy down at the police station.

The New (De)face of Cybercrime

Tue, 19 Feb 2008 11:16:15 -0800

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

Secure Programming Makes the Rounds

Sat, 16 Feb 2008 18:45:57 -0800

It's been a while since Brian or I posted anything about Secure Programming with Static Analysis, and Gary McGraw's mention of the book in his recent article on Dark Reading seems like as good an excuse as any. Gary concludes his post, The Truth Behind Code Analysis, with the following:

"If you’re interested in static analysis for security (and you should be), buy and read Secure Programming with Static Analysis by Brian Chess and Jacob West."

The book was also recently reviewed in a recent blog post by the folks over at the Denim Group. And the following are just a few of the other relevant mentions it has received: - SDTimes - Dr. Dobb's Journal - Sylvan von Stuppe - Justice League (Cigital) - SANS - Deep Inside | Security & Tools I've also been (pleasantly) surprised by how much interest we've gotten in the warez scene. I won't post those links, however.

WTFs/Minute

Wed, 06 Feb 2008 10:33:30 -0800

We don't get that many cartoons about code review, so when a new one crops up, it's cause for celebration. If you don't think it's hilarious, you need to do more code review. Many thanks to Mark Curphy.

SATE

Mon, 04 Feb 2008 23:36:54 -0800

NIST has announced what they call a Static Analysis Tools Exposition (SATE). Participating static analysis tools will be used to analyze a small set of programs selected by NIST. Eventually all of the results will be made public. I like the idea a lot, and I'm going to make sure Fortify takes part in both the C and Java tracks. Running a bunch of programs against the same test cases might seem like a straightforward exercise, but it's not. Finding an even-handed way to examine complicated tools is tough, and the fact that NIST is emphasizing the detection of security vulnerabilities makes it that much tougher. (Tell me again, what exactly constitutes a "vulnerability" in source code?) Just browse through the steps in the SATE protocol to get a feel for the complexity involved. To make the exercise even more difficult, everyone who makes a tool can't help but worry that they'll come out looking bad. After all, this sounds a little bit like the setup for a product review. We've seen those before. (Here's a link to the one Network Computing did in the middle of 2007: link.) Product reviews generally have winners and losers. NIST says they'll work hard to avoid these kinds of labels, but it's not going to be easy. All of this makes test case selection a touchy subject, and comparative presentation of the results is an absolute minefield. The problems are many, but there's also a lot to be gained. Here are the three reasons I'm looking past all of the complexity and anxiety and participating in SATE: 1) People who want to run their own tool comparisons will benefit. You might like the way SATE works or you might not, but you'll be able to see what they did and where it took them. 2) Tool builders will benefit. Static analysis for security is a hot topic in both industry and academia. The results will give us a little bit of insight into which problems we've conquered and which ones require more work. 3) The security community will benefit. Being able to compare output from different tools will give us a better idea about how the tools classify code, and my guess is that we'll learn that our nomenclature still needs improvement. Better nomenclature makes it easier to talk to the 99% of humanity that doesn't think about software security every day.

They Set the Wii Free

Tue, 29 Jan 2008 23:49:17 -0800

It appears that a buffer overflow vulnerability in The Legend of Zelda for the Wii, and that’s all hackers need in order to run their own code on the machine. Here’s the scoop. Pretty soon this will mean game pirating for the Wii without the need to get out your soldering iron. That’s important if you want to get people to steal games in the same casual manner they steal music. Piracy is a big deal for all modern gaming platforms because most of the money comes from software (games) not from hardware. Apple has run into similar trouble recently. It seems that more than a million iPhones have been unlocked, and I think it’s safe to assume that it’s mostly happening using the simplest mechanism out there, a web site that exploits a buffer overflow in the iPhone. That means Apple is missing out on their cut of the phone subscription going to AT&T, and that has to hurt. The moral to this story is this: if your business relies on the security of your software, you’ve got two choices:

Design a system that will be secure even when people discover a few bugs.
Make sure you don’t have even a single bug.

Neither of those options is easy, but creating a robust design not nearly as hard as creating a flawless implementation.

Analyzing the Analyzers: Looking at Source Code for Breathalyzers

Mon, 28 Jan 2008 11:25:33 -0800

For as long as there have been breathalyzer machines, DUI suspects have been looking for creative ways to beat them (see newspaper clipping below.) The latest trend is to go after the source code. Here are three recent cases:

August 2007: Minnesota Supreme Court rules that source code must be revealed.
December 2007: Source code analysis in New Jersey class-action breathalyzer case.
January 2008: Kentucky appeals court rules that source code must be revealed.

My favorite anecdote so far comes from the New Jersey analysis. One of the teams used Fortify to analyze the code, and lo-and-behold, they found a buffer overflow vulnerability! This raises the possibility that if you mix just the right cocktail at just the right time, you could craft an exploit. (Dream on.) The real lesson here is that our legal system is waking up to the importance of code. If the code isn’t trustworthy, the outcome isn’t trustworthy either. (Electronic voting machine vendors, you might want to read that last line again.) If the code provides evidence that the programmers weren't being careful, that's going to be bad news for the vendor.

The Checklist

Fri, 25 Jan 2008 06:54:42 -0800

“What do you do when expertise is not enough?” Atul Gawande Hundreds of little decisions per day. Screw up any one of them, and disaster could ensue. Smart and highly trained professionals who know what to do, but who aren’t always focused on the details. A transition from a cowboy mentality to an emphasis on a boring but safe and repeatable process. Sound like the hymn of software security? It does indeed, but it’s also the way Atul Gawande describes modern intensive care units in his article The Checklist. Intensive care units appear to suffer from many of the same problems the software community faces. Too much complexity creates too many opportunities for error. Little mistakes lead to complications, and those complications can, quite literally, kill. As with software, there is no easy or complete answer to the problems doctors face in the ICU, but the surprising finding this article points out is that a simple tool, the checklist, is enormously effective. Arm nurses with a five step checklist for avoiding an infection when inserting a line, and secondary infection rates plummet. Do programmers in your organization have the equivalent for common security-sensitive operations? Maybe those cross-site scripting errors keep popping up because there’s no template to guide programmers as they create new code. If you’re still casting around for one or two more new year’s resolutions, resolve to give programmers good examples they can follow. In the book, we try to give a positive, correct, and secure code listing for every broken, bad, or vulnerable piece of code we discuss.

Getting Started

Mon, 14 Jan 2008 12:52:33 -0800

Software security can be hard to talk about, sometimes because people who make software are an incredibly diverse bunch. I’m not talking about globalization, I’m referring to the fact that the term “software” covers a lot of ground. Building operating systems, web sites, cell phones, and airplanes all require major software chops, and they all require an understanding of security, but they are very different undertakings. If you’re talking to someone about the new software security initiative you just got off the ground, the result can be wild confusion before you figure out that the other person’s take on what a “software security initiative” means is completely different than your own. I like McGraw’s latest DarkReading column because it gives a nice overview of the different ways people get started.

Has Online Banking become Safer than Offline Banking?

Mon, 29 Oct 2007 07:21:37 -0800

Last summer, I gave a talk about online banking: http://www.aipsi.org/eventi/download/agenda_issa_rome_2007.pdf (PDF) After the talk, a CSO from a major bank came up to me and said, "Great presentation, but you missed one key thing: banking online is safer than banking offline." Seems counter intuitive. Doesnt it? Banking online can be scary because: 1) Hackers have global reach, If you're doing offline banking in California, you only need to be worried about bad guys in California, for instance the customers and employees present in your local branch. If you're banking online, anyone in the world could attack you and your assets. 2) Automation - in the physical world attackers are limited by their ability to manipulate physical items like making an extra copy of your account number. In the online world attackers are essentially unlimited in the resources they can bring to bear. 3) Online security is opaque to the end user. People who aren't particularly tech savvy have a tough time differentiating between good online security practices and bad online security practices. Security in the physical world is much more intuitive for most people- keep your checkbook in a safe place or don't let someone peek when you are entering your PIN. How can someone argue that online banking is safer?

Inside a Cross-Site Scripting Attack

Tue, 07 Aug 2007 13:43:17 -0800

A while back I recorded a brief video that demonstrates a cross-site scripting attack against a Java Web application. If you write XSS exploits all day, this won't be for you, but if you spend your days with your nose buried in code and always wanted to see a little more about how the bad guys work, check this out:

Click To Play

Web Vulnerabilities in the Age of the iPhone

Sat, 14 Jul 2007 18:03:01 -0800

I've read lots of articles about hacking the iPhone lately. They're mostly focused on exploring the hardware, circumventing the intended activation process, or putting new software on the device. That's nice, and I like to see a technological marvel smashed open with a hammer just as much as the next geek, but I'm more interested in how the iPhone changes the balance of power when it comes to security. Small items first: There are a few minor application issues that make a phisher's job easier. For instance, the email client does not display the URL you're going to visit when you click on a link, so a phisher can send out spam that says Click here to go to PayPal and point the link to http://paypal.fakesite.ro, and there's no way to know what's going to happen until you click. Once you do click, the browser displays only the first 20 or so characters of the URL, so its easy to hide a big gnarly cross-site scripting attack without arousing any suspicion. Alternatively, the phishing site can use JavaScript to scroll the URL bar out of site. (See Joe Hewitt's writeup.) I expect issues like these will be addressed soon enough, just as they've been with all of the major desktop mail clients and Web browsers. Much more interesting is the way the iPhone connects the Web browser and the phone. As the author of a Web site, you can embed a telephone number in a web page like this: call me! You can also write JavaScript that causes the iPhone to initiate the dialing process: When that code runs, the user will be prompted "1-900-867-5309 (call) (cancel)". If the user accepts, the phone dials. Now you can turn phishing into money faster than ever before because the payload is the product: victims dial a 900 number, and the money starts rolling in. By the way, setting up a 900 number is easy. Alternatively, use a cross-site scripting vulnerability to have a banking Web site initiate a call to a fake technical support number. What's the first thing the fake support rep asks for? Your account information of course! After all, you called them, so they need to "confirm your identity". Once again, an old scam gets new legs with a little help from the latest technology, and once again the ante on cross-site scripting goes up. I expect two things will happen in coming year: 1) We'll learn about more cute tricks that web applications can use to look more like native iPhone applications and to interface with the iPhone and allow access to things like contacts, photos, and maybe even the phone's physical location. All of these features will expand the horizons of enterprising attackers. 2) All of the other handset makers in the world will begin to deliver their response to the iPhone. At that point, they will all have been working around the clock in panic mode for the better part of a year, and the devices will contain a treasure trove of security vulnerabilities that make the iPhone look like Fort Knox. After all, Apple got plenty of things right: at least you have to confirm before the phone dials.

Exploiting Online Games

Thu, 12 Jul 2007 22:37:54 -0800

Hoglund and McGraw's new book just came out. It's brilliant. Exploiting Online Games: Cheating Massively Distributed Systems is a peek into the future and an amazing recruiting tool all rolled into one. If you already understand the kinds of security problems today's software creates, then the book gives a view into the kinds of security problems tomorrow's software is going to create. Here's a hint: Time and State. Massive distributed systems can fail in the same ways that centralized (traditional) systems can fail, but they're also likely to run trouble as they try to coordinate critical data between nodes. There is a lot of money flowing through modern games, and so any sort of defect fuels the fight between the game companies and people who seek to profit from them. But if you just think games are cool and want to know more about what your options are for getting ahead, or if you're trying to figure out why your arch-nemesis from the next dorm building seems to have such good aim with his Crossbow of Ultimate Peril, this book has all sorts of tricks, hacks, code examples, and step-by-step information on how to get inside the mother of all massive multiplayer online games: World of Warcraft (WoW). When I was in college, there was a whole subculture of people who learned to program so that they could extend and improve Multi-User Dungeons (MUDs), an early forerunner of WoW. This book is going to be the gateway to programming for the WoW generation. And, if everything goes as I'm sure Hoglund and McGraw have planned, those kids won't even know its possible to program without thinking about security.

Speaking of Secure Programming

Tue, 10 Jul 2007 12:03:17 -0800

A few months ago, while we were still in the thick of finishing off the book (Secure Programming with Static Analysis) and hadn't yet started focusing on selling it, Brian and I recorded and interview with Informit's new OnSoftware podcast where we talked about software security and the kind of material we cover in the book. Well, months later the book is finished and now the interview we recorded is available for mass consumption through iTunes as either a video or audio podcast. You can subscribe to the podcast series on www.onpodcastweekly.com or link directly to our episode at http://media.podhoster.com/peachpittv/05_SOF_ChessWest_01.mp4. Secure Programming with Static Analysis has gotten some nice attention from other sources, too. Gary McGraw recently posted the forward he wrote for the book on his Justice League security blog http://www.cigital.com/justiceleague/2007/07/06/from-the-foreword-to-secure-programming-with-static-analysis and SANS has a nice interview with Brian up at http://www.sans.edu/resources/securitylab/brian_chess.php. I particularly like the part in the SANS interview where Brian takes credit for all the typos in the book ;-).