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.