Wednesday, November 11, 2015

Decrypting & modifying encrypted web data on the fly with Burp Extender

Today I was auditing a mobile app, and found out the web request & response was encrypted.




























Luckily, it was fairly trivial to find the encryption scheme and elements from the decompiled java code.




























It uses AES in CBC mode with PKCS5 padding, with 16 NULL bytes as IV, and a hardcoded Key. :)


After a few moments, I was able to make a quick & dirty python script to decrypt encrypted messages.
















I started modifying parameters and went through the usual webview based mobile app auditing routine, but after some time, going back and forth between cmd.exe & burpsuite became too cumbersome.

So I thought, why not integrate the decrypt/encrypt python script into burp suite and inspect/modify parameters on the fly?

At first, I thought of creating a script for fiddler since I hate java and initially thought I'd have to make a burp extender plugin in java. But after realizing it supports python, I decided to make a plugin for burp.

There is some past work to reference from, so the learning curve wasn't so steep. After a couple hours I had a working prototype, and all encrypted data was neatly displayed and editable all within the burp proxy screen.













Basically, the plugin parses the post data & URL info, and if it matches a specific condition, creates a new tab called "Encrypted Data viewer & editor" and displays the decrypted data.

It's possible to even modify decrypted data in the new tab, and when you forward it to the mobile web server, the plugin will automatically encrypt the modified data and pack it into post parameters that the web application understands.

The plugin also conveniently integrates into burp repeater, so you can test different parameter modifications with ease.


































All in all, I think burp extender is great for pentesting web based mobile or web apps.
Use it, know it, and get the most out of it. :)

Here's the source code of the extension for anyone who wants to use it for reference.
I deleted all the sensitive info(keys, domain info, etc.) to not expose an attack surface on the app(although the app can't be downloaded without knowing the specific download URL).


https://bitbucket.org/externalist/aes-encrypt-decrypt-burp-extender-plugin-example


On a side note, I deliberately separated decrypt.py and encrypt.py from the plugin source, because burp extender has some issues loading *.pyd files, and the pycrypto module references _AES.pyd.

Tuesday, November 10, 2015

How to fix slow HTTPS traffic in Burp Suite, while inspecting mobile app traffic

Whenever I have to look into HTTPS mobile traffic through burp suite, the traffic is extremely slow and it eats a lot of my precious time. Someone already posted about the issue on the burp suite forum 2 years ago, and the admins said they'll look in to it, but it doesn't seem to be fixed as of today.

In the meantime, here's a quick fix. Just put some other proxy in front of the burp proxy, and the traffic flow is a lot smoother. The proxy could be any tool, be it Zap, fiddler, charles proxy and the like.

So it goes like this.

[ Mobile device ] -> [ ZAP ] -> [ Burp Suite ] -> [ Mobile app server on the web ]

Pretty simple huh?

Don't forget to install the foremost (ZAP in the above case) proxy certificate on the mobile device.

Thursday, October 30, 2014

Dump Android Process Memory

So yeah, I needed a tool to observe android process memory contents, and I stumbled across this post.
Fairly decent tool, but I needed to speed up the process so I added some new features and pushed it to bitbucket.

Usage is pretty simple.

android_dump_memory <dump|show|search> <pid> <start_address> <total_bytes> [search string]


  • dump : Dump memory contents to a file. File name will be in the format ./dump_startaddress_endaddress.
  • show : Print memory contents in the console.
  • search : search for an ASCII/UNICODE string.
  • start_address, and total_bytes should start with "0x", cause sscanf expects it to be there.
Check the repository for more details.

Cheers!! :)