Earlier this year Apple announced it had fixed a vulnerability that allowed an attacker to intercept traffic between iOS devices and the App Store because that traffic was sent in clear text. Apple used HTTPS to resolve the matter, but with the amount of open Wi-Fi hotspots, HTTPS does not provide an adequate resolution—as I’ll explain. Fortunately, the recently announced iOS 7 beta introduces per app virtual private network (VPN) capabilities, but how many enterprise apps will actually support it?
HTTPS is the result of layering HTTP on top of Secure Socket Layer (SSL) and Transport Layer Security (TLS). SSL and TLS are both cryptographic protocols that enable secure communications over the Internet. Without SSL/TLS, communications between a client and a server are exchanged in clear text—HTTP for example—allowing anyone to eavesdrop on the communications and obtain sensitive information.
The problem with HTTPS as it relates to enterprise apps is the willingness of employees to connect to any available open Wi-Fi access point—in their local grocery store, coffee house, shopping mall, or mom-and-pop shops. In fact, many employees configure their devices to automatically connect to open hotspots. What is the cost of this convenient access? It’s surprisingly easy for an attacker to set up a rogue wireless access point with open access and perform a MiTM attack, gaining access to a wealth of sensitive information.
The following diagram outlines how a cyber criminal might use a rogue wireless access point to launch a MiTM attack. The miscreant first sets up an open wireless access point to which victims can connect. When the victim opens a personal app or enterprise app that uses HTTPS, the criminal uses DNS spoofing to provide the app with a fraudulent certificate. Depending on the app, the victim might receive a message to update the certificate, or the app might automatically update the certificate. Once the app’s certificate is updated to the fake certificate issued from the access point, the rogue access point acts as a proxy between the mobile device and the rest of the world. As a result, all information is available to the attacker in clear text. In fact, any HTTPS session is visible in clear text to the cyber criminal who has control over the access point.
Although per VPN apps are not available yet, we do have the ability to set up a VPN connection on most mobile devices. By setting up a VPN for employees’ mobile devices, organizations can filter communications to the Internet through the corporate network, making sure a MiTM attack is not successful. The diagram below illustrates how a VPN would mitigate a rogue Wi-Fi hotspot.
There are a few strategies that you can implement to MiTM proof your enterprise apps.
Any enterprise app should be designed to validate the server’s security certificate. Failure to do so will allow an attacker to inject a fake certificate. Earlier in 2013 all T-Mobile customers were affected by this vulnerability. The Wi-Fi calling feature did not validate the T-Mobile server’s security certificate, leaving calls and text messages open to MiTM attacks. Hackers were able to pose as a T-Mobile server, issuing their own fake certificate which enabled them to eavesdrop on conversations and modify traffic.
Safeguard your IP:
Your enterprise apps connect to internal systems that store intellectual property. You cannot control non-enterprise apps, but you can control yours. You should force enterprise apps on employees’ devices to connect via a VPN tunnel that your organization controls. Although this does not mitigate against a compromised device, it does mitigate against MiTM attacks that target your enterprise apps.
By educating your employees about the risks of connecting to open Wi-Fi connections, you can dramatically decrease the overall risk of employees falling victim to MiTM attacks. Moreover, it will also help employees become more aware and think twice about connecting to some of the Wi-Fi hotspots they currently frequent.