Years ago I learnt docker basics because I just couldn’t get that $ruby_tool to install. The bits of progress I’d make usually left my host’s ruby install in shambles. With docker though, I had quick reproducible build & run environments I could clean up easily without leaving a mess behind. The more I used docker, the more I’ve come to love it, and today it’s become a natural part of my daily workflow. It’s not without its flaws though, so in this post I want to show you an experiment of mine where I tried to write a docker pwn tool manager. A “docker-compose for hackers” if you will, called dwn (/don/). You can find it here: https://github.com/sensepost/dwn.
In this post I want to share two things. First, a quick primer on how you would you go about navigating the source code when contributing to objection, and secondly an application specific proxy feature I added to it. Introduction While on holiday I wanted to look into a certain mobile application that dealt with medical information. I was mostly interested in the data that was sent and received by the application so this meant proxying the traffic into Burp. I did not have a test device with me, so I had to use my personal device. This being my personal device meant that once I had the proxy set, certain applications would cease to function normally (especially those with SSL pinning) as Burp was in the middle.
It’s too easy when hacking, to assume something is invulnerable and not interrogate it. This was the case for me when it came to Duo’s two-factor authentication solution. However, we were able to discover two variants of the same 2FA bypass. These rely on redirecting a victim’s push notifications to an attacker-controlled device, to authorise access to a victim account. Interactions with Duo had this fixed in record time, and were easily some of the best vendor/researcher interactions we’ve ever had. If you’re looking for their technical guidance around this, you can find it here.