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.

Squeezing the Avocado

The debate over Ethical Hacking goes on in increasing fury. It rages in convention-panels, TV shows, blogs, and security-companies' lunchrooms everywhere.

The debates rage all over, except where it counts: in the legislative bodies wherever they may be.

Criminals or heroes, common sense versus legal philosophies, ownership issues, and other elements all tie into this debate which sometimes loses focus on what the real issue is. The broken bridge between two worlds: the technical world and the corporate world. Two groups that speak completely different languages, unable to convey their point of view in a way that could even be appreciated by the other side.

“What do property issues have anything to do with security?” The hackers might ask “We’re only helping”.

The corporate managers might look dumbly and shrug. “Property is for the lawyers,” they will say, “Security? Well, we have an IT department for that.”

A Few Blurbs

There a few things that I'd like to write about, but each of them is currently a bit short, so I have decided to cram them all into a single post that will summarize everything.

1. IBM Acquires Watchfire - most of the people I know already read about this (I got plenty of personal emails about it), and I should probably dedicate a large post to this subject one day, but I really don't have anything to say about this at the moment, other than saying that I believe this is a smart move for both companies, and hopefully for the entire web application security market.
   
2. Positive Security - I have just read an interesting article over at "The Register", which sort of talks on what I have written about in my post "Playing in the Sandbox" a couple of weeks ago. According to the article, It seems that Anti-Virus vendors are planning on replacing the old (and notorious) blacklisting technique with whitelisting (aka Positive Security Model). I can't stress how important this move is to the security industry. Actually, I would love to see more Positive Security based products in the Web Application Firewall market as well. I wanted to write a full post on this subject, but this will have to wait.
   
3. Myth Busting - a few days ago, I read a cool blog post over at Dargos Lungu, where Dragos did a short research called "Top 10 Open Source Forums" ("Top 10" being "The Top 10 Most Secure...") - according to the original research, BBPress and Beehive both won, with 0 (that's a zero people!) publicly known vulnerabilities in the past 12 months. Well, originally I was intrigued by the post, because I myself was looking for a secure web platform to install internally here at Watchfire - but then, my evil alter-ego took over, and me being me, I just had to validate with my own two eyes (and AppScan as my sidekick), that there are actually PHP forum applications out there, that are secure. To make a short story even shorter, it took about 5 minutes to locate the first XSS vulnerability in BBPress, and another 15 minutes to locate 3 XSS vulnerabilities in Beehive (check out Dragos' cool post on the subject).
   
4. AppScan eXtensions Challenge - for those of you who are not aware of this yet, AppScan 7.5 includes an extensions framework (AXF), which enables users to download and install all sorts of cool add-ons. In order to get people started with writing their own extensions, Watchfire recently announced an eXtension writing challenge. If you want to experiment with writing an eXtension, this is your chance, and as an incentive, we'll give away an XBOX 360 for the winning eXtension.
   
5. This one is a bit old , but have you seen the interview with Rain Forest Puppy?

That's it for now.

Dangling the Pointer for Fun and Profit - BH USA 2007

I was just contacted by BlackHat to let me know that my presentation (Dangling the Pointer for Fun and Profit) was accepted to be a part of BH USA 2007 convention. I believe that this presentation will be very interesting and beneficial both for application developers as well as security experts.

Playing in the Sandbox

According to this eWeek article, Google has just bought Internet security startup GreenBorder Technologies Inc.

Here’s an excerpt from the article:

GreenBorder, a venture-backed startup founded in 2001 and based in Mountain View, California, where Google is also headquartered, offers security software that sets up temporary, virtual sessions each time a computer users surfs the Web, then discards the resulting data once the user is finished surfing.

The article then goes on to describe the technology:

The technology creates a secure zone, called a sandbox, for online interaction. "Any type of activity and interaction, while you are on the Internet, will be directed to the protected environment," according to GreenBorder's site.

Out of the many ways to protect end users from malware, viruses and other types of malicious content, I am a strong supporter of this specific positive approach, and am very surprised (and saddened) to see that desktop anti-virus vendors have mostly decided to disregard this approach, and stick mainly to negative (signature-based) solutions.

What The Fuzz Are You Talking About?!

Last week, I attended the OWASP (Israel) mini-conference, which included some very interesting presentations (one of which was our own Overtaking Google Desktop).

One specific presentation that caught my attention was "Fuzzing in Microsoft and FuzzGuru framework". The presentation was given by John Neystadt, Microsoft’s lead program manager for the Forefront Edge product (aka ISA server).