tl;dr In this blog post, I will share insights I learned while researching the Flutter framework and the reFlutter tool. It will dive deep into Flutter’s architecture, some of its inner workings and dependencies, and finally, drill down into the SSL verification logic. The post will end by exploring what the reFlutter tool actually does and my attempts at replicating the same behaviour with Frida.
Note: If you are in a pinch on a mobile assessment where the application uses Flutter, the reFlutter tool is a great option. This blog post does not advocate that you need to use Frida logic. It is simply an exercise in seeing whether a Frida equivalent may exist.
Abuse of Active Directory Certificate Services (AD CS) has become a staple of our internal network assessment methodology. In fact, I can’t recall an internal I’ve done in the past two or more years that didn’t feature ADCS abuse in some manner or another.
We can all agree that when AD CS abuse works as intended, it is fantastic. As Tinus Green stated in his BSides talk, AD CS abuse is the teleport scroll to the top of the mountain. It allows us to rapidly gain high-privileged access to the domain and, from there, can target more lucrative objectives.
On a recent internal assessment, we ran into a problem. While holding low-privileged access to an internal Windows host, we realised the software on the host was communicating to a remote API endpoint over HTTPS. However, the remote endpoint was enforcing authentication using client SSL certificates.
Normally, the above scenario is easily fixed by exporting the local client SSL certificate from the host and importing it into either Burp Suite or Postman. In Burp Suite, when you want to use a client SSL certificate, you must manually load the certificate and private key into it. This implies (on Windows, at least) that you’ll need to export the client SSL certificate. However, this is only possible if you hold appropriate permissions to the certificate and its private key and it allows exporting.
A few months ago I was exploring the write-ups and video solutions for the retired HackTheBox machine – Quick. It’s during this exploration that I came across HTTP/3. For those that are not aware, HTTP/3 is the upcoming third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, succeeding HTTP/2.
Now, to be honest, my knowledge of the Hypertext Transfer Protocol (HTTP) has mainly been restricted to the HTTP/1.0 and HTTP/1.1 specifications. In particular, as that is the main specifications of the protocol we (security pentesters) observe in Burp (our intercepting proxy) when assessing web applications. We are familiar and comfortable seeing HTTP GET/POST requests and the myriad of responses that can be received (e.g., 400, 503…)