At a recent Dagstuhl seminar on web application security, I spoke with Jasvir Nagra (one of the people at Google working on Caja) about the best way to run a public security contest. The goal of the contest would be to encourage people to find as many bugs as possible, with additional rewards for more severe security vulnerabilities. As a starting point, we discussed the ongoing Google Native Client (NaCl) security contest. For this contest, the top five bug-finders over a ten-week period receive recognition and cash prizes of $8192, $4096, $2048, $1024, and $1024. While this model has a few strong points, it also is problematic in the way that it incentivizes security research. This article discusses how to more effectively design a security contest.

(more…)

At the recent USENIX Security Symposium, Niels Provos, head of the security team at Google, gave a compelling presentation about the state of client-side web security (you can find research project details here). His research project involves idenfitying drive-by downloads and filtering them from Google search results. One conclusion of the analysis was that any type of site can be malicious. It is usually not the owner, but rather a hacker who places exploit code on websites. This seems to suggest that the only way to keep malware off of computers is to either stop browsing the web, or lock down the web browser.

As security experts, we know how to use a browsing sandbox like Sandboxie or a VMWare appliance. Try, however, to explain this to an average user. It is not a straightforward process. Most people do not even understand the necessity for such precautions. People need a secure browser that is easy to install and manage. An example of such a browser was GreenBorder, which Google bought and promptly took out of commission. During the Q&A session following Niels’ talk, I asked him (in more friendly terms) why Google bought the one browser that promised to improve web security and stopped selling it. At the time he was unable to comment on Google’s strategy, but now the answer is clear: Google Chrome.

(more…)

The results of a recent study on security design flaws in banking websites will be presented tomorrow at the Symposium on Usability and Privacy. The research was conducted by Dr. Atul Prakash, Laura Falk, and myself (Kevin Borders). It found that flaws, such as presenting login information on an insecure page, were widespread. What does this mean for the security of the internet at large? Will hackers routinely exploit these vulnerabilities to conduct widespread fraud in the future? And, the most important question: how do we fix it?

(more…)

I was first exposed to SQL injection when David Litchfield (see his blog) came and gave a talk on the subject while I was working at the NSA in the summer of 2002. SQL injection is a type of security vulnerability that occurs when some code includes untrusted input, such as a website form field, in a SQL database query without first escaping or removing special characters that may affect SQL syntax (‘, ”, \, etc.). This may subsequently allow an attacker to terminate the original query and inject another query to do something malicious, such as the following: “”; DROP TABLE users;”. After hearing about SQL injection, my friends and I proceeded to go home and type “‘”; select * from users;” into form fields on numerous websites. Though we didn’t see any database table dumps, a surprisingly large number of sites gave us responses with SQL syntax errors, indicating potential vulnerabilities.

Things have changed a lot since the advent of SQL injection attacks. Many security researchers have investigated the topic and written papers on how to correct the problem. As the title of this blog post suggests, however, the SQL injection problem has been solved. Sometimes it makes sense for people to continue researching a problem when existing solutions have serious usability constraints or add significant development overhead. That is not the case for SQL injection. The rest of this article briefly touches on some SQL injection research and then shows you how to avoid vulnerabilities on your website using a common PHP library as an example.

(more…)

This past week at the Blue Hat security conference, Lurene Grenier from Sourcefire gave an impressive presentation about exploit and signature development. She rapidly creates proof-of-concept exploits following Microsoft’s patch release on the second Tuesday of every month. Thanks to years of experience, the whole process only takes a few hours. It would be exceedingly difficult for prospective hackers to create and use a weaponized exploit any faster than signatures are pushed out by intrusion detection system (IDS) vendors. However, it may be possible to create a working exploit that escapes detection entirely. This article takes a look at issues related to completeness of IDS signatures. (more…)

The 64-bit version of Microsoft’s latest operating system, Windows Vista, comes with a feature known as “PatchGuard.” PatchGuard will monitor “key resources used by the kernel or kernel code itself” (see Windows Vista Security – An Introduction to Kernel Patch Protection) to detect tampering. If it notices any writes to protected areas, it will immediately shut down the system. The goal of PatchGuard is to harden the kernel against malicious code. However, it also hardens the kernel against security software that does system call monitoring. This side-effect has stirred up unrest among vendors such as Symantec (see Assessment of Vista Kernel Mode Security). They argue that the inability to filter system calls make systems with PatchGuard less secure than systems that are only running their protection software. So who is correct in the kernel patching debate? This article argues that both parties are in the wrong, and suggests a better way that Microsoft can work with vendors to maximize overall security. (more…)

Have you ever wondered after seeing report after report of new software security vulnerabilities: when will it stop? More importantly, if you are using software that has never had a publicly announced security vulnerability, is it secure? There is a clear disconnect between the total number of bugs in a program and those that are announced publicly and result in a patch. Nobody knows exactly how many bugs are out there, but this article takes a look at factors that affect the relationship between the current and true number of software vulnerabilities. (more…)

This weekend, SC Magazine published an an article about a vulnerability that allows remote code execution if you are running Firefox, but also have Internet Explorer 7 installed on your computer. I happen to run Firefox and have IE 7 installed on my computer, so I decided to investigate further by testing a shockingly simple sample exploit:

mailto:test%../../../../windows/system32/calc.exe”.cmd

And it worked. The interesting thing about this particular vulnerability is that it requires the combined effort of two applications to allow remote code execution on your computer. This naturally opened the door for people at both Firefox and Microsoft to deny responsibility. For this vulnerability, however, Microsoft is at fault. No URI that has “mailto:” should ever execute a file, and it is not Firefox’s job to shield insecure Windows interfaces from unchecked data. Vulnerabilities like this make you wonder, how many other insecure interfaces exist in the operating system that are safe only because third-party applications have yet to expose them to the internet?