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.

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.

According to CVE-2007-4424:

“…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 were found, 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.

[CROSS POST]

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.

1. Obviously, the vulnerability affects Internet Explorer 7.0 and 8.0 beta. According to Secunia it also affects IE6.
2. 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.
3. The proof-of-concept code was embedded in all of the pages of the blog.
4. 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.
5. 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".
6. Anchor = HTML anchor (<a> tag) = link. What else can you do with a link? Print it.. (I did say think "out of the box")
7. Charles Babbage is the inventor of the printer.
8. This screenshot is of the actual vulnerable code in the local resource script. One line of code is needed to be fixed here.
9. First video: Print. Second video: Table. Third video: Links. ===> Print Table of Links. Simple as that.

 

Q: How critical is this vulnerability anyway?

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.

 

        

Figure 1 - Several AV detect the PoC              Figure 2 - No AV detect the slightly modified PoC

Summary

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

Affected version

Internet Explorer 7.0 and 8.0b on a fully patched Windows XP.

Windows Vista with UAC enabled is partially affected (Information Leakage only).

Earlier versions of Internet Explorer may also be affected.

Technical details

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:

 

I removed the proof-of-concept of the 0day treasure hunt. A live proof-of-concept can be found at milw0rm.

Solution / Suggestion

I’ve contacted Microsoft last Tuesday. Their last response was that they are looking at an appropriate fix.

Until a patch is available, I suggest not to use the “print table of links” feature when printing a webpage.

[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 to many great sites 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.