[Full-disclosure] Vulnerability found in SplashID 5.5

["Chase,Philip B" <pbc@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx * 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@xxxxxxxxxxxxx:/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@xxxxxxxxxxxxx'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/