I recently had an assessment reviewing a kiosk application. As I have been working on Mallet recently, this seemed like a perfect opportunity to put Mallet in between the kiosk and its upstream, and see how the kiosk worked. This is a practical walkthrough to help you replicate the setup for your own MitM needs.
The initial state of the network
The end result
Thanks to IoT and other developments, we’re having to review more and more non-HTTP protocols these days. While the hardware is interesting to look at, one can often find vulnerabilities at a network layer too. With many of the non-HTTP-only proxies having fallen out of maintenance or requiring a significant amount of custom code to be written for each unique protocol encountered, we decided to build a tool to make such work easier.
Sometimes on an engagement, you’d like to construct a believable certificate chain, that you have the matching private keys for. An example might be that a mobile app is doing cert pinning, based on attributes of the signing certificate, such as the Canonical Name (CN), serial number, or Issuer, or that you are intercepting an embedded app that only supports a particular algorithm. Whatever the reason, it’s a fairly complicated process if you are not familiar with X509 certificates. And trying to kludge it together with OpenSSL and some shell scripts under time constraints will only make you tear your hair out! While Metasploit can do some of this, it only clones a single certificate and self-signs it, rather than cloning the entire chain. If you need more than that, keep reading!
(If you’re new to this project, read the intro first)
For the past few months, I’ve been working on porting the USaBUSe stack from the custom hardware (AVR+ESP8266) to the Linux USB gadget stack. I wanted to make the techniques more accessible to people unfamiliar with embedded development, and I also wanted to take advantage of the variety of possibilities inherent in having a fully featured Linux environment to work in. I presented this work at HackCon in Norway.
This is a tool that I have wanted to build for at least 5 years. Checking my archives, the earliest reference I can find is almost exactly 5 years ago, and I’ve been thinking about it for longer, I’m sure.
Finally it has made it out of my head, and into the real world!
Be free! Be free!
So, what does it do, and how does it do it?
The core idea for this tool comes from the realisation that, when reviewing how web applications work, it would help immensely to be able to know which user was actually making specific requests, rather than trying to just keep track of that information in your head (or not at all). Once you have an identity associated with a request, that enables more powerful analysis of the requests which have been made.