Mobile App Security - Want to Be a “Man in the Middle” of a Mobile Communication? It’s Easier Than You Think

Mobiles are everywhere nowadays and a central part of almost everyone’s lives. In fact, we are using them for everything - both for personal and business purposes. From streaming media entertains us on our way to work, to chatting with friends and family, to sending emails at work - mobiles are now effectively computers on the go. According to Cisco "The Zettabyte Era—Trends and Analysis" ^[1] study, we are using mobile access more and more. And this trend will continue well into the future.

Our productivity, accessibility, and attainability rely on mobile apps. The connecting process to a mobile network is transparent and invisible. The same applies to all other services that we consume. Everything is fast, invisible and already set. We are consumers of this myriad of mobile services without ever thinking about what could happen if someone were to intercept that connection.

So how come we hear about data leaks like the thefts celebrities' private photos theft, stolen identities, unauthorized bank transfers, and millions of customer records being stolen from large companies?

Data security - What happens to your data?

The data-in-motion - that is, data that flows from your mobile app to the server and back - travels across the world. It is transferred over your local WiFi network or via your mobile connection to the operator’s router or base transceiver station (known as BTS). Then, the data is redirected from one one router to another. On the way, the data is inspected by automatic processes (such as antispam & antivirus appliances). Every data hop is under someone’s administration - who can eavesdrop any data.

Thank God (or cryptologist), data encryption exists to protect our data-in-motion.

Hopefully, you have heard about HTTPS, a protocol that uses TLS/SSL for data encryption. But setting the encryption in the proper way is difficult. Encryption could be configured in many different ways. Even if we take fine tuning out of the equation, there are still at least 1400 combinations of factors (in a case of HTTPS settings). That’s just before you take additional requirements, like backward compatibility, into account. Because of different requirements, there is no straightforward way to configure it. And trust me, it is very easy to make a mistake. Moreover, every day we find new threats and new attack vectors. It is a tough challenge to keep all provided services at all servers up to date and correctly configured.

What is a Man in the Middle Attack?

The situation outlined above is ideal for hackers and attackers. Attackers can easily direct their victims’ data to their device and eavesdrop on the communication, performing a Man-in-The-Middle (MiTM) attack.

Attackers can easily access your connection in a public place such as shopping center, airport or cafe by creating an open WiFi access point without a password. (This is also called an evil twin ^[2] or rogue Access Point ^[3].) Then they wait for new clients to come and try to synchronize the victim’s digital activities. They can even speed up the process by disassociating clients from the original legitimate Access Point.

This method allows hackers to ignore things like strong user passwords, highly protected sites and services. All that is needed to cause later disaster is one misconfiguration during the development or operation of the mobile application But a MiTM attack is still possible even when everything is "correctly" implemented--you should understand "correctly" is “securely.”

Even if everything is done correctly and securely by the developers and operators, you can still be liable to Man in the Middle attacks. The culprit? Users. They visit an unsecure website and see a warning advising from not going further, but they click on the “Proceed anyway” button. You can guess how many users will click on that button. In this always-on, I-want-it-now digital age, no warning can stop users from getting what they want. A study shows that people ignore security alerts up to 87% of the time. ^[4]

That’s all attackers need, folks, to steal your identity, access codes, and data.

Does this warning message look familiar to you?

Example of a browser SSL warning

Is Man in the Middle really that easy?

The anatomy of a MiTM attack against SSL ^[5] is to replace (SSL hijack) or remove (SSL Strip/Downgrade) the certificate which protects the exchange of the password used for future traffic encryption. There are automated tools and tutorials to do that, and they are publically available on the Internet and on Youtube. ^[6] Almost everyone can do it.

There are, of course, other MiTM techniques that manipulate with domain name resolution service (DNS)^[7], ARP ^[8], DHCP, STP or ICMP protocols. But this goes beyond the scope of this article.

What enables SSL-related Man in the Middle attack?

1. Incorrect certificate validation: bypassing the functionality or using own cryptographic library, etc..
2. Use old and obsolete protocols to establish a secure communication e.g. all SSL versions or early versions of TLS
3. Lack of experience with technologies

You are right to say that it's not possible to demand everybody to understand IT security. That's why mobile app security is the responsibility of the mobile application/backend server developers and server operators.

Why do we still use old protocols? Why don’t we implement a proper certificate validation?

Statistic of usage of SSL settings on server side ^[9]

We all want to get things done quickly. Software developers, pressured by deadlines and the need to cut costs, often wind up leaving gaps in their security that hackers can take advantage of. Even if time and money are not a problem, many developers lack the necessary experience with mobile app security, security settings and configurations. We talked about thousands and thousands of possible settings. Missing or unavailable operating system update could also be a problem. They might forget a development/production switch that completely bypasses certificate validation. It is as simple as that.

On the user side, much of the blame lies with people using old phones with limited support for cryptographic protocols, misconfiguration of secure access, or acceptance of all certificates for connection - again, certificate validation bypass.

Our research shows that 75% of tested application has activated some certificate validation bypass. Now we can ask again: “How it is possible that we experience so many data breaches?”

Now, you know the answer.

How can we help?

We can fix it. Our mobile application security technology, SeaCat, has by-the-book certificate validation, no way to bypass it. On top of that, every mobile application installed on a mobile device has a unique and automatically-managed identity to allow bi-directional authentication or mutual authentication. We immediately know if any person wants to be in the Middle and quickly disconnect this person. We support the latest cryptographic protocols on even old mobile phones and devices.

We make no sacrifice in security.

Send us an email at info@teskalabs.com to share your opinion or ask us any question.

Reference

1. https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/vni-hyperconnectivity-wp.html
2. https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)
3. https://en.wikipedia.org/wiki/Rogue_access_point
4. https://nakedsecurity.sophos.com/2016/08/19/why-people-ignore-security-alerts-up-to-87-of-the-time
5. http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html
6. https://www.youtube.com/watch?v=-hd7XG-b6uk
7. http://www.windowsecurity.com/articles-tutorials>authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
8. http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part1.html
9. https://www.netcraft.com/internet-data-mining/ssl-survey

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.