Steamed rice · 2015/02/27 18:35

0 x00 profile

weibo:http://weibo.com/zhengmin1989

We discovered a phishing attack (which could steal Apple ID passwords, Gmail passwords, etc.) on non-jailbroken iOS devices in March and April last year when iOS was 7.0, and reported it to Apple early on. 609680831) and apple hasn’t fixed it yet. To keep up with the trend of Project Zero (90-day vulnerability disclosure strategy), we are now going to make the demo and details public:

First of all, let me read the demo. Steal the App Store password on a non-jailbroken iPhone 6 (iOS 8.1.3) :

In this demo, the App Store is a real system App, but the login box that pops up is not from the App Store, but from another App running in the background. As we know, in sandbox strategy, an app runs in its own sandbox space. Theoretically, it cannot affect other apps. If it can affect other apps, it is a serious problem. In addition to sandbox escape, there are a few things that need to happen to make this demo a success:

  • Install the phishing app to the target device.

  • Background unlimited running and boot up.

  • Detect the running status of the target app (such as the App Store).

  • Get the Apple ID username to execute a phishing attack.

  • A phishing dialog box is displayed, and the password is uploaded to the server.

0x01 start

1. Install the phishing app on the target device

Phishing apps use some special API functions (which we will discuss later because they are not private frameworks), so we need to consider what happens if the App Store rejects such apps. If the App Store refuses to accept it, there are usually two options:

1. Use special methods to bypass detection: The simplest method is obfuscating and dynamic loading, which were the favorite methods of 360 at that time and were later discovered by Apple, forcing all apps to be removed from the shelves for one or two years. For more sophisticated methods, see Usenix Security’s paper: Jekyll on iOS: When Benign Apps Become Evil. This method is to upload an App with overflow vulnerability to the App Store, and then trigger the vulnerability by remote ROP Attack and call the private API.

2. Sign the app with an enterprise certificate or developer certificate. In this case, instead of using the App Store, the App can be installed directly on the phone via USB or other means. That is, PP assistant, synchronous push technique used. Want to do this is very simple, a open source libraries abroad libimobiledevice (http://www.libimobiledevice.org/) can meet your demand.

2. The background runs wirelessly and starts up

There are several options for this, and I’ll briefly introduce two of them:

1. If enterprise certificates or developer certificates are used for propagation, add the Continuous, unboundedTaskCompletion and VOIP properties to the UIBackgroundModes plist. The first two are private apis and will not be approved if you upload them to the App Store.

2. If you want to upload to the App Store, you need to disguise it as a VOIP App, so that you can boot it up. Then can adopt the method of background silent music background, playback tools can use AVAudioPlayer this object, and then declare a AudioSessionProperty_OverrideCategoryMixWithOthers properties. Because of MixWithothers, there is no display on the panel, the user will not notice that the music is playing, and other players will have no effect on the music playing.

3. Detect the running status of the target app (such as the App Store)

There are many ways to do this, but two of them are simple:

1, the UIDevice Category For the Processes (http://zurb.com/forrst/posts/UIDevice_Category_For_Processes-h1H). In this way, you can get the currently running program. Demo checks every 5 seconds to see if the App currently running has an App Store. If so, a phishing dialog box will pop up.

2. Obtain information about all installed apps. Use the LSApplicationWorkspace object to get information about all installed apps.

4. Get the Apple ID username to execute a phishing attack. Please refer to CVE-2014-4423 for details.

5. A phishing dialog box is displayed

And upload the password entered by the user to the server. Normal dialogs use UIAlertView, but dialogs generated by this class can only be displayed on the view of your app. But if you use the CoreFoundation framework (not the private framework) CFUserNotificationCreate() and CFUserNotificationCreate CFUserNotificationReceiveResponse () method, an app can jump out of the sandbox constraints, and on the other app interface pop-up dialog box.

For example, in the picture below, the first one is a real dialog box, while the second one is faked by me. I deliberately changed the K to lowercase to distinguish between them. With the CFUserNotificationCreate() API, you can fake login dialogs for many applications, not just the App Store, but also YouTube, Gmail, Tmall, and so on. Since there is no difference between a fake dialog box and a real one, the chances of a user being fooled become very high. This API was originally designed for Mac OS X, but because iOS and Mac OS X share some basic underlying frameworks, iOS does not block the API or do any permissions checks, resulting in sandbox escape.

0x02 Epilogue & Reference article

People tend to think that iOS is more secure than Android, so they are particularly bold when using An Apple phone, but that’s not the case. Through several holes in combo, hackers can easily trick you out of your account password. To make matters worse, the iOS bugs shown in this article are just the tip of the iceberg. In our ASIACCS 15 paper, we also introduced the use of iOS remote control, monitoring and other vulnerabilities, interested students can continue to learn.

  1. Min Zheng, Hui Xue, Yulong Zhang, Tao Wei, John C.S. Lui.
”Enpublic Apps: Security Threats Using iOS Enterprise and Developer Certificates”. (Full Paper) 
Proceedings of 10th ACM Symposium on Information, Computer and Communications Security (ASIACCS 2015)

2. Tielei Wang, Kangjie Lu, Long Lu, Simon Chung, and Wenke Lee.
”Jekyll on iOS: When Benign Apps Become Evil”, Proceedings of Usenix Security 2013