No, I’m not trying to re-invent the MitM initialism. However, I do want to detail setting up the Mallory intercepting proxy for use in mobile application assessments. Mallory is a useful tool for intercepting non-HTTP traffic. On a recent engagement, I had a need to proxy IMAP/S traffic to determine how the mobile application I was testing handled messaging. Alas, trusty Burp suite couldn’t help me here, so I turned to Mallory, as Mallory can intercept and tamper with non-HTTP protocol traffic.
I had the need to proxy traffic from Burpsuite to another proxy during web app testing this week. There are a few ways to do this, but this method was the easiest since I already had Burpsuite’s TLS certificate installed. For more information on this, see the Burpsuite help. To configure an upstream proxy for Burpsuite, such as OWASP ZAP, follow these steps:
First, configure your upstream proxy that will sit between Burpsuite and the web application to listen on a different port since they both bind TCP 8080 by default. Here I’ve configured ZAP to listen on port 8082 :
Then, edit Burpsuite’s configuration to point to the upstream proxy. Here, I set a wildcard destination host using ‘*’ and set the proxy host to ‘localhost’ and proxy port to ‘8082’:
This post was inspired by a client who came to me and said “I do not understand all of these findings, can you explain them to me?”, referring to my web application penetration test deliverable. We spoke for an hour, as I described the various findings to him. I corrected him when his understanding was shaky, and I confirmed where his understanding was solid. He had a development background, and was studying for a security certification, but he was managing a large security project for a well-known company and I was surprised to learn he was a security newbie. At the end of our conversation, he thanked me and said “Now I understand, and I’ll make sure my manager does as well!”
This is what we should strive to hear from our clients.
Adam Shostack recently published a great read on why the phrase “X is Security 101” is a hindsight-focused and generally not very useful statement.
I completely agree with his point that people who are (or pretend to be) security experts need to do more than flippantly make this remark when discussing the latest security story. [I think this is part of a larger, symptomatic issue the InfoSec community has, but I’m still formulating enough thoughts on that to publish a post on it].
Mr. Shostack, at the (near) start of 2015, I would like to see your 101 list and raise you mine:
- Use two-factor authentication for each online service you make use of – at least the critical ones
- Never reuse passwords across online services.
- Corollary to the above: use a password manager like 1password, lastpass, or keepass
- Be careful what you post on Social Media
- Corollary to the above: always be sure your Social Media preferences block sharing with anyone other than your friends
- Always inspect links in e-mails – advice I’ve been following since at least 1996
What are your Security 101 items?
On a recent engagement I supported the lead by developing a PowerShell payload for a RubberDucky. The gist is that it will run a handful of standard Windows commands and then e-mail the results to a specified address. It proved to be very helpful and I’ve included it below with comments – here’s a present from penetratio.io: