Listening to unencrypted network traffic between applications and their APIs is an important step for pentesters to learn how to communicate. In this article, I will introduce you to a method related to how we can more easily see open messages sent between applications and APIs on a device that the attacker controls. Also; In HTTPS, I will also show you how to put those requests and responses to Burp for analysis at a later time by blending existing tools and a new plugin developed by Silent Signal. In other words, I can say that it is not an unusual technique, but an advanced level of the familiar.
Of course, most of these channels today; It is secured using TLS, which provides features such as encryption, integrity protection and authentication for one or both ends of the m3taphor tunnel. In most cases, the best method to remove this limitation is to cut the packets and send the server to the client; It is said to be a man-in-the-middle (MITM) attack, a special program that acts as a client on the server.
For well-coded applications, this may not work in different angles, but it all depends on the conditions, like how many steps should be taken to weaken the security of the test environment for this attack to work. This process started by adding MITM CA certificates to OS repositories. The latest operating systems require even more obscure verifications, and certificate pinning is great for acceleration. The other substance may come to the center stage; Either you can beat it with automated tools like Objection, or things can become a daunting task.
And then there is another case where both parties validate, since most of the time the server is presenting the certificate. We usually call this Client Certificate Authentication. Because end-to-end TLS is divided into two in such scenarios, legitimate client authenticates to the MITM server. But still the MITM client needs to present a certificate to the legitimate server. For this, the certificate and its private key must be removed from the application, or you may find yourself dealing with reverse engineering for hours in frustration.
Some of you might think: do we really need to do MITM? Of course, the MITM attack has its advantages as well: it's easy to edit an already outgoing plaintext traffic, a Match and Release rule can be added to Burp to switch X-Jailbroken: true to false for it to work. On the other hand, if you have that many problems and all you need is to read plain text traffic, there are better solutions. Okay, maybe MITM has been working fine for a long time, but sometimes there are some voices in your head, sometimes even if it's not the best option that fits your problem.
It is obvious how we can read plain text from TLS in a MITM scenario. If we can make the application talk directly to the API, do we really need to crack the password to make the text clear? The old people here know that there is an option in Wireshark that breaks the SSL / TLS password when the private key is given to the server certificate. But this also has two main problems. First, it is in the nature of pentest projects. The second is about the year 2020. To mention the first one, in most pentest projects, you don't get the server's private key for various reasons. The other problem, even if you do, is that it is progressive in favor of workarounds such as RSA-based key exchange, traditional (DLP-based) and elliptical curve (EC) Diffie-Hellman (DH), where passwords are encrypted using the public key in the server certificate. The reason, of course, is exactly why this RSA key exchange approach can work. The actual hackers can easily collect TLS traffic and subsequently retrieve the private key. Therefore, today's applications recommend Key exchange algorithms with Perfect Forward Secrecy (PFS).
There is another way though: The crypto keys in the TLS session derive from the Pre-Master Secret, which is located at both ends of the secure channel. And since we control one of these ends, it can be used to extract clear text from TLS traffic. Fortunately Wireshark also supports this way, by specifying the file that contains those passwords in a specific format. The best part is that this file is in the process of reading by Wireshark. Thus, the password of live network traffic can be instantly cracked if the file is also written as soon as those passwords are available. Since it is not something everyone uses in Wireshark on a daily basis, I leave a screenshot below that tells you where that precious input field is, which will allow you to specify an SSL key log file.
Browsers like Mozilla Firefox have a feature that allows you to download such files for debug purposes. And for Android, there is a great project by Saleem Rashid called frida-sslkeylog. Using Frida with convenient OpenSSL (or BoringSSL) functions, you can instantly extract and extract passwords from the running application. For this, the only condition in the device part is Frida, you can install it on a rooted device with the Android instructions in the official ********. If there is a problem preventing the app from running on the rooted device, or anything that might prevent the above method, there is one more alternative method of injecting Frida Gadget into the app. Thus, it works in the same process, preventing the need for root. The easiest way to do this is to use Objection's patchapk command.
This method gives us good decrypted traffic on Wireshark, which is good on its own but for us it's just the beginning. If you want to use this information in the API itself, we need to find a way to bring these request-response parts to Burp so that we can use tools such as Repeater, Scanner, and Intruder. So this is the general picture of what we want in general:
From what I learned from my mistakes, I looked for an existing solution. But the only reasonable was the Pcap importer running at the PCAP level. But what I needed was high-level, pre-processed information like HTTP requests cracked in Burp (ex-HTTPS).
Luckily I remembered using PDML for my other previous network protocols reverse engineering projects. PDML is an XML-based export format from Wireshark, and it also contains all the parsed information available in the lowest panel in the GUI, which is part of the tree structure. Using this format, most of the work is done in Wireshark, for example detecting HTTP messages and associating requests and responses, parsing URLs, etc.
It may seem a little difficult to parse at first, but it turns out that the main useful things were in these two parts:
The attributes called - show included strings parsed like integers.
Properties called value contained raw (but in clear text) bytes encrypted using hexadecimal numbers, and the request and response body was reconstructed from them.
The last big challenge was performance. These PDML files would quickly become massive, as they contained every bit of information relevant to all packages. Most people trying to deal with XML parsing would choose the DOM because it would parse the entire ******** into an in-memory tree that can be passed through a random pattern with tools like XPath. In that case though, this would lead us to a huge delay for both the initial decomposition and the tree structure stage, and then it would pass through this structure. The logic was written using a streaming (SAX) parser that runs the event for each structural element. So, instead of a hidden tree, I could create a private structure that accommodates only what I need. It consisted of storing requests indexed by package numbers. Then, when the response is found, it can be accessed at O (1) time, and HTTP messages can be added to the lists with the response. This made things a great deal faster.
There is a new plugin called PDML importer on GitHub under the MIT license. You can fulfill your pull requests.
Link: https://github.com/silentsignal/burp-pdml
Below is a screenshot of the plugin.
Of course, this is not one and the best approach for all scenarios, as there is no method that fits every scenario.
Source: https://blog.silentsignal.eu/2020/05/04/decrypting-and-analyzing-https-traffic-without-mitm/
Source: https://www.turkhackteam.org/kripto...rafiginin-sifresini-cozme-ve-analiz-etme.html
Translator: @Thekoftte
Moderatör tarafında düzenlendi:
