RSA is pretty much over now and it has been a blurry several days. Some real good sessions, some real good panels. Lots of meetings and interviews and many old friends on hand (shoutouts to Dave Perry, Larry Bridwell, and Lysa Myers), but I digress. …

For me the best event was the “Hacking Exposed” session, by Stuart McClure and George Kurtz. OK, I cop to being biased because I know and work with both these gents/slackers at McAfee, but they did show a really wild hack–they pwned a primary domain controller from an iPhone! Yep, you read that correctly. They hacked a Windows server FROM an iPhone.

For those who were not among the annointed and attended, I have uploaded the slide deck here. Stu and George recorded the hack as well:

The Apple iPhone is vulnerable to a new bug related to the signing of iPhone applications.  Applications that are created with the official iPhone SDK need to be cryptographically signed by the author and Apple before they’re allowed into the App store or installed on an iPhone.  The digital signing is a security measure that serves two purposes; helping to identify the developer in case of any problems and making sure that an approved application hasn’t been modified.

An iPhone developer discovered the bug while looking for a way to duplicate a feature of Apple created iPhone applications: dynamic default.png files.  The default.png file is displayed when an iPhone application is launched and can be used as a static splashscreen.  When you quit an Apple created application, it takes a snapshot of the screen when you quit and saves it as default.png within itself.  The next time you start the app it loads the new default.png, and everything looks like it was when it was last run. The application hasn’t fully loaded yet, but the saved default.png trick makes it look that way.

Unlike Apple’s apps, those created by other developers can’t modify their default.png files. Since the default.png is stored within the application as a part of itself, it gets digitally signed.  Modifying the image file and thus the app, makes the digital signature invalid.  An alternative would be to use a default.png in the application’s data directory, but only the file within the application is supported on the iPhone.

The method to replicate Apple’s default.png trick involves a defect in the codesign utility in the iPhone SDK.  codesign is the utility used by developers when they digitally sign their applications.  Normally codesign will take every file within an iPhone application into account when it creates the digital signature.  the problem with codesign is that it doesn’t handle symbolic links (symlinks) properly.

Symlinks are like shortcuts to files; if you want to refer to one file in two locations or with two different names you can create a symlink in the new location.  The symlink isn’t a new file copy, just a pointer to the original file.  codesign doesn’t follow the pointer to the original file, so it doesn’t consider that file during signing.  The new approach is to create a symlink named default.png that points to a location or file outside of the application that can be easily modified.

This is a neat trick, but harmless.  If it were only the codesign utility that has this symlink problem, then the technique would not work for an installed application.  The real trouble arises when symlinks are used to obscure other program files or components during signing.  The digital signature process was intended to ensure that no unapproved or unsafe modifications could occur.  An attacker could arrange for malicious components to be installed using a self-update feature.  Since the digital signature ignores symlinks, the malicious application could contain pointers to the yet to be downloaded parts.  Since the bad portions of the program don’t exist during the approval process, malicious applications can sneak through.  This effectively bypasses the iPhone OS’s protection against the running of malicious code.

Fortunately, since the application is signed, tracking down the author of such malware should be considerably easier.  Given that the vulnerability lies within a utility in the iPhone SDK and within the iPhone OS’s verification system, it should be fixed shortly in a future update.

Within the first 24 hours, participants in McAfee’s SPAM Experiment have already started to receive a wide range of spam. The U.S. economic crunch (bearing in mind I am NO economist ) may be having an effect on spam campaigns, as several of the recipients, browsing the Web and working independently of each other, have started to receive offers that center around guaranteed loans, credit cards, and debt relief.

The spam that isn’t offering money is trying to take it away from the participants. Three of our “victims” have already been targeted by phishers! It didn’t take long at all for some of their e-mail address to be picked up and exploited by fraudsters.

According to their blogs, some of the participants started to receive spam almost immediately after they clicked on pop-ups on the first day and provided their e-mail addresses for free offers! As usual with the free offers it turns out that it’s almost impossible to meet the conditions to get the free Xboxes, Wiis, iPods, iPhones, etc.

At the time of this writing, the overall spam submission counts have exceeded 550 from 17 of the participants. One participant alone has received more than 130 pieces of spam!

More to come during the next 29 days. Make sure you follow the participants blogs and stay tuned.

The iPhone has generated a lot of curiosity in the hacker community. Last year when Apple released its iPhone, hundreds of hackers tried to break the iPhone software in multiple ways. Some of them succeeded in customizing the iPhone in the way they wanted. They changed their mobile service provider and deployed their own applications. Some hackers were able to break the iPhone by exploiting vulnerabilities in applications such as Safari.

Now Apple has released its official SDK to developers. By opening up the iPhone OS and publishing the SDK Apple looks forward to thousands of Mac developers developing iPhone applications. At the same time, Apple announced a lot of new features for enterprise customers.

It appears that Apple is carefully stepping forward to analyze and manage the security implications of opening up its platform for development. In the Leopard OS release Apple added security features such as sandboxing, code signing, etc. The same features are also used as the foundation for iPhone.

Let’s look at some of the security aspects of the iPhone’s application execution environment: Apple issues a certificate to the developer, who signs the iPhone application using this certificate. The iPhone OS then checks the authenticity and integrity of the application before installing and executing it. Each application runs in a sandboxed environment–with very limited access to the file system and other resources. The AppStore application on iPhone manages all third-party application deployments on the iPhone.

One application can interact with other applications using URLs. http://, https://, and feed:// are handled by Safari; mailto:// is handled by the Mail client; and itms:// is handled by iTunes. Third-party applications can declare their own urls (such as myapp://) to handle messages from other apps.

Each application is sandboxed to contain failures if it is compromised. However, an application’s access to a lot of other resources–such as network, phone, camera, address book, mail, and urls–is not controlled. Hackers may now focus on vulnerabilities in applications and also on the mechanisms provided to access iPhone resources.

Enterprise features such as Exchange Server support, and security features such as Cisco IPSec VPN, WPA2/802.1, etc. may encourage wider deployment of the iPhone in enterprises; and thus open up more possibilities for attackers.

Within four days of Apple’s announcement, more than 100,000 SDK downloads indicate the enthusiasm of developers. Sun has announced Java support for the iPhone, and that may attract even more developers.

For now the SDK is still in beta, which gives Apple some time to fix security issues that hackers are going to discover during the next few months. This seems to be a very good strategy. We look forward to Apple’s next steps and the impact they will make on the domain of mobile device security.

Unlocking your iPhone so that you can install third party applications can be fun. Using the Installer.app application on the iPhone and its default repository you can install utilities, games, and other applications. By adding additional repositories to the Installer, it is possible to gain access to a much greater quantity of software.

Occasionally, if you’re not careful you can end up installing malicious software from a bad repository. This happened to a number of iPhone owners a few days ago.

An application calling itself “iPhone firmware 1.1.3 prep” claims to be a tool to prepare your iPhone for the upcoming iPhone update. It actually installs another separate legitimate utility. The damage occurs if you already had the utility installed and you want to remove the false firmware update “prep” tool. Uninstalling the fake tool just uninstalls the real utilities.

Information from the STE Packaging repository site and its owner details how the “prep” tool functions and how it was distributed. Users who added the jmwiki.com repository site to Installer.app were offered the “prep” tool and two other similar packages. It was determined that the malicious repository and applications were created by an 11 year old. The child’s parents were informed and the repository was taken down.

Phone modification (changing the OS, reflashing, unlocking, etc.) can sometimes be dangerous. While corrupting a firmware upgrade for a mobile device might be possible, it is not surprising that someone has created much simpler malicious installation files. On the Symbian platform we have seen quite a few malware, such as SymbOS/Skulls and SymbOS/Appdisabler, that disable or overwrite legitimate applications upon installation.

Users can avoid such problems by:

• Acquiring software only from trusted sources
• Installing only official firmware updates