Recently, WeipTech was analyzing suspicious Apple iOS tweaks reported by users and found over 225,000 valid Apple accounts with passwords stored on a server.
In cooperation with WeipTech, we have identified 92 samples of a new iOS malware family in the wild. We have analyzed the samples to determine the author’s ultimate goal and have named this malware “KeyRaider”. We believe this to be the largest known Apple account theft caused by malware.
KeyRaider targets jailbroken iOS devices and is distributed through third-party Cydia repositories in China. In total, it appears this threat may have impacted users from 18 countries including China, France, Russia, Japan, United Kingdom, United States, Canada, Germany, Australia, Israel, Italy, Spain, Singapore, and South Korea.
The malware hooks system processes through MobileSubstrate, and steals Apple account usernames, passwords and device GUID by intercepting iTunes traffic on the device. KeyRaider steals Apple push notification service certificates and private keys, steals and shares App Store purchasing information, and disables local and remote unlocking functionalities on iPhones and iPads.
KeyRaider has successfully stolen over 225,000 valid Apple accounts and thousands of certificates, private keys, and purchasing receipts. The malware uploads stolen data to its command and control (C2) server, which itself contains vulnerabilities that expose user information.
The purpose of this attack was to make it possible for users of two iOS jailbreak tweaks to download applications from the official App Store and make in-app purchases without actually paying. Jailbreak tweaks are software packages that allow users to perform actions that aren’t typically possible on iOS.
These two tweaks will hijack app purchase requests, download stolen accounts or purchase receipts from the C2 server, then emulate the iTunes protocol to log in to Apple’s server and purchase apps or other items requested by users. The tweaks have been downloaded over 20,000 times, which suggests around 20,000 users are abusing the 225,000 stolen credentials.
Some victims have reported that their stolen Apple accounts show abnormal app purchasing history and others state that their phones have been held for ransom.
Palo Alto Networks and WeipTech have provided services to detect the KeyRaider malware and identify stolen credentials. In the remainder of this blog, we provide details about the malware and the attacks.
The attack was first discovered by i_82, a student from Yangzhou University and member of WeipTech. WeipTech (Weiphone Tech Team) is an amateur technical group consisting of users from Weiphone – one of the largest Apple fans websites in China. Previously, WeipTech cooperated with us to report on other iOS and OS X malware including AppBuyer and WireLurker.
Beginning in July 2015, WeipTech members began investigating reports that some users’ Apple accounts were used to make unauthorized purchases and to install iOS apps. By looking at jailbreak tweaks these users had installed, they found one tweak that collected user information and uploaded it to an unexpected website. They then found this website has a trivial SQL injection vulnerability that allows access to all of the records in the “top100” database (Figure 1).
Figure 1. WeipTech found SQL injection vulnerability in the C2 server (from WeipTech)
In this database, WeipTech found a table named “aid” that contains 225,941 total entries. Approximately 20 thousands entries include usernames, passwords and GUIDs in plaintext, while the rest of the entries are encrypted.
By reverse-engineering the jailbreak tweak, WeipTech found a piece of code that uses AES encryption with fixed key of “mischa07”. The encrypted usernames and passwords can be successfully decrypted using this static key. They then confirmed that the listed usernames were all Apple accounts and validated some of the credentials. The WeipTech researchers dumped around half of all entries in the database before a website administrator discovered them and shut down the service.
On August 25, WeipTech posted about the leak on their Weibo account, submitted a vulnerability report to Wooyun (a leading vulnerability crowdsourcing website in China) and forwarded the information to CNCERT/CC.
When Palo Alto Networks researchers analyzed the tweak WeipTech mentioned in their report, we found that it did not contain malicious code to steal passwords and upload them to the C2 server. However, through other information WeipTech provided to us, we determined that there was other malware in the wild that was collecting the stolen credentials and uploading them to the same server.
We named this new iOS malware family “KeyRaider” because it raids victims’ passwords, private keys and certificates. (Just like “Lurker” and “Reaper”, Raider is also a unit in Blizzard’s real-time strategy games.)
KeyRaider, as far as we know, only spreads through Weiphone’s Cydia repositories for jailbroken iOS devices. Unlike other Cydia sources such as BigBoss or ModMyi, Weiphone provides private repository functionality for each registered user so that they can directly upload their own apps and tweaks and share them with each other.
One Weiphone user, named “mischa07”, uploaded at least 15 KeyRaider samples to his personal repository so far in 2015 (Figure 2). Since his user name was also hard-coded into the malware as the encryption and decryption key (Figure 3), we strongly suspect mischa07 is KeyRaider’s original author.
Figure 2. mischa07’s personal Cydia repository
Figure 3. “mischa07” was hardcoded in the malware as encryption key
According to Weiphone’s web page, some of the tweaks mischa07 uploaded have been downloaded tens of thousands of times (Figure 4). These apps and tweaks provide functionalities such as game cheating, system tuning and app advertisement stripping.
Note that there are two especially interesting tweaks in mischa07’s repository:
- iappstore (Figure 5): Provides service to download non-free apps from Apple’s official App Store without purchase.
- iappinbuy: Provides service to get some official App Store apps’ In-App-Purchasing items totally free.
Mischa07 even posted in Weiphone forum to promote these two tweaks but some users didn’t believe their supposedly magic functionalities. However, from Weiphone’s website, the iappinbuy still received 20,199 downloads (Figure 4), while iappstore got 62 (only counting the newest version).
Figure 4. One malicious sample was downloaded over 30,000 times
Figure 5. The iappstore tweak can directly install non-free apps from App Store
Figure 6. Author promotes his iappstore tweak
Another Weiphone user that distributed the KeyRaider malware is “氵刀八木” or “bamu”. Bamu’s personal repository is pretty popular in the community since he frequently provides useful tools. After the attack was exposed, bamu deleted almost all of malware he uploaded from the repository and denied it on the forum. However, with help from Weiphone, we checked all apps or tweaks he has ever uploaded and found at least 77 of them will install the KeyRaider malware on victims’ iOS devices. While mischa07 appears to have created the malware and developed different versions of it, bamu’s malicious apps are mostly created by repackaging existing apps or tweaks such as iFile, iCleanPro and avfun with the malware.
When KeyRaider uploads hijacked user password to its C2 server, it includes a parameter named “flag” or “from” in the HTTP URL to track the source of the infection. In mischa07’s code, the value of these parameters is always the app’s name such as “letv.” While in bamu’s samples, the value will always be “bamu”. From leaked data, we found that over 67% of stolen accounts came from bamu.
Since bamu is only a distributor, our latter behavior analysis will mainly focus on samples directly distributed by mischa07.
Stolen User Data
KeyRaider collects three kinds of user data and uploads to its C2 server by HTTP; we identified two different C2 servers.
During the course of our analysis, these domain names resolved to the IP address 188.8.131.52. In the “top100” database in this server there are three tables: “aid”, “cert” and “other”. KeyRaider use four PHP scripts on the server to access the database: aid.php, cert.php, other.php and data.php.
By analyzing the code and data dumped by WeipTech, we found that the “aid” table stored 225,941 stolen Apple ID’s user name, password and device GUID combinations. The “cert” table stored 5,841 entries of infected devices’ certificate and private key that are used by Apple’s push notification service (Figure 7). Finally, the “other” table stored over 3,000 entries of device’s GUID and app purchasing receipts from App Store server.
Figure 7. One entry in the leaked cert table
We sorted the email addresses from the stolen Apple IDs and found more than half of them used email service provided by Tencent. Below are top 10 most popular stolen account Email address domains. (Six of them are primarily in use by Chinese users):
However, we also found some email addresses belong to other countries’ or regions’ domain names, including:
- tw: Taiwan
- fr: France
- ru: Russia
- jp: Japan
- uk: United Kingdom
- ca: Canada
- de: Germany
- au: Australia
- us: United States
- cz: Czech Republic
- il: Israel
- it: Italy
- nl: Netherlands
- es: Spain
- vn: Vietnam
- pl: Poland
- sg: Singapore
- kr: South Korea
The KeyRaider malicious code exists in Mach-O dynamic libraries that are used as plugins for the MobileSubstrate framework. Through MobileSubstrate APIs, the malware can hook arbitrary APIs in system processes or in other iOS apps.
Many previous iOS malware families also abused the MobileSubstrate. For example, the Unflod (aka SSLCreds or Unflod Baby Panda) that was found by Reddit users and was analyzed by SektionEins used it to intercept SSL encrypted traffic and steal Apple account passwords. The AppBuyer malware discovered last year used the same technique to steal passwords and to purchase apps from App Store. KeyRaider takes this technique another step further. It implemented the following malicious behaviors:
- Stealing Apple account (user name and password) and device GUID
- Stealing certificates and private keys used by Apple Push Notification Service
- Preventing the infected device being unlocked by passcode or by iCloud service
Stealing Apple Account Data
Most KeyRaider samples hook SSLRead and SSLWrite functions in the itunesstored process (Figure 8). itunesstored is the system daemon that is responsible for communicating with the App Store using the iTunes protocol.
Figure 8. KeyRaider hooks SSLRead and SSLWrite in itunesstored
When the App Store client asks the user to input their Apple account for login, the information is sent to the App Store server via an SSL encrypted session. In the replacement function of SSLWrite, KeyRaider looks for this kind of login session, and searches for specific patterns to find the Apple account’s username, password and device’s GUID in the data being transferred (Figure 9). Next, in the replacement function for SSLRead, these credentials are encrypted using the AES algorithm with the static key “mischa07”, and then sent to the KeyRaider C2 server (Figure 10).
Figure 9. Searching for Apple account information in SSL data
Figure 10. Uploading stolen credentials to the C2 server
In addition to hooking SSLRead and SSLWrite, KeyRaider also invokes MGCopyAnswer(“UniqueDeviceID”) to read the device GUID.
Stealing Certificates and Private Keys
In some samples, KeyRaider also hooks the apsd process — the daemon process responsible for Apple Push Notification Service on iOS systems. It hooks the SecItemCopyMatching function defined in the Security framework. This API is used to search keychain items that match given search query.
After installing the hook, when the search query has a label value of “APSClientIdentity”, KeyRaider will execute the original SecItemCopyMatching, then invoke SecIdentityCopyCertificate and SecIdentityCopyPrivateKey to copy the certificate and private key from the original function’s return result (Figure 11). Together with GUID, these credentials are then sent to the C2 server (Figure 12). In the iOS keychain, the key that labeled with APSClientIdentity is used for the push notification. Through these credentials, an attacker can create a fake push notification to the system.
Figure 11. Copy push service’s certificate and private key
Figure 12. Upload certificate and key
When KeyRaider hooks the SecItemCopyMatching, except for intercept notification credentials, it will also compare current query’s label with a very special string “com.apple.lockdown.identity.activation”. If the label is this string, KeyRaider will set this query’s result to zero. (Figure 13)
Figure 13. Set lockdown activation result always to zero
At the time of this publication, there isn’t any public documentation of the com.apple.lockdown.identity.activation query on the Internet. We believe that this query is used to unlock devices. By setting this query’s result to zero, KeyRaider may prevent users from unlocking their own devices either by locally inputting correct unlock passcode or by remotely unlocking the devices via iCloud.
Note that in all samples we’ve found thus far, this piece of code is standalone and not invoked by any other code; it has only been implemented there and exported as a function. However, we have evidence that real attacks using this functionality have occurred.
Free Apps For Everyone!
Some samples of KeyRaider implemented code to download purchase receipts and Apple accounts from the C2 server. However, only in the iappstore and iappinbuy jailbreak tweaks were these actually used.
According to an author’s description, iappstore can be used to download any app from App Store totally free. Let’s take a look at how they make that possible.
The app hooks the SSLWrite API twice. The first hook is used for password stealing just like others. The second hook tries to determine whether current HTTP request is equal to “POST /WebObjects/MZBuy.woa/wa/buyProduct”. This is used to determine if the session is making a purchase using the iTunes protocol (Figure 14).
Figure 14. Hooking app purchase session
If the request is making the purchase, the next time SSLWrite is invoked, the hooking code will try to match keywords such as “salableAdamId”, “appExtVrsId”, “vid”, “price”, “guid”, “installedSoftwareRating” and “pricingParameters” in the data being sent to get payment information about current app. If the app is not free, a function named fire() is then invoked.
The fire function then invokes the readAid() function. readAid() reads a local file located at /var/mobile/Documents/iappstore_aid.log. This file contains an Apple account’s username, password, device GUID, related iTunes session’s token, cookie, phone number and carrier, operating system information and iTunes CDN server number. The function then parses this data and creates an Account object.
If the file doesn’t exist, it will invoke readAidUrl() function which will download new account information from KeyRaider’s C2 server and create an Account object (Figure 15). Figure 16 shows an account downloaded from the server.
Figure 15. Downloads Apple account from C2 server
Figure 16. Stolen Apple account was downloaded from C2 server
After creating the Account object, fire() will generate a plist format string that contains the account information, and invoke login(), then invoke sendBuy().
The login() function will construct an HTTP connection to the follwing URL with the plist string and a AppStore client like user agent value.
This causes the current iTunes session to be logged in with the remote Apple account. (Figure 17)
Figure 17. Emulating login protocol
After the login request, login() will parse the returned result for the cookie, token and other information and will save this data together with an account password to the local iappstore_aid.log file, to be used for the next purchase. If the login failed due to a password error, it will invoke readAidUrl() again to get a different Apple account from the C2 server.
The sendBuy() function works similarly to the login() function but requests another URL for app purchasing verification:
Through this procedure, the iappstore tweak can successfully purchase any app using another person’s stolen Apple account.
Note that, besides of these operations, in two standalone functions verifySF() and verifySF2() implementation in this sample, KeyRaider also tries to get or use information about Apple account’s password recovery questions and answers. This functionality hasn’t been finished in the samples we analyzed.
The functionality of iappinpay is similar to iappstore. The only difference is that the purchase interface has changed as well as some of the parameters used (Figure 18). Since the C2 server database also stored some previous In-App-Purchase receipts, it seems that author also planned to implement functionality to reuse these receipts, possibly to send them to Apple to prove that that they have previously purchased an item.
Figure 18. In-App-Purchase verification request
Phones Held for Ransom
In addition to stealing Apple accounts to buy apps, KeyRaider also has built-in functionality to hold iOS devices for ransom.
Some previous iPhone ransomware attacks are based on remotely controlling the iOS device through the iCloud service. Some of these attacks can be avoided by resetting the account password to regain control of iCloud. KeyRaider is different. It can locally disable any kind of unlocking operations, whether the correct passcode or password has been entered. Also, it can send a notification message demanding a ransom directly using the stolen certificate and private key, without going through Apple’s push server. Because of this functionality, some of previously used “rescue” methods are no longer effective.
We know that KeyRaider has been used to hold a phone for ransom, as one victim reported that his phone was locked while prompted message in screen is “Please contact by QQ or phone to unlock it.” (Figure 19)
Figure 19. Ransom message on locked iPhone
Other Potential Risks
At Palo Alto Networks Ignite 2015 conference back in April we introduced the underground economy and supply chain involved with iOS hacking. KeyRaider plays a very important role in this chain.
With a victim’s Apple account and password, attackers can launch all kinds of additional attacks. For example, they can control the device through iCloud and compromise the victim’s private data contained in their iMessage logs, contacts, photos, emails, documents and location. In 2014, for example, many celebrities’ iCloud accounts were hacked and photos leaked, which raised awareness of the threat from stolen Apple account credentials.
Additionally, there are many other ways to profit from these stolen accounts.
Some developers will pay money for their apps to occupy a better position in App Store rankings, and installation count is one of the most important factors in creating these rankings. Using the stolen data, attackers can easily install “promoted” iOS apps from App Store to increase their installation count. In fact, many of KeyRaider’s victims reported that their Apple accounts had an abnormal app downloading history, which led to the discovery of this attack.
Attackers can purchase non-free iOS apps from App Store using stolen accounts. The fee will be paid by victims, but money will go to Apple and then partly to developers. Then developers share this income with attackers, as was the case with the AppBuyer malware.
Valid Apple account usernames can also be sold standalone for use by spammers. Previous SMS based spam may cost money to send and is easily to be blocked by carriers. However, iMessage-based spam only needs Internet access and the recipient’s Apple ID. This kind of spam has become very popular in the last two years.
Holding the victims’ Apple accounts, their devices or the information contained in their iCloud storage for ransom can also generate revenue for the attacker.
These stolen accounts can also be sold in another market. Apple adopted a security mechanism to prevent lost or stolen devices being wiped and re-sold that requires you to verify the Apple ID before wiping. Hence there is now a market for individuals looking for certain devices’ Apple account information.
Other Future Attacks
Combined with personal data in iCloud, stolen accounts can also be used in social engineering, fraud and targeted attacks.
Protection and Prevention
It’s important to remember that KeyRaider only impacts jailbroken iOS devices. Users of non-jailbroken iPhones or iPads will not be affected by this attack.
WeipTech has provided a query service in their website http://www.weiptech.org/ for potential victims to query whether their Apple accounts was stolen. Palo Alto Networks provided the stolen account information to Apple in August 26.. Worth noting is that WeipTech was only able to recover around half of stolen accounts before the attacker fixed the vulnerability. Users who have ever installed apps or tweaks from untrusted Cydia sources could also be affected.
Palo Alto Networks has released DNS signatures to cover KeyRaider’s C2 traffic to prevent the malware from relaying credentials in protected networks.
Users can use the following method to determine by themselves whether their iOS devices was infected:
- Install openssh server through Cydia
- Connect to the device through SSH
- Go to /Library/MobileSubstrate/DynamicLibraries/, and grep for these strings to all files under this directory:
If any dylib file contains any one of these strings, we urge users to delete it and delete the plist file with the same filename, then reboot the device.
We also suggest all affected users change their Apple account password after removing the malware, and enable two-factor verifications for Apple IDs.
Our primary suggestion for those who want to prevent KeyRaider and similar malware is to never jailbreak your iPhone or iPad if you can avoid it. At this point in time, there aren’t any Cydia repositories that perform strict security checks on apps or tweaks uploaded to them. Use all Cydia repositories at your own risk.
SHA-1 values of some KeyRaider samples are listed here:
Special thanks to i_82 from Yangzhou University and WeipTech for sharing data, report and all kinds of useful information with us.
Thanks CDSQ from WeipTech and thanks Weiphone for providing potential samples to us. Thanks Xsser and Fenggou from Wooyun in information sharing.
Thanks Sereyvathana Ty, Zhaoyan Xu and Rongbo Shao from Palo Alto Networks for their effort on detecting the threat. Thanks Ryan Olson from Palo Alto Networks for reviewing and revising this report.