Fix Your Management Interface

Lets state some facts:

  1. Most of your appliances (Firewalls, ID(P)Ses, Proxies, Email Gateways, Storage Devices, etc) have web interfaces for management
  2. Most vendors recommend that these web interfaces should not be accessible to the public (except those vendors that provide their interfaces over the Internet in some form of *aaS)
  3. All modern browsers provide a function to store your passwords

Now lets make some assumptions:

  1. Many admins are lazy (or just not aware of the risks of these types of interfaces and auto password fields)
  2. Most developers developing these backend web management interfaces are NOT accounting for external threat agents (i.e. – the only people who can access this interface are internal resources)
  3. Many developers are not mitigating against common web attack vectors due to the above


I believe that most appliances are vulnerable to common Cross Site Request Forgery (CSRF – Yeah, It Still Works) attacks. I don’t mean that they’re partially vulnerable by implementing basic (and known to be ineffective) referrer checking, I mean they’re probably not even doing the simple stuff like ensuring that parameters received are from POST requests as opposed to GET requests. I believe this so much that I even offered pints* out to those people finding interfaces without these weaknesses.

We’ve done test after test of appliance interfaces and it’s not even a surprise any more when you find non-idempotent GET methods that simply require an appropriate “Authorization” header to perform functions such as adding a new admin user, resetting the device to factory defaults, or simply shutting down the system. More often than not you don’t even need to lure an administrator into clicking anything, you can just include these GET statements in a bunch of webpages or emails (or RSS feeds) under the clever disguise of an <img> tag.

So come on appliance vendors, pick up your game. Stop trying to imagine that there is a ‘gator-filled-moat between the administrators accessing your products and the nasty web. The browser is the OS, and the people managing your appliances have Twitter and Facebook and God-knows-what open on different tabs. Look, we’ve made it easy for you – just have a read of the OWASP Cross Site Request Forgery Cheat Sheet. Even a little double-serving of Cookies can help (nom nom). Better yet, if you’re building a web management interface for your appliance utilise pre-built security controls, such as OWASP’s Enterprise Security API (ESAPI), this library even comes with FREE anti-CSRF methods? Amazing!

*Nb: You have to come to Perth to collect :)

(This interface goes from Shotgun to Hoover! – Which do you want?)

Inaugural Perth AISA Technical Security Day

Today we announced our involvement with the Perth AISA Tech day:

Hi all,

Christian and I will be presenting a workshop on behalf of OWASP at the
Perth AISA tech day on Friday the 4th of December.
More information on the tech day (including online registration) can be
found here:

OWASP members are able to attend our session (and the other sessions) for
free. However, if you want free lunch and post-event drinks, you’ll need
to be an AISA member.

Hope to see you there.


I’m really excited to be participating in the workshop and I’m sure that for the price you’re paying ($0) you won’t get better value for a technical, hands on web-security session. The hardest decision you’ll have to make is either attend the OWASP session or the Stratsec session (which focuses on building/designing secure web apps, whilst we’re focusing an assessing them). If only these were back to back as opposed to at the same time! Maybe next time this will be better.

If you have any questions jump on the Perth OWASP Mailing list or shoot me an email, twitter or leave a comment.

Self-signed Certificates in Burp

I’m happy to announce that I’ve got a guest blogger for the day. My guest blogger is David, a colleague of mine from work. He and I have been working together for about 2 years now and we’ve had some pretty interesting times.. so here it is:

Christian and I were recently asked to perform an application security assessment on a .NET smart-client / web services application (What is a smart-client you ask? -c). This required a bit of hackery with certificates to get the traffic flowing through Burp. We figured this would be worth sharing, if only to save others a bit of time in future. So, I get to be guest blogger for the day.

The smart client was hardcoded with the address of the web services providers. Initially it seemed that this might require the intercepting proxy to run as a reverse (or transparent) proxy but it turned out that the app honoured IE proxy settings, so this was not necessary.

Next, we found that the client was failing to validate the SSL certificate provided by Burp, and there was no option to ignore the cert error and continue. To get around this, we generated a self-signed certificate for the correct server name, then this cert was loaded into Burp and imported into the certificate store on the client.

The Short Way

To generate the self-signed cert…

openssl genrsa 4096 > server.key
openssl req -new -x509 -nodes -sha1 -days 1000 -key server.key > server.crt
(Common Name = FQDN for the SSL server)
openssl pkcs12 -export -out server.p12 -in server.crt -inkey server.key

To load the cert into Burp…

Choose "Proxy" tab.
Choose "Options" tab.
Select the active listener.
Click "edit" button.
Tick "use a custom server SSL certificate".
Specify path to server.p12 and password.
Click "update" button.


To load the cert into the client’s trusted store…

Copy either server.crt or server.p12 to the client machine.
Right-click, “Install Certificate”.
“Place all certificates in the following store” / “Trusted Root Certificate Authorities”

Restarting the smart client, it connected through Burp to the web services provider with no further problems.

A Slightly Longer Way

The above was sufficient for our purposes, but what if the smart client was using web services from a number of providers, all requiring SSL? So long as all the WS providers could be wildcarded to the same domain name, the above methodology can still be used with a couple of tweaks.

Or, what if you frequently needed to change the cert presented by Burp, but didn’t want the hassle of having to load a new certificate into the client machine each time.

First, generate a self-signed CA certificate…

openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 1000 -key ca.key -out ca.crt
(Make the CN whatever you like... 'App Testing CA')

Import the CA cert into the client machine as before. You shouldn’t need to repeat this step ever again; any certs subsequently signed by your CA cert will validate.

Then, generate the wildcard server cert, signed by your (self-signed) CA cert…

openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
(Make the CN something like... '*')
openssl x509 -req -days 1000 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
openssl pkcs12 -export -out server.p12 -in server.crt -inkey server.key

Finally, load the server.p12 file into Burp like before.

Notes, restrictions, the potential for mischief…

This all got me thinking that it might be nice to build a wildcard cert for something like “CN = *” that would be valid for any SSL site I might visit through Burp. This would save some time wading through pages of validation errors when testing browser-based apps. It would also present some interesting possibilities if one could, say, surreptitiously load a cert into the trusted store on a client then transparently proxy their web traffic…

Unfortunately (or fortunately), it turns out that this is not possible. Wildcard certs are only good for one level of wildcard. * is good for and, but not for In the same way, a cert for “*” would presumably be good for “com” or “au”, but not or Foiled by the ITU-T. :-)