iOS apps vulnerable to HTTP Request Hijacking attacks

Share this article:
Researchers have determined that the vulnerability can be exploited in several iOS apps.
Researchers have determined that the vulnerability can be exploited in several iOS apps.

After learning of a redirection bug in one of its own iOS products, the researchers at mobile security company Skycure determined that the vulnerability – known as HTTP Request Hijacking (HRH) – can be exploited in several iOS apps.

The first part of the HRH, known as the “injection phase,” is when an attacker changes the logic of the app, Yair Amit, CTO and cofounder of Skycure, told SCMagazine.com on Tuesday. The next part is when the attacker takes control over the app's traffic, even when they are far away.

“The first phase starts with a man-in-the-middle (MiTM) scenario,” Amit said. “That can happen when the victim connects to a coffeeshop, hotel or airport Wi-Fi – a very popular target for MiTM attacks. Then, while the victim uses his applications, the attacker captures the requests they issue and responds with 301 HTTP responses that direct the victim's apps to interact with an attacker's controlled server.”

Amit added, “If the applications honor 301 HTTP responses, they would remember this directive and from that moment on will practically persistently change their logic and keep interacting with the new, attacker-controlled URLs, even though their developers specifically coded these applications to work with their designated servers.”

So, what is the end result for victims? Whether near or far, the attacker has access and control of iOS applications and can essentially alter how they operate.

Amit used a news app as an example, stating that the attacker can modify the content being delivered from the vendor. The CTO added that during his research he has seen stocks, social and even banking apps that are also vulnerable to HRH.

“One interesting example for this would be the huge effect the Syrian Electronic Army had when they hijacked the Associated Press Twitter account earlier this year and tweeted about explosions in the White House and the injury of President Barack Obama,” Amit said. “As you may remember, that led to about $136 billion being erased from the S&P 500 in a matter of three minutes.”

The exploitation is hard to detect for the average user because a successful HRH attack results in “persistent” change of the URLs to which the apps connect and, since most apps do not display web addresses, the owner may go on using the altered app for some time. However, a technical person who analyzes app traffic might be able to make the discovery.

Amit, who posted the findings in a blog post, offered some best practices to avoid getting drawn into this vulnerability.

“As a best practice, it is always advisable to program applications to interact via an encrypted channel, such as HTTPS, instead of HTTP,” Amit said. “However, this is a mitigation of HRH, not a fix. An attacker might utilize techniques such as malicious profiles in order to circumvent the SSL layer, and perform a persistent attack even if the victim removes the malicious profile.

A more thorough fix for HRH would be to change the caching policy of the application to not store persistent redirections, Amit said.

Share this article:

Sign up to our newsletters

More in News

In Cisco probe, misuse or compromise spotted on all firms' networks

In Cisco probe, misuse or compromise spotted on ...

Cisco analyzed the business networks of 30 multinational companies last year, and revealed the findings in its 2014 Annual Security Report.

Fareit trojan observed spreading Necurs, Zbot and CryptoLocker

The Necurs and Zbot trojans, as well as CryptoLocker ransomware, has been observed by researchers as being spread through another trojan, known as Fareit.

Post Heartbleed, tech giants join initiative to bolster open source

Post Heartbleed, tech giants join initiative to bolster ...

The newly formed Core Infrastructure Initiative, created to boost under-funded open source projects, will tackle OpenSSL first.