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... '*.yourdomain.com')
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. *.yourdomain.com is good for aaa.yourdomain.com and bbb.yourdomain.com, but not for some.thing.yourdomain.com. In the same way, a cert for “*” would presumably be good for “com” or “au”, but not mail.google.com or www.ebay.com. Foiled by the ITU-T. :-)

“Hey girl in your eyes
I see a picture of me all the time
(step!)”

Which is roughly how this new mechanism works to provide a second factor of authentication using an out of band mechanism. After submitting a payment, a “Cronto Visual Cryptogram” (a picture) is displayed which has to be decrypted by your mobile phone (or other device) providing you with a code you then have to enter into your payment page.

Similar to SMS 2FA (or at least well implemented SMS 2FA), the “cryptogram” can include other textual information such as payment details. This should hopefully prevent fraudulent transactions from being “authorised” via the channel, such as those generated by a “man-in-the-browser” trojan.

Whilst I haven’t really had time to process the benefits and disadvantages (mobile phone compatibility?) of this mechanism I’m quite happy to hear that innovate research is still being done in this space. Interesting…

(Thank you SBN feed for bringing this article to my attention!)

I just added the new “SBN Lijit” search form over there on the right. Had a quick play with it, seems pretty good at providing a site-wide search for my blog, and for the entire SBN community.

Alan has more information here.

Whilst phishers, or at least the guys who make and distribute the kits, have been relatively good at keeping their methods up to date with changes in Internet technology (Twitter phish anyone?), it’s still not uncommon to find the odd scammer who runs a phish site like we’re still the 90s. You can sometimes tell these guys apart from the rest because of their general lack of HTML and CSS knowledge.

A couple of the tell tale signs I’ve noticed over the past year or so is things like their inability to recreate a HTML button which uses CSS to use a custom image. For example, where the HTML is similar to:

<input type="image" class="loginbutton" src="blank.gif" style="height:30px;width:80px;" />

And the CSS is similar to:

.loginbutton {background-image: url(actualbutton.jpg); background-repeat:no-repeat;}

Because this prevents the user from right clicking the button and choosing “Save Image As..”, you’ll find that instead of going through the CSS to find where the ACTUAL button image is (actualbutton.jpg) they’ll take a screenshot of the page and recreate the image from there.

Another sign is the “Mark of the Web” (MotW). The MotW was created back in the days of IE 4.0 as a mechanism for a HTML page to run in a different security zone then what it actually is. For example, if you want to test a HTML page locally, but make sure it runs in the Internet zone you can set the MotW within the HTML page to “about:internet“. An example MotW is:

<!-- saved from url=(0022)http://www.google.com/ -->

The #### between the brackets indicates the length of the following URL.

Now you might be wondering whether or not this allows a page out there on the Internet to run in the “Local” security zone in IE, the MotW is configured such that it will only run the HTML in the prescribed MotW zone if it is more restrictive than the “Local” security zone.

So what’s this got to do with phishing? Well, when you save a page in IE, it inserts the MotW into the saved HTML as the URL of the site. So for example, if the login page the phishers want to impersonate is http://www.twitter.com, then the saved HTML would include

<!-- saved from url=(0023)http://www.twitter.com/ -->

Of course, when they setup their phishing site the URL won’t be that, it’ll be something like http://i.hacked.some.joomla.server.com/images/twitterphish/index.html. Naturally this URL does not match what is specified in the MotW within phished content at index.html.

Surely you’d think that the guys setting up these phishing kits would look at the HTML and remove these sorts of things? Sometimes yes, but sometimes no. Often the only thing they have to change is where the login form POSTs to. So instead of POSTing to itself, they’ll then change their phishing content to post to some mailer script at “mailer.php” or whatever.

As far as I know, none of the browsers look at the MotW for anything, except IE which looks at it for security zones. I’m unsure if any of the Google or Yahoo bars review the MotW for any discrepancies. Whilst not entirely accurate, and likely to lead to some false positives I thought it was worthwhile to look at anyway. This is where “Mark of the Phish” (MotP) was born from.

MotP is a Greasemonkey script (that means Firefox only folks!) that looks at the MotW tag within HTML documents, and if it does NOT match the current URL pops up an alert asking if you want to continue. This is primarily a proof of concept to determine if this type of early detection would work at all in the real world. It’s difficult for me (or even perhaps anyone who reads this?) to tell, because as professional security folks we’re tuned to detect a dodgy site, regardless of what’s included within the HTML, MotW or not.

In an ideal world this functionality could be built into anti-phishing toolbars, or perhaps into the browser itself. I’m also aware that this is only a temporary detection, you would assume that Darwin’s theory of natural selection would eventually weed out all the phishers creating useless phishing kits, and slowly but surely the guys making the effective kits would get better at reviewing their HTML before rolling it out. Until that point though, perhaps every little bit helps. Tell me what you think.