How, and Why, to run a Man-In-The-Middle Attack on Your Own App

Wait, what? Why would I want to do that?

Lots of good reasons:

  • If you want to see the actual traffic you’re sending over the network, for debugging purposes.
  • See what third-party libraries might be sending, and how they’re sending it.
  • Demonstrating how trivial it is to do so, as a pre-condition for mitigating it.
But I’m using HTTPS, so I can’t MITM my traffic.

id45(side note: any day I can use an Independence Day GIF is a good day)

Yes, by using HTTPS, a random third-party can’t decrypt your payloads.

https-side-by-side-marked

But while HTTPS protects you from a third-party listening in to your traffic, the endpoints are still vulnerable.

alice-bob-carol-marked

I don’t want to get sidetracked with a detailed explanation of how HTTPS protects you, so here’s the short version: First, you verify the server’s identity using the Public Key Infrastructure. The server presents a certificate saying “I am example.com”. That certificate has been signed by a trusted third-party, called a Root Certificate Authority (CA). That signature says “I am Trusted CA, Inc. and that really is example.com”. Your OS has a couple hundred root CA certificates installed, so it can be sure that it’s really Trusted CA, Inc. that signed the certificate. (In reality, the server’s certificate has actually been signed by an intermediary CA, which was in turn signed by the root CA. We call this the chain of trust).

After you’ve established the server’s identity, you exchange public keys, and can encrypt messages to each other that can only be decrypted by the known party – no third party can listen in to your encrypted messages and see what you’re saying.

Since we can’t decrypt your HTTPS payloads, we’re going to attack by making a fake root CA and installing it as one of the device’s trusted roots.

Isn’t that hard?

Nope. We’re going to install a tool that handles it all for you.

Step 1. Install mitmproxy on your dev machine.

Step 2. Run mitmproxy on your dev machine. Down in the bottom-right corner, it’ll tell you what port it’s running on. Also, make note of your dev machine’s IP address.

Step 3. Connect your Android (or iOS or whatever else) device to the same network as your dev machine, and in your network settings, set your proxy to your dev machine’s IP address and the port that mitmproxy is running on. The exact details of how to do this vary by OS version, so’ll have to google that for yourself.

Step 4. On your target device, open a browser and go to (mitm.it) This magic domain will help you install mitmproxy’s certificate as a trusted root CA on your device.

Step 5. Run your app, and watch mitmproxy dump all of your traffic.

mitm-https-cleartext-marked

So what do I do now?

You pin your certificates. I’ll follow up with another blog post soon to help you do that (edit: follow-up post on certificate pinning is up). (Good news: it’s pretty easy)

Also, you learn a little more about HTTPS. Knowledge is power.

Author: jeb

Views expressed here are my own and do not necessarily reflect the views of my employer.

One thought on “How, and Why, to run a Man-In-The-Middle Attack on Your Own App”

Comments are closed.