While preparing a security awareness demo, a friend of mine and I decided to work with an intercepting proxy. This is what we did.

The situation

A friend of mine (let’s call him Roger) and I were asked to do an awareness demo in front of the upper management of an international company. It should contain something which could happen to them and it should not be too technical.

We chose a scenario with mobile devices. Something we hoped everybody would understand and could relate to his or her own situation.

Scenario

At the beginning of the demo, our demo user got an email from the computer support team stating that he should install a configuration (policy) file or that he won’t be able to synchronise with the corporate mailserver anymore.

That policy file was signed, contained all the elements of said company, but was signed by an untrusted CA. While in the demo the user could clearly see that, he installed the policy file anyway.

The policy file contained some certificates (for the ssl bumping) and a VPN configuration. After installing the certificate, the demo iPhone automatically connected to the VPN endpoint on our server.

The server was configured so that every http based connection from the VPN was routed over our local burp proxy before it was proxed to the proper system. The local burp proxy had two important configurations.

First it broke SSL connections with the feature called ssl bumping. When ssl bumping, the burp proxy breaks the secured SSL connection and presents the client a rewritten SSL server certificate, containing all the original information, but signed by the burp proxy itself (which is also why we installed a certificate together with the VPN configuration on the iPhone).

Second we installed an icap service into burp. Burp has the problem, that it only can log meta data. But we wanted to whole traffic data. we made use of icapjs, a very lightweight icap service written in node. icapjs has no real functionality, it can only pass on whatever it gets and log it meanwhile.

Every connection, after being bumped and logged, was then forwarded to its original destination.

All the logs were sent to a Splunk backend for further analysis.

So when the demo user finally installed our policy, started the webbrowser and surfed to gmail, our Splunk backend instantly notified our hacker of a new userid and password.

Our hacker used then these credentials during the demo to learn even more about his demo victim. Thanks to that GMail login the demo hacker was able to get at even more data through g+ and such.

Used software

At the end, we had this setup: - iOS client with user installed configuration file. - Strongswan based VPN to route all traffic over. - Squid Proxy with SSL Cert Bumping. - nodejs with icapjs to log all traffic going through burp. - Splunk based back-end to analyse logs and as a nice hackers frontend.

Why that setup

We used several different setups and at the end decided on the above. We wanted to have a setup where it definitely was the users fault that he was compromised. And we did not want to have some magic going on but for the participants to understand what they did wrong and what consequences one wrong can have.

We played around with a WiFi based approach instead of the VPN based one but finally decided on the VPN since it was much more flexible (although a lot less convincing when you know what to look at on an iOS device).

We also played around with several VPN tools and finally decided on Strongswan since it was the most robust and most painless to install and configure.

to be continued…