Full Disclosure: Vulnerability found in SplashID 5.5

["Chase,Philip B" <pbc () PHHP UFL EDU>]

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 () phhp 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 () 192 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 () 192 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/