80% of Androids Are Vulnerable to Linux TCP Flaw. But I Don’t Care!

Researchers from the University of California, Riverside, and the U.S. Army Research Laboratory have found an off-path TCP vulnerability[[1] that affects more than 80% of Android mobile devices. Unlike a Man-in-The-Middle attack, you don't need to be in the middle of the communication to get hacked - all attackers need to know is who you communicate with.

The vulnerability has already existed for over four years. Attacks which exploit this vulnerability have a remarkably high successful rate, between 88% and 97%, and it can take less than a minute to complete. While you might not be interested in the technical details, you should know such attack can prevent you from communicating with the server using HTTPS protocol. Attackers can completely alter the data by manipulating all responses and requests in HTTP connections.

You also want to know that the majority of Android devices will never be updated. The vulnerability remains active for years. Based on Google Play statistics[[2], more than 65% of active Android operating systems are older than two years, and more than 22% of active Android operating systems are older than three years).

It only takes one vulnerable party to trigger a successful attack and prevent server operators from doing anything about it. The vulnerability remains in the system without requiring any interaction from the users. What a perfect attack method - no user activity is necessary as opposed to a Man-in-The-Middle attack. You can't fix this security issue without updating your mobile device. The attackers only need to choose their victims.

Bad news for all application operators and providers.

Is there a solution that can fix this issue and relieve the worry about the security and availability of mobile applications? Of course, there is.

First of all, HTTP protocol is dying, as it should be. If you are serious about the mobile app that you're owning or developing, you should not use HTTP protocol, and instead, implement HTTPS. But that’s easier said than done. Configuring HTTPS properly is not a trivial task. You don't think so? Look at how many mobile apps, including ones with millions of active users, that don't have a proper validation mechanism of server certificates.

Even if you avoid HTTP protocol, and you implement HTTPS by-the-book, you are still at risk of not being able to communicate with the server due to this TCP flaw.

Software Defined Network (SDN) to the rescue

There is a workaround[3], but it applies only to the server side of the connection while leaving the client side vulnerable. One vulnerable component is enough for attackers. The only way to deal with the vulnerability at the mobile operating system side is to use a “higher network logic” to completely bypass the fragile network connection. There is a name for this solution - Software Defined Network (SDN). SDN should be appended to your application to enable advanced control over the connection without root access to the operating system.

The right SDN technology is smarter than your standard connection. Typically, an application is fully reliant on the operating system to control the hardware of the phone. The operating system negotiates the connection via a network driver. If the vulnerability is in the operating system core or in the network driver (as in this specific case), you cannot recover from the error. Your application remains stuck in this broken network state.

However, with additional network logic- that is, SDN logic- you can detect network problems and respond promptly. SDN only closes the stuck/broken connection, and immediately opens a new one without the users even notice it. Thanks to SDN functionalities, your mobile apps can then quickly recover.

To sum it up, I don’t care about this TCP vulnerability. I don’t use HTTP. I use SDN to handle and secure all network requests. Disconnection on the lower level is not something that makes me go crazy.

I don't care because I’m prepared. Waiting for Android to be fully safe is a waste of time.

If you have any question, contact us.

Reference

  1. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf
  2. https://en.wikipedia.org/wiki/Android_(operating_system)#Platform_usage
  3. http://www.zdnet.com/article/linux-tcp-flaw-lets-anyone-hijack-internet-traffic/

About the Author

Jiri Kohout

TeskaLabs’ VP of Application Security, Jiri Kohout, brings years of experience in ICT security, having served as the Chief Information Security Officer for the Ministry of Justice and Chief Information Officer for Prague Municipal Court. He cooperated with the Czech National Security Agency to prepare the Czech Republic cyber security law.




You Might Be Interested in Reading These Articles

Why Hackers Target Small Business Websites 5 Tips to Stop them

With the rise of online businesses, so does the hacking community. Many talented people with barbarous intentions from across the world develops systems with one intention in mind, to harm and attack websites and ruin the day for most entrepreneurs.

Continue reading ...

security

Published on October 15, 2019

Application Security Issues for HTML5-based Mobile Apps

HTML is no longer restricted to just websites. With its latest edition, HTML5, the markup language family has now become a popular choice for mobile applications. After gathering the relevant data and researching, Gartner predicted two things; firstly, HTML5 would be the most commonly used language for mobile applications in 2015 and secondly, HTML5-based hybrid mobile app using technologies such as PhoneGap, Codova or React Native reach up to be 50% of all mobile apps 2016.

Continue reading ...

mobile security

Published on March 01, 2016

Binary distributions of OpenSSL static libraries

The official source of OpenSSL software is the OpenSSL website. One can download OpenSSL source codes archives and compile them for a given platform. The compilation work can sometimes be quite tedious, especially for exotic platforms. We, at TeskaLabs, set up this page because we frequently compile OpenSSL for various platforms for our internal purposes and this may save some time to other developers.

Continue reading ...

development android windows ios security

Published on July 20, 2017