We all know what happens when a software vendor downplays the severity of a security vulnerability. It usually comes back to haunt them, when the vulnerability is eventually discovered by the bad guys and used to exploit innocent computer users.

Microsoft, Apple and even Mozilla have all been guilty of this in the past. Lately (and sadly), Adobe has joined this train.

Recently, I found a design flaw on Adobe’s website, which allows the abuse of the Adobe Download Manager to force the automatic installation of Adobe products, as well as other software products (e.g. Google Toolbar).

Instead of admitting that this design flaw is indeed a problem which can be abused by malicious attackers, Adobe decided to downplay this issue. When ZDNet Zero Day blogger Ryan Naraine reported my discovery to Adobe, the company sent this response:

"A few important points:

The Adobe Download Manager is intended for one-time use. The Adobe Download Manager is designed to remove itself from the computer after use at the next restart. The user can also remove the Adobe Download Manager prior to this using Add/Remove Programs.

The Adobe Download Manager can only be used to download the latest version of software hosted on Adobe.com.

The Adobe Download Manager presents a very large user dialog box when downloading software…”

I think they missed the whole point here. While it is true that the Adobe Download Manager is removed upon computer restart, the user, who has just updated their Adobe product (usually without the requirement to restart the computer after the update), is still exposed to forced automatic installation until they restart their computer.

This specific design flaw does indeed force installation of the latest version of Adobe products. But, what if there is a zero-day flaw in an Adobe product, and you have decided to remove it from your system because of that zero-day? This is not a far-fetched “what if”. An attacker can force you to automatically download and install the vulnerable Adobe product, and then exploit the zero-day vulnerability in that product.

This is the kind of scenario that’s common when skilled, motivated attackers are going after select targets.

And yes, you do get a big dialog box when you are forced to download the software. Like this will really matter to the attacker, when all he wants is to get his malicious software on your machine.

On the same day I published my last blog post, I found yet another issue — a remote code execution flaw in the Adobe Download Manager. Basically, what I found is that an attacker can force an automatic download and installation of ANY executable he desires. So, if you go to Adobe’s website to install a security update for Flash, you really expose yourself to a zero-day attack.

Recently Adobe released a security update for a critical vulnerability in Adobe Flash (not related to the “Private Browsing” issue).Adobe also issued a security advisory for Adobe Reader, where they plan to release an update for Adobe Reader (v9.3 and v8.2) “to resolve critical security issues, including the Flash Player issue described in Security Bulletin APSB10-06.”So, you upgraded to the latest Flash version (10.0.45.2), and use an alternative PDF reader. You are safe from this vulnerability, right? You are probably not!If you did upgrade to the latest version of Flash from the Adobe website, you very likely have Adobe Download Manager installed.What is the Adobe Download Manager? “The Adobe Download Manager (Adobe DLM) is a small application that is used to deliver two of Adobe's most frequently downloaded products, Adobe Reader and Adobe Flash Player.”Is the Adobe DLM safe to use? According to Adobe: “The Adobe DLM is signed by Adobe, uses SSL, MD5 checksum integrity verification, encryption and other methods to insure that the software you request is the software you receive from Adobe.”Pay attention to the bold part of the last sentence. The reason I marked this part of the sentence is that apparently you can force automatic download and installation of software upon anyone who visit your website and have Adobe Download Manager installed. Safe to use, ha?

Any of the following can be forced to automatic download and install (Thanks Mike Bailey for helping me with the list!) :

Adobe Flash 10

Adobe Reader 9.3

Adobe Reader 8.2

Adobe Air 1.5.3

ARH tool - allows silent installation of Adobe Air applications

Google Toolbar 6.3

McAfee Security Scan Plus

New York Times Reader (via Adobe Air)

Fanbase (via Adobe Air)

Acrobat.com desktop shortcut

So, even if you use an alternative PDF reader, an attacker can force you to download and install Adobe Reader, and then exploit the (yet to be patched, but now known) vulnerability. The attacker can also exploit 0-day vulnerabilities in any of the other products mentioned above.

ThreatPost’s Denis Fisher wrote a blog post about “Flash cookies and privacy” research paper, which states that over 50% of the websites are using Flash cookies to track users. This is very disturbing, and as Denis wrote in his post, “On the most basic level it's clear evidence that the advertisers, site owners and their affiliates are continuing to look for new, less obvious ways to gather information on site visitors and track their movements around the Web”.

Unfortunately, what’s more disturbing, in my opinion, is the fact the Flash cookies can be used to bypass the new “security” feature implemented in most of the browsers today: “Private Browsing”. According to Mozilla: “What Private Browsing will not retain - Cookies: Files created by websites, that store information on your computer, such as your preferences when visiting that site (when a website has a "remember this" checkbox, it is using a cookie) will not be stored.”. This is the same for other browsers that implement the “Private Browsing” feature.

To test this problematic issue you can do the following:1) Open this flash (created by Philipp Kostin) in your browser "regular mode".2) Enter some details and click “Save”.3) Open the same flash in “Private Browsing” mode.4) You should see the information you entered in the regular browsing mode appears in the “Private Browsing” mode.

I think Adobe should work with browser vendors and fix this. Until then “Private Browsing” is totally useless.

Back in July 2006, I had the opportunity to be part of a cool initiative called “Month of Browser Bugs”. This initiative was created by H.D Moore in order to raise the awareness of security vulnerabilities in web browsers. Back then it was mainly focused on system Active-X issues, but it also provided some great examples of how, so called “unexploitable” vulnerabilities, can still be abused for a remote code execution. The initiative was a great success, in my opinion, and made the browser vendors more attentive to security vulnerabilities in their products (e.g. In Internet Explorer 8, installed Active-X controls are now not running automatically, and can be opted-in to run on specific sites).Today, three years after the “Month of Browser Bugs”, I’ve decided to declare July 2009 as “Month of Twitter Bugs” (MoTB). I’m doing so in order to raise the awareness of the Twitter API issue I recently blogged about. MoTB could have been easily converted to any other “Month of Web2.0 service bugs”, and I hope that Twitter and other Web2.0 API providers will work closely with their API consumers to develop more secure products.Each day I will publish a new vulnerability in a 3rd party Twitter service on the twitpwn.com web site. As those vulnerabilities can be exploited to create a Twitter worm, I’m going to give the 3rd party service provider and Twitter at-least 24 hours heads-up before I publish the vulnerability.Even though I have enough vulnerabilities for this month, you are more than welcomed to send me (via email or twitter) vulnerabilities you find in 3rd party Twitter services. I will do my best to publish all submitted vulnerabilities. I will, of course, credit the submitter.

Mikeyy wrote a twitter worm. It’s old news, I know, and by now Twitter seem to fix all the known vulnerabilities on their website.But, let’s say that there are no more XSS/CSRF/etc. vulnerabilities on Twitter.com. Does it mean that there will be no more twitter worms? Unfortunately, the answer to that question is no.Even if the guys at Twitter will hire the best security engineer, which will fix all the vulnerabilities on twitter.com, they still have one big issue: Twitter API.And no, I’m not talking about vulnerabilities in Twitter API, but rather abusing Twitter API as a weak link that can allow the creation of twitter worms.

According to the Twitter Fan Wiki, there are dozens of Twitter services and applications which utilize the Twitter API. It takes only one vulnerability in one of those applications to trigger the next Twitter worm.An example for this threat is a vulnerability I found a few weeks ago in twitpic.com website. twitpic.com imports the profile information from twitter, and displays it on the twitpic.com profile page. While twitter.com (finally) sanitize and encode HTML tags in the twitter profile information (name, URL, bio, etc.), twitpic.com failed to do so and by that allowed injecting scripts to the twitpic user profile page. This is a very simple persistent XSS, which can be easily abused to hijack twitpic.com user accounts. However, because twitpic.com also uses the Twitter API to automatically send twits on behalf of the user, whenever the user uploads a picture or comments on another user’s picture, it can also be easily used to create a Twitter worm. I’ve created a proof of concept, which automatically comments on a random picture on twitpic.com, whenever a user visits the twitpic.com profile of the user I created – “twitpicxss”. This could have caused anyone who visits the profile page, and was logged in to twitpic.com, to automatically send a twit on twitter.com with the content I set in the comment. The content contained a link to the “twitpicxss” profile, which could have made other users, who follow the victim, to click on that link, be exploited, and keep spreading the worm. I’ve reported this vulnerability to twitpic.com, and they have fixed it on the same day. But again, this is just one example. As I said, there are many services and applications out there that use the Twitter API. Some of them are probably vulnerable too.

Twitter are not alone in this mess. This “Cross-Web2.0 Scripting” type of vulnerabilities can affect all other social networks with open API (e.g. Facebook, LinkedIn). In conclusion, if you are the owner of a service which provides an API, fixing your own website or application vulnerabilities might not be enough…

I love CORE Impact’s advisories. Most of them contain a long timeline which most of the time I find very amusing.Usually, whenever I post an advisory the timeline is short, as most of the vulnerabilities are fixed in a reasonable time span.

Today is different. Today, Microsoft have released a patch for the “DLL-load Hijacking” vulnerability that I reported them 2.5 years ago. I had a long discussion with Microsoft about this vulnerability, and we both had several twists as time went by.

I hope you will enjoy reading the following timeline, which I’ve tried to make it “a la CORE Impact” as possible.

30/Oct/2006 - Provided Microsoft with all the vulnerability details and different ways to exploit it.

30/Oct/2006 – Microsoft stated that “If an attacker has the ability to modify/replace system files on a users system then it is very likely that the system is already compromised in many other ways.”

30/Oct/2006 – I sent some clarifications, stating that the attacker has to have the ability only to CREATE specific DLL files on specific directories, not necessarily on SYSTEM directories. For example, on the Desktop or directories in the user’s PATH.

30/Oct/2006 – Microsoft stated that they will send the information to the IE team for further investigation.

31/Oct/2006 – Microsoft IE product team stated that "If the attacker can put a dll on the box in a location that is in the user's PATH variable, then they already own the box". Microsoft flagged this as a “bad behavior” which they have logged in their “bugs database“, and will fix in next version of the OS.

31/Oct/2006 – I sent Microsoft a notification that I’m going to publicly disclose this vulnerability.

01/Nov/2006 – Publicly disclosed first details of the vulnerability. I didn’t have much time to go with full details, because I had to prepare for a Honeymoon trip to Thailand with my beautiful wife.

10/Dec/2006 – Got back from a great Honeymoon, to find out that some guys were bitching about this vulnerability as a hype, a hoax or just "old news".

14/Dec/2006 – As there was still no change in mind at Microsoft, I've publicly disclosed full technical details of this vulnerability, with a Proof-of-Concept code published on Milw0rm.

14/May/2008 - Nitesh Dhanjani released details about a vulnerability in Safari which allows automated download of files to the user’s Desktop, without any user interaction. He named it “Safari Carpet Bombing”.

20/May/2008 – Shared details with Ryan Naraine on how to combine the “Safari Carpet Bombing” with “DLL-load Hijacking” vulnerability. I showed him a fully automated remote code execution proof-of-concept. Ryan asked me to hold of disclosure of the vulnerability.

24/May/2008 – Microsoft contacted me and added Apple to the discussions about the vulnerability. Microsoft requested that I won’t publish the technical details until they fix the vulnerability.

25/May/2008 – I’ve denied Microsoft’s request and asked them why this issue was not fixed in Windows XP SP3.

27/May/2008 – Microsoft stated that it was not fixed in XP SP3 because of an application compatibility issue, and it will take them time to fix this. They also tried to convince me to keep the technical details until they release a patch, by promising to credit me in their advisory and bulletin.

31/May/2008 – Microsoft issued an advisory, calling the combined vulnerabilities a “blended threat”, and suggesting Apple Safari users to stop using this Safari. This was all done without crediting me for working with them on this issue.

31/May/2008 – Microsoft changed their mind and stated that they will not credit me in their bulletin because I publicly disclosed information about the vulnerability in November 2006. By that Microsoft broke their 2nd promise.

01/Jun/2008 – I refused to continue the discussion with Microsoft until they change their mind back, and keep their promises.

04/Jun/2008 – Microsoft changed their mind back, stating that this is a onetime exception and they will credit my work in both the advisory and bulletin.

06/Jun/2008 – Microsoft updated their advisory and added the acknowledgment.

19/Jun/2008 – Apple fixed their side of the “Blended threat”, and released a new version of Safari. Still no fix from Microsoft.

02/Aug/2008 – Microsoft approached me at their BlackHat conference party. They stated that due to application compatibility issues (mostly with Adobe applications), the vulnerability will not be fixed until the release of Windows 7.

19/Mar/2009 – Microsoft released Internet Explorer 8, which is not vulnerable to the “DLL-load Hijacking” vulnerability. Older versions were still vulnerable.

14/Apr/2009 – After almost two and a half years since I first notified them about the vulnerability, and almost one year after I notified them about the “blended threat”, Microsoft have finally released a patch. They broke their 3rd promise (Windows 7, remember?), but this time for a good reason.

If you ask any Opera fanboy, he will tell you that Opera is the most secured browser. Well frankly, it really is a good and secure browser, implementing many restrictions that other browsers simply ignore.

For example, while other browsers allow scripts running from local resources to access local files Opera doesn’t. And by that, it is almost impossible to steal local files, or execute code by exploiting vulnerabilities local resources.

You probably noticed that I used the word almost. It is almost impossible, due to the fact that one, and only one local resource, does allow you to access local files and other browser settings. The local resource is opera:config.

One of the many settings this local resource can be used to change is the mail external application. The mail external application will be opened whenever you click on a “mailto:” link, or whenever your browser redirects to a “mailto:” URL. If an attacker can change this setting it means that he can automatically execute arbitrary code on the user’s machine from remote.

This is of course irrelevant, unless you can actually change the settings automatically from remote, and unfortunately for Opera users, there was a way.

Today, Opera released a new version, 9.62, with a fix for a vulnerability in a different local resource - the “History Search” page (opera:historysearch). The problem was that Opera did not sanitize specific parameters correctly, and an arbitrary script could be injected to this page. An attacker could then execute a script that will create an iframe which will open the opera:config local resource. And then, it will call a script within the opera:config page, which will change the settings and execute arbitrary code on the user’s machine as explained previously.

The vulnerability in the “History Search” page was found by Stefano Di Paola, during our discussion on the full-disclosure mailing about an older vulnerability in the “History Page” that was found by Roberto Suggi and was fixed by Opera in version 9.61. I’ve created proof-of-concept codes which demonstrate the vulnerabilities. Both can be found on milw0rm.com.

While both vulnerabilities in the “History Page” are now fixed, the core problem which makes it possible to execute code from remote, still isn’t.

There is still no Same Origin Policy restriction between local resources in Opera. It is still possible for a script to access one local resource (e.g. opera:cache) from another (e.g. opera:config). In my submission to Opera I’ve asked them to fix this issue as well, and I really hope they will do so before other vulnerabilities will be found in more local resources.

You all learned about the value of sharing. When I was a kid my mother taught me that I should share my stuff with my friends. Unfortunately, sharing is not always a good thing. Especially, when talking about sharing web-applications across domains.

Over six months ago I've discovered an interesting, yet troubling, issue - Google.com suffers from a cross-domain web-application sharing security design flaw. There are several Google web applications which are accessible over multiple google.com subdomains. The following are some of those web-applications and subdomains:

So, what's the problem with that, you ask? Well, there are several ways this cross-domain web-application sharing security design flaw can be exploited. For instance, one small XSS issue in Google Maps can now be exploited to hijack Google, GMail or Google Apps accounts, by bypassing the browser's Same Origin Policy. There were several XSS issues reported in the past, on some of the google.com subdomains, which are now fixed.

Furthermore, as shown by Adrian Pastor of the GNUCitizen team, it is also possible to abuse features of one of Google's web-application and then impersonate to an other. Adrian's proof-of-concept exploits a frame injection vulnerability in Google Images to inject a fake GMail login page. It then uses the cross-domain web-application sharing flaw to further convince the victim that this is a legitimate login page, from the legitimate mail.google.com subdomain.

I've notified Google about this issue several days after I discovered it, back in April. Their initial response was that they were looking into it. Today, after not getting any further response from the Google security team about this issue, and after Adrian published his proof-of-concept, I've decided to reveal this information in a hope that this security design flaw will be fixed by Google as soon as possible.

We've just passed the Jewish new year's holiday. Happy new year! It's a custom in this holiday to eat an apple and honey for a sweet new year.

Sadly, this year starts with a little bit sour Apple. If you follow my blog, you probably remember that I wrote about 2 vulnerabilities I've found in Apple's iPhone.

I have disclosed the technical details to Apple few weeks before that post, in a hope to get those security issues fixed as soon as possible. Unfortunately, two and a half months later, and still there is no patch for those vulnerabilities. I've asked Apple several times for a schedule, but they have refused to provide the fix date. Three versions (v2.0.1, v2.02, v2.1) have been released since I provided them with the details, and they are still "working on it". Therefore, I've decided to publicly disclose the technical details.

Both issues are pretty trivial, and can be easily fixed by Apple.

Phishing vulnerability

The iPhone's Mail application can be used to view both HTML and plain text mail messages. When the mail message is in HTML format, the text of links can be set to a different URL than the actual link. In most mail clients (e.g. on your PC / Mac), you can just hover the link and get a tooltip which will tell you the actual URL that you are about to click.

In iPhone it's a bit different. You need to click the link for a few seconds in order to get the tooltip. Now, because the iPhone screen is small, long URLs are automatically cut off in the middle. So, instead of "hxxp://www.somedomain.com/verylongpath/verylongfilename", you will get in the tooltip something like "www.somedomain.com/very...ilename".

The problem here is that an attacker can set a long subdomain (~24 characters) that, when cut off in the middle, will look as if it's a trusted domain. The following iPhone screenshot shows an example:

In this example, the text of the link is "https://securelogin.facebook.com/reset.php?cc=534a556abd1006&tt=1212620963", and the actual URL is http://securelogin.facebook.com.avivraff.com/reset.php?cc=534a556abd1006&tt=1212620963. However, when the victim will try to check what is the actual links is, he will see: "securelogin.facebook.com...556abd1006&tt=1212620963". This will convince the victim that the link is from facebook.com, where it is actually from avivraff.com.

When the victim will click this link, Safari for iPhone will be opened:

As you can see, the address bar shows: "securelogin.facebook.co...", this will further convince the victim that he is on the right trusted domain. Furthermore, when clicking the address bar, the cursor will jump to the end of the URL. So, in order to view the right domain the user will have to scroll back, which requires a lot of clicks and patience.

Spamming vulnerability

This one is not just a trivial bug, it's actually a pretty dumb design flaw, which was already fixed by all other mail clients ages ago. Whenever you view an HTML mail message which contains images, a request is made to a remote server in order to get the image. Most of the mail clients today requires you to approve the download of the images. This is done for a good reason.

If the images were downloaded automatically, the spammer who controls the remote server will know that you have read the message, and will mark your mail account as active, in order to send you more spam. This "feature" is also known as "Web Bug"

The iPhone's Mail application downloads all images automatically, and there is NO WAY to disable this feature!

Workarounds/Suggestions

As I wrote, there is no workaround for the spamming issue. So, my only suggestion is to avoid using the Mail application until a fix is available.

If you still insist on using it, you should be careful with the links you click, as they might not be from the trusted domain you think they are...

A "software mule" is a computer program which embedded, and therefore is dependent on, code of many other programs and libraries.

Q: Ok, I understand the definition. But, why being a "software mule" is a security issue?

By definition, a software mule embeds the code of its "parents" programs and libraries, and therefore it inherits their genetic problems, also known as - software vulnerabilities.

If a security vulnerability was found in a program or a library that is part of the software mule, it makes the software mule in high probability of being vulnerable to this security too. The vendor of the software mule will need to deliver a patch for each and every fix that was the made for the embedded code. This will take time, and will put the software mule users at risk, because the vulnerability in the embedded program/library will be already publicly known.

Q: So, Because Google Chrome is a software mule it is vulnerable to "Carpet Bombing"?

Most likely. As I wrote in my previous post, Google Chrome is using a mix of code of other browsers and libraries (also documented by Google themselves). "Carpet Bombing" (aka automatic file download) is a vulnerability that was found in Apple Safari and was already fixed.

This vulnerability is partially fixed. They have added a check to make sure that the default download folder is not the user's desktop. This is a good security measure, but definitely not a full patch for this issue. The vulnerability can still be exploited for a remote code execution. The proof-of-concept I provided in my previous post still works.

Q: Is there a workaround which can be used to mitigate this vulnerability, at-least until Google fixes it?

Yes, there is. Click on the "wrench" icon and then "Options". Under the "Minor Tweaks" tab make sure that the "Ask where to save each file before downloading" checkbox is checked. This checkbox is unchecked by default, and therefore the automatic download of malicious files is possible.

Q: Well, this is a simple workaround, and I've applied it in my browser. Does it mean that it is now safe to use Google Chrome?

No. As I've mentioned before, Google Chrome is a software mule. This means that it probably inherits all the security vulnerabilities of the program's code it embeds. For example, it uses an old version of WebKit, so it is probably vulnerable to all the security vulnerabilities that were already fixed in the latest version of WebKit. Maybe even the latest vulnerability that was fixed in the latest WebKit version of the Safari for iPhone...

In real life, when you take two species, a horse and a donkey, and mix them up you get a mule. In the browsers world, when you take a horse (Firefox/IE) and a donkey (Safari) and mix them up, you get – Google Chrome.The new browser from Google tries to get the best from other browsers, but instead (well, at least in the current beta version), it seems to be doing quite the opposite.

The current beta uses an old version of WebKit - 525.13 - which is actually the same WebKit engine used by the old Safari v3.1. The current Safari version is v3.1.2, which fixed several critical issues, including the “blended threat” Carpet Bombing vulnerability. Google even mention that they use Safari v3.1 rendering engine in their own documentation (Thanks Yonatan Grabber for the information!)

On the other hand, Chrome borrowed (and modified) local resource files from the Mozilla project. And also, for some reason, in some cases there is an ActiveX plug-in loaded by Chrome, which might be an evidence of a capability of this browser to execute ActiveX controls.

I really wonder why Google have taken several features from other browsers and mixed them all together. Security wise, it’s very problematic. They’ll have to track all security vulnerabilities in those features, and fix them in Chrome too. This will probably be only after those vulnerabilities were fixed by the other vendors or were publicly reported. It will put Chrome users at risk for a long time.

Back to the WebKit issue. I’ve created a proof-of-concept which demonstrates the automatic download vulnerability that was already fixed by Apple. This PoC will automatically download a JAR file and place it in the the downloads folder (there are reports that in some cases it will download it to the Desktop, as in Safari. In those cases, the Safari-Pwns-IE exploit can be easily converted to Chrome-Pwns-IE exploit).

Unfortunately, whenever Google Chrome downloads a file, it creates a download bar at the bottom of the page, which seems, for the untrained eye, as part of the page. The downloaded filename is displayed as a button, and the one click on this button will execute the file. If the file is an executable (e.g. .EXE, .BAT, etc.), Windows Explorer will show a warning that this file was downloaded from the Internet. In this case, Google Chrome does a good job by setting the Zone.Identifier in the alternative data stream.

However, as was mentioned by pdp at his great Black Hat talk this August, when Windows Explorer will try to execute a JAR file, it will automatically run the associated application, which in most cases is the JRE (Java Runtime Environment). JRE will not check the Zone.Identifier in the alternative data stream, and will execute the JAR file with no warning. JAR file, of-course, should be treated as any other executable file. This is again a sort of a "blended threat". Two small issues in different products, when blended together create a much larger problem.

In conclusion, Chrome seems to be a very nice and slick browser, but it is far from being secured as it is advertised by Google. It borrows several insecure features from other browsers, and it has its own security design flaws.

Do you think that just following security best practices will keep you and your users safe? Think again.

Recently, I've found 2 examples where following security best practices can actually expose you to security vulnerabilities, if you won't put your mind to it.

Example no. 1 - NoScript

Everybody who use Firefox and concerned about its own security and privacy uses NoScript. Unfortunately, for the customers of the PhishMe.com service, using NoScript will actually expose their private login credentials.

According to an eWeek article: "PhishMe, a new security SAAS offering from the Intrepidus Group, enables companies to launch mock phishing attacks against their own employees in the name of improving e-mail security...PhishMe does not collect sensitive information...JavaScript on the Web site overrides anything users actually input into fields during tests."

So, basically, using NoScript will disable JavaScript on the user's browser and will actually send over the sensitive information of the user.

Now, both of the teams here play fair in this game. Intrepidus Group follows some kind of privacy best practices by changing the HTML form to not send the user's private information over the network, and NoScript does it's own security best practice by disabling JavaScript on an unknown website.

But combined together (don't you love those blended threats?), the PhishMe.com service will try to phish users' credentials using pages which are not in the trusted domain, NoScript will then disable the JavaScript on the fake phishing page and the phished users of the fake phishing attack will eventually expose their private credentials.

Example no. 2 - Plain Text Emails

From "forgot my password" to "Johnny Depp wants to be added to your friends list", many services today send notification emails to their users. Security best practices wave a big "no, no" on HTML emails, and suggest that you read your email messages in plain text. There are services which already do the job for you and send their messages in plain text.

Unfortunately, what most of those services forget is that on a plain text email, a text which begins with either a URL protocol handler (e.g. http://, https://, etc) or "www.", will automatically transform itself to a clickable link, on most if not all mail clients.

This becomes a big issue when the plain text message contains a user generated content. The exact problem is described in my advisory over the TwitPwn website.

Twitter sends their users a notification, each and every time a different user has started following them on twitter. This email contains the following template:

Hi, *Your full name*.

*Follower's full name* (*Follower's username*) is now following your updates on Twitter.

Check out *Follower's username*'s profile here:

http: //twitter.com/*Follower's username*

You may follow *Follower's username* as well by clicking on the "follow" button.

Best,

Twitter

Now, both the Follower's username and full name can be alerted by the attacker, as it is save in his own profile. The username was restricted to alphanumeric characters, and therefore cannot be used for the attack. But, the full name was only restricted by the size, around 25 characters, enough to put the attacker's malicious http://www.evil.com link. All the attacker had to do was to run a bot which automatically follow people, and just wait for the victims to click on the links in the mails that were sent by twitter.

This vulnerability was fixed by twitter, and now you cannot use the dot character in the full name.

Conclusion

This post was not intended to get people to stop following security "best" practices. On the contrary, I encourage you all to follow them. All I'm saying is that following those and other security "best" practices will not make you and your users bullet-proof safe. You will now need to be more careful and think about other vectors too...

The iPhone's Mail and Safari applications are prone to a URL Spoofing vulnerability, which may allow attackers to conduct phishing attacks against iPhone users.

By creating a specially crafted URL, and sending it via an email, an attacker can convince the user that the spoofed URL, showed in the mail application, is from a trusted domain (e.g. Bank, PayPal, Social Networks, etc.).

When clicking on the URL, the Safari browser will be opened. The spoofed URL, showed in the address bar of the Safari browser, will still be viewed by the victim as if it is of a trusted domain.

Affected versions

iPhone Mail and Safari on firmware 1.1.4 and 2.0 are affected by this vulnerability.

Earlier versions may also be affected.

Technical Details

I'm currently withholding the technical details until a fix will be delivered by Apple. Security vendors who would like to get more information about this vulnerability can contact me.

Solution / Suggestion

Apple have acknowledged the vulnerability in the Mail application, and are still investigating the issue in the Safari for iPhone.Until a fix is available, I suggest to avoid clicking on links in the Mail application which refers to trusted web sites (e.g. Bank, PayPal, Social Networks, etc.). Instead, a user should enter the URL of the website manually in the Safari application.

As a side note, beside being phishable, the iPhone's Mail application is also "spammable". Apple has acknowledged this as a security issue.

This is a basic security design flaw which might already be exploited in-the-wild. iPhone users should consider stop using the Mail application until Apple fixes this issue, unless they want to be spammed.

Again, I'm withholding the technical details until Apple will deliver a patch.

Apple’s Safari for Windows is a nice browser. It really is. It has slick user interface, some pretty cool features, and benchmarks show that it is really fast. But, saying that it is “secured from day one” is simply not true, to say the least.

Unfortunately, Apple forgot to do the first thing you learn when you get a sunburn — learn from past mistakes, especially if they were made by others. The following are three prominent examples:

Automatic File Download

This issue is pretty simple. You visit a Web site and, without your confirmation, Apple downloads a file to your computer. Asking Apple to fix this issue was first treated as a “enhancement request.” This security hiccup was discovered by laurent gaffie, and then again, in a different variation, by Nitesh Dhanjani.

“…it could be argued that this is not a vulnerability because a dangerous file is not actually launched, but as of 2007, it is generally accepted that Web browsers should prompt users before saving dangerous content…”

Also, as already confirmed by Apple, this vulnerability can be used in a blended attack to automatically execute arbitrary code from remote, without user interaction. Strike one!

Let’s move on…

Browser Fuzzing

July 2006’s Month of Browser bugs was all about fuzzing. During this month and afterwards, several browser fuzzing tools were released by HD Moore, Matthew Murphy, Thierry Zoller and I. Hamachi, CSS-Die, DOM-Hanoi and AxMan, were freely available to the public.

Going a year forward, Apple Safari for Windows was released. A few hours later, several critical bugs werefound, simply by using the publicly available browser fuzzing tools.

Nothing more to add!

Cache and Cookies Predictable Location

Last but not least, a new design flaw. Apple Safari for Windows keeps the Cache and Cookies in files at a predictable location. This design flaw was already researched in the past by several security researchers. This is exactly why the Temporary Internet Files of Internet Explorer are saved in random directories, and Firefox generates a random name for the profile directory.

But not in Apple Safari for Windows. The cache.db (SQLite database file) and cookies.plist (XML file) are saved in the user profile directory under a static named directory.

Think about a new blended threat, where it is possible to load an local XML file from remote (was possible in the past in other browsers), and in combination with this design flaw, an attacker can easily steal all of the user’s cookies and hijack browser sessions.

Should we say more?

In conclusion, before porting the Safari browser from Mac to Windows, Apple should have looked at past browser vulnerabilities and design flaws, and really try to avoid them.

The examples above show that Apple didn’t learn anything from past mistakes.

I’ve just read Ryan's post about the new VLC remote code execution vulnerability. He quoted Secunia’s workaround recommendation for VLC users: “Do not open untrusted WAV files”. This recommendation is not good for two reasons:

1) VLC can play files WAV files that ends with other file extensions that VLC can open, e.g. MP3 files.

2) An attacker can place an webpage which uses the VLC ActiveX for IE users to play the malicious WAV files (installed by default by VLC), or just redirect to the malicious WAV file for Firefox users who installed the Mozilla plugin (not installed by default, need to be manually selected, or installed if the user chooses the Full installation).

The best suggestion is of course to upgrade to the latest version, or use an alternative media player.

So, After reading that post, I got Ryan’s twit where he asks if VLC has an automatic update mechanism. That was a good question, and I did remember that VLC had some sort of update mechanism.

For my surprise, the latest unpatched version, v0.86h, didn’t have that option. So, I tried to go few versions back (using the awesome OldApps website).

Version 0.86 did have the “Check for Updates” option under the help menu. Clicking on it brought a new ugly window with only one button, of yet again, “Check for updates”. Clicking on this button did absolutely nothing.

So, then I decided to move few versions forward to 0.86c. This was the version I remembered having the update mechanism. It also had the option under the help menu (which brought the ugly window again). Clicking that button showed a new windows suggesting to download the “available updates” – version 0.86d.

Hrmm.. Wait.. Shouldn’t v0.86i be the latest VLC version? According to the VLC download website the answer is not yet, but even there it is version 0.86h and not 0.86d.

So, I’ve decided to download and install the 0.86d version anyway, just to find out that the "Check for updates" option is now missing again.

Not a good way of implementing a software updater…

P.S. No, there was no automatic update on any of the versions I checked.

[Updated - see below]Yes, you've read it right. Apple Safari can be used to pwn users with Internet Explorer installed. Well, basically this means that attackers can pwn Windows users who browse the web using Safari for Windows.

I've reported this issue to Microsoft over a week ago, and they have just issued a security advisory.I've decided to work with Microsoft on this issue, because this combined attack also exploits an old vulnerability in Internet Explorer that I've already reported to them a long long time ago.

The root of this combined attack is Safari's "Carpet Bomb" vulnerability that was recently found by Nitesh Dhanjani. I didn't bother contacting Apple, as they've told Nitesh that they consider this as an "enhancement request" and will not bother to fix this issue any time soon.

I've currently decided not to publicly disclose any further details, until Microsoft or Apple provide a patch. I can only say that Microsoft's suggestion for a workaround is not enough. This combined Safari/IE vulnerability might still be successfully exploited, even if the user will change Safari's download location. Also, the Safari "Carpet Bomb" vulnerability can be used in combination with vulnerabilities in other products, so even if MS fixes their vulnerability, Safari users will still be vulnerable.The current best solution is to stop using Safari until Apple fixes their vulnerability.I would like to take this opportunity and remind you that I've added a new RSS feed for the upcoming advisories. This feed will include new vulnerabilities which I've found but have not yet published their technical details on my blog.

Security vendors are welcomed to contact me in order to get more information about those vulnerabilities.

[UPDATE 07-JUNE-2008] Microsoft took my advice and updated the suggested workaround in the advisory. This updated workaround reduces the probability of being exploited to almost zero. So, if you decide to keep using Safari for Windows, you should follow the steps described in the new workaround.

During the past 2 weeks I got tons of questions regarding the 0day treasure hunt and the vulnerability itself. In order to make things more clear and understandable, I've compiled a list of answers for several frequently asked questions.

Q: Why do you involve politics and security?

A: I see nothing politic in celebrating my country's independence day. I'm sure you all do the same in your own country. We also play this treasure hunt game during the Passover holiday, but I thought it will more suite independence day this year. Maybe next year I'll do it earlier in Passover.

Q: Can you explain the clues? I'm not sure how they fit with the 0day treasure.

A: Sure. You can find the clues here. I'll explain each of them by their number.

Obviously, the vulnerability affects Internet Explorer 7.0 and 8.0 beta. According to Secunia it also affects IE6.

In order to exploit the vulnerability the user must interact with the exploit by printing the webpage and enabling the "Print Table of Links" option.

The proof-of-concept code was embedded in all of the pages of the blog.

The proof-of-concept was hidden as a "tracking" script that was dynamically generated in order to generate a link. This script used XMLHttpRequest to get a page that returned the main page of the blog, but with a 404 (File Not Found) status code.

Acidus wrote in a blog post about the Phishing hole I found a year ago in IE7. Both vulnerabilities are within Internet Explorer "local resources". Acidus was right in that I then said that only most of the local resources are running in "Internet Zone". The 0day vulnerability is within a local resource which runs in "Local Machine Zone".

Anchor = HTML anchor (<a> tag) = link. What else can you do with a link? Print it.. (I did say think "out of the box")

A: Well, it depends. As this vulnerability requires user interaction in order to be exploited, it will surely not be used in a worm scenario. However, it still highly possible to be used in several other attack scenarios. For example, an attacker can add malicious links to massively printed user generated websites (e.g. Wikipedia, technical forums, blogs, etc.) and just wait for the victims to print those pages with the "print table of links" option (usually used to print a "references" appendix).

Q: So if that's the case, why haven't you waited a reasonable time to let Microsoft patch this vulnerability?

A: I've had bad past experience with Microsoft's response time. The last time I used their "responsible disclosure" policy, I had to wait 6 months for them to fix a one line of code in a non core component. As I've already showed, this 0day vulnerability also requires one line of code to be fixed, and I'm sure no one wants to wait 6 months for it to fix. Past experience also shows that Full Disclosure can help in getting a quicker fix. I usually do provide enough time for a vendor to fix a vulnerability.

Q: My security product (Anti-Virus/IPS/IDS) says that it detects this vulnerability. Am I safe to print pages with links?

A: Not necessarily. Even though several AV products have already added a signature to the proof-of-concept I provided (see Figure 1), they only protect you against this specific proof-of-concept. How do I know? Very simple, I just changed the proof-of-concept a little bit (the proof-of-concept still executes Windows Calculator), and tested against VirusTotal again. This time no AV product could detect it (see Figure 2). You can test the new proof-of-concept yourself here. Anyway, you should really ignore the PR guys of the security companies who simply lie when they say that their product protects against this 0day vulnerability. It doesn't. In this case, it just try to protect you against executing Windows Calculator on your machine.

Internet Explorer is prone to a Cross-Zone Scripting vulnerability in its “Print Table of Links” feature. This feature allows users to add to a printed web page an appendix which contains a table of all the links in that webpage.

An attacker can easily add a specially crafted link to a webpage (e.g. at his own website, comments in blogs, social networks, Wikipedia, etc.), so whenever a user will print this webpage with this feature enabled, the attacker will be able to run arbitrary code on the user’s machine (i.e. in order to take control over the machine).

Whenever a user prints a page, Internet Explorer uses a local resource script which generates an new HTML to be printed. This HTML consists of the following elements: Header, webpage body, Footer, and if enabled, also the table of links in the webpage.

While the script takes only the text within the link’s inner data, it does not validate the URL of links, and add it to the HTML as it is. This allows to inject a script that will be executed when the new HTML will be generated.

As I said in a previous post, most of the local resources in Internet Explorer are now running in Internet Zone. Unfortunately, the printing local resource script is running in Local Machine Zone, which means that any injected script can execute arbitrary code on the user’s machine.

Proof of Concept

The following is an example of a URL which executes Windows Calculator:

[And the winner is: George the Greek]Today we are celebrating, here in Israel, 60 years of being an independent country. As part of the celebration, I’m releasing a new 0day vulnerability. One of our customs in Independence day is to play a “treasure hunt” game. In this game there is a treasure hidden somewhere in our beautiful country, and we get mysterious clues that help us find this treasure by traveling tomanygreatsites all over Israel.In the spirit of this day, I’ve decided not to release full details about this vulnerability yet, but rather play a little “treasure hunt” game. Somewhere in my blog, I embedded a proof-of-concept code which exploits this 0day vulnerability. The following are some clues that will help you find this 0day treasure: 1) IE7.0 and IE8.0b users will get pwned. 2) An interaction with the sploit is needed. 3) There’s no need to find the post. It’s everywhere. 4) 404 is the way to go. 5) Acidus was right! Local resources is the key. 6) What else can you do with an anchor? Think out of the box, literally. 7) Charles Babbage is probably turning in his grave. 8) The following screenshot should really help you find the source of the treasure:9) Put the videos together to find the treasure.

Every day or two I will add a new clue to this list, in a hope that by next Wednesday someone will eventually find the treasure Next Wednesday I will release the full technical details of this 0day vulnerability and the proof-of-concept code. Until then, feel free to comment your findings. The first person who will post a comment with the proof-of-concept code and details on how to use it to exploit the vulnerability will be declared as the winner.Now, I don’t have any laptop prize to give the winner. But, beside the credit for being the first to find a 0day treasure, I’m willing to offer the winner a free entrance to the IsraCON security conference that will take place in Israel this summer.

Happy hunting!

[UPDATE 08-May-2008] Some of you guys out there are already in the right direction, some are not. I've added 2 more clues.[UPDATE 10-May-2008] You are getting closer. Pay attention to clue number 6.[UPDATE 11-May-2008] Yet another clue added.[UPDATE 12-May-2008] I've added a new screenshot clue. [UPDATE 13-May-2008] Last clue added (3 videos). The game will end tomorrow evening (Israel time). You still have enough time to find the treasure.[UPDATE 14-May-2008 02:30] And we have a winner! details soon...[UPDATE 14-May-2008 16:15] The winner is: George the Greek. Congratulations! Full technical details of the vulnerability are available here.

I hate when things like this happen. You are too eager to succeed in something, and it eventually fails because of pure bad luck. This exactly what happened to me in CanSecWest's PWN2OWN contest.

I've heard that the second PWN2OWN contest will be held at CanSecWest, a week before the conference began. I couldn't attend the conference this year, but I did want to participate. So, I looked at my vulns arsenal, and picked one that looked pretty neat, was easy to exploit, and met the contest terms: the vulnerable application is AIM (a popular software client), exploiting the vulnerability allows remote code execution, and the neat thing is that the exploiting the vulnerability requires Man-In-The-Middle, which can be easily achieved by using the cool AirPwn tool.

The next thing was to look for an on-site trusted person, with enough skills to build the attack. Fortunately, I've been able to contact Steve Manzuik, who teamed up with AirPwn creator, Bryan Burns, to create the exploit.

Now that we were ready, the only thing that we waited for was the first day of the contest to arrive. Unfortunately, and this is where the bad luck begins, a day before the contest began Tipping Point have decided to change the rules. So now, instead of being able to participate in the contest from the first day, we had to wait for others to try and exploit the machine for a whole two days, before we can start.

Day 3 came. Vista machine was still up, MacBook air already gone, and my friends, Steve and Bryan, are waiting in line for the contest. One place before them in the line was the winner of last year's contest, Shane Macaulay. Rumors were that he had a working exploit. 10 minutes passed, nothing. 20 minutes, not a single word. After 30 minutes (the official limit for each turn), the word was out that there were some kind of hardware problems. Eventually, after few hours (??), with some help from his friends, Shane was able to get his Flash exploit working. Kudos to Shane, Alexander and Derek for winning!

Now I left with one little problem. What should I do with the AIM vulnerability. The way I see it, I have three choices:

1) Leave it as it is - Only Steve, Bryan and me will know about it, until eventually someone else will find it.

2) "Responsibly" disclose it - Send all the information to AOL, wait for a fix to be delivered, and then publish the technical stuff.

3) Full Disclosure - Inform AOL, and in parallel publicly disclose all the technical information.

I'm interested in what you think the best choice is. Please comment or send me an email with your thoughts. New ideas are also welcomed.

One of these dialogs is used by a feature called "SkypeFind". This feature, available from version 3.1, allows Skype users promote and review businesses around the world. Sadly, it could also be used by attackers to own Skype users' machines.

Within this feature any Skype user can add a new business and review an existing business. Skype does a great job sanitizing the data provided in the business item entry, and also the text provided in the user's reviews.

Unfortunately, they forgot to sanitize the full name of the reviewers. So, an attacker can inject a malicious script in his Skype's Full Name, and whenever a victim will view a business which was reviewed by the attacker, in the SkypeFind dialog, the malicious script will be executed in an unlocked Local Zone!

Fortunately for the attacker, it is also possible to open the dialog in a specific business details page from the browser, using the skype: URI handler (e.g. skype:?skypefind ). This means that it is possible for the attacker to create a worm!

The attacker however, must authorize the victim to view the attacker's full name, but this can be easily achieved in the following two ways (thanks pdp for the second suggestion!) :

Interactive bot:

The victim enters a malicious website which automatically calls the attacker via Skype. This can be done by using the skype: URI handler (e.g. skype:attacker?call)

The attacker's bot intercept the call, and cancels it. Now that the bot has the victim's username, it uses the User.IsAuthorize API call to allow the victim to view the attacker's full name.

After a few seconds, the malicious website opens the malicious SkypeFind dialog, and the victim gets owned!

Passive bot:

A passive bot is searching the Skype network for active users.

For each user the bot uses the User.IsAuthorize API call to allow the victim to view the attacker's full name.

When a victim who was authorized visits a malicious website, the malicious SkypeFind dialog will be opened, and the victim will be owned!

I've contacted Skype security team, and they have provided a quick fix for the full name issue.Unfortunately, this is not enough! I'm worried that there are probably other ways to inject a script to this dialog. I strongly advised Skype to disable this feature until they provide a patch for the cross-zone scripting vulnerability. For no good reason, they have decided to decline my advice.

Therefore, until a patch is available, my suggestions to Skype users are:

Disable the skype: URI handler. This can be done by a registry change, and I recommend it only for power users.

Other users who don't want to mess with the registry should uninstall Skype. Having Skype installed without using it will not solve the problem, as the skype: URI handler will automatically open Skype and login!

Zull (Guy Mizrahi) has created a great demonstration video. A better quality video is available here.

[More updates at the end of the post]As of last Saturday, Skype have disabled adding videos from Dailymotion. They have announced it in their security bulletin.

While this "workaround" was good enough to mitigate the proof-of-concept I provided, it cannot be considered a real workaround that will help secure Skype users, until a patch is available.

For an unknown reason, Skype have decided to leave adding Metacafe videos through its' "Add video to mood" and "Add video to chat" features. So basically, injecting a script to Metacafe video's metadata (Title, Description, etc.) should be - again - enough to execute code from remote.

So, I've tried a simple script tag injection to the metadata of a video, and failed because Metacafe are stripping HTML tags from the metadata. I did that by submitting a video through the Metacafe website.

But then I saw a little link on the upper right of the website, suggesting to download "Metacafe pro", which is the software version of the Metacafe website. So, I did, and surprise, surprise... Submitting a video with HTML and script tags through the "Metacafe pro" application does not filter the tags!

After few tweaks (Thanks Golan!) I was able to create a fully working proof-of-concept exploit.

The more troubling issue here is that this PoC can actually be triggered by simply visiting a website, or clicking on a link from your Instant Messaging application. Which basically means that this vulnerability is now wormable!

This is why I've decided not to publicly disclose the proof-of-concept, nor to show a video that might disclose too much information.

I've sent the PoC to Skype's security team, and have been told that they are going to release a patch for this vulnerability ASAP. Furthermore, they have now disabled the Metacafe tab too - which means, no more adding videos in Skype until a patch is released...

[UPDATE 23-JAN-2008 00:55 GMT+2:00] For no good reason, Skype have decided to bring back the Metacafe videos feature. The proof-of-concept still works. So, as this is a wormable vulnerability, my advice for you guys is to downgrade your Skype to a version that does not support adding videos (before v3.5.0), or even better - Uninstall Skype, and use an alternative client!

[UPDATE 23-JAN-2008 11:30 GMT+2:00] After talking with the Skype security team, it seems like bringing Metacafe back was probably a malfunction, and surely was not on purpose. They are doing their best to disable it again. I for one can say that on some of my computers Metacafe is now disabled. Let's hope they'll disable it everywhere, at-least until a patch will arrive.

Skype uses Internet Explorer web control within the application to render internal and external HTML pages. Examples for this pages are the "Send money via PayPal" dialog, or "Add video to chat" dialog.

Recently, I've discovered that Skype is running this web control in Local Zone. The more problematic issue here is that Skype runs the HTML pages is a not-locked Local Zone mode, the same as AOL's AIM does in the chat message window.

This means, that if it is possible to inject a script to any of those pages, it is possible to execute code on the user's machine. pdp suggested that AirPwn can be used for that, and I can't do more than agree with him.

Today, Miroslav Lučinskij posted to Full-Disclosure that it is possible to inject a script to the "Add video to chat" dialog via the Title field of the DailyMotion movie information. He called this a Cross-Site Scripting vulnerability, but it is actually a Cross-Zone Scripting vulnerability, because the script runs in IE's Local Zone instead of the Internet Zone.This basically means that an attacker can now upload a movie, set a kewl popular keyword (e.g. "Paris Hilton"), and own any user that will search for a video with those keywords through Skype.

I've tested this with the latest version of Skype - v3.6.0.244. Prior versions may also be affected.

Until the Skype guys fix this vulnerability, I recommend that you stop searching for videos in Skype.

I've created a proof-of-concept which executes the calculator when searching for "calc test" in Skype's "Add video to chat" dialog. The following video demonstrates the proof-of-concept:

After reading the great post, I must say, "Hacking the Interwebs" by the GNUCitizen team, I thought that it would be a waste not to try and find a way of attacking UPnP without the Flash requirement.

Basically, what needs to be achieved in order to attack the device through UPnP over HTTP is to:

Be able to send a "POST" request to the device's IP address.

Be able to set the "SOAPAction" header of the "POST" request.

Now, because we can't set headers in a simple HTML form submission, we can instead use XmlHttpRequest. But, becuase the device's IP address is of-course different from the attacker's web site IP address, the same origin policy comes into play.

If we'll disregard that the device might have XSS vulnerabilities, another way of breaking the same origin policy is DNS pinning.

I was about to start and investigate whether XmlHttpRequest and DNS pinning can be used to attack UPnP enabled devices, just to find out that someone else has already done this research.And this was done almost a year ago!

Evasive attacks are everywhere. Malicious attackers are using methods like blocking multiple visits to an exploit, or serving specific exploits per browser, in order to minimize the detection of the attack by the security vendors.

Another way to evade an attack is patch detection. Why try to exploit a machine which has a patch for a vulnerability already installed?

Most installed patches are saving an un-installation setup program. The path to this program is usually: "\WINDOWS\$NtUninstallKBXXX$\spuninst\spuninst.exe", where XXX is the knowledge base number of the patch.

So, for example, if an attacker would like to know if he should serve an exploit for the MDAC vulnerability, he can detect if the client has the MS06-014 patch installed. According to the MS bulletin, 911562 is the knowledge base number of this patch, so he can now check if the file "\WINDOWS\$NtUninstallKB911562$\spuninst\spuninst.exe" exists. If this file does not exist, he will then serve the exploit. If the patch does exist, he will not serve the exploit, and by that he will minimize the probability of being detected.

There are already proof-of-concepts for local file enumerations out there, so I see no reason for providing another one. As I've already mentioned, the PoC's can be easily modified to implement patch detection.

P.S. - Patch detection can also be used for legitimate causes. I encourage you all to download Secunia's PSI (Personal Software Inspector), and check whether you have an unpatched software installed on your machine. Although, now that there is a way to detect patches from remote, we might see an online version of PSI soon :)

Q: Why should Firefox sanitize single-quotes and spaces? Mozilla follows the standards, and the RFC says the Realm value is a quoted-string.

A: Nowhere in my advisory I said that Mozilla does not follow the standards in this case. But, because of the way they implement dialog, it is possible to create fake double quotes, and by using multiple spaces it is possible to fake a new line. I also did not suggest to sanitize the single-quotes and spaces as a solution. In my opinion, a better solution would be to display the server name before the realm value, or even in a different field or in the title of the dialog.

Q: Is there a proof-of-concept available for this vulnerability?

A: While I did not provide a proof-of-concept for this issue, it is very easy to follow the instructions on my advisory to create one. In fact, Alex of bitsploit.de has already created a good demonstration on his blog.

Q: How did you discover this vulnerability?

A: I've found a similar vulnerability in an early version of Firefox (back when it was still called Firebird). Lately, Zull's forums (Hebrew) were attacked by a basic authentication phishing attempt. This attack included just the server name of Zull (hacking.org.il) in the realm value. I then remembered my old finding, and tested it in the new version of Firefox, just to find out that there is a much easier way to exploit it.

Q: How do other browsers display the Basic Authentication page?

A: The guys at Kriptopolis blog have published some screenshots of Internet Explorer, Firefox, Opera and Konqueror displaying a spoofed Basic Authentication dialog.

Q: I'm using (Fill in product name)-Anti-Phishing tool. Am I protected against this vulnerability?

A: While anti-phishing tools may help in some cases, most of them will block the phishing page only after the page is displayed, or will just display the currently visited domain in a toolbar. This means that some of the anti-phishing tools may not be able to protect you against this vulnerability, as the phishing attempt will occur before a page in the attacker's domain will be displayed.

Q: Are there any other attack vectors?

A: I'm sure that there are other attack vectors which can be used to attack this vulnerability. For example, Alex of bitsploit.de has found that if you have the FasterFox extension installed, an attacker can just put a link on a trusted page. FasterFox will then use its' pre-fetching feature to try and cache the attacker's link which will trigger the spoofed basic authentication dialog.

I hope that these answers make things more clear. If you have any other question, don't hesitate to comment or just send me an email.

Mozilla Firefox allows spoofing the information presented in the basic authentication dialog box. This can allow an attacker to conduct phishing attacks, by tricking the user to believe that the authentication dialog box is from a trusted website.

Affected versions

Mozilla Firefox v2.0.0.11. Prior versions and other Mozilla products may also be affected.

Technical details

Mozilla Firefox displays an authentication dialog, whenever the visited web server returns 401 status code, and the "WWW-Authenticate" header. In order to specify basic authentication, the "WWW-Authenticate" header should have the value [Basic realm="XXX"] (without the brackets). The Realm value, which in this case is XXX, will be displayed in the authentication dialog window.

While Firefox does not display the characters in the "WWW-Authenticate" header Realm value after the last double-quotes ("), it fails to sanitize single-quotes (') and spaces. This makes it possible for an attacker to create a specially crafted Realm value which will look as if the authentication dialog came from a trusted web site.

There are at-least two possible attack vectors:

An attacker creates a web page with a link to a trusted website (e.g. Bank, PayPal, Webmail, etc.). When the victim clicks on the link, the trusted web page will be opened in a new window, and a script will be executed to redirect the new opened window to the attacker's web server, which will then return the specially crafted basic authentication response.

An attacker embeds an image (pointing to the attacker's web server, which will return the specially crafted basic authentication response) to:

A mail which will be sent to a webmail user.

RSS feed which will be consumed by a web RSS reader.

A forum/blog/social network page.

A video which demonstrates the first attack vector can be found on YouTube. A better quality video can be download from here.

A video of a real live attack on a forum, which used basic authentication but without exploiting the vulnerability, can be found on Zull's weblog (Hebrew).

Suggestion / Workaround

Until Mozilla fixes this vulnerability, I recommend not to provide username and password to web sites which show this dialog.

Google Toolbar allows spoofing the information presented in the dialog which is being displayed when adding a new Google Toolbar button. This can allow an attacker to convince the users that his button comes from a trusted domain. This button can then be used to download malicious files or conduct phishing attacks (e.g. show a login form of a bank).

Affected versions

Google Toolbar 5 beta for Internet Explorer

Google Toolbar 4 for Internet Explorer

Google Toolbar 4 for Firefox (partially)

Technical details

Google Toolbar provides a nice API for creating toolbar buttons. Basically, the button information is stored in an XML file.

In order to add a button, the toolbar user must click on a specially crafted link which refers to the button's XML file. When the user click on the link, a dialog appears with all the following details: The domain where the button is being downloaded from, the name, description and icon of the button and some "privacy considerations", which basically shows the domains which the button interacts with (sends/receive information).

By creating a specially crafted URLs it is possible for an attacker to fake the domains displayed in the "Downloaded from" and "Privacy considerations" sections. This specially crafted URL can be created by simply adding an open redirector (e.g. in google.com - http://www.google.com/local_url?q=) before the URL.

An attacker can use this vulnerability to gain the victim's trust to add and use the button, and by that the victim will trust the files that the button offer, or enter private information. In the new beta version of the toolbar it is also possible to alert the user every few seconds to click on the button.

In the Firefox version of Google Toolbar it is only possible to fake the "Privacy considerations" section.

Proof-of-Concept

A proof-of-concept which adds a "critical update" button can be found here. Use it at your own risk, though it shouldn't do anything but suggest you to download gupdate.exe from my site, which is basically the windows calculator.

Workaround / Suggestion

Google have acknowledged this and are already working on a fix. Until a fixed version is provided, I suggest to avoid adding new buttons to the toolbar.

No. I'm not going to show you how to use Cross-Site Request Forgery (CSRF) in order to attack mobile phones while using a mobile phone to surf the web. Instead, I'm going to talk about how CSRF vulnerabilities can be used to cause denial-of-service attacks against mobile phones, by flooding the phone with SMS and service messages.

Mobile phone service providers in Israel, and throughout the world, provide a web interface to send SMS messages. Fortunately, they limit the SMS sending web interface to 20 messages per day, and they also require the user to login to their web site in order to send an SMS.

Unfortunately, at-least when referring to the Israeli providers, they also give attackers a way to send endless SMS and service messages without any kind of authentication and with a simple HTTP request. While this method doesn't allow to specify the message of the SMS, it does allow the attacker to specify the targeted phone number.

All Israeli mobile phone providers (Orange, Cellcom, and Pelephone) place at-least one advertisement on their website, which require their customer to enter their mobile phone number in order to get a specific service, a coupon, or a password for an online service. This ad (mostly written in Flash) simply sends an HTTP request to the mobile provider web servers which then sends the SMS message to the given phone number. Again, this web service is not limited and the messages can be sent to any number over and over again.

With this CSRF vulnerability, an attacker can send multiple requests to the server in order to make the use of the mobile phone not practical. This is because the victim will get so annoyed (sometimes even without a way to make a phone call) that he will probably just shut the phone down. The attacker can also place an IFRAME or image on a website (e.g. MySpace profile, a forum post, etc.) which will be used to mimic the ad's HTTP request. So, on every visit of this page, the victim will get an SMS. On high volume website pages (e.g. MySpace or Facebook profiles), this will cause a lot of requests to be sent to the mobile provider web service and the victim will again get too much messages which will make its mobile phone useless.

Other mobile phone providers around the world might also have advertisements which allow sending SMS without any limitations. My suggestion to the mobile phone providers is to limit the ads SMS sending web service to one SMS per phone number per day.

P.S. the GNUCitizen team has published a great explanation on CSRF and how it can be exploited.

Sometimes it is nice to see old vulnerabilities come back from the dead.

This time I'm referring to a vulnerability in Internet Explorer that was discovered almost 3 years ago by cyber_flash. The vulnerability allows an attacker to bypass the security download warning dialog, and display a regular save file dialog, by manipulating IE into displaying executable file (a file with .exe extension) as a regular html file.

While this vulnerability was partially patched by Microsoft in IE7, it was still remained unpactched in IE6 SP2.

Few days ago, this vulnerability came back to life when laurent gaffi posted in Bugtraq that it is possible to download and open an executable file in an application associated to a different extension, using a very similar specially crafted URL that was used in cyber_flash's proof-of-concept.

I've been able to use this old vulnerability to automate an attack vector that was found by pdp from GNUCitizen. In his proof-of-concept, pdp exploits a vulnerability by opening a manually downloaded PDF file in Adobe Reader. When I tried to open the PoC file inside IE7 it didn't exploit the vulnerability. This is probably because the Adobe Reader ActiveX control is running in a different way, in terms of security, than the external application. Therefore, I used the old IE vulnerability in order to automatically download and open the PoC PDF file in the external Adobe Reader application. The exploit then executed the Windows calculator.

The following is a video which demonstrates the difference between opening the proof-of-concept PDF file in the browser (embedded) and in the external application.

I've tested this version against the critical vulnerability I've found. While it does fix the specific attack vector of the vulnerability, it still does not utilize the Local Zone lockdown. This means that if someone will found another way to inject a script to a message, it will still be possible to execute arbitrary code from remote.

I've decided to postpone the release of my proof-of-concept, at least until AOL will fix their client properly. This is mainly because it will probably not be so hard to manipulate the PoC and find another way to inject a script, and there's a short way from this to creating a massive IM worm.

Unfortunately, there are no release notes to indicate that there was a security fix in the new version.

AOL's AIM is one of the most used IM clients in the world. According to Neilsen/Netratings, AOL had around 53 million IM subscribers in 2006.

A week ago, I've found a critical vulnerability in the latest version of AIM, which could allow an attacker to execute code from remote by simply sending a message to the victim.

Just before reporting the vulnerability to AOL, I've encountered a blog post by Ryan Naraine which describes a vulnerability in AIM that was found by "Shell". After reading the advisory, I understood that this vulnerability is a bit different from the one that I found, as it is in the Notification window which pops-up only when you are not in the middle of conversation with the attacker.

So, I've decided to report the vulnerability to AOL, and provided full description and Proof-of-Concepts. I have yet to receive any response from AOL.

Today, Core Labs have published an advisory which describes the general case of my findings. In the advisory they also claim that AOL has patched the vulnerability, so the latest beta version (v6.5.3.12) of AIM is not vulnerable anymore.

I've tested the PoC which I provided to AOL against the "patched" version. While the latest beta version seems to filter my PoC, I've been able to change my code a little and successfully exploited the vulnerability again.

The problem with AOL's patch is that they filter specific tags and attributes, instead of fixing the main cause of the vulnerability, which is locking down the local zone of their client's web-browser control.

Core Labs describes a workaround in their advisory which messes up with the registry. I think that the common people should avoid this workaround, and stop using AIM until a real fix from AOL will arrive.

I also encourage AOL security staff to contact me as soon as possible. I am willing to provide them with all the new information. I will not contact AOL again, as I'm still waiting for AOL to respond my first email.

[UPDATE:] I've just got an email from AOL which confirms that the "patched" beta version is still vulnerable:

Hi,

We apologize, for not initially responding to your email. We have already fixed out client on these issues and the client is scheduled for a mid-October release. This fix is not yet in the current AIM beta client.

But, what if you are using a limited web environment, where you can't use iframes or scripts to automate your pwning? Several limited web environments (e.g. blogger.com blog system) does not allow using iframes or script, but they do allow embedding QuickTime movies.

Few days ago, pdp found that it is possible to use QuickTime .qtl files to execute code from remote, when the default browser is Firefox. This is a variant of the good old MOAB #3 and pdp's own MP3 backdooring exploit. It uses a simple "-chrome" command-line switch injection.

As this is a Firefox only exploit, I looked for ways to do the same in Internet Explorer. I found that it is also possible to perform all other noted XAS attacks using QuickTime.

So now, if you are in a limited web environment, you can just embed a .qtl file and conduct an automated XAS attack against the visitor of the web page.

The following is the QuickTime .qtl version of the "shutting down skype" PoC:

We've just passed Microsoft's black Tuesday. Microsoft have patched two vulnerabilities that I've reported in the Windows Vista Sidebar gadgets.

The first vulnerability was in the Contacts gadget. Because I was supposed to present this vulnerability at Defcon as Finjan's representative, I cannot discuss it. But, you can find information about this vulnerability at Finjan's MCRC blog post.

The second vulnerability was in the RSS Feeds gadget. I've reported this vulnerability to Microsoft through iDefense VCP program. iDefenst have recently published their own advisory for this vulnerability.

Microsoft have decided to rate these vulnerabilities with "Important" severity. This is because that according to Microsoft's rating system, they rate a vulerability as "Critical" only when the exploitation of the vulnerability could allow a propagation of a worm without user interaction.

Not rating the RSS gadget vulnerability as "Critical" might make sense in the old era of "Web 1.0". But on today's "Web 2.0" era, an Internet Worm can be easily propagated by exploiting this vulnerability.

Think about the following scenario: 1) User Joe is subscribed to digg.com's "Upcoming Stories" RSS feed.2) The attacker adds a malicious item to digg.com. When the vulnerable RSS gadget fetches the malicious item, it infects Joe's computer with a malicious Trojan worm.3) Joe is a major blogger at myblog.com. The malicious trojan worm identifies that Joe has a myblog.com cookie, and automatically adds a malicious post to his blog.4) User Juliet reads Joe's blog regularly, as she's one of the thousands people who subscribe to Joe's blog RSS feed. Juliet also gets infected by the Trojan worm, when her vulnerable RSS gadget automatically fetches the malicious post.5) Juliet is a known writer at FamousPeople.com magazine. She uses a standard online content management system to publish her stories. Again, the malicious Trojan worm identifies the content management system, and automatically post a fake story about Paris Hilton, which of-course includes a malicious payload.6) User Dan is a fan of Paris Hilton. But, instead of using the FamousPeople.com RSS feed, he subscribe to Google News RSS feed with all Paris Hilton related news. When Google News spiders FamousPeople.com it automatically adds the malicious story to the RSS feed, and Dan gets infected too.7) For Dan, the malicious worm sends a malicious payload as an email to all his contacts which uses webmail (e.g. GMail). Why? You guessed it right. The webmail systems also support RSS feeds. So, now all of Dan's contacts who fetch their mail as RSS feed and use a vulnerable RSS gadget are in danger...8) Etc. etc. etc.

As you can see from this scenario, when it comes to a vulnerability in an RSS reader, an internet worm becomes very realistic.Fortunately, this vulnerability has already been fixed by MS. Unfortunately, it took them almost 6 month to fix one line of code in a non-core component.If you are using Windows Vista, I encourage you to update your machine as soon as possible, or stop using the Windows Vista Sidebar.

For those of you who develop gadgets, I recommend to read Microsoft's "Inspect Your Gadget" document. Although it is not perfect, this document should give you some hints on how to develop a more secure gadget.

Today, Thor exposed a way to execute code from remote, if you have both IE and Firefox installed on your machine.

This is done by cross application scripting. He used an iframe in IE which refers to a protocol handler that was registered by Firefox, in order to open the latter browser and inject a script in an elevated privileges (chrome) mode.

Now the question is, whose fault is it? Is it an Internet Explorer problem or a Firefox problem?

Well, past experience shows that this is not the first time IE suffered from cross application scripting. Inge Henriksen demonstrated a way to attach arbitrary files to outlook messages using IE and cross application scripting.

Thor himself found a remote code execution vulnerability in Safari for Windows using cross application scripting.

Lately, I've noticed that it is possible to shutdown Skype from remote, in the same way:

<iframe src='skype:" /shutdown'></iframe>

An online PoC can be found here (be careful, clicking this link will also close all your opened Skype chat sessions!)

Back to the IE/FF problem. So, who should to fix this issue? I think both.

Mozilla should fix the way they register the "FirefoxURL:" protocol handler, and Microsoft should sanitize the parameters they pass to external applications.

CVE-ID: CVE-2007-3185
Available for: Windows XP or Vista
Impact: Visiting a malicious website may lead to an unexpected
application termination or arbitrary code execution
Description: An out-of-bounds memory read issue in Safari 3 Public
Beta for Windows may lead to an unexpected application termination or
arbitrary code execution when visiting a malicious website. This
issue does not affect Mac OS X systems.

I've tested the new version by running Hamachi again. Apparently, this version fixes the vulnerability.

This patch also fixes the command injection vulnerability that was found by Thor.

Apple decided not to credit any of the security researchers in their advisory, and I don't think this is a smart move.

"...The Metasploit Framework ("Metasploit") is a development platform for creating security tools and exploits. Version 3.0 contains 177 exploits, 104 payloads, 17 encoders, and 3 nop modules. Additionally, 30 auxiliary modules are included that perform a wide range of tasks, including host discovery, protocol fuzzing, and denial of service testing..."

Now that Metasploit 3.0 is out, you can expect a first alpha version of VoMM very soon.

One of the comments for my post on the phishing hole in IE7 was that the anti-phishing tool of the browser will detect scams exploiting this vulnerability, because it will check the external javascript reference (e.g. In my PoC - http://www.raffon.net/research/ms/ie/navcancl/phish.js). I’m not an IE7 anti-phishing internals guru, so I’ve decided to test it.I’ve searched for a list of live phishing sites and found millersmiles.co.uk anti-phishing service. From the list I chose http://pqpal.com/cgi-bin/index.htm, which is a paypal phishing page. IE7’s anti-phishing tool reports this as a phishing website. To be able to use this phishing URL in my test, I’ve created a local DNS entry for pqpal.com and set it to my local web server. To verify that the anti-phishing tool actually works with this local DNS entry, I’ve loaded the phishing URL in IE7, and got the phishing warning page again.Next, I’ve created index.htm file under cgi-bin directory on my local web server. This file simply contains: alert(“Hello from phishing site!”);For the proof-of-concept, I’ve created a HTML file with a reference to the external script - http://pqpal.com/cgi-bin/index.htm. When I’ve loaded this HTML file in IE7, I got the “Hello from phishing site!” alert box, and no indication that this comes from a phishing URL.This means that IE7 anti-phishing tool DOES NOT block pages with external scripts that points to a flagged URL. So, unless Microsoft will flag the navcancl.htm local resource as a phishing page, I see no other way for IE7 anti-phishing tool to detect phishing scams exploiting this vulnerability.Again, until this vulnerability is fixed by Microsoft, do not trust any link in the “Navigation Canceled” page.

Technical DetailsThe navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled. When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com. The navcancl.htm page then generates a script in the “Refresh the page.” link in order to reload the provided site again when the user clicks on this link. It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.

Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.

To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace). When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.

Proof-of-ConceptA CNN.com article spoofing proof-of-concept can be found here. If you are not using IE7, you can watch a demonstration video here.

Whether the vulnerability is cross-site scripting, cross-domain scripting or cross-zone scripting, sooner or later an attacker will need to inject a code in order to exploit it. The difference between each of these types is the context.

When we talk about a cross-site or cross-domain scripting vulnerabilities, we mean that an attacker can execute the injected code within the context of a different internet site or domain. However, when an attacker exploits a cross-zone scripting vulnerability, the context is now changed from an internet site to an intranet site, or even worse - pages in local zone.

Intranet sites and pages running in local zone are often and by default run with less security restrictions than internet sites. This means that if an attacker can execute his own code in intranet site or local zone, he will eventually be able to execute malicious code on the victim's machine.

A good example for the difference between those vulnerability types is the quicktime vulnerability that was found by pdp. When this vulnerability was exploited by the Myspace worm, this was a cross-site vulnerability. Only internet sites were involved, and it was used to steal MySpace accounts information. In MoAB#3, I've introduced a way to exploit this vulnerability in the context of local-zone. This means, that it is now a cross-zone scripting vulnerability, and an attacker can use quicktime to execute malicious code on the user's machine. MoAB#3 also used another vulnerability found by hdm in one of the local resources of Win2k. As Internet Explorer restricts linking to local resources (res:// files), I used quicktime to do it.

Lately, I've found that it is possible to open a local resource in Internet Explorer without the need for any additional plug-in (like quicktime). By using a simple redirection header, an attacker can link and open a local resource and bypass Internet Explorer's restriction. I've tested this on IE6 SP2, IE7 and IE7 on Vista.Now, this alone might not be a big issue, as Microsoft now runs most of the local resources in the Internet Zone, but it might be used to perform other types of cross-site scripting attacks.

Almost two weeks after I've sent the first mails, and after sending two more follow-up mails asking if there are any updates regarding this issue, I got only one more response - from Google. Google's response was somewhat vague:

Hello,Thanks for your report. We apologize for any inconvenience this may have caused.When we are notified of such issues, we investigate and take appropriate action if we find that the Gmail Terms of Use have been violated. To read the Gmail Terms of Use, please visit:http://mail.google.com/gmail/help/terms_of_use.html.We appreciate your concern, and thank you for taking the time to send us your comments.Sincerely,The Google Team

From Gmail’s terms of use: “…Before you register for your Gmail account, you must read and agree to these Gmail Terms of Use and the following terms and conditions and policies, including any future amendments…”.

I’m not an attorney and I didn’t go to any law school, but from what I can understand from the first line of the terms is that these “terms of use” are only for Gmail registered users. So, if an attacker will brute force the MySpace phishing list and will find a valid Gmail username/password and use it, he will not violate these terms because he hasn’t registered to that account and therefore he doesn’t need to read or agree to the terms. I’ve sent this comment to Google.

I'm still waiting for a respond from Yahoo and Microsoft. Again, to demonstrate how easy it is to extract a valid username/password from the phishers list, the following is a modified version of the Gmail account validator. This time, for Yahoo! Mail:

Yesterday, a huge list of MySpace accounts’ usernames and passwords was revealed to the public. This list was harvested by phishers. Most of those MySpace accounts’ usernames are emails of the following webmail accounts: GMAIL, Hotmail, Yahoo! Mail and AOL.Some of those poor MySpace users are probably using the same password in their MySpace account for their webmail account, and probably for other web services too (ebay/Amazon/etc).Brute forcing those web services to extract the valid credentials from the phishers list is very easy. So, I’ve decided to first contact the webmail vendors (Google, Microsoft, Yahoo and AOL) and ask them to analyze the phishers list against their own database in order to warn the poor users to change their passwords as soon as possible.Over 21 hours later, and only AOL have responded to my suggestion/request. AOL's response (10 minutes after I’ve sent the mail!) :

Hi Aviv,

Thank you for the notification. We noticed this on the Full-Disclosure list as well. We will do everything we can to protect these users.

Thank you,

Kent L.AOL Product Vulnerabilities

Just to demonstrate how easy is to extract the valid username/password from the phishers list, the following are 20 lines of C# code which validates username and password of a GMAIL account:

As I’ve already mentioned in the third "Month of Apple Bugs" advisory, the QuickTime HREFTrack feature, which was exploited in the last MySpace worm, is vulnerable to cross-zone scripting attacks.Landon Fuller, who have decided to publish fixes for the bugs disclosed in the "Month of Apple Bugs", has provided a fix for this vulnerability a few hours after it was published.This fix, which blocked referencing the javascript protocol handler in the HREFTrack attribute, was aimed to fix the cross-site scripting vulnerability. Again, this specific vulnerability was previously disclosed by pdp, and was exploited in the MySpace worm. This is a different vulnerability, and although this fix was better than the fix apple provided (which probably only prevented the MySpace worm), it didn’t fix the vulnerability I disclosed in MoAB #3.

Today, after exchanging mails with Landon Fuller, he published a new version of this fix. This time, instead of black-listing the javascript protocol handler, he white-listed only the protocol handlers that were supposed to be referenced in the HREFTrack attribute (http, https and ftp).

This updated fix, although it seems to be only for Macintosh users, should prevent exploitation of this issue on that platform. Good job Landon! We’ll now have to wait for an official cross-platform fix from Apple, or maybe a cross-platform “Month of Apple Fixes” initiative.

P.S.This fix patches the rNPN_GetURL() function. If this patch is global for both the QuickTime plug-in and the QuickTime player, it should also prevent exploitation of the .qtl cross-zone scripting vulnerability that was also previously disclosed by pdp.

A month ago, a vulnerability in QuickTime was exploited to spread a worm in MySpace. The vulnerability was first published by pdp. In his article, pdp describes how HREFTrack attribute in .mov files can be used for malicious scripting. The MySpace worm abused this vulnerability in a cross-site scripting attack vector.

This MoAB issue shows that this vulnerability can also be used in a cross-zone scripting attack which could allow, in combination with other vulnerabilities, to remotely execute arbitrary code on the user's machine, as well as disclosure of the filesystem contents.

It has been over a month since my last post regarding the IE7 vulnerability. Thailand is really an amazing place for a honeymoon J.The feedbacks to this issue were mixed. Some said it's an issue that should be fixed as soon as possible, other said it's a minor issue, a hoax or just "old news".

Well, although I did not give the full information in my last post, it is definitely not a hoax, and as far as I know (and Google knows) no one ever informed about this specific issue in Internet Explorer.As a workaround, Thierry Zoller suggested that the “Enable Safe DLL Search Order” feature should be enabled. Other informed that the Desktop folder is not in the user’s PATH by default. While this is true, the behavior of the “DLL Search Order” (when it’s disabled) is to look for the DLL in the current directory, right after the Internet Explorer’s directory. As most users execute Internet Explorer from the Desktop, the current directory will be of course the user’s Desktop (see screenshot below).

The following DLL file names can be used to exploit the IE7 DLL-load hijacking vulnerability:• sqmapi.dll• imageres.dll• schannel.dll

A Proof-of-Concept code for this vulnerability can be found at milw0rm.

So, Microsoft has released version 7.0 of Internet Explorer a few weeks ago. The new version introduced some nice security features like "ActiveX opt-in", "Better add-on management", "Phishing filter" and more. But even with those new security features, IE7 is still heaven for spyware writers.

The new version of Internet Explorer is vulnerable to a DLL-load hijacking. When IE7 is executed it will load several DLL files. While trying to load some of those files, it does not provide the full path of the DLL file to the function which loads the DLL file to the memory, and therefore Windows will search for this file in the user's machine using the directories provided in the PATH environment variable, and will load the first match it will found.

Today, most desktop security products include a generic detection for changes in the startup folder and startup registry keys, in order to catch malicious code trying to load when the users boot his machine.

Now, all the attacker has to do to bypass this detection is to put a malicious DLL file (or just a downloader DLL of a malicious file) in one of the PATH directories (e.g. the user's desktop), and the next time the user will run IE7 the code of the attacker's file will be executed instead of the original DLL file.

Moreover, the attacker can hide the DLL file, by setting an hidden file attribute. As most users have the option of not showing hidden files enabled (this is the default settings), it will not show them the malicious file on the user's desktop, but still IE7 will load the DLL file.

This vulnerability also can be used instead of registering Browser Help Objects (which some of the security products also monitor), as the DLL will run in the context of IE7 process.

I've reported this to Microsoft few days ago. Their response: "If the attacker can put a dll on the box in a location that is in the user's PATH variable, then they already own the box. ". While this is true in most cases, the user will still think he is secure with his desktop security products installed, which is not true as this vulnerability allows spyware writers to execute code automatically without changing startup and BHO information.

As Microsoft intends to fix this issue only in future releases of their OS (according to their response), I encourage security vendors to update their products to detect this behavior as soon as possible.

Exploits for browser vulnerabilities are here to stay. Most security products today are using reactive methods (signatures) to detect the specific exploit, instead of trying to detect the general case of the vulnerability exploitation. Evading those signatures is very easy, as I already showed.

The methods I presented were simple and very specific to the VML vulnerability. H.D. Moore have implemented some of these methods in his Metasploit's VML exploit module. Others were implemented in old browser exploit modules, like the createTextRange exploit module.

H.D. Moore, LMH, and I have decided to generalize the evasion methods and package them all into one project.

The purpose of this project is to create a module for Metasploit that will take any given browser exploit and make it as undetectable as possible.

Currently, most Anti-Viruses signatures relies on "variants". Meaning, any little change in the malicious code is considered by the AV as a new variant. The VoMM project shows that this procedure cannot be applied to browser exploits, as each exploit can have endless number of "variants" with no change to the server side code.

More detailed information about the VoMM project, and the evasion techniques that were implemented, can be found in LMH's info-pull blog.

The code for exploiting the unpatched VML vulnerability is in-the-wild for a week or so. This was enough time for Anti Virus, IPS/IDS and other reactive security products' vendors to create a signature for the in-the-wild exploit. So, I put my hand on one of the in-the-wild and tested it using Virus Total. The results were not so good. Only 10 of 27 Anti-Viruses detected the exploit on the malicious web page.According to ISC diary: "Some reports indicate that client-side anti-virus is not sufficient to protect, some AV apparently only catches the VML exploit code once Internet Explorer writes the temp file to disk, which can be too late.".Now, what if the exploit is detected by the AV signatures? Are those signatures generic enough? I've decided to check it out.

I've used 5 simple methods, trying to evade being detected by the signature:1) I've replaced the location where EIP should jump when the exploit is activated, with a different valid address.2) I've replaced the VML element from "rect" with one of the other VML elements.3) I've replaced the payload with a different valid shell code.4) I've replaced the namespace key with a random key.5) A combination of all of the above.

Please note that when I changed the code using any of the methods, the exploit still worked.

IPS/IDS vendors also wrote signatures for detecting exploitation of the VML vulnerability.According to a post in the Bleeding Edge Snort forums: "this signature 2003106 that should detect a vml exploit is a bit too generic." .I say the opposite! The signature is too specific. It can be easily bypassed, by using method 2 or method 4.

As you can see, evading AV/IPS/IDS signatures of web page exploits is too easy.

P.S. Randomization of any of the evasion methods (e.g. using a random VML element) can be implemented by using server side scripting.

[UPDATE:] H.D. Moore has published a new metasploit module for the VML vulnerability. This module uses evasion methods 2 and 4. It also uses an evasion technique I did not mention - Randomizing javascript variables. So, it will probably not be detected by most AV/IPS/IDS signatures.[UPDATE2:] According to H.D. Moore, the new module is not detected by any of the current AV/IPS/IDS signatures. Virus Total test confirms this.

As I already reported, I've found a vulnerability in AOL Security Toolbar, which could allow an attacker to control the user's toolbar configuration options from remote.

Within 1 (one) day, AOL replied by email, confirmed the vulnerability and delivered a fixed version. Wow, very fast response!

I've verified that this fix actually plugs the hole. Good job Spencer!

So, I recommend to anyone who use the AOL Security Toolbar to update to the latest version.

To know which version you are using, go to Left Button Arrow --> Help --> "About AOL Security Toolbar". The vulnerable version is: Version 1.11 (08-03-06).

If you are using this version, and have not received (or ignored) the message asking you to update your toolbar, you can manually update by going to Left Button Arrow --> "Update Toolbar...". You should be notified if you use the latest version of the AOL Security Toolbar.

But just to be sure, the version that is not vulnerable is: Version 1.13 (08-18-06).

I will update this post on Friday with a proof-of-concept exploit for this vulnerability.

I was more than happy to help HD Moore with MoBB, and provided some nice browser bugs for this project.

One of those bugs was "MoBB #30 - Orphan Object Properties". This bug occurs when referencing an object that was created inside an object data window inside a frame, and then relocating the frame to a different position, leaving the created object orphan.I've found this bug while creating a subset of the Hamachi fuzzer. So, I've decided to create a specific fuzzer that will find all possible orphan object referencing bugs. I've actually found over 15 crashes involving 8 different objects.

Last Tuesday Microsoft released a cumulative security update for Internet Explorer, MS06-042. I was surprised to find out that they were quick to fix the orphan objects issue, with no mention of fixing this vulnerability in the security bulletin.

As this vulnerability was silently patched and the orphan objects' bugs cannot be exploited anymore, I've decided to stop my research on this issue and I'm releasing the fuzzer to the public.The Orphan Objects Fuzzer can be downloaded from here. An online version of the fuzzer can be found here.

On the other hand, this cumulative security patch included another patch for the "COM Object Instantiation Memory Corruption Vulnerability". Those patches (the first was MS05-038) are actually a workaround for the real problem. Instead of fixing the browser's code, Microsoft has decided to update IE's kill-bit repository with the problematic COM objects' CLSIDs.

By now, all they did is to add CLSIDs of the operating system's COM objects. What they forgot is that their user base includes a lot of PCs with 3rd party COM objects installed. Some of them (e.g. Yahoo Messenger, AOL's new Anti-Virus' Security Toolbar, and more) can be used to exploit the same vulnerability.

I don't know if they did this on purpose, or because they were not aware of the 3rd party issue. I can only hope they are going to fix this vulnerability, which is known for over 10 months now, and this time for real.

P.S. AOL's new security toolbar is not playing nice in another point of view. I will discuss this on one of my next posts.

"...DOM-Hanoi is a community-developed utility for verifying browser integrity, written by H D Moore and Aviv Raff.DOM-Hanoi will look for common DHTML implementation flaws by adding/removing DOM elements, in a similar way to the known Tower of Hanoi game..."

"...CSSDIE is a community-developed utility for verifying browser integrity, written by H D Moore, Matt Murphy, Aviv Raff, and Thierry Zoller. CSSDIE will look for common CSS1/CSS2/CSS3 implementation flaws by specifying common bad values for style values..."

On Thursday a new generation of the createTextRange exploit was released under Metasploit.

Few hours later, and an article was published on techweb, where AV vendor Fortinet claimed that this exploit is much faster (??) than the older exploits. And, probably after reading my blog post, older exploits caused the browser to freeze.

Up until today, in the wild createTextRange() vulnerabilityexploits were not so silent. The need to wait more than minute, while your web browser freezes, in order to get the exploit to be executed, was too much for the victims. Most of the victims were probably shutting down the browser manually before the vulnerability was actually got exploited.

Introducing the Next Generation of the createTextRange() exploit from Metasploit. This exploit uses a non-CPU consuming techniques in order to get a more silent exploitation.

Now that we have a new generation of exploit out there, we can only hope MS will be fast enough to deliver an out-of-cycle security update for the createTextRange() vulnerability.

P.S. This exploit will also evade most "generic" AV and IPS detections which are mostly looking for specific tokens from the old proof-of-concept script, instead of using a real heuristic detection.

"...Hamachi is a community-developed utility for verifying browser integrity, written by H D Moore and Aviv Raff. Hamachi will look for common DHTML implementation flaws by specifying common "bad" values for method arguments and property values..."

In about a week and a half, three new Internet Explorer security holes were publicly disclosed:

- 13-Mar-06: Jeffrey van der Stad informed about a vulnerability in IE which allows running HTA files without the user's permission.- 16-Mar-06: Michal Zalewski introduced a Proof-of-Concept of a vulnerability in the way IE handles a large number of events in a single HTML tag.- 22-Mar-06 (Today): A memory corruption vulnerability was disclosed in Full-Disclosure by Stelian Ena (although he claims it to be a "well known issue"). The problem is with the way IE calls the createTextRange method from a CheckBox control. According to MSDN, the CheckBox control should not have the createTextRange method.The published Proof-of-Concept will only crash the browser. But, I've managed to create another Proof-of-Concept (which I WILL NOT publicly disclose just yet), and it seems that this memory corruption vulnerability is exploitable for a remote code execution on a fully patched XP SP2. It might also be exploitable on other windows operating systems.

Too many holes in such a short time... We can only hope MS will take these problems seriously and provide a patch soon.

[UPDATE:] "Computer Terrorism (UK) :: Incident Response Centre" have published an advisory for the createTextRange vulnerability. They also confirm a production of a Proof-of-Concept, and that they already notified Microsoft about this issue.

[UPDATE2:] Secunia has also reported on this issue. This time about the Radio Control.

I would like to add that 3 types of input controls can be used to exploit this vulnerability: CheckBox, Radio (as already reported) and Image control (<input type="image">).

[UPDATE3:] Microsoft has published a security advisory for the createTextRange vulnerability.

It appears that the severity of the new vulnerability found in Windows Media Player's plug-in for non-IE browsers was downplayed by Microsoft.

According to iDefense's advisory: "Due to unicode translations, shellcode characters are somewhat limited to character code values below 0×80". So, my assumption was that MS ranked this vulnerability with 'Important' severity instead of 'Critical' because of the un-feasibility of injecting a usefully shell-code.

Well, I guess I was wrong. Alphanumeric shell codes can be used, and also SkyLined heap spraying method. Both Proof-of-Concepts were demonstrated by H D Moore and Matthew Murphy.

A week ago, Mozilla Foundation released a new security update which included 8 advisories. 4 of the advisories were rated with 'Moderate' severity. At least 3 of them, IMHO, are exploitable for remote code execution with no user interaction.

Today, HD Moore, the author of Metasploit, published a remote code execution exploit for one of the 'Moderate' severity rated vulnerabilities.

This again shows you that Mozilla Foundation are not learning from past mistakes and are still downplaying vulnerabilities.

My guess is that they are waiting for an exploit in the wild before they are going to rate any exploitable memory corruption vulnerability as 'Critical'.

As the great Israeli comedians group, "Hagashash Hachiver", was known to say: "So... What did we have so far?"

One critical vulnerability in Windows' Graphics Rendering Engine. Over 200 known viruses exploiting this vulnerability. At least 3 "generations" of the Metasploit Proof-of-Concept code. Two third-party unofficial patches. One leaked "beta" patch, and one official patch, released 5 days earlier.And all this in a week or so. Wow! What a great opening for 2006.

According to the Microsoft's security bulletin, and some other sources (haven't bindiff it myself yet...), the patch only forbids the Escape's code execution functionality, if it was called by the WMF rendering engine. But, is it enough?

A quick scan through my %windir%\system32 shows that over 20 DLL files are importing the problematic Escape function.

A better solution by Microsoft would be to forbid the SetAbortProc functionality, as they probably already did in the 64bit version of Windows XP.

I can only hope that they'll provide a better fix, before someone else exploits this design flaw.

After 5 months, Mozilla foundation have finally updated their advisory, and set the severity status to 'Critical'.

This small "victory" actually expose the hypocrisy of the Security Community. Many times before we have seen security experts bashing Microsoft for downplaying vulnerabilities (even patched ones). But, when it comes to Mozilla products, the silence of the community rumbles.

I hope this incident will set a red flag at Mozilla foundation, and they'll do better in the future with their vulnerabilities management. Just a reminder - they have yet to take back their claim of ZIPL0CK's DoS finding to be just a 'minor' issue.

I've also encountered some disturbing information regarding FireFox users who haven't upgraded their browser, and are still vulnerable to the InstallVersion.compareTo() vulnerability. I will publish this info soon.If you are still using old version of FireFox please upgrade as soon as possible.

A few days ago, ZIPL0CK introduced a new Denial Of Service vulnerability in Firefox. By creating a huge web page title, which will fill the history.dat file with large content, Firefox will hang for some time (depending the content size and the user's system) on the next time the user will try to use the browser.

Today, Mozilla foundation published an advisory, claiming this issue is not so serious, and that the unresponsiveness of the browser is only "temporary". This is true for the Proof-of-Concept exploit, and for people with strong computers. But by modifying the PoC, an attacker can easily achieve a humongous history.dat file which will cause the Firefox to hang (with 100% CPU utilization) for a LONG LONG time. So long, that most users will not wait just to delete the history as suggested by Mozilla foundation in the advisory. The right workaround would be to delete the history.dat file. Moreover, Mozilla foundation should acknowledge this problem as more severe, and address it as soon as possible.

This reminds me the last time Mozilla underestimated a vulnerability. I've also posted this issue to Full-Disclosure, but yet to receive response from Mozilla.

I think it's been enough time for people to upgrade from v1.0.4. of Firefox. So, here is the PoC exploit for the InstallVersion.compareTo() vulnerability. The PoC does nothing but returns (this can be easily replaced with shell code), and it uses SkyLined's InternetExploiter2 methodology to inject code to the heap.

[UPDATE:] Apparently, Mozilla team has removed the access to the InstallVersion.compareTo() bug report page. I hope this means they will finally set the severity of this security hole in the advisory to higher than just 'Moderate'.

[Another Update:] Packetstorm has removed the Denial-of-Service exploit page. This PoC can be found at milw0rm.

[Last Update? :] The InstallVersion.compareTo() bug report page is opened again. Unfortunately, the severity of the vulnerability in the advisory is still 'Moderate' :(.

According to somemessages at the Kaspersky website's forums, there should be a security update available for the "Windows workstations" version of the Anti-Virus. The updated version is 5.0.227.

Yesterday, Kaspersky published a response to the advisory, claiming they released an update to their Anti-Virus signatures that should handle exploitation of the CAB engine vulnerability. They also promised that an update to the engine, that will plug the security hole, will be released.

A new critical vulnerability was found in the Kaspersky Antivirus engine.According to the advisory, the vulnerability is a Heap Overflow in the CAB file format parsing engine, which can be exploited remotely by receiving a specially crafted CAB file through email or while surfing the web.There is still no response from the vendor about this issue.As this advisory includes a Proof of Concept, a malicious exploit will surely arrive soon.My recommendation to all the Kaspersky Antivirus users is to currently disable CAB files monitoring, by modifying the Real Time Protection settings, until a patch will be available.

To disable Kaspersky CAB files monitoring:1) Double click the Kaspersky icon in the system tray.2) Click the "Settings" Tab3) Click the "modify real time settings" link4) In the opened window, click the "Additional settings" button.5) In the opened window, click the "Details" button.6) In the opened window, check the "Objects" checkbox under the "Exclude from scan" section, and click the enabled "Modify" button.7) In the opened window, Click the "Add" button.8) In the opened window, write "*.cab". Click "Open" Button. 9) Click the "OK" button, and again.. the "OK" Button.10) Click on the "E-mail" tab.11) Follow sections 5-9 to disable monitoring CAB files in email attachments.

After the patch for this security hole is available and installed, make sure you restore to the default settings by clicking the "restore default settings" link under the "Settings" tab.

Good news for the security industry. eWeek reports on a new plan to create a database for common names of malwares. This will reduce the confusion of trying to figure out which Virus are people actually talk about.

A great example is the last Trojan Horse involved in the industrial espionage incident that took place in Israel last May. Symantec called the Trojan "Rona" or "Hotword", while McAfee called it "PWS-HOTWORLD". This created a big confusion in the media.

The even better news is that this database will not be commercial, so I'm sure it will help the security industry in creating better collaborative tools for fighting malwares.