Data security in mobile applications today depends on SSL pinning - and it has loopholes. Would it be possible to re-elect the web as safer? That's what I tried.
Sometime ago I received a video that exposed weaknesses in SSL Pinning, the technology that ensures data communication in mobile applications. I had already worked on apps that use the technique - as well as having tried to break it before - so I thought it would be interesting to investigate.
This data transmission security solution consists of establishing an SSL certificate together with the application build - for exclusive client-server communication through this key. As the build embeds its own set of certificates, it protects itself from attacks on the Certificate Store of the client's operating system, for example.
Along with its popularity, the technique has been receiving attention from cyber defense authorities as it has weaknesses that allow apps to be tampered with bad keys. Through reverse engineering, it is possible to tamper a build with malicious keys and thus expose the client to impersonalization attacks.
Web or Mobile? The safe choice
After investigating the structure of these attacks, I realized that the web environment had the potential to be more resilient to tampering.
Mobile applications are delivered directly to the client host, thus being exposed to the fate of the OS and device itself. At the other end, let's say a PWA Web application, its release is restricted to the browser context only.
However, to reach the level of security that pinning proposes, a web release would need to contain at least two characteristics:
- allowing the validation of original certificates;
- being resilient to the tampering of this information.
SSL pinout: Authority is what counts
I started the research with SSL Pinning. Conceptually, the idea is great: linking the frontend application to an exclusive set of certificates. But in practice, the approach creates problems as it exposes the certificates in the build, being subject to reverse engineering, and tampering, among others.
Would there then be something similar in the browser? The answer is yes.
In 2013, Google created a mechanism to help defend against attacks on the CA Store, called Certificate Transparency. This is an internet standard in which digital authorities must publish public logs with all their issued certificates. This way, the client browser itself can decide whether a given domain has such a certificate, or whether it is fake.
The approach has been gaining ground and since 2018 Google Chrome has required that all certificates be available in a public log.
Tamparing the application
The pinned release can have its certificates patched if the client is exposed. The attacker can also change the frontend to call his domains and impersonate the whole API.
As the web application does not pin the certificate - but rather authenticates it in the global transparency repository - there is no risk of certificate tampering.
Unfortunately browsers, as a rule, do not encrypt the cache, leaving it up to the user to protect themselves with storage encryption solutions. Therefore the attacker, in possession of the host, can manipulate the application cache and its version as well. However, the multiple security layers on the browser (like CORS) will likely make the tampering impractical.
Obscurantist solution: the hack against reverse engineering
A simple and reasonably effective solution is to employ techniques to make it difficult to manipulate compromising information: in this case, URLs in javascript builds or SSL keys embedded in the mobile release.
Code Obfuscation is the means of deliberately creating code that is difficult to read and reverse engineering. There are automatic solutions, but manual care is necessary if the intention is to protect yourself from more skilled attackers.
Another technology being developed is the in-memory validation of code hashes. This approach, promising against tampering, consists of validating at runtime whether the method has been modified, preventing the program from continuing in the event of tampering.
Connecting the dots
Certificate Transparency seems to me to be an important advance and could be incorporated into other environments in the future.
Unfortunately, mobile application frameworks do not evolve with the same cohesion and timing as the W3C or Google Chrome, leaving the promising solution resident of just a few use cases.
Top comments (0)