The View From The Top Isn't Much Better
Hello again. This is part 2 of the research related to iOS application security. Sit back, relax and refill that popcorn.
The scope of this blog post is related to mobile application security only and does not refer to the platform's security - all data is anonymised.
Approach
A snapshot list was taken of the "Top 50 Free iPad" applications in Apple's App Store. Each of these applications was then downloaded and passively assessed. We analysed the application binary, how the application communicated with third party servers and how it was storing data. At no time did we did carry out any active testing – no outgoing requests were manipulated for example.
The iPad "apps" occupying the top 50 free list were a mix of applications and games. It is important to note that this list was for free applications, so the results may differ if the same approach was used on paid apps. Developers will often release their game or application with a small number of features (and lots of advertisements) for free in order to attract interest for the fully featured paid application. The split between applications and games that we analysed was roughly half.
Privacy
Each Apple device has a unique identifier, often referred to as a UDID. The uniqueness of this value allows it to be used to link users to devices. The user can then be tracked, profiled and advertisements can be delivered to them based on this data. It is generally frowned upon for developers to use the UDID as an identifier as it could be considered an invasion of privacy depending on what it was used for. UDIDs cannot be changed or deleted as they're tied to mobile devices.
An application that records geo-location data could send this back to a server along with the UDID and have a record of where that device (the person) has been. Apple itself has informed developers not to use the UDID as an identifier and has stated that it intends to deprecate them in future iOS versions.
Our research showed that many of the apps in the top 50 free lists used the UDID as an identifier. In fact just under half (44%) of them analysed communicated this value to a third party server. Interestingly, digging into the data a little more reveals that game-type apps were the worst offenders. 77% of games were found to send the UDID when compared to 27% of application-type apps that did this.
The HTTP request below is an example of how the UDID (UDIDXXX) is sent to a third party's server.
GET /X/X/UDIDXXX/?model=iPad_1G&sysVer=5.1&bundleVer=1.0&bundleID=com.X.X HTTP/1.1
Host: XXX
User-Agent: XXX Darwin/11.0.0
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
Proxy-Connection: keep-alive
Transport Security
The growth of wireless networks over recent years is staggering. Franchise locations such as food & beverage outlets and hotels provide open wireless access to the Internet in order to attract and retain customers. Nicholas J. Percoco, SVP and head of Trustwave SpiderLabs was recently quoted on why and how this is also attracting criminality.
An open wireless network (such as a hotspot) is a shared medium and anyone on that frequency is able to read the data sent across it if it's not encrypted. It is therefore important for mobile applications that encryption is implemented to protect the data that is sent/received. Often the user will not know if their data is being transmitted without encryption as no padlock UI that they have come to look for is shown like in a web browser.
Our research demonstrated that even the top apps fail to use transport layer encryption properly. 80% of the apps tested were collectively found to use no transport encryption or at best used it interchangeably.
Binary Analysis
An attacker can often learn a wealth of information by carrying out passive actions. In the real world for example, a burglar may carry out a reconnaissance exercise walking down a street to identify possible points of entry/weaknesses before any action is taken. This costs the attacker nothing except time. Cyber attackers approach targets in the same way. An attacker will often trawl the Internet to discover information about the organisation or person they wish to target, which may be useful in further social engineering exercises or attacks. Analysis of an iOS binary can often reveal information about the developer and their environment. A simple strings dump of the application binary, following a quick search through can prove fruitful.
64% the apps assessed were found to reveal information relating to either personally identifiable information of the developer or the environment/frameworks used. In one instance we found a key being used to communicate with a server API in the binary simply by searching for the string "secret".
The two examples below disclose the developer's name (our made up MrTW in this case) and information about the environment in which the application was developed.
/Users/MrTW/Documents/Builds/X/Classes/AppX.mm
/Users/MrTW/Documents/workspace/X/X/SDK/private classes/X/MrTW.m
Shared Hardcoded Credentials
A small number of the applications (precisely four) were found to use shared credentials that were hardcoded into the application. In three of these instances Basic Authentication was found to be protecting the service that sits on the web server that the client communicates with. A 401 (Access Denied) status code is presented in the WWW-Authenticate response initially. The client (an app in this case) then supplies an Authorization request with the hardcoded base64 encoded username and password. The client is then granted access to the API. The HTTP request (anonymised) below shows the mobile application providing base64 encoded credentials (xXXx==) as part of an Authorization request. We were able to learn these credentials simply by base64 decoding them.
POST /api/xxx/ HTTP/1.1
Host: xxx
User-Agent: XXX 1.0.0 (iPad; iPhone OS 5.1; XXX; en_GB)
Content-Length: 94
Content-Type: application/json
Accept-Encoding: gzip
Authorization: Basic xXXx==
Connection: close
Proxy-Connection: close
{"device_tokens":{"add":["UDIDXXX"]}}
Data Storage / Cached Information
The likelihood of losing a tablet/smartphone or even having one stolen is high when compared to gigantic desktop computers. Users rely upon the device's platform security to protect their data in these instances. However, often users will not enable PIN codes or when they do will pick trivial ones. An attacker is then able to access the underlying operating system and query files/databases to retrieve cached information. In relation to iOS this would involve an attacker jail-breaking the device.
Developers have a multitude of ways to dictate how and when their data is accessible when securely storing items in Apple's Keychain. However, once the device becomes jail-broken then even this information is up for grabs. Developers should therefore think of security as layers, defense-in-depth and all that – it does work. There is nothing wrong with encrypting data before placing it in the Keychain. Call it an insurance policy.
Developers will sometimes decide to boycott using the Keychain altogether. They instead opt to cache sensitive data inside temporary files, sqlite databases, .plist files, etc. sitting in the application's directory. Examples of these are shown below.
/var/mobile/Applications/XXX-XXX-XXX-XXX/Documents root# ls
secrets.pdf payroll.pdf
/var/mobile/Applications/XXX-XXX-XXX-XXX/Library/Caches root# ls
Snapshots com.apple.xxx.configuration.plist com.xxx.xxx.databases com.xxx.xxx.profile-images.2 com.xxx.crashxxx.data http_xxx.xxx.com_0.localstorage https_xxx.com_0.localstorage
XXXCrashxxx com.xxx.xxx com.xxx.xxx.profile-images com.xxx.xxx.streams.2
http_xxx.com_0.localstorage
Other apps prefer to record all actions to a log file.
/var/mobile/Applications/XXX-XXX-XXX-XXX/tmp root# cat xxx.log
14:34:22.177 I [xxx.cpp:1337] Request for file xxx1 complete (code: 0)
14:34:22.847 I [xxx.cpp:1337] Request for file xxx2 complete (code: 0)
14:34:22.848 I [xxx.cpp:1337] Time for file sync: 9782 ms file_size: 4 MB avg speed: 453 KB/s
14:34:22.849 I [xxx.cpp:1337] Downloaded xxx1 of 2712000 bytes in 216898 seconds (0.0122105 kB/s)
Our research found that 20% of the apps analysed cached information happily in the application's directory. Things we found were usernames, chat logs, copies of previously opened files, more chat logs, search history logs and more chat logs. Did I mention that we found lots of chat logs? We even caught an app sending crash dumps (without our permission) back to a server on the Internet. The crash dump contained a wealth of information about our device.
Conclusion
Many developers will offer free apps as a taster and will want something in return. This is usually in the form of information about you, which is shared with advertising companies. They will usually plaster you with adverts too. However, many paid apps are also guilty of this however it is hidden in the background. You know what they say - there's no such thing as a free lunch.
Our research has shown that many of the top 50 free apps (particularly games) generally don't bother with encryption. Therefore think twice before you use any apps on an open hotspot in a coffee shop, etc. We have also learned that a small percentage of these apps store information about us in an insecure manner (taking the platform's security out of the equation). Other apps like to make copies of files we open and store them on the device without our permission. Hardcoding passwords into an application has never been a good thing. Our research shows that very small minorities of mobile developers are releasing free apps which make it to the top 50 list still do this.
It is important to emphasise that our research is breadth and not depth in order to get a picture of the landscape. These examples discussed are low hanging fruit, which we could easily demonstrate in the time available. There is a very high likelihood that more issues will be found when quality time is spent looking in depth at one app, especially when actively fuzzing server interactions and hooking into the runtime.
This was just a flavour of why we're so interested in the mobile security space, and think you should be too. Incidentally, Paul Kehrer of Trustwave discovered an issue with Apple's iOS SSL implementation last year that may interest you. No doubt we'll release other items of interest by sharing them with you on this blog. If you are developing an iOS application and are concerned about security then get in touch and we'll be happy to discuss further.
Until next time...
