Date: Fri, 21 Jan 2011 10:52:45 -0500
From: "Chase,Philip B" <pbc@...P.UFL.EDU>
To: "'full-disclosure@...ts.grok.org.uk'" <full-disclosure@...ts.grok.org.uk>
Subject: Vulnerability found in SplashID 5.5

I submitted this vulnerability report about the password database SplashID to cert.org in early November 2010.  CERT bounced it back saying they were too busy.  No big deal, so I sent it to the product's vendor, SplashData, on 11/5/2010.  I worked with SplashData for a few weeks to help them understand the problem.  We had some differences of opinion on what needed to be done to protect their customer's data.  After more than 2 months I have still not seen any updates to their product.  With all that in mind it seems time to go public with the vulnerability and my exploit of it.  

I'd like to thank Shawn Merdinger for his advice on this report.  David Cortes and Kevin Hanson provided invaluable assistance in testing.

Philip

Philip Chase * pbc@...p.ufl.edu * 352-273-6190
University of Florida, College of Public Health & Health Professions

----------------------------------------------------------------------

Vulnerability Description

SplashID is a multi-platform password manager from SplashData.  The vulnerability I found is in SplashID version 5.5 for iPhone and SplashID Lite 4.6 for iPhone.  

In normal operation SplashID is supposed to protect secret information using 256-bit Blowfish encryption (see http://www.splashdata.com/splashid/blowfish.htm).  Upon launch the user is presented with a password dialog.  Incorrect passwords do not allow access to the data.  If the correct password is entered a list of entries in the database is displayed and the secrets are accessible.  SplashID has an option to maintain a record of the valid password entry-if not the password itself-for a configurable amount of time after exiting the program.  As the iPhone OS does not fully support multitasking, this credentials-caching is a valuable usability feature.  It is also makes exploiting the vulnerability quite easy.

The vulnerability is a failure in the application's design to use the password as either an encryption key or a passphrase to decrypt the encryption key.  One can exploit this vulnerability to decrypt all of the secret information in a Splash ID database without the password.  

The exploit is a fairly trivial matter.  It requires a copy of the SplashID database with the secret information, file system access to a jail-broken iPhone and a copy of SplashID.  An ssh deamon on the iPhone expedites the exploit but is not strictly required.  To gain access to the secrets execute the following steps:

1. Copy the SplashID database of interest to the file system of a jail-broken phone with an installed and running OpenSSH deamon:

# scp SplashIDDataBase.db root@....168.1.102:/var/root/

2. ssh into the phone, index the file system, locate the active database, and erase or move your existing SplashIDDataBase.db file:

$ ssh  root@ 192.168.1.102 
root@....168.1.102's password: 
joes-iPhone:~ root# updatedb 
joes-iPhone:~ root# locate SplashIDDataBase.db 
/private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Library/SplashID/Backup/SplashIDDataBase.db 
/private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Library/SplashID/SplashIDDataBase.db 
/private/var/root/SplashIDDataBase.db 
joes-iPhone:~ root# mkdir backup
joes-iPhone:~ root# mv /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Library/SplashID/SplashIDDataBase.db backup/ 

3. On the iPhone Home screen, launch SplashID.  A copy of the sample database will be created for you. Still in SplashID, go to Tools, Set Password and set a simple password.  I used 'cat' in all of my tests.  Splash ID will tell you it is encrypting the database.  Still in Tools, go to Security Options and set Lock on Exit or Sleep to 10 minutes.  This is the only value I tested, but the precise value is probably irrelevant as long as it is not 'immediately'.

4. Return to the SplashID mainscreen and press Lock.  You will see the lock screen and a prompt to enter your password to unlock.

5. Unlock the sample database with your simple password.  Press the iPhone Home button to leave SplashID.  You now have 10 minutes to attack a SplashID database.

6. Return to your ssh session and copy the database you want to attack into the standard database location:

joes-iPhone:~ root# cp backup-20101102/SplashIDDataBase.db /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Library/SplashID/SplashIDDataBase.db

7. Launch SplashID from the iPhone home screen.  The database will open without a password entry and all secrets in the database will be accessible.

There are multiple  methods to acquire the SplashIDDatabase.db file with the desired secrets..  Exact copies of the SplashIDDatabase.db file exist within the iTunes backup.  If the attacker can gain access to the computer with the iTunes and that backup is not encrypted (the default), a full text search tool such as grep can locate the SplashID database file.  The name is obfuscated within the backup, but grep easily finds it with a search like "grep -i -R splash *" on the iTunes backup directory.  The md5sum of the iTunes backup files matches that of the corresponding file on the iPhone.

An iPhone with openssh installed presents an easy point of attack if the passwords for the root and mobile accounts have not been changed from their default of 'alpine'.  If these are not changed the attacker only needs the IP address of the iPhone and about 2 minutes when the phone is unlocked to locate and copy the file off for offline attack.  

Stealing the iPhone would give the attacker an opportunity to jailbreak the phone, install openssh, and transfer the file off  to another phone on which the attack can be performed.  While this attack is not very time consuming an attack on a phone that had already been jail-broken would be even faster.  Pass codes on iPhones can be defeated by attacking the phone with jailbreak tools or forensic analysis tools.  

Protection against this vulnerability would require a multi-faceted approach.  Encrypt of the iTunes backup or placing the iTunes backup on an encrypted disk partition removes one point of attack.  Using a passcode makes the attack on a stolen phone more difficult.  Setting of passwords for users root and mobile is a must to prevent a remote attack  Disabling the sshd when not in use is advisable.  That said, loss of the phone means the secrets stored in SplashID will be accessible to the determined attacker.

Vulnerable System Configurations

The systems tested were an iPhone 2G and an iPhone 3GS both running iOS 3.1.3.  Attacks on both phones were done using SplashID 5.5.  This is the current release as of 2-Nov-2010.  The source databases were made on SplashID 5.5 and SplashID Lite 4.6.  Each phone was able to access the secrets in the SplashID database from the other phone without using the corresponding password.  

The iTunes backup tests were against a backup made with iTunes 10.0.1.22 (current as of 2-Nov-2010) on a computer running Windows XP SP3.  

No other configurations were tested.  

Vulnerability Discovery

This vulnerability was discovered during a restore of a SplashID database to a freshly upgraded phone.  Having only an rsync backup of the phone I had to restore data by hand via scp.  I happened to execute the attack steps by accident as I made a temporary database, locked it, unlocked it, located it in the file system, replaced it with the copy from backups, and then accessed it.  This worked on a freshly installed OS that had never seen the password for the SplashIDDatabase.db file.  

Impact

A person who can gain access to the SplashIDDatabase.db file can reveal all secrets stored within it.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists