Nokia XSS + Nokia Spoofing = Nokia Lumia

Back in February I heard Nokia were starting a new bounty program. I didn't think it would be that hard finding a few holes and getting me a shiny new Nokia Lumia. Turns out I was right :)

This post is about a rather boring XSS and some email spoofing lolz that I worked on back in February.

The XSS

The Nokia developer site contained a search feature that didn't properly encode user queries before displaying them on the results page.

Here's a screenshot of the XSS:

And lack of HttpOnly meant it was trivial to steal the session data:

Bounty time...right?...wrong!

So I reported the issue and waited for a response. Fair play to Nokia they fixed the XSS pretty quickly. However when inquiring about a bounty I received the following response:

Oh great, so no bounty for XSS. Taking a closer look at the Nokia vulnerability disclosure policy:

Reward & Recognition
Nokia will recognize and reward researchers based on the vulnerability criticality and vulnerable service priority. A Nokia internal committee will review and determine what type of recognition is given to the researcher when applicable. Our most common recognition is our Hall of Fame.

Hmmm ok, but the Nokia engineer did mention a bounty was possible if I could find something more interesting...

Any ideas? Oh yeah that blog post I wrote...

I'd recently been looking at the dangers of email spoofing (see post here: http://pwndizzle.blogspot.com/2013/03/targeted-email-spoofing-and-alexa100.html) and seen how many companies weren't aware of the risks. If Nokia were vulnerable this would make a great POC and hopefully get me my Nokia Lumia!

In a nutshell, many SMTP servers on the internet today don't enforce spoofing mitigations. Reverse-DNS checks, SPF, DKIM and filtering of external emails using your company address, can all help mitigate spoofing but in a lot of companies they just aren't strictly enforced. Lucky for me, Nokia was one of those companies :)


Lets Get Spoofing!

Spoofing is trivial to perform. Simply connect to the companies SMTP server, send your "mail from", "rcpt to", your message data (with headers) and you're done. A little something like this:

As can be seen above, to demonstrate the impact I sent a message from the Nokia president Stephen Elop to the Nokia engineer. So from a few simple SMTP commands we get a spoofed email that says:

The security engineer at Nokia was rather surprised to see a message from the president and after discussing the attack/mitigations I finally got my reward, a new Nokia Lumia, wahey! :)

For more details on how to spoof your favourite CEO or how to protect your own CEO, check out my previous blog post here:
http://pwndizzle.blogspot.com/2013/03/targeted-email-spoofing-and-alexa100.html


Final Thoughts

Bug bounties come in all different shapes and sizes. Nokia might pay a little less than the average Google/Facebook/Paypal bounty but then again Nokia aren't doing all that well financially nor are they as such a juicy target as Google/Facebook/Paypal. So to offer a bug bounty at all is impressive enough!

Thanks to Nokia for their swift responses/fixes and for the new phone :)

Pwndizzle out.

On the Meraki Bounty Trail

Back in March Meraki started a bounty program. I ended up digging around the site in April so missed all the easy XSS but still came across a few interesting bits and bobs.

Today I'll talk about six issues that caught my attention, starting with the mediocre leading up to the slightly more interesting.


#1 Missing HTTPS

No SSL on the tools login page meant any attacker could sniff your credentials right out of the air, who knows maybe even when you're using your own Meraki wifi.

#2 Sensitive File Disclosure on Partner Site

It's always amazing what Google can uncover. In the case of Meraki it turned out that a number of potentially sensitive files for partners/resellers were (still are?) accessible through Google. Want to know how much a Meraki AP really costs and what cut your Meraki reseller is taking? Easy just Google for it!

Needless to say these kinds of files shouldn't be publicly accessible.



#3 Lack of Brute Force Mitigation

Anyone was free to guess user passwords an unlimited number of times without experiencing any kind of lockout or captcha. In the screenshot you can see on my 123rd attempt i guessed the correct password (meraki123) and received a 302 indicating a successful login.

It was quite funny that when I (and presumably other people) reported this to Meraki, they replied that they didn't regard this as an issue that needed fixing! I know, it's hard to believe. Luckily they had second thoughts and a few days later had implemented a captcha check on five failed logins.


#4 Information disclosure when adding device

When playing around with my test account I found I couldn't test all the features as I didn't actually have a Meraki wireless access point. Looking over the "Add Access Point" form I was thinking I could maybe brute force the serial/order number field.

The problem was I didn't know the length or structure of the numbers. So I thought why not Google it? Again Google to the rescue and after a little searching I found a blog post that actually contained device serial numbers!

Inserting these numbers I received an error message that the access point was already in use. Interestingly though the error message contained the email address of the user who had registered the access point! Say wut?!

So now we can target that user with some clever meraki-based spear-phishing, compromise their account and then go on to potentially compromise all of their wifi users! Nice.

And now for the catch....a twelve character serial containing letters and numbers (12^36) isn't remotely bruteforceable. Even if Meraki produced a few million devices its still going to take a long long time to guess valid serials. So it's low risk?

Well the other possible attack vector here would be the order number, if Meraki are using sequential order numbers you could potentially dump the email address of every user. Sweet! :)


#5 Splash Page Javascript Inclusion

Meraki allows you to define a splash page, which is a page that users will be shown when they first connect to your wifi. To create your page they provide a HTML editor but prevent the inclusion of sensitive HTML, e.g. script, iframe, embed, event handlers etc.

After a little playing around I found they had missed style attribute filtering, allowing Javascript inclusion.

<img style="xss:expression(alert('LOL'))">
Or:
<style type="text/css">BODY{background:url("javascript:alert('LOL')")}</style>

For any determined bounty hunters out there, I would definitely recommend taking a look at the editor as I'm sure there are more holes in it :)


#6 Mobile Site XSS

The final issue was in the mobile site. Burp flagged this up as XSS and on closer inspection it turned out to be a json callback parameter being echo'ed back unencoded (allowing us to insert <script> etc.).

However in Chrome and Firefox this was not actually exploitable as they correctly enforce the json content-type sent from the server meaning the Javascript isn't rendered by the browser.

After a little digging I found the following:

https://superevr.com/blog/2012/exploiting-xss-in-ajax-web-applications/

I never knew if you renamed the file extension IE would ignore the content-type sent by the server. So by adding a .html to the url IE would render the page as HTML, which meant XSS!

Annoyingly, it turns out the IE XSS filter doesn't take any prisoners. After a lot of playing around I just couldn't evade the filter and Microsoft appear to have fixed the same domain trick mentioned in the the post below:

http://nomoreroot.blogspot.co.uk/2008/08/ie8-xss-filter.html

So the XSS was dead in the water (at least in IE8/9/10). Microsoft got something right!

Final Thoughts

Rather simplistic information disclosure/account security issues can seem trivial but under the right circumstances they can cause serious damage. And the funny thing is that these are the issues vulnerability scanners will often miss.

Today's security tips:

• Always use SSL
• Make sure your directory permissions are correct
• Always use brute force mitigation
• Don't disclose user information in error messages
• Don't allow users to insert HTML
• Always html encode user input when outputting it on your page

Questions, comments, corrections and IE XSS filter bypasses are always welcome :)