Wi-Fi HTTP Request Hijacking attack against iOS users

http://securityaffairs.co/wordpress/
I’m not surprised for trust given by Internet users to public Wi-Fi networks that are notoriously insecure, wrong habits on the open networks could expose our identity to serious risks, one on all the identity theft.
Mobile security researchers at Skycure have discovered a new technique, HTTP Request Hijacking, exploitable by an attacker to access mobile phone apps from Wi-Fi networks, in particulate he could exploits a vulnerability in the code within iOS apps.
The attacker is able to modify the server URL from which a mobile application loads its data, in the attack scenario the app instead load data from its legitimate server could load it from a server controlled by the attacker without the victim note it. The data acquired from a server controlled by the attacker could be exploited to load malicious links, or insert fake, market-moving news into a news app.

The researchers at Skycure have decided to public disclose the methods HTTP Request Hijacking to exploit the vulnerability because it is present in hundreds of apps they tested, including stock management apps  and news apps.

“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 HTTP Request Hijacking 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).” 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 fromhttp://www.attacker.site, even after the MiTM attack is over and the attacker is long gone.

In the HTTP Request Hijacking attack scenario a victim connects to the Wi-Fi in a public place and uses his favorite apps as usual. An attacker is in the immediate vicinity and performs a silent HRH attack on her apps. The next day, he uses again the app at office, but the data he received are not the legitimate one, for example he logged in to reads the news, but he accessed to the attacker’s news!

==> Read More