If at first you don't succeed; call it version 1.0
Thursday, 30 October 2008

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.


Thursday, 30 October 2008 17:47:21 UTC | Comments [0] | Security#
Friday, 10 October 2008

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

googlenewsmaps

 

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.

gmailimages

 

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.


Friday, 10 October 2008 13:03:06 UTC | Comments [1] | Security#
Thursday, 02 October 2008

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:

iphone1

 

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:

iphone2

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


Thursday, 02 October 2008 06:16:33 UTC | Comments [5] | Security#
Friday, 12 September 2008

 

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. 

chromesaveopt

 

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


Friday, 12 September 2008 16:51:17 UTC | Comments [2] | Security#
Wednesday, 03 September 2008

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.

mozchrome

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.

coupwns

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.

Wednesday, 03 September 2008 19:24:45 UTC | Comments [6] | Security#
Monday, 18 August 2008

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


Monday, 18 August 2008 21:19:57 UTC | Comments [1] | Security#
Wednesday, 23 July 2008

Summary

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.


Wednesday, 23 July 2008 18:34:37 UTC | Comments [0] | Security#
Contact Me
RSS Feeds
  
Blogroll
Archive
Admin Login
Sign In
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.