How much can you trust your devices? In this blog post, we will cover a practical attack that utilizes the iPhone Configuration Utility, a malicious Mobile Device Management (MDM) server, and a little bit of social engineering to get you data from iOS devices, HTTP and HTTPS web traffic, and possibly domain credentials.
To start this off, we will be sending out a .mobileconfig file to iOS devices at the HACKME company. This .mobileconfig file is created with the iPhone Configuration Utility (shown below) and will set up iOS devices to use a specific proxy host when connected to a specific Wi-Fi network. This proxy will be used later to capture HTTP and HTTPS traffic. Additionally, we will configure trusted certificates and an MDM server to use for (malicious) device management.
Our example will focus on getting users to install this .mobileconfig with a phishing email. The phishing email will come from firstname.lastname@example.org and will have the .mobileconfig file attached. The email will encourage the iPhone owners to install the .mobileconfig to maintain compliance with company policy.
Once the target is phished and the profile is installed on their device, we will want their iOS device in range of our wireless access point. This could easily be done with a high powered Wi-Fi access point in the parking lot. If we want even closer access to our targets, we could send someone into the client building with a battery powered 3G/4G AP in a bag and have them run the attack from inside the building.
The first step in this attack is to set up our malicious .mobileconfig profile to send out with the phishing email. This .mobileconfig will have a default Wi-Fi network configured along with a proxy to use when connected to the Wi-Fi. For this demonstration, we will be showing screenshots from the Windows version of the iPhone Configuration Utility.
Wi-Fi Network Setup (with proxy settings)
If we are going to intercept HTTPS traffic, we are going to need a trusted root CA on the iOS device. This too can be done with the iPhone Configuration Utility. In this attack, we will be using the PortSwigger CA from the Burp proxy.
This config will then be exported to a .mobileconfig file, and we will send it along with the phishing email.
The only downside to this is the signing of the profile. As of now, it can be a pain to get these properly signed using Windows. The Apple device management utility allows you to specify certs to use for signing, so I would say use the Apple tool for exporting your profiles. Overall this won’t too big of a deal, if you’re assuming that people will not care about the “Not Verified” warning on the profile.
Once the user has the profile installed on their iOS device, we need to get in Wi-Fi range of their device. For simplicity’s sake, let’s say that we just tailgated into the office and set up shop in an empty office or conference room. A capture device, such as a RaspberryPi or laptop, and wireless AP (with 4G internet access) will be with us and running off of battery power. The capture device could also easily sit in a bag (purse, backpack, etc.) in an unlocked file cabinet. For our safety, we will lock the cabinet and take the key with us. We could then leave the devices for later retrieval, or have the capture device phone home for us to access the proxy logs remotely.
At this point, there should be some decent data coming through on the Wi-Fi traffic, but our main goal for this demo is to capture the exchange ActiveSync request. It looks like this:
You’ll see the Authorization token in the request header. This is actually the base64 encoded domain credentials (HACKMEhackmetest:P@ssword123!) for the iPhone user. Now that we have domain credentials, the rest of the escalation just got a lot easier.
We also set up a web clip to deploy to the iOS device. This fake app will be handy in the event that we’re unable to get the ActiveSync credentials. The app will look like a branded HACKME company application that opens a web page in Safari containing a login prompt. The malicious site will store any entered credentials and fail on attempts to login. So even if we’re not on the same Wi-Fi network, we might be able to get credentials.
One additional item to think about is that these profiles do not have to be deployed via email. If an attacker has access to an unlocked device and the passcode, they may be able to install the profile to the iOS device via USB. This attack can be particularly applicable to kiosk iOS devices that allow physical access to their lightning/30-pin connectors.
Finally, all of this can be continually manipulated if you set up an MDM server for the device to connect to, but we’ll save that for another blog.
Don’t leave device management up to your users. If you are using iOS devices in your environment, lock the devices down and prevent users from installing their own configurations. More importantly, go and configure your company devices before an attacker does it for you.