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.
 
See you in July.

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.

Timeline

29/Oct/2006 – Notified Microsoft about the “DLL-load Hijacking” vulnerability.

29/Oct/2006 – Microsoft acknowledged notification.

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.

21/Apr/2008 – Windows XP SP3 released. Microsoft broke their first promise (in this timeline). Still no fix.

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.

22/May/2008 – Ryan contacted Microsoft regarding the combined vulnerabilities, and provided them with my proof-of-concept.

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.

Nevertheless, my recommendation for Opera users is still to upgrade to the latest version.

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:

• Google Maps (maps.google.com)
• Google Mail (mail.google.com)
• Google Images (images.google.com)
• Google News (news.google.com)
• Google.com (Google Search, Google Accounts, Google Apps, Google History, etc.)

Here's example of Google News being hosted on the Google Maps subdomain: http://maps.google.com/news?sa=N&tab=ln

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

Q: What is a Software Mule?

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.

Q: Google claims that they have fixed this vulnerability. Is it true?

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