It's 2023 and certificate validation is still hard (Bounty incoming :D)
Just recently I watched this DEFCON talk by Aapo Oksman:
In his talk he describes on a couple of examples that validating TLS certificates improperly is still a big thing even in 2023. He started his journey in 2020 and found more than 80 vulnerabilities on Android, iOS, Windows, Mac, game consoles, IoT, etc ... according to his presentation. Within the 10+ assigned CVEs are some bangers. For example CVE-2021-31980 describes a RCE in Microsoft Intunes. A system used to manage devices in environments of all sizes allowed him to execute code on that managed endpoints as SYSTEM. So only by a proper network position he was able to take over everything that went through the man in the middle position, just crazy.
During the time I watched his presentation, I remembered myself of many times I was analyzing a fat client or mobile app and tried all the different test cases to analyze the TLS implementation. Checking the certificate pining, testing for arbitrary trusted CAs, testing against self-signed ones. Shortly, all the steps you could easily achieve by using any of the well-known proxy apps like burpsuite, owasp zap, mitmproxy, caido (go on and support them) and so on.
However, testing for stuff like cloning the complete certificate chain from a custom, untrusted CA, have been tasks that sometimes fell off the test scope.
Luckily, Aapo exactly built a tool that can achieve this task and much more. Briefly, he built another man in the middle proxy that will automatically intercept all TLS connections and replace the real certificate by one created by a number of test cases. For a complete overview, I recommend watching his talk.
I tested certmitm locally and it's exactly what I was looking for since years :-)
So, I am planning to use it for all upcoming TLS tests. And, if you are still reading (thank you) I will give you the chance to also use my environment.
I created an environment just for this task. As entry point I choose a good old OpenVPN connection. Just download one of the profiles (3 public profiles for 3 simultaneous VPN connections are available) from the certmitm storage location and import it into your OpenVPN compatible client on your device. Afterwards, every connection to the well-known TLS enabled ports are intercepted and put under test for the test cases provided by certmitm.
So, normally all your mobile apps or fat clients should stop working right now because all TLS connections are going to be intercepted with rogue TLS certificates, right? But now the fun just begins. As of writing this post, I was starting the OpenVPN connection on my daily phone and opened some apps in an arbitrary order. First, I saw exactly what I expected. Endless TLS handshake and connection errors.
What you see here is the stdout log output form certmitm. It's publicly exposed on a https web service to easily monitor the testing activities. Once in while you will see log output printed in red, that's when a test case was successful to establish a TLS connection and intercept what's inside.
Interesting, a call to /api/accessToken has been successfully intercepted, what could possibly go wrong here :-D I quickly realized, the app I just opened, was part of one of our #karfejaeger BugBounty Live-Events and therefore has a program available, where I can try to report it to. TLDR; The issues discovered by certmitm are real, but getting the issues addressed and understood by the triagers might not be always easy, as Aapo also describes in his talk.
I had a funny moment, when I checked which service is affected here:
After the testing you are able to fetch all your successful intercepted connections at the certmitm storage location. There is a sub directory for one of the three profiles.
certmitm storage location:
certmitm live view: https://terminal.kaeferjaeger.gay