Palo Alto Networks recently found and analyzed a new iOS malware affecting jailbroken iOS devices in the wild. The malware will connect to C&C server, download and execute malicious executable files, hook network APIs to steal user’s Apple ID and password and upload to the attacker’s server, and simulate Apple’s proprietary protocols to buy apps from the official App Store by victim’s identity. We named this new family AppBuyer.
Background
The AppBuyer was first mentioned by four members of the WeiPhone Technical Group at May 18th, 2014. They remotely assisted a user to find out why some apps periodically had been installed onto his jailbroken iPhone, and finally located two strange files on that device. They found that these files would download, execute and delete other executable files from the Internet. Lastly, they tried to identify the attacker through analyzing the C&C server’s domain name through the samples used. They also provided these samples for downloading.
In the same day, being noticed by this group, we posted a quick introduction to this new threat in the mobile.malware Google group with a temporary name “Updatesrv”.
However, the WeiPhone Technical Group didn’t explain how the samples install other apps into infected devices. On the other side, the sample’s C&C servers are still alive currently, which may impact more users. The team did some deeper analysis on the samples to disclose its mechanisms and provide solutions and suggestions to defeat it.
Technical Analysis
We still don’t know how the AppBuyer malware was installed onto jailbroken iOS devices. There’re some possibilities that include through malicious Cydia Substrate tweak (like Trojan.iOS.AdThief) hosted in third-party Cydia sources, through other PC malware, through a PC jailbreaking utility, or possibly some other unknown ways.
After these devices were infected, the following files will be present in the file system:
- /System/Library/LaunchDaemons/com.archive.plist
- /bin/updatesrv
The com.archive.plist is a launchd daemon configuration file which specified that every 7,200 seconds (or 2 hours) the /bin/updatesrv will be loaded and run (Figure 1).
Figure 1. The updatesrv is configured as being launched every 2 hours
Main execution logic of the updatesrv is shown in Figure 2.
At first, it will connect to
to fetch configuration of local UUID file path: /etc/uuid. Then it reads the UUID from this file and constructs the second URL:
The updatesrv will then determine whether the server returns “IDLE”. If so, it will exit immediately; otherwise, it will download two files from the server, rename them as /tmp/u1 and /tmp/u2, then execute the first one, and lastly delete all of the files.
During the course of our analysis, we found that after updatesrv executes three times, the server will always return IDLE. Let’s look at each of those three executions.
Figure 2. Main execution logic of the updatesrv
First Execution: Generate UUID
During the first execution, the updatesrv will determine if /etc/uuid exists. If not then the second URL will have no UUID value:
updatesrv will then download two files named u1 and u2 using the following URLs:
The code in u1’s is quite simple, it generates a new UUID by combining the current time, a random number between 0 to 9999 and current process ID, and stores it into /etc/uuid. The u2 file simply contains the character “1”, but this is not used by the code.
Second Execution: Steal Apple ID and Password
After the UUID is generated, the second execution of updatesrv accesses the URL with the UUID value:
The server returns u1_80 and u2_80 as results, then download respective files from:
The code in u1_80 simply copies u2_80 into /Library/MobileSubstrate/DynamicLibraries/aid.dylib (Figure 3), thus the u2_80 will be loaded by the Cydia Substrate framework later.
Figure 3. Main logic of u1_80
The u2_80 is a Cydia Substrate tweak. After being loaded, it will hook the (void)connectionDidFinishLoading:(id)arg1; method of the ISURLOperation class (Figure 4). It uses this hook to capture every HTTP or HTTPS request made by the phone and inspect the traffic for three strings in the body (Figure 5):
- <key>appleId</key>
- <key>guid</key>
- <key>password</key>
The code uses a customized algorithm to encrypt these three strings in the binary, but we decrypted them during our analysis and they are shown in the following screenshots.
Figure 4. u2_80 hooks network API
Figure 5. u2_80 searches for specific strings in all HTTP/HTTPS requests' body
Every time the hooking code finds one of the strings, it will parse the adjacent <string> field, reading values of the appleId, guid and password in the session data. Through this way, u2_80 can steal a victim’s Apple ID, GUID and password.
Then, the hooking code will connect with another server 106.187.38.163, and send the stolen ID, GUID and password to it (Figure 6). The IP address, uploading URI and parameters are also encrypted in the code.
Figure 6. u2_80 uploads stolen ID and password to C&C server
Third Execution: Buy Apps with the Victim’s Identity
Now, in the third execution cycle the updatesrv will download two executable files from:
Figure 7. u1_88 drop a fake gzip binary file
The u1_88 simply copies u2_88 to /usr/bin/gzip (Figure 7). Gzip is a widely used utility in iOS system, however, its default path on iOS systems is /bin/gzip. This new one is clearly a fake gzip.
The u2_88 is the most interesting part of AppBuyer. Briefly, it will buy apps from official App Store using the stolen apple ID and password. Then these apps will be downloaded and installed by Apple’s synchronization mechanism.
To be more specific, the u2_88 emulates the essential App Store protocols for login and purchase (free and paid) of apps (Figure 8). We don’t yet know how the malware was delivered to the device. However, by reversing its code, we found it expects some specific arguments including:
- Account name of user’s Apple ID
- Password of user’s Apple ID
- ID of the specified app to buy
- A task ID for feedback statistics
- Other parameters like GUID, etc.
Figure 8. Main logic of u2_88
After all essential arguments are prepared; u2_88 will then login into Apple’s iTunes server using the victim’s Apple ID and password through a HTTPS connection (Figure 9). Here u2_88 implemented the steps necessary to create an iTunes login session in the C programming language. When successfully authenticated, u2_88 will store values of the “passwordToken” and “dsPersonId” in the response data into two global variables “token” and “dsid” for further usage.
Figure 9. u2_88 logs into Apple’s server using the victim’s password
The u2_88 will use the token, IDs, app ID, and GUID specified by the program’s arguments to buy related app from App Store (Figure 10). It will even check for a successful app purchase or in-app purchase.
Figure 10. u2_88 buys specified apps from App Store by previous token
After the attempted app purchase (whether success or not), the u2_88 process will connect with 223.6.250.229 for feedback and further statistics (Figure 8). Here 223.6.250.229 is the exact IP address of the previous C&C domain name jb-app.com.
Conclusion
Now, we know the updatesrv will effectively run three times on infected devices:
- In the first run, it will download a executable files to generate a unique UUID and save into /etc/uuid;
- In the second run, it will download a Cydia Substrate tweak to intercept all HTTP/HTTPS session for stealing user’s Apple ID and password and uploading to the attacker’s server;
- In the third run, it will download a fake gzip utility that will login into the App Store via the user’s ID and password, and purchase additional Apps.
Hence we classify this sample as a Trojan, and name it AppBuyer.
Suggestions for Defense
We highly recommend iOS users not jailbreak their devices. AdThief, another iOS malware found by Palo Alto Networks in this year, which also targets jailbroken iOS devices, has infected more than 75,000 devices. Another example is Unflod, which is a malicious Cydia Substrate tweak, will steal a victim’s Apple ID in the similar way.
For users who have already jailbroken their devices, here is a DIY solution to determine whether one or some of these files exist in the file system:
- /System/Library/LaunchDaemons/com.archive.plist
- /bin/updatesrv
- /tmp/updatesrv.log
- /etc/uuid
- /Library/MobileSubstrate/DynamicLibraries/aid.dylib
- /usr/bin/gzip (Some early tweaks may also create this file. You may need to run "strings /usr/bin/gzip | grep '223\.6\.250\.229'" to confirm whether it's malicious or not. If the command output "223.6.250.229", it is. Thanks to Yingandyang from Reddit.)
If any of the files exist, the device may be infected by the AppBuyer malware. However, since we still don’t know how the AppBuyer got onto the device, just deleting these files may not solve the problem completely.
The Palo Alto Networks platform is able to protect against AppBuyer malware in multiple ways. We have already released URL signatures to stop the download of the malicious files mentioned in the article, and will be releasing DNS and IPS signatures during the next content release. By blocking AppBuyer’s executable files from downloading, it can essentially defeat this new iOS malware.
Acknowledgement
We would like to thanks CDSQ from WeiPhone Technical Group for providing AppBuyer’s samples and allowing us to quote their investigation results.
Related Malware Resources
Threat Research
Threat Actor Groups
High Profile Threats
Get updates from Unit 42