Security

The history of Android app development has gone through several notable stages, from small apps running locally, to client-server apps, app ecosystems, and super-apps. Each of these stages raised the bar of complexity, creating new vulnerabilities, and increased developers’ concern about the security of both the applications and the data they operate with. The operating system itself has evolved, providing developers with more options and security mechanisms. But there are always a few more unknowns in this system of equations than meets the eye. This article will cover how mobile app vulnerabilities have evolved, what influenced them, what vulnerabilities are relevant now, and what’s in store for the future.

In 2022, our team discovered 216 vulnerabilities during studies of 25 pairs of apps for Android and iOS platforms. The storage of user data in clear text accounted for the largest share of vulnerabilities (14%). Despite the efforts of operation system developers and secure application development communities, this class of vulnerability has continued to be the most prevalent for several years in a row. This trend will remain relevant in 2023, although it is now very simple to use cryptography in mobile applications: both vendor and open-source solutions make working with cryptographic primitives easier for developers. Vulnerabilities related to application integrity checks and storing confidential information in the code shared second place, with 9% each. Third place (8%) was taken by vulnerabilities related to untrusted environment checks.

If you like to integrate with external security systems, then you have probably come across such a thing as Mutual TLS (also known as TLS mutual authentication or mTLS). There is nothing particularly difficult in such integration. Except for two nuances:

1. Integration will have to be done in each service
2. In each service you need to put client certificates for passing the mTLS handshake

And if you can somehow live and put up with the first nuance, then the second already causes much more problems and leads to sad faces of your security team. To make them happy again, and at the same time eliminate the need to write the same code in each service, can be made by a smart reverse proxy, which will take all the hardships and hardships handshake related and possibly some other additional logic. We will do this farm on Ktor, because why not;)

To make them happy again, and at the same time get rid of the need to write the same code in each service, we will write a smart reverse proxy which will take care of all hardships associated with an mTLS handshake and other security logic. I will implement all these things with Ktor, because why not ;)

In general, I don’t use Drozer. And using this tool on macOS is unusual for me. If I do some “pentest things” I just take my Kali Linux with pre-installed Drozer and use it there. But the day has come, and I decided to install Drozer on my macOS. It was a real hell =)

I spent a lot of time trying to make it work. Eventually, I had to rewrite a piece of class loader script… A living hell! When everything started working right, I came up with a better way of installing Drozer on macOS and removed all this stuff . In fact, there are two good ways to do it. The Docker-way and the following one