Fortunately, Wireshark supports this way as well, by specifying a file that has these secrets in a specific format. And since we control one end of that, it can be used to get plaintext from TLS traffic. However, there’s another way: cryptographic keys in a TLS session are derived from a (Pre-)Master Secret, which is present at both ends of the secure channel. The reason, of course, is exactly why this approach against RSA key exchange would work, as real-world attackers could just as easily collect TLS traffic and compromise private keys later, hence modern implementations preferring key exchange algorithms with Perfect Forward Secrecy (PFS). But even if you’d get it, the latter problem is that RSA-based key exchanges, where secrets are being encrypted using the public key from the server certificate are being phased out in favor of ephemeral solutions like traditional (DLP-based) and elliptic curve (EC) Diffie-Hellman (DH). The former problem comes from the fact that in most pentest projects, you don’t get the private key of the server, for multiple reasons.
This has two problems, one inherent to pentest projects, another related to the year being 2020. But what do we really need to decrypt plaintext if we let the app speak directly to the API? Old-timers might remember Wireshark having the option to decrypt SSL/TLS when given the private key to the server certificate.
It’s obvious why we can read plaintext from TLS in a MITM scenario. It’s just that MITM worked so well for so long, that it’s the first thing that comes to mind sometimes even if it’s not the best fit for the problem. On the other hand, if there are this many problems and all we need is reading the plaintext traffic, there are better solutions out there. For this, the certificate and its private key must be extracted from the app, which, similarly to the aforementioned certificate pinning can be either done quick and easy (when it’s in a PEM file) or it can lead to hours of frustrated reverse engineering.Īround this point is where some start thinking: do we really need to perform man-in-the-middle? Of course, MITM has its bright sides: modifying the plain text traffic on-the-fly is easy to implement, adding a match-and-replace rule to Burp to switch X-Jailbroken: true to false just works. In such scenarios, since the end-to-end TLS is split into two, the legitimate client authenticates to the MITM server, yet the MITM client also needs to present a certificate to the legitimate server. Latter can get to a point, where there’s a big cliff: either you can defeat it with automated tools like Objection or it becomes a daunting task, where you know that it’s doable but it’s frustratingly difficult to actually do it.Īnd then there are the cases from the second sentence of this post, where both ends perform authentication, and since the server is the one presenting the certificate most of the time, we usually refer to it as client certificate authentication, since that’s the “exception” to the rule.
It started with adding MITM CA certificates to OS stores, recent operating systems require more and more obscure confirmations and certificate pinning is gaining momentum. In many cases, the best method to overcome this limitation is man-in-the-middle (MITM), where a special program intercepts packets and acts as a server to the client and vice versa.įor well-written applications, this doesn’t work out-of-the-box, and it all depends on the circumstances, how many steps must be taken to weaken the security of the testing environment for this attack to work. Of course, nowadays, most of these channels are secured using TLS, which provides encryption, integrity protection and authenticates one or both ends of the figurative tube. So our approach is less of a novel attack and more of an improvement on current techniques. In this blog post, we’ll introduce a method to simplify getting our hands on plaintext messages sent between apps ran on our attacker-controlled devices and the API, and in case of HTTPS, shoveling these requests and responses into Burp for further analysis by combining existing tools and introducing a new plugin we developed. Sniffing plaintext network traffic between apps and their backend APIs is an important step for pentesters to learn about how they interact.
0 kommentar(er)
