Endpoint Protection Mobile

Preface

This post contains details about a coding pitfall I recently identified in many iOS applications, which we call HTTP Request Hijacking (HRH). Adi Sharabani, CEO of Skycure (now part of Symantec), and I will be presenting the problem, its ramifications, and some fix suggestions to developers later today at RSA Europe (14:10 – 15:00 | Room: G102). If you are an iOS developer in a hurry to fix this issue, feel free to jump over to the “Remediation” section. We’ve created a quick-and-easy solution that will automatically protect all vulnerable iOS apps.

UPDATE: There are many references to Skycure in this post, which is now part of Symantec. The Skycure product is now called Symantec Endpoint Protection Mobile (SEP Mobile).

Overview

Nowadays almost all mobile applications interact with a server to send or retrieve data, whether it’s information to display or commands to be executed. Many of these applications are susceptible to a simple attack, in which the attacker can persistently alter the server URL from which the app loads its data (e.g., instead of loading the data from real.site the attack makes the app persistently load the data from attacker.site). While the problem is generic and can occur in any application that interacts with a server, the implications of HRH for news and stock-exchange apps are particularly interesting. It is commonplace for people to read the news through their smartphones and tablets, and trust what they read. If a victim’s app is successfully attacked, she is no longer reading the news from a genuine news provider, but instead phoney news supplied by the attacker’s server. Upon testing a variety of high profile apps, we found many of them vulnerable. This brings us to a philosophical question: When someone gets up in the morning and reads news via her iPhone, how sure can she be that the reports she reads are genuine and not fake ones planted by a hacker?

HTTP Request Hijacking

The problem in a nutshell

The problem essentially revolves around the impact of HTTP redirections caching in mobile applications. Many iOS applications cache HTTP status code 301 when received over the network as a response. While the 301 Moved Permanently HTTP response has valuable uses, it also has severe security ramifications on mobile apps, as it could allow a malicious attacker to persistently alter and remotely control the way the application functions, without any reasonable way for the victim to know about it. Whereas browsers have an address bar, most mobile apps do not visually indicate the server they connect to, making HRH attacks seamless, with very low probability of being identified by the victims. HTTP Request Hijacking attacks start with a Man-in-the-middle scenario. When the vulnerable app sends a request to its designated server (e.g., http://www.real.site/resource), the attacker captures it and returns a 301 HTTP redirection to an attacker-controlled server (e.g., http://www.attacker.site/resource). Lets take a look at the RFC of 301 Moved Permanently HTTP response:

10.3.2 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

Source: RFC 2616 Fielding, et al The 301 HTTP redirection issued by the attacker is therefore kept in the app’s cache, changing the original code’s behavior from then on. Instead of retrieving data from http://www.real.site, the app now loads data from http://www.attacker.site, even after the MiTM attack is over and the attacker is long gone.

How it all began

One evening, Assaf Hefetz and Roy Iarchy, two of our engineers, called me over and told me they had come across a weird redirection bug in our product. We started discussing it when it suddenly hit me that this “bug” might in fact be a widespread vulnerability waiting to be discovered! A few days later we had a “white night” (work into the night) that resulted in a working PoC of an attack against a well-known iOS application. We went on to test a bunch of high profile applications, and were amazed to find that about half of them were susceptible to HRH attacks. Focusing on leading app store news apps, we found many of them vulnerable and easy to exploit. Unlike most vulnerabilities, where a responsible disclosure could be made in private to the vendor in charge of the vulnerable app, we soon realized that HTTP Request Hijacking affects a staggering number of iOS applications, rendering the attempt to alert vendors individually virtually impossible. We therefore chose to reveal the problem, along with clear and detailed fix instructions, to empower developers to fix their code quickly and efficiently, before hackers attempt to exploit it.

The Skycure Journal: A Responsible Disclosure case study

As part of our Responsible Disclosure policy, we decided to not name specific vulnerable apps we are aware of as long as they are not fixed. Therefore, for the sake of discussing the technical nature of the problem and our proposed fix, we created a sample news application, which we called “The Skycure Journal”. You can clone its code through here. While very basic, The Skycure Journal operates in a similar way to most major news apps: it loads a feed of news from a server (http://skycure-journal.herokuapp.com/) in JSON format, parses it, and then displays it to the reader.

Here’s a relevant snippet from the code: This code, variations of which can be found in many iOS apps, is susceptible to network-based HRH attack. By capturing the request to http://skycure-journal.herokuapp.com/ (via a MiTM attack, for example) and returning a 301 Moved Permanently HTTP response directing the victim’s app to an attacker controlled server (e.g., http://ATTACKER/SJ_headlines.json), the Skycure Journal logic will persistently change to loading data from the attacker’s server, no matter where and when the victim uses it in the future. Without touching the application binary, HRH makes it behave as if the code was altered to this:

A quick demo

Imagine the following scenario: A victim walks into Starbucks, connects to the Wi-Fi and uses her favorite apps. Everything looks and behaves as normal, however an attacker is sitting at a nearby table and performs a silent HRH attack on her apps. The next day, she wakes up at home and logs in to reads the news, but she’s now reading the attacker’s news! Ariel Sakin, Skycure’s head of engineering, and Igal Kreichman, Skycure engineer, created a really cool demo showing how the attack appears from the attacker’s and victim’s perspectives.

While cache attacks have been thoroughly discussed in the past, they were perceived more as a browser problems than a native apps problem. The reason is that by performing a classical cache poisoning attack (e.g., returning a fake json/XML response with cache-control directives) on native apps, the impact is very limited. In such attacks, since the cached response is static by nature (as long as the native app does not rely on an embedded browser to render it), the attacker would not be able to persistently view, control or manipulate the apps’ traffic. On the other hand, HRH attacks give the attacker remote and persistent control over the victim’s app.

HRH limitations and advanced techniques

The aforementioned attack has two limitations:

1. The attacker needs to be physically near the victim for the initial poisoning (the next steps of HRH attack can be carried on the victim regardless of geolocation).
2. The attack works only against HTTP traffic (well, almost only).

In a previous post, we uncovered the ramifications of malicious profiles. It is interesting to note that by luring a victim to install a malicious profile that contains a root CA, an attacker can mount HRH attacks on SSL traffic as well. Combining the malicious profiles threat we uncovered together with this new threat of HTTP Request Hijacking, generates a troubling scenario: Even after the malicious profile is identified and removed from the device, attacked apps continue to interact seamlessly with the attacker’s server instead of the real server, without the victim’s knowledge.

Remediation

For app developers

HRH affects a large proportion of iOS apps and we want to help ensure as many as possible are properly protected before exploits of this vulnerability start to appear. There are two main approaches for tackling HRH:

Option A
Make sure the app interacts with its designated server(s) via an encrypted protocol (e.g., HTTPS, instead of HTTP). As described earlier in the post, this is an effective mitigation for HRH, but not a fix.
Option B
Assaf Hefetz, of our R&D team, has come up with this cool and simple fix for vulnerable apps.
Step 1
Create a new subclass object of NSURLCache that avoids 301 redirection caching. Leave the rest of the logic intact.
Step 2
Set the new cache policy to be used by the app, making sure you place the initialization code before any request in your code.

For CIOs/CISOs

We see a significant increase in attacks mounted via the networks around us. Some affect apps; others the entire device. Skycure is dedicated to providing companies with a solution that detects and protects employee devices from a variety of trending mobile security threats. If you are interested, why not to start a free trial.

For iOS users

If you believe you’ve been subject to an HRH attack, remove the app and then reinstall it, to ensure the attack is removed. Then please drop us a line at security@skycure.com to tell us about it. It is of course always recommended to keep your apps fully up-to-date, so that when fixes are released, you’ll have them installed on your device at the earliest opportunity. Do this either manually or by enabling auto-update in iOS 7.

Future work

• In this write-up we’ve discussed the impact of 301 HTTP responses on mobile applications. Note that there are other redirection responses that might also prove to be problematic, such as 308 HTTP response (it is still a draft).
• HRH isn’t necessarily a problem of iOS applications alone; it may apply to mobile applications of other operating systems too.