IBM Application Security Insider

URL Protocols - Off the Record

I would like to point out an interesting research done by Thor Larholm, which deals with URL Protocols.

The subject of URL Protocols was actually researched within the Watchfire Security Team recently and we reached different yet complementing findings to those of Thor.

URL Protocol is a mechanism built into different browsers to handle specific URL types with external applications.

For example: the URL: mailto://[email protected] opens an outlook composer window that is ready to send an e-mail to: [email protected].

This actually executes the mail application with specific arguments (parameters). The most interesting thing to note though, is that in Internet Explorer this execution is performed automatically (without user interaction) and can be forced on your browser by the site you browse.

Here are some ideas that Watchfire's Security Team had on the security implications of this feature:

• If one ever had complete control over a remote system and wanted to leave a simple backdoor, he/she could just register a new URL Protocol in the registry (CMD:// for example) that will execute the URL it receives in a CMD prompt.
  
  This can enable an attacker to send shell commands to the victim's computer every time the victim opens a browser and surfs to the attacker's web site.
  
• Of special interest is the callto:// protocol. This protocol is configured to execute the Netmeeting application by default, but it executes Skype instead, if it's installed on your computer. This can be exploited in various ways:
  • The attacker can initiate a call from the remote computer to himself and thereby tap the microphone on the victim's computer.
  • The attacker can initiate many calls on behalf of the victim and thereby waste his/her money.
  • The attacker can initiate a conference call to himself and to a person he/she wants to talk to and the victim will be the only one paying for it.
  In this scenario, the attacker's biggest problem is that the attack pops a Skype window on the victim's desktop. An attacker might be able to reduce this problem using JavaScript to focus the windows of the browser but obviously it is not ideal.

• You can create many automatic links to a specific URL Protocol (for example: mailto://) and by that open many outlook processes, creating a DoS situation that cannot be resolved by closing the browser.
  
• Microsoft Media Player oftentimes suffers from published/known Buffer Overflows. These attacks usually occur because the application has a bug in the way it parses media files. As a rule of thumb, Microsoft suggests that you only use trusted media files. There are several URL Protocols that enable an attacker to make the browser automatically open Microsoft's Media Player with untrusted streams. 

I hope that this research spills more light on the dangers of URL Protocols and emphasizes the dangers of allowing sites to control external application execution through the browser without user interaction.

IIS 5.1 Patched (Dangling Pointer)

Yesterday was Microsoft's patch Tuesday - a very exciting day for all of us. One of the vulnerabilities that was fixed is the IIS 5.1 dangling pointer vulnerability that Adi Sharabani and I revealed.

This vulnerability was fixed a long time after its original public disclosure date (it was known since December 2005). At first, it was considered a DoS vulnerability and therefore Microsoft decided that it wasn't important enough to fix in a security update and deferred it to a service pack instead.

While the importance of a DoS issue is debatable (as a previous reply to our blog suggests), it is not the subject of this post. But I will just say that I personally think that DoS is a very severe issue.

Anyway, as our research proved, this Dangling Pointer bug could be exploited for arbitrary remote code execution and therefore, it was quickly and efficiently patched by Microsoft (kudos to Microsoft's Response Team who was very responsive and co-operative during the disclosure process)

An interesting thing to note about yesterday is the old debate about managed code (like .NET and Java) vs. unmanaged code (like C and C++).

This debate has many aspects and viewpoints to it and can be discussed for long hours.

Before I dive into the point I'm trying to make, I want to say that in my opinion, security problems lie on the shoulders of developers and nobody else is to blame. Secure code provides good security. Obviously, secure frameworks can help, but it is never the complete solution.

The first point yesterday's patch Tuesday made in this debate is that managed code provides better security for dangling pointer problems. This means that if the IIS web server was developed using a managed code framework, it was not vulnerable to this kind of a remote code execution exploit. This doesn't mean that remote execution vulnerabilities cease to exist when using managed code, but rather that their impact usually becomes a DoS instead.

On the other hand, yesterday's patch included a fix for another two .NET vulnerabilities. This is amusing because the impact of these two  vulnerabilities was that even if the best developer in the world developed the most secure .NET-based software, it was still vulnerable to a remote execution exploit because of the framework it used. This is a big minus for managed code.

We will reveal more specific details about our research into the exploitation of dangling pointer bugs for remote code execution and about this specific vulnerability at the BlackHat conference -

http://www.blackhat.com/html/bh-usa-07/bh-usa-07-speakers.html#Afek

Here's Microsoft's official  advisory -

 http://www.microsoft.com/technet/security/Bulletin/MS07-041.mspx

CWE (Pie Chart) is in the Eye of the Beholder

A few days ago, I was sitting down at my desk, doing my daily blog reading session, when I stumbled upon a post at the Matasano Chargen blog. The post (which quotes Mark Curphey) mentions a presentation that Jeff Williams gave at a New York OWASP chapter meeting, in which Jeff uses the following slide:

Jeff took some information that was posted by MITRE, and used it to demonstrate that if you take all automated security tools, and use them all together against something, the tools will only cover 45% of the known vulnerability types enumerated by the MITRE CWE project. 

Since I was an active participant in the CWE project (on behalf of Watchfire), I know a thing or two about the CWE project. Specifically, I know that:

1. The CWE project includes input from many different types of sources, such as Source Code Scanning vendors, Web Application Scanning vendors and all sorts of preliminary taxonomies. This super-set-input, includes numerous entries that are not what you would call a vulnerability per-se.
2. If you look at the CWE project as a tree of 600+ vulnerability types, there are 104 (non-leaf) nodes, which describe categories, and not vulnerabilities.
3. Many of the CWE vulnerability types, are design issues, or business logic issues.

So, using the CWE information as-is, without digging deep into it, and understanding its structure and nature, will get you to the same conclusion, that automated tools only cover 45% of the CWE vulnerability types, while in reality, things are not as simple and bleak as they seem (check out the CWE full dictionary page, and you'll understand why I say it is not simple)

However, I do agree (and I did state this in this blog before) that automated tools have a lot of room for improvement, and that some things cannot be fully automated, but I certainly can't say (based on the current statistics) that they cover 45%, 65%, 75% or any other percentage of the vulnerabilities in the world.

In addition, I do believe that the CWE project is super-important, and will supply us with great statistics (that's why I was happy to participate in the project), which end users will be able to use for their benefit (evaluating tools, building proper testing processes), and tool vendors will be able to use for improving their products.

To wrap things up, you can read MITRE's official response to the whole CWE Pie Chart evolution, which they kindly posted on the Matasano Chargen blog, after I've raised my concerns to them about the validity of the pie chart that was circulating in the blogosphere.

My Wish for Open Source Web Application Security Tools

If web application scanning tools are the power tools used for broad application assessment, then the more sophisticated penetration tester will extend and refine the results through the usage of finely tuned scalpels.  Myself?  I've always favored using Netcat, Paros and human intelligence.  This is not to say that there are not many other powerful tools available, but these happen to be my scalpels of choice.

Whenever I hear people saying that they wish there was an open source web application scanning tool available, similar to a Metasploit type tool but for the application, I'm genuinely puzzled.  I wish for something even more basic - a solid, mature open source framework from which to perform web application assessments.  I want a framework from which I can begin with an architectural risk analysis, and move forward, collecting and trending SDL artifacts - through to a platform from which I can proxy, build, fuzz and report on my assessment.  Am I missing something?

SQL Injections in UPDATE/INSERT Statements

Lately I have been researching SQL injections that occur anywhere other than the WHERE clause of SELECT SQL queries (a research that was originally done together with Yair Amit). In particular, injections that occur inside INSERT/UPDATE statements (again, not in the WHERE clause).

The common SQL Injections covered in earlier research papers, usually dealt with a scenario, where user input, is directly used to create dynamic SELECT SQL queries, such as:

Statement = "SELECT count(*) from users WHERE userId='$USER_ID' and password='$USER_PASS'"

As mentioned above, user input is used inside the WHERE clause of a SELECT query, and that is where the SQL Injection may occur.

Our research deals with common scenarios, where user input is embedded as a part of a dynamic INSERT or UPDATE statement, in places other than the WHERE clause, for example:

Statement = "UPDATE users set firstName='" + $FIRST_NAME + "', lastName='" + $LAST_NAME + "' where userId=..."

Anyway, I'll probably post our findings sometime in the near future, and although there's nothing groundbreaking about it, it does summarize the techniques for detecting and exploiting such SQL Injections in a well organized manner.

During the research, I tried finding resources on SQL injections in INSERT/UPDATE statements, and I stumbled upon this article, which I managed to somehow overlook when it first came out.

The author of the article refers to another research paper that was written originally in Russian, and shows how to use the MySQL benchmark() function for exploiting Blind SQL injections, and then he goes on to present a cleaner and more elegant way of exploiting Blind SQL injections, without the overhead and drawbacks of using the benchmark() function.

So, I highly recommend reading this article, especially if you're stuck with trying to exploit SQL INSERT/UPDATE statements.