Vulnerabilities in Government mobile apps

As part of my Ph.D. research, I analysed several mobile apps last year to identify vulnerabilities that could potentially be exploited to exfiltrate sensitive data and personally identifiable information (PII) stored on mobile devices. One of these apps is Medicare Express Plus (MEP) app released by the Department of Human Services of the Australian Government. 

 

The findings of this investigation were accepted for publication and presented at the 48th Annual Hawaii International Conference on System Sciences (HICSS 2015).

C. D'Orazio and K-K. R. Choo (2015), “A generic process to identify vulnerabilities and design weaknesses in iOS healthcare apps”, Proceedings of 48th Annual Hawaii International Conference on System Sciences (HICSS 2015), 5-8 January 2015, pp. 5175-5184, DOI: http://dx.doi.org/10.1109/HICSS.2015.611.

Using the proposed iOS App Analysis Process (iOSAAP – see Figure 1), the app was studied and previously unknown / unpublished vulnerabilities were identified, which would expose a user’s sensitive data and PII such as claim history and electronic health transactions stored on the iOS device. The vulnerabilities were reported to the Australian Government Department of Human Services on 13 May 2014. The reported vulnerabilities were fixed in version 1.0.9 of the app released on 22 May 2014. In this blog entry, it will not be discussed if the vulnerabilities were addressed appropriately, but it is worth mentioning that the new release still remained vulnerable to certain sorts of attacks which, on some devices, would allow a malicious party to exfiltrate data more rapidly.

The app allows users to use their iOS and Android devices to view their medical history, access health-related documents saved in the vault (e.g. medical transactions and lodged claims), update their personal information (e.g. residential address, telephone numbers and e-mail, contact numbers, e-mail and bank account information), find the nearest service centres, etc. In order to access their accounts, users must first register with the agency to receive their username. The username is an 8-character field, in the following format: Two capital letters followed by six digits (e.g. ‘ZZ999999’). Users will then choose their password, a 4-digit PIN number and three (pre-defined or user-generated) security questions. The 4-digit PIN number is designed to replace the need for user to enter his/her username and password when using the app on the mobile device.

The iOSAAP comprises four main stages, namely

1. Analysis environment set-up (Device, PC, analysis tool configuration);
2. App decryption (Removal of the Apple FairPlay DRM technology);
3. App disassembly (Static analysis using Hopper Disassembler);
4. App debugging (Dynamic analysis using a debugger). 

Figure 1

The aim of this post is not to describe the iOSAAP thoroughly but to alert about vulnerabilities that lead to data breaches. For an exhaustive examination of how to perform the app analysis please refer to the paper.

After completing all the stages of the iOSAAP, it was possible to identify the relevant classes, methods and API calls implemented within the app for the protection and encryption of the documents saved in the vault. For example, by using search patterns such as “PIN”, “key” and “AES” I obtained the following list of relevant methods.

1. PinLockController_saveKeychainEntries
2. KeychainItemWrapper_securedSHA256DigestHashforPIN 
3. Encryption_AESdecryptData_usingPassword
4. Encryption_AESKeyForPassword_salt

The inspection of these methods exposed an important number of hash and cryptographic functions as well as a hard-coded SALT value denoted as ‘FvTivqTqZXsgLLx1v3P8TGRyVHaSOB1pvfm02wvGadj7RLHV8GrfxaZ84oGA8RsKdNRpxdAojXYg9iAj’. I was surprised that when I did a search for this string on the Internet, I discovered that the code using the SALT value shows significant similarities to the Objective C code on http://www.raywenderlich.com/6475/basic-security-in-ios-5-tutorial-part-1. This suggests that the code of the app might have been lifted from the Internet and reused without significant changes.

At the end of the iOSAAP process, I was able to determine the complete algorithm that generates an AES key derived from the username which is used to encrypt/decrypt documents as illustrated in Figure 2.

Figure 2

Due to the lack of entropy to calculate the AES key that encrypts the documents in the vault, an offline brute-force attack can be executed. Although the total number of key combinations for AES-128 is 3.40 x 10³⁸, deriving the AES encryption key from the username (an 8-character field: two capital letters followed by six digits) reduces this combination to only 676,000,000 (all possible valid usernames from ‘AA000000’ to ‘ZZ999999’).

As a proof of concept, I developed an application capable of generating 7 million combinations (in the format: two capital letters followed by six digits) in 24 hours using four instances of the application running simultaneously on an Intel Core i5-4570 CPU (3.20 GHz) PC – see Figure 3 for the screen capture.

Figure 3

The offline brute force attack can also be executed in parallel using cloud computing or more computers. For example, I could determine the username and AES key (total of 676,000,000 combinations) in less than ten days using 10 computers running Intel Core i5-4570 CPU (3.20 GHz).

In addition, the app does not perform public key pinning to secure data in transit, as a consequence, HTTPS communications between an iOS device and the Healthcare server can be decrypted by a malicious party performing a man-in-the-middle (MiTM) attack. More specifically, the app does not validate certificates to ensure that connections are established with the right remote server.

The outcome of the analysis revealed an alarming number of serious vulnerabilities in just one Government app:

1. Broken cryptography;
2. Insufficient transport layer protection;
3. Lack of binary protection;
4. Insecure data storage;
5. Reuse of code from the Internet;
6. Hard-coded SALT value.

In addition, I would like to propose recommendations to respectively and individually address these vulnerabilities with the hope that similar structural mistakes can be avoided in future app design. 

Recommendation 1: To further complicate brute-force attacks, the AES key in the MEP app should be derived from a username containing not only digits but also a combination of lower- and upper-case characters. Additionally, the AES initialisation vector (IV) (a starting variable that adds pseudo-randomisation) currently defined as null (an existing weakness) should be initialised. 

Recommendation 2: The lack of public-key pinning can easily be exploited to turn encrypted HTTPS connections into plaint-text HTTP connections. The authenticity of a remote server must be validated at several stages for ALL HTTPS connections. 

Recommendation 3: The lack of binary protection is a common vulnerability in the majority of mobile apps. Developers should consider to implement hardened checksums to verify that an attacker has not been tampering with the binary code. On the contrary, other security checks such as jailbreak detection can effortlessly be bypassed. 

Recommendation 4: As a result of the findings, it is recommended that stored documents (in all iOS apps) should belong to the NSFileProtectionComplete Data Protection Class (also known as Class A), which offers a secure passcode-derived encryption. This would prevent the files to be directly acquired from a device that is locked. 

Recommendation 5: There are obvious risks in reusing the source code available on the Internet in any apps, as an attacker can exploit known vulnerabilities to facilitate their access to the data. All code lifted from the Internet must be modified and tested thoroughly to make sure that there are no traces. However, the safest approach is not to reuse code publicly available on the Internet. 

Recommendation 6: There are as well obvious risks in embedding values in any apps, as a reverse engineer can search for all hard-coded strings to select and explore those representing tale-telling values generally used in cryptographic methods. It is recommended to generate salt values dynamically and to embed fake values that would never be used in order to divert attention.

In conclusion, the study revealed that mobile app security is still an understudied area. Despite having sufficient funds to invest in the design of strengthened solutions, Government organisations fail to assemble security and development teams. Based on my own experience working for companies and security agencies, I remark that vulnerable apps are not only the result of NOT introducing security appropriately into the SDLC, but also the consequences of delegating security solutions to regular developers who have never been trained to understand, design, and implement security in order to safeguard sensitive data. Unfortunately, a great deal of development teams believe that software security can be simplified to the encryption of confidential information. Sad bad true!

CJ