Troy Hunt's Blog

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

2013-05-20T21:46:00.001+10:00

Here’s an often held conversation between concerned website user and site owner:

User: “Hey mate, your website isn’t using SSL when I enter my password, what gives?!”

Owner: “Ah, but it posts to HTTPS so your password is secure! We take security seriously. Our measures are robust.” (and other random, unquantifiable claims)

Loading login forms over HTTP renders any downstream transport layer security almost entirely useless. Rather than just tell you what’s wrong with this, let me show precisely why this is with a site that implements this pattern:

How’s that for simple?! What people forget about SSL is that it’s not about encryption. Well that’s one feature of secure sockets, another really essential one is integrity insofar as it gives us confidence that the website content hasn’t been manipulated. Anything you load over an HTTP connection can be easily changed by a man in the middle which is why it’s absolutely essential to load those login forms over a secure connection. OWASP is very specific about this in part 9 of their Top 10 web application security risks and summarise it well in the transport layer protection cheat sheet:

The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location.

It’s not just Woolworths doing this, in fact it’s extremely common and you’ll see it on GoDaddy:

On Pandora:

And even on the Financial Times:

I’m calling out these simply because they’re high-profile sites yet they all load the login forms over HTTP and post to HTTPS. Why aren’t they implementing SSL correctly? Most likely convenience; customers can login direct from the homepage and they can have it delivered over HTTP. Mind you Pandora links off to a login page so why they couldn’t just serve that securely to begin with is a bit of a mystery.

So how should it be done? Load the login form over HTTPS, either by linking to a dedicated login page or popping it up in a separate window (although there’s a UX argument against this). Even better, just load the whole site over HTTPS! Yes, there are some barriers to HTTPS across the board (managing certs in web farms, dependencies on assets from third parties, impact on CDNs, etc) but it sure solves the login form issue. Check out Netflix’s approach – straight into HTTPS, job done!

The other issue with the examples above is that potential manipulation of the content aside, missing HTTPS on the login form leads to exactly the discussion this post opened with – users not believing their credentials are protected. All the messaging we’ve been delivering to website users since the early days of the web about checking for the padlock in the browser address bar goes down the drain because it’s simply not there! There’s no assurance that their credentials will be protected and it’s a real shame to dilute such an important security message.

As for how the exploit in the video works, it’s just a simple Fiddler script to inject the keylogger before the body tag closes off. The keylogger itself is over on Google Code, the only code I wrote to incorporate it was the script tags you saw at the end of the video and the “Hack Yourself” website which receives the logged keys. It really is that simple.

Whilst Fiddler is good for demonstration purposes, clearly an actual weaponised attack would work differently but the principle is the same: When unencrypted traffic passes through a node on the network – NIC, ethernet cable, router, proxy, ISP, etc. – it may be observed or manipulated by an attacker. This isn’t theoretical, there are many precedents such as the Tunisian government harvesting Facebook credentials en mass.

This is all a bit odd really, I mean these sites have gone to the effort of implementing some SSL but then blown it by loading those login forms over HTTP. As we saw with Woolworths, posting over a secure connection is completely useless if there’s no integrity in the login form itself, an attacker may already have the credentials by then if the connection is compromised which is the very risk they all implemented SSL to protect from in the first place!

Hack yourself first – how to go on the offence before online attackers do

2013-05-16T06:34:00.001+10:00

The unfortunate reality of the web today is that you’re going to get hacked. Statistically speaking at least, the odds of you having a website without a serious security risk are very low – 14% according to WhiteHat’s State of Web Security report from a couple of weeks ago. Have enough websites for long enough (as many organisations do), and the chances of you getting out unscathed aren’t real good.

There’s this great TEDx talk by Jeremiah Grossman titled Hack Yourself First where he talks about the importance of actively seeking out vulnerabilities in your own software before the evildoers do it for you. In Jeremiah’s post about the talk, he makes a very salient point:

Hack Yourself First advocates building up our cyber-offense skills, and focusing these skills inward at ourselves, to find and fix security issues before the bad guys find and exploit them.

I love this angle – the angle that empowers the individual to go out and seek out risks in their own assets – as it’s a far more proactive, constructive approach than the one we so often see today which is the “after it breaks, I’ll fix it” approach. Perhaps that’s not always a conscious decision but it all too often turns out to be the case. It also advocates for the folks writing our apps to develop the skills required to break them which is a big part of what I’ve been advocating for some time now and features heavily in many posts on this blog as well as throughout the Pluralsight training I recently released. If developers do not understand the risk – I mean really understand it to the point where they know how to exploit it – then you’re fighting an uphill battle in terms of getting them to understand the value of secure coding.

It’s not just the dedicated security folks talking about hacking yourself first. The other day I was listening to Scott Hanselman talking about WordPress security on his podcast and he made the following point:

I know when I’m writing code I’m not thinking about evil, I’m just trying to think about functionality.

Which of course is perfectly naturally for most developers – we build stuff. Other people break stuff! But he goes on to say:

When was the last time I sat down and spent a day or a week trying to break my site?

And we’re back to hacking yourself first or in other words, making a concerted attempt to find vulnerabilities in your own code before someone else does. As Jeremiah referred to it, building up cyber-offense skills for developers. Developing the ability to detect these risks is easy once you know what to look for, in fact many of them are staring you right in the face when you browse a website and that’s what I want to talk about here today.

Let me share my top picks of website security fundamentals that you can check on any site right now without doing anything that a reasonable person would consider “hacking”. I make this point for two reasons: firstly, you really don’t want to go messing up things in your own live site and testing for risks such as SQL injection has every chance of doing just that if a risk is present. The other reason is that by picking non-invasive risks you can assess them on other peoples’ sites. I’ll come back to why I’m saying this and the context it can be used in at the end of this post, the point is that these are by no means malicious tests, think of them as the gateway drug to identifying more serious risks.

This is going to be a lengthy one so let me give you a little index to get you started:

Lack of transport layer protection for sensitive data
Loading login forms over an insecure channel
Secure cookies
Mixed mode HTTP and HTTPS
Cross Site Scripting (XSS)
Password reminders via email
Insecure password storage
Poor password entropy rules
Denial of service via password reset
HTTP only cookies
Internal server error messages
Path disclosure via robots.txt
Sensitive data leakage via HTML source
Parameter tampering
Clickjacking and the X-Frame-Options header
Cross Site Request Forgery (CSRF)

Remember, every one of these is remotely detectable and you can find them in any website with nothing more than a browser. They’re also web platform agnostic so everything you read here is equally relevant to ASP.NET as it is PHP as it is Java – there are no favourites here! I’m going to draw on lots of examples from previous posts and live websites to bring this back down to earth and avoid focussing on theory alone. Let’s get into it.

1. Lack of transport layer protection for sensitive data

We’ll start off one that’s easy to observe and manifests itself in several different ways. When we talk about HTTPS, we’re talking about a secure transport channel and as I’ve written before, it’s about more than just encryption. In fact HTTPS gives us assurance of identity (we know who we’re connecting to), it ensures data integrity (we know the content hasn’t been modified) and finally, it gives us privacy (the data is encrypted and can’t be read by others).

Observing HTTPS is simple as it’s right up there in the address bar:

Any time any of those three HTTPS objectives are required – assurance, integrity, privacy – HTTPS needs to be there. There are several common HTTPS-misuse scenarios but clearly the most obvious one is when it simply doesn’t exist at all. We saw this recently with Top CashBack where they allowed for registration – including password transmission – without any transport layer protection whatsoever:

Confidential information such as bank account info, passwords and other data which should not be publicly accessible must be sent over HTTPS. Failure to do this opens up the requests to interception and eavesdropping by a third party at many, many points in the communication chain. Have a read of my post on The beginners guide to breaking website security with nothing more than a Pineapple if you’re not quite sure how that might be possible.

2. Loading login forms over an insecure channel

As OWASP talks about in part 9 of the 10, HTTPS is about more than just “do you or don’t you have it”, it’s about doing it properly. Indeed this is why they refer to it as “insufficient transport layer protection”. If a page isn’t loaded over HTTPS then you have no confidence in the integrity of it. In the aforementioned link, I pointed out how the Tunisian government had harvested Facebook credentials because the logon form could be loaded over HTTP. This meant that the state run ISPs could inject their own script into the page to siphon off credentials on submit. Nasty.

Detecting insufficient use of HTTPS is easy – you won’t see the HTTPS scheme in the address bar! If you see a logon form and the address starts with http:// then that’s wrong. Here’s an example courtesy of Singapore Airlines:

This may look the same as the previous section but here’s the difference:

<form id="headerLoginForm" action="https://www.singaporeair.com/kfHeaderLogin.form" method="post" autocomplete="off">

It posts to an HTTPS path. Strictly speaking, the credentials are encrypted when they’re posted but by then it’s too late – the login form has already been loaded over an insecure channel and an attacker has already (potentially) injected their own keylogger into the page.

On occasion, you’ll also see a form loaded into an iframe within an HTTP page. The problem, of course, is we come back to integrity again: there is no guarantee that the HTTP page that embeds the iframe hasn’t been manipulated. Sure, when everything goes just right then the login form is loaded from a secure server, but when it doesn’t then you end up with an attacker loading their own login form that looks just like the real one and the victim is none the wiser.

3. Secure cookies

The thing about HTTP is that it’s stateless which means that each request is a new connection totally independent of previous requests. To maintain state (i.e. some knowledge about the user and their previous activities on the site), we most commonly use cookies and one of the most common uses of cookies is that after logging on, we set what’s referred to as an “auth cookie”. The auth cookie is verification that the user has indeed successfully logged on.

Now, if an attacker can obtain that auth cookie then they can impersonate the victim simply be sending it in a request to the target site. I showed how this works in part 9 of the OWASP Top 10 for .NET developers where I very easily sniffed out an auth cookie from a public network and hijacked the session. Consequently, all authenticated requests must be made over an HTTPS connection. If you can load a page that displays personal information while authenticated and the address starts with http:// then that’s almost certainly wrong.

For example, take a look at Qantas:

Get your hands on that auth cookie and suddenly you’re viewing my travel history, booking flights on my behalf, buying stuff with my frequent flyer points and so on and so forth.

The fix is easy and twofold: Firstly, you obviously don’t want to be loading pages over HTTP which need to show personal info once you’ve logged in, that’s quite clear. The other thing is that those auth cookies need to be flagged as “secure”. I wrote about this in detail recently in the post titled C is for cookie, H is for hacker – understanding HTTP only and Secure cookies but in short, cookies have an attribute called “secure” which when set disallows the browser from sending them over an insecure connection. Here’s what Qantas’ cookies look like in Chrome’s developer tools after I've logged in:

No secure cookies! Some of them shouldn’t be because they relate to browsing habits outside of my authenticated session, but some of them definitely should be and that includes the multiple auth cookies that are passing my frequent flyer account number around.

4. Mixed mode HTTP and HTTPS

Continuing with the HTTPS theme, another improper implementation is when a page loaded securely over HTTPS then embeds content insecurely over HTTP. This was one of the many (many, many) things that Tesco got wrong as it means you present your users with a rather disconcerting message like this:

That’s pretty clear – “Don’t load”! Not particularly reassuring, but assuming you do load the page, here’s what you’ll see:

The usual assurance provided by the HTTPS scheme and the padlock has a great red cross through it. Nasty (particularly on a page designed to convince you of their security!)

What’s so bad about this? I mean the three HTTPS objectives I outlined earlier – assurance, integrity, privacy – still apply to the page, right? To the page itself as loaded over the wire, yes, but unfortunately things go downhill from there.

Here’s a scenario: a page is loaded over HTTPS which therefore means an eavesdropper cannot modify the contents. However, that page then embeds JavaScript which is loaded insecurely over HTTP which means that it can be intercepted and modified. So that’s just what an attacker does and the modification includes embedding JavaScript to siphon off credentials just like the Tunisian government did earlier. It’s that simple.

The easiest way to identify mixed mode is just to look for the browser warnings you see above. Different browsers will present the warning in different ways, for example in Internet Explorer:

You can also often see more information by clicking on the padlock icon, here’s Chrome (sorry Qantas, I’m calling you on bad security again!):

But that doesn’t tell you what was loaded insecurely. To do this, all we need to do is look at the requests made by the browser and the Developer Tools in Internet Explorer (just hit F12) are a great way of doing this. Here I’ve simply looked at the network requests made to load the Qantas website and identified the request that was sent over the HTTP scheme:

And there we have it; a single request designed to set a tracking cookie and now you’re being told the whole page can’t be trusted!

5. Cross Site Scripting (XSS)

This is the one area where some folks might argue a little exploring is no longer playing nice. However, assuming we’re talking about reflective XSS (the kind you only see when they payload is passed in via the request) and not persistent XSS (the kind you put in the database and gets served to everyone), I reckon, in my humble opinion, there’s no harm done assuming you don’t then go out and leverage it in an attack.

Moving on, you can observe reflective XSS when content such as HTML tags and JavaScript is able to be passed to a page (usually via query string or form post data) and rendered into the markup thus changing the way the page behaves. Take a page such as Billabong’s registration page:

Now let’s manipulate a few query string parameters and the page can be modified to include Bugs Bunny and Miranda Kerr:

Clearly this is pretty innocuous but it demonstrates that an attacker can modify the page behaviour if they can engineer a victim to click on a carefully crafted link to the site. That link may rewrite the page contents to something quite different, serve the victim malware or even steal their cookies and hijack their session. There are many, many ways that XSS can be used to do nasty things and the detection of the risk is very simple.

Usually it takes nothing more than wrapping untrusted data (remember, this is the stuff your users provide to the system), in an italics tag to confirm the presence of XSS. For example, if I search for “Earth-shattering <i>kaboom!</a>” on a website and it then says “You searched for Earth-shattering kaboom!”, we have a problem. Instead of correctly output encoding the angle brackets into < and > it has rendered them exactly as provided to the source code and thus changed the actual markup rather than the content.

It’s a similar (although arguably more prevalent) problem with untrusted data rendered to JavaScript. What you need to remember is that encoding differs from context to context; you can’t encode angle brackets like you would for HTML, instead they become %3Ci and %3E. Developers often make the mistake of doing this very manually (“if char is < then replace with %3Ci”) which inevitably leads to gaps in the encoding logic so testing a range of different characters often yields results where the obvious ones won’t.

6. Password reminders via email

Nothing of a sensitive nature goes into email, it’s that simple. You should never, ever receive an email like this:

There are a couple of reasons why and the first one is that email is simply not a secure transport mechanism. Whilst it’s possible to secure the connection to an outbound SMTP server using SSL (SMTPS), there’s a lot that happens downstream from there with no guarantee that transport layer encryption is present on each downstream node. Of course there are options like PGP Email but I’ve never seen this used in a password reminder from a website. Ever.

The other issue is that your mailbox is simply not a secure storage facility. Of course there are many different mail providers with many different implementations but the only safe assumption is not to store sensitive data in there. Websites that email credentials put users at risk not just on their own site, but also on other sites due to the (unfortunate but real) propensity for people to reuse passwords. We’ve seen password reuse exploited before through cases like the Gawker Acai berry tweets. It’s a real risk.

The only suitable way for a website to assist a user who has lost heir password is to provide a secure password reset feature. This means emailing a time-limited, single use token that allows a new password to be set on the account and a confirmation email sent to the user afterwards. That’s a pretty simple mechanism but there are still numerous sites doing the wrong thing and sending the original password in email.

7. Insecure password storage

The previous point around emailing passwords is only possible because passwords are not stored correctly to begin with. Let that just sink in a bit and allow me to repeat: if a website is even able to email you your password then they’re not satisfactorily protecting it. You’ve got three common ways of storing passwords:

In plain text
Encrypted
Hashed

The first point is pretty clear – there is no cryptography involved in the storage of the password. One little SQL injection risk let alone disclosure of the database and you’re toast – every password is immediately readable.

Encryption is at least some attempt at secure storage but as I’ve often said before, the problem with encryption is decryption. Once you’re talking encryption you’re talking key management and that’s not something we do well enough, often enough, particularly when it comes to websites (keys in config files, anyone?). What it usually means is multiple points of potential failure when a system is breached.

The most appropriate means of storing passwords is with a strong hashing algorithm. That doesn’t mean a single hit of MD5 or SHA1 (or any other SHA variant for that matter) and it also doesn’t mean just salting it before it’s hashed. I go into a lot more detail about this in Our password hashing has no clothes but in short, we’re often doing hashing wrong and what you really want is a computationally expensive algorithm designed for password cryptography.

Here’s why this is important:

This is an AMD Radeon 7970 consumer-level graphics card. You can buy it for a few hundred bucks and it can crack up to 7.5B hashes per second. Yes, that’s with a “B” so in other words 7,500,000,000. Crikey! Without delving into the nuances of cryptographic hashes here (the “no clothes” post above covers that), the point is that you have to choose the right hashing algorithm. Cracking is still possible, but what if we could bring that rate down by, say 99.99% then it poses a very different value proposition to an attacker.

In the context of this post though, there’s a very easy way to tell when a password hasn’t been stored as a hash – you can see it. That’s usually via the previous risk where it’s emailed to you but sometimes it’s also represented in the UI (more on that a little later). Another common way that poor password practices are disclosed is when an operator knows it, for example when you call up for support. Now identity verification is just fine and there are multiple ways to do that, but using the same credentials for web login and customer service verification is fraught with problems, not least of which is the fact that your personal credentials are visible to other humans whether that be by them looking at them in the system or people verbally providing them to operators.

You start to understand more about why this is a problem when you see stats like these:

When 58% of people are reusing credentials (and many studies will show far higher levels than that), the risk of sloppy password management by a website starts to have much greater reach than just their own site, they’re jeopardising customers’ other sites because rightly or wrongly, there’s a pretty good chance those credentials have been reused elsewhere.

8. Poor password entropy rules

Here is a very simple password fact: the longer it is and the more characters of different types it contains in the most random fashion possible, the better it is.

Conversely, the more constrained a password is whether that be by length or particular characters or even entire character sets, the more likely it is to be cracked if push comes to shove.

Consequently, this is bad:

But this is even worse:

These are examples taken from my 2011 post on the Who’s who of bad password practices – banks, airlines and more where an alarming number of websites were placing arbitrary constraints on passwords. A follow-up post found 3 major reasons why these constraints exist and frankly, they’re all pretty weak excuses.

We need to come back to why this is so important: in the last risk above about password storage I mentioned cracking 7.5B passwords per second with a consumer level graphics card. Now, imagine you bank with ING Direct using a 4 digit password, their database gets breached and the hashed accounts are leaked – the hash is now the only thing between the password being protected and an attacker gaining access to it and using it anywhere it’s still valid, either on the original site or places it’s been reused. An attacker can compute the entire key space of hashes in 1/750,000th of a second. Clearly ING felt this might be a risk so since this post they strengthened their password policy… all the way up to 6 digits, or in other words, 1/7,500th of a second. Your password is toast. But strength increases exponentially so the longer a password becomes and the more characters it contains, the stronger it gets. It’s that simple.

Constraints of any kind on password fields (short of perhaps just one on a very long length) are just not on – there’s simply no good reason for it today. In fact I also made the point a little while back that you should expressly allow XSS in your passwords – no sanitisation at all! The thing is that per the previous risk on storage, passwords should never be redisplayed in any context anyway so let customers go nuts.

9. Denial of service via password reset

Here’s one that you often see gotten wrong: password reset processes that immediately disable the old password. It looks like this:

Now that might not seem too bad, but the problem is that it poses a denial of service risk (there’s also that mixed mode HTTP / HTTPS warning we looked at earlier). Here’s an example: you know someone who uses the Aussie Farmers Direct website and you want to make life a bit hard on them so you reset their password and bingo – they can no longer log in. Now of course they can go and grab the new password from their inbox (or junk mail) and log themselves in again, but they’ll probably want to then change it which adds another layer of inconvenience. This sort of practice can be used as an attack, for example it can take someone out of the running just before the end of an auction so the impact can extend beyond the realm of just mere inconvenience.

The correct way to issue a password reset is to send a time-limited, single use token to the recipient. This gives only the legitimate owner the ability to change their password and it does so without breaking the earlier rule of emailing a password that can then be used beyond the reset process. You can read more about this and other aspects of password resets in Everything you ever wanted to know about building a secure password reset feature.

10. HTTP only cookies

People often don’t think a lot about cookies but those little bytes of information in the header have hidden depths. They can also be pretty damn important to the security of the website and thus need to be appropriately protected. For example, it’s usually cookies that are used to persist a user’s authenticated state across requests. If an attacker can get hold of that cookie then they can hijack the session or in other words, immediately take on the identity of the victim.

I wrote about this recently in C is for cookie, H is for hacker – understanding HTTP only and Secure cookies, the latter part of which we looked at in the third risk in this post. For now though, the important thing to understand is that cookies may have an attribute set that is referred to as “HTTP only” which you can easily view from any tools which can inspect cookies such as Internet Explorer’s developer tools:

Here’s the party trick that HTTP only cookies have: they can’t be read by JavaScript on the client. Keeping in mind that there are cases where you want JavaScript to be able to access cookies, in many situations it’s only the server that needs to access those cookies. For example, when you logon to a website it’s usually an auth cookie that’s returned by the server and then automatically sent back again with each new request. This is what enables the website to see that you’re still authenticated.

This is what also enables session hijacking; if an attacker can get that cookie then it’s all over red rover – they can now become you. A popular means of session hijacking is to leverage an exploit such as XSS to send the cookies to an attacker. For example, an attacker may socialise a link which causes JavaScript to be embedded in the page which accesses document.cookie and makes a request to a resource which they own whilst passing the cookies along in the query string.

When we look at the response after logging into a site which doesn’t properly protect cookies with the HTTP only flag – such as Aussie Farmers Direct (again) – we see something like this:

What we can see here is that the PHPSESSID cookie is not flagged as HTTP only. All it would take is one little XSS risk to be combined with this and things would start to get very ugly.

11. Internal error messages

I’ve written a bunch about disclosure of internal error messages in the past. For example, there was Kogan with their massive leakage last year:

This included everything from framework versions to code locations to database credentials. This was running on Django but I’ve written about equally bad practices in ASP.NET, such as the masses of exposed ELMAH logs that are easily discoverable via Google. There were 11,000 easily discoverable ELMAH logs exposing authentication cookies when I wrote about this early last year:

It’s, uh, kinda gotten a bit worse since then:

Of course the problem with internal error messages is that they can give an attacker a massive head start when it comes to compromising a vulnerable website. Naturally this will depend on the nature of the data exposed in the error, but in a case like those ELMAH auth cookies it makes session hijacking an absolute cinch. Other examples of exposed information can include anything up to and including connection strings to database servers that are publicly accessible. Ouch!

How you tackle this will differ by framework but the simple message that’s relevant across the stacks is this: keep internal errors internal! Configure your app to return generic error messages that don’t leak any info about how the app is put together. It’s not only more secure, it’s a whole lot more user friendly.

In terms of detection, there are enough times where an error message will just reveal itself during the organic use of the website. That was the case with Kogan above but you can often cause an internal error simply by a minor change to the request structure. For example, replacing “id=123” with “id=abc” and an exception is raised when the parameter is attempted to be converted to an integer without the appropriate error handling. Or simple appending an illegal character to a URL – an angle bracket will often cause an exception.

12. Path disclosure via robots.txt

Everybody know what robots.txt does? Here’s a quick recap: when search engines come knocking to discover what’s on a website so that it can be indexed and made easily searchable, in theory the search engine will look for a file named robots.txt in the root of the site. This file contains information which complies with the Robots Exclusion Standard and the idea is that it helps search engines with both what to index and what not to index.

The reason why the “what not to index” bit is important in the context of web security is that often developers will use the “Disallow” syntax to prohibit the search engine from making information on their site discoverable. For example, they may have some sensitive documents or administrative features they don’t want people stumbling across via carefully crafted Google searches (everyone is aware of Google Dorks, right?) so they politely ask the search engine not to crawl that particular piece of content.

The problem is that you end up with sites like GoGet and their robots.txt file which looks just like this:

User-agent: * 
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /editor/
Disallow: /help/
Disallow: /images/
Disallow: /includes/
Disallow: /language/
Disallow: /mambots/
Disallow: /media/
Disallow: /modules/
Disallow: /templates/
Disallow: /installation/
Disallow: /bookings/secret/

See the last one – “/bookings/secret/”? The problem, of course, is that just naming a path “secret” does not make it so! Now GoGet isn’t immediately disclosing anything of risk (although they might want to review the earlier point on insufficient use of TLS), but there are many examples where that isn’t the case.

The thing about robots.txt is that it very often gives an attacker a starting point. It’s one of the first things to look for when trying to understand how a site is put together and where features that are intended to be private might exist. But most importantly, a disallow declaration in the robots.txt is never a substitute for robust access controls. Regardless of how much obfuscation you throw at a path, you absolutely, positively need to implement access controls and work on the assumption that all URLs are public URLs.

13. Sensitive data leakage via HTML source

Everyone knows how to view the HTML source of a page, right? It’s always a variation of the classic right-click –> view source or for the keyboard ninjas, CTRL-U in browsers such as Chrome and Firefox. But of course that’s not the only way to view source, you can always proxy the traffic through tools like Fiddler or Charles and inspect the page contents at that point. The point is that HTML source, for all intents and purposes, is readily viewable and not the place to store any sensitive data. Yet we have examples such as MyDish.co.uk doing this in the browser:

Which is driven by this in the source:

Now this is clearly just crazy stuff – there’s absolutely no reason to pre-populate this field and of course just the fact they can also means that they’re not storing the password correctly as a secure hash to begin with. Whilst this risk only discloses your own password, if an attacker could hijack the session then they could easily grab it from the HTML source (and then leverage everywhere it’s been reused on other sites).

This is a rather extreme example but I’ve seen many, many others which expose data they shouldn’t in the source. Just viewing the source code of various pages in a site can disclose a huge amount of information about how it’s put together and often disclose risks in the design. On many occasions now I’ve seen comments in the source which disclose varying levels of information about the internal implementation of the source. In fact commenting of code itself can be very revealing, particularly if it points to paths that may not be properly secured or contain their own vulnerabilities.

Another angle is the nature of the information disclosed through source in the legitimate function of the website. On occasion I’ve seen SQL statements in hidden fields which not only discloses the structure of the database but also opens the site up to parameter tampering and potentially SQL injection. Speaking of which…

14. Parameter tampering

Here’s an interesting one – when you search Action Recruitment for jobs you’ll notice a URL a little like this:

http://www.actionrecruitment.ie/search.html?module=next_results&basic_query=SELECT%20*%20,%20'1'%20AS%20Score%20FROM%20posting%20WHERE%20%20%20%20(%20CategoryID%20LIKE%20'%')%20%20%20ORDER%20BY%20Title%20&start=10

Can anyone see the problem with that? Let me break out the important bit and remove the URL encoding:

SELECT * , '1' AS Score FROM posting WHERE    ( CategoryID LIKE '%')   ORDER BY Title

That’s right, you’re looking at SQL statements embedded in the query string. For the sake of posterity should the site design change in the future, here’s what that page looks like right now:

The problem here is that should this site indeed just take the query string parameter and execute it as an entire SQL statement, well, it actually poses two problems. The first is that tampering can produce results outside the intended function of the app. This could be minor – such as returning more records – or more significant such as returning someone else’s records. The second issue is that it could be at risk of SQL injection if manipulating the parameter changes the structure or behaviour of the database query itself. This is where things become a lot less grey and a lot more black…

The intention of this post is to draw attention to detecting risks which don’t step into the realm of what most reasonable people would deem “hacking”. Probing for SQL injection flaws very quickly descends into that realm and that’s not somewhere you want to go anywhere near on someone else’s site if you’re trying to play nice.

15. Clickjacking and the X-Frame-Options header

A few days ago I wrote about Clickjack attack – the hidden threat right in front of you and showed just how easily a clickjacking attack can be launched. In essence, this attack boils down to placing the target site in an iframe and whacking the opacity of it down to zero so that the site underneath that shows through. The underlying site is then structured to show tempting links which line up perfectly underneath the target site so whilst the victim thinks they’re clicking on a link on the hoax site, they’re actually clicking a hidden link on top of that which is served by the victim site above it.

Imagine this scenario:

This image shows the victim site sitting at 50% opacity (it would normally be at 0% therefore hidden), so you get a sense of how everything lines up. The impact of the clickjacking attack is commensurate with the action being performed by a simple click; it could range from a social media endorsement such as a “like” all the way through to performing a banking action.

The mitigation is simple to implement and also simple to observe, you just need to look for the response header. By example, here’s what you’ll see on ASafaWeb (my own site we’ll come back to shortly) using the Chrome developer tools:

As you’ll read in the post above, there are a few different possible values for this header, the main thing is that unless you’ve got a good reason to allow the site to be embedded in a frame absolutely anywhere, there should be an X-Frame-Options header returned along with each request. You can also check this with ASafaWeb, this test has been added to the software just this week.

16. Cross Site Request Forgery (CSRF)

In many ways HTTP is quite clever. For example, you can authenticate to a website and then in unison with the web browser it will happily send your auth cookie back to the website with each request automagically.

In other ways HTTP is rather foolish. For example, you can authenticate to a website and then in unison with the web browser it will happily send your auth cookie back to the website with each request automagically. Oh – even when you didn’t actually intend to make the request!

It’s that last bit that CSRF exploits. The risk here is that if an attacker can trick a victim’s browser into making a request to a website they’re already authenticated to and modify the parameters of the request to do the attacker’s bidding, we might have a bit of a problem. For example, if a banking website allows an authenticated user to make a request such as “/transfer/?amount=500&to_account=1234567890” and it actually impacts a change (such as transferring money), then we have a CSRF risk. That’s a very simplistic example and I do go into a lot more detail in part 5 of the OWASP Top 10.

Let me give you a real world example. When you’re logged in to Toys R Us, if you make a POST request like this:

http://www.toysrus.com.au/scripts/additemtoorder.asp

And you send the following form data:

productid: 1675220
quantity: 1
injectorder: true

You will add one of these to your cart:

Now of course there is nothing wrong with a Lego Star Wars X-wing model, assuming you actually wanted one! The problem is that all an attacker needs to do is trick your browser into reproducing the same request pattern – just the URL and form data – and you’ll have one of these in your cart. This execution of this can be extremely simple, for example, visit an attacker’s page where there are hidden form fields reconstructing those three pieces of data I showed earlier on and set the action to the URL which adds the item to the cart. Now give them a big “Win free stuff” button (which is how the attacker lured them in to begin with) and badaboom – they’ll submit the request along with their authentication cookie to the Toys R Us website and have a shiny new Leo model in their cart! The attacker might even target a hidden frame so that the victim can’t see the response from the Toys R US server.

That’s a very simplistic example in a low-risk scenario. There are more complex executions and obviously more risky scenarios and they’re possible because the CSRF attack is able to reproduce the appropriately structured HTTP request which, of course, also sends off the authenticated user’s cookies because that’s just how HTTP works.

The mitigation is detailed in the post I mentioned earlier and it’s all about using an anti-forgery token in the form with a corresponding cookie. If both of these values don’t reconcile when the request is made then it’s considered to be forged. This works because an attacker cannot simply recreate the correct form data without grabbing the token from the website which is unique to the user. The anti-forgery cookie will be sent automatically – that’s fine – but its mate from the form won’t be.

What’s important in the context of this post though is what a secure request should look like. Here’s what happens when I logon to ASafaWeb and there are two important bits of info I’ve highlighted:

This is the anti-forgery token in both a cookie then further down in the hidden field. This is the way ASP.NET names them, other web platforms may show slightly different names but the point is that the token exists and without it, the request fails. This should be in every location where an inadvertent request could have an adverse impact for the user. If you don’t see it – like on Toys R Us – then a CSRF risk is almost certainly present.

Scorecarding websites with ASafaWeb

There’s a lot to remember when securing websites and indeed what’s listed above only even scrapes the surface. However it’s a good starting point and these are all risks that have many precedents of being exploited for an attacker’s gain. They’re also all risks that as I stated from the outset, can be remotely detected without stepping into the evil hacker realm. You can be responsible in detecting these risks.

I often see tweets like this:

Clearly this is somewhat of a rhetorical question as it’s very unlikely the culprit is aware of the risk. Moving on, rather than just having people point website owners to a lengthy post covering multiple issues as is the case above, I wanted to provide something more succinct that talks about specific risks then provide further reading from there. Given the sort of risks I’ve outlined throughout this post, I wanted to provide an easy mechanism for assessing, recording and sharing them so here it is – the ASafaWeb Scorecard:

This is very simple mechanism and it works like this: first you enter the URL of the site you’re assessing. Next, for each of the 16 risks outlined above there’s an entry on the ASafaWeb Scorecard along with “Pass” and “Fail” buttons. You then go through and self-assess the site, clicking the appropriate button as you go (you can click the same button again to de-select the risk).

This is not a dynamic analysis tool like the ASafaWeb scanner is and that’s simply because for the most part you need to be a human to detect these issues. For example, you actually need to do a password reset and assess the resulting email in order to discover that it’s not being stored satisfactorily.

As you complete the assessment you’ll see the results appear in a hash in the URL. What this means is that a completed assessment has a URL something like this:

https://asafaweb.com/Scorecard#url=notasafaweb.apphb.com&LackOfTls=Fail&InsecureLogin=Fail&SecureCookies=Fail&MixedModeHttps=Pass&Xss=Fail&PasswordReminders=Pass&PasswordStorage=Pass&PasswordRules=Pass&PasswordDos=Pass&HttpOnly=Pass&InternalErrors=Fail&RobotsTxt=Pass&HtmlSource=Pass&ParameterTampering=Pass&Clickjacking=Fail&Csrf=Fail

When the URL is received by someone and they open it up, the Scorecard appears with a little summary and the risks in read only mode so that they can’t be directly edited again:

Mind you, it’s easy just to change the URL and as a result the Scorecard values, but this isn’t intended to be a tamperproof rather it’s a means of sharing information via URL alone. When the Scorecard is opened up it won’t show any risks that haven’t been given a pass or a fail grade so you can elect exactly what data you want to share. Only want to raise one risk – fine, just select that. Only want to alert someone to failing risks – likewise, just send those. You choose.

There are two reasons I’ve done this and by far the most important is that I don’t want to be building up a repository of vulnerable sites! By persisting the risk in the URL parameter the address contains all the information that’s required to understand what’s going on. Secondly, because that URL is so self-contained it’s easy to pick up and send to someone so it’s very transportable.

Ultimately that’s the goal – to create a mechanism to easily report on risks and share them around. I’d love to see this tool being used in place of trying to explain risks via Twitter and engaging in the banter that often ensues in an attempt to try and explain things in only 140 characters a shot. It would be great if this gains some traction and I’d love feedback on the effectiveness of it, including if there are further risks that should be included in an attempt to encourage people to seek them out.

And that brings us back to where this post started out – hacking yourself first. Using the Scorecard above, the chances of you finding at least one risk in your own site is very high and if you can do that and mitigate it before someone exploits it then that’s a very good thing indeed. And likewise, if you do find issues in someone else’s site, the risks above should keep you out of trouble if you detect and report on them responsibly. Hopefully the Scorecard feature helps this process and makes the web, well, ASafa place!

More hacking yourself

The risks outlined above are ones I tend to use as a starting point either to assess sites I’m involved in building or to get a sense of the relative security position of someone else’s site. They’re not exhaustive though and as I said at the outset, there are other risks such as SQL injection which are serious, prevalent and will very likely cause damage if probed a little further.

A good resource for further probing is the OWASP Testing Guide. This will take you through hundreds of pages of steps that go into a lot more detail than what this blog post alone covers. If you want to get really in depth then there’s my recent Pluralsight video training which gets right down into the guts of how these risks are exploited and mitigated across just over eight hours of material.

Clickjack attack – the hidden threat right in front of you

2013-05-13T19:36:00.001+10:00

XSS protection: check!

No SQL injection: check!

Proper use of HTTPS: check!

Clickjacking defences: uh, click what now?!

This is one of those risks which doesn’t tend to get a lot of coverage but it can be a malicious little bugger when exploited by an attacker. Originally described by Jeremiah Grossman of WhiteHat Security fame back in 2008, a clickjacking attack relies on creating a veneer of authenticity under which lies a more sinister objective.

Imagine you visit a website and see the following:

Free stuff is always good so you click on the big button and WAMMO! You’ve just been clickjacked. You see, whilst you think you just clicked a “WIN” link, in reality you just clicked this instead:

This, of course, is your bank. You are logged in and your bank provides a handy option to transfer all your money with a single click. But of course you don’t know you you’ve just given Mr Dotcom all your money because you never even saw the link. This is a very simple example of a clickjacking attack, let’s take a look at the mechanism underneath and then talk about defences.

Sleight of hand and other tricks

This is a little like a magician’s sleight of hand trick; your focus is on one particular area of interest (winning free goodies) and whilst you’re distracted by this, the real “magic” is happening just out of view. This all make a lot more sense when we toggle some opacities on the page, take a look at it again now:

What you can see now is the bank’s page sitting in an iframe on top of the iPad page, it simply has the opacity set at 50%. Earlier on it was set to 0% which effectively meant it was hidden but still active.

Here’s another neat way to view this courtesy of Firefox’s 3D view:

You can see the content that’s actually visible in the attack (such as the “Hey – we’re giving away…” text) sitting several layers deep and the highlighted turquoise box is actually the “WIN” text. The banking site is sitting on top of this which is why you can see several layers on top of it and the “WIN” text ultimately showing through them because of their opacity.

Here’s the key to a clickjacking attack: the target content is hidden and the attacker’s content sits over the top and effectively tricks the victim into clicking links they don’t know they’re clicking. Here’s what the markup of the attacker’s page looks like:

<div style="position: absolute; left: 10px; top: 10px;">Hey - we're giving away iPad minis!!! Just click the WIN button and it's yours!!!</div>
<div style="position: absolute; left: 200px; top: 50px;">
  <img src="http://images.apple.com/my/ipad-mini/overview/images/hero.jpg" width="250">
</div>
<div style="position: absolute; left: 10px; top: 101px; color: red; font-weight: bold;">>> WIN <<</div>
<iframe style="opacity: 0;" height="545" width="680" scrolling="no" src="http://mybank/Transfer.aspx"></iframe>

How easy is that?! Whack the target content in an iframe, hide it then position some rogue links underneath the ones you actually want them to click. Job done.

When we look at the request that was made by clicking on the “WIN” link (which of course was actually the “Donate” link), we see the following in Chrome’s developer tools:

The two important highlighted areas here show the donate resource being requested and an auth cookie being passed with the request. Remember the significance of this – it persists your logged in state which means that for all intents and purposes, this is an authenticated requests from a logged in user, it’s just that they didn’t really intend to issue it. Now of course for something like a banking website or any other use case that takes advantage of an authenticated state, the user actually needs to be logged in. In that regard it’s a little like a cross site request forgery attack. There’s also a bit of broken authentication and session management going on insofar as also like CSRF, this is one of those cases where expiring sessions quickly is a great defence albeit at the expense of usability.

So that’s the execution of it, let’s take a look at the mitigations.

Frame busters (and frame buster busters)

The issue here is that the target site has been loaded up within an iframe. One way to address this is via a little JavaScript in the banking website which works as follows:

if (top.location != location) {
  top.location = self.location;
}

Simple – if the page isn’t the URL in the address bar (and remember, this is our hypothetical banking site), then redirect the top location of the browser to this page so that it and it alone is loaded into the browser. In other words, the target page is literally “busting” out of the frame and taking over the entire browser window hence freeing itself of the malicious site. Job done? Not quite.

For every frame buster there is a frame buster buster. In a classic example of the arms race that is builders versus breakers, there are numerous ways this model can be circumvented. There’s a fantastic paper from a few years ago titled Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites that talks about this in detail but in short, frame buster busters use techniques such as:

Nesting the victim site in two frames as the double framing causes the descendent frame navigation policy to disable the redirection
Tapping into the onBeforeUnload event to cancel the redirection (albeit with some user input) when the frame buster attempts to unload the page
Exploiting XSS filters designed to prohibit cross site scripting in order to cancel out the frame buster

Implementations differ by browser and by version and it becomes somewhat of a quagmire of conditional logic and varying degrees of success, but the real point is that frame busting via JavaScript is very patchy. We need a better mousetrap.

X-Frame-Options

Frame busters are hacks. Nasty, messy hacks of limited efficiency. What we really need is a simpler, more semantic means of specifying how and where a page may be used when it comes to being embedded in a frame and that's what we have in the X-Frame-Options (XFO) header. This one actually came out of Microsoft back in early 2009 so it’s been around for a while although evidence would suggest it hasn’t been extensively adopted.

Firstly a bit of response headers 101. When an HTTP header is preceded with “X-“ then it’s not strictly part of the HTTP spec. Anyone can make up their own headers to pass info around outside of the response body. Fortunately it’s a little more organised than that with the browser vendors agreeing to recognise the header and place some limitations on how the browser handles the page as a result. There’s actually a draft IETF spec for the header so we may see more formality at some point in the future.

You’ve got 3 different values for your XFO headers and I’ll quote from that draft IETF spec as it does a good job of describing them:

   DENY
         A browser receiving content with this header MUST NOT display
         this content in any frame.

   SAMEORIGIN
         A browser receiving content with this header MUST NOT display
         this content in any frame from a page of different origin than
         the content itself.
         If a browser or plugin can not reliably determine whether the
         origin of the content and the frame have the same origin, this
         MUST be treated as "DENY".
         [TBD]current implementations do not display if the origin of
         the top-level-browsing-context is different than the origin of
         the page containing the X-FRAME-OPTIONS header.

   ALLOW-FROM (followed by a URI of trusted origins)
         A browser receiving content with this header MUST NOT display
         this content in any frame from a page of different origin than
         the listed origin. While this can expose the page to risks by
         the trusted origin, in some cases it may be necessary to use
         content from other domains.
         For example: X-FRAME-OPTIONS: ALLOW-FROM
         https://www.domain.com/

There is also the non-standard ALLOWALL value which does just what it sounds like it does – in theory. Apparently this value started getting served up by Google quite recently and got the browsers a little confused. Well more specifically, the browsers don’t recognise it as a valid value and consequently just ignored it which, of course, is exactly what the intention is and is the equivalent of having no XFO header at all. Except it isn’t really; when you see no header there are two possible options with the first being that the developer wants to allow the page to be embedded anywhere and the second that they never even thought to include it. My money is on the second option being by far and away the most prevalent situation and the ALLOWALL value is an explicit acknowledgement that a conscious decision has been made to allow embedding in frames. The intent is much clearer and far less implicit which IMHO is a good thing.

There is, however, some criticism of the XFO implementation as it stands. For example, it’s not possible to allow framing of content both from the same origin and from a trusted URI. In a similar vein, it’s also not possible to allow framing from multiple trusted URIs. Both of these are unfortunate shortcomings of the header as they’re very real scenarios. Allowing the browser to recognise multiple non-conflicting definitions of the header would be one approach but that doesn’t appear to be on the cards just now.

Moving on, XFO is all pretty simple and the browser support is very good with IE8 onwards implementing it as well as all the other major vendors for a number of versions now (Firefox 3.6, Safari 4, Chrome 4.1). What if a browser doesn’t implement it? Absolutely nothing, it will just carry on as usual and not put any constraints around the content being framed.

Assuming you don’t actually want a site embedded within other sites (which will usually be the case), just use it – it’s a few bytes of overhead to prevent a potentially rather malicious scenario. Ideally, you want to just deny access to browsers loading the page in a frame. If you really want to load your own pages into frames on the same site then you do the same origin trick or open it up further to another site with the “allow-from” syntax. Do be cautious though: things will break if you’re overzealous and inadvertently block content from loading into legitimate frames.

XFO in practice

Getting back to our original example, here’s what happens to that site once XFO denies embedding in a frame (I’ve left the opacity at 50%):

You see that? Of course you don’t, that’s the whole point! The banking site is no longer rendered in the browser, all you can see is the iframe border. Mind you, the banking site is still requested because after all, that’s the only way the browser can be instructed not to render it once it’s returned by the server. You can see this in Chrome’s network profiler:

Check the status of that last request to Transfer.aspx – it’s now “cancelled” which is kind of right. As I said earlier, the request is actually still made and indeed you can inspect the response headers:

Just to close the loop on things, there’s that XFO header. Job done!

Protecting your ASP.NET app with NWebsec

Adding response headers to most frameworks is a piece of cake, ASP.NET included. Normally I’d just go and create a custom HTTP module and be done with it but being a fan of taking community projects that already work well, it’s worth checking out NWebsec first. This little package was created by André Klingsheim who has done a number of clever security things over the years. As with all good .NET packages it can be easily grabbed from NuGet:

PM> Install-Package NWebsec

One of the things I like about NWebsec is that it’s a configuration-only install; there’s no recompile, just drop in the libraries and setup the web.config and you’re done. For some people, this is quite advantageous. The other neat thing is that it tackles a bunch of other security related headers as well. For example, I just dropped it into ASafaWeb and used it to both add an XFO header and replace my existing HSTS header code with just a web.config configuration. Speaking of ASafaWeb…

Detecting the clickjack risk with ASafaWeb

As many of you will already know, I maintain a little security misconfiguration scanner called ASafaWeb which is the Automated Security Analyser for ASP.NET Websites. As the name suggests, it’s predominantly aimed at security misconfiguration of sites built on the Microsoft stack but its horizons are increasingly being broadened. For example, I recently added support for detecting HTTP only and secure cookies which, of course, works across any web platform that talks in HTTP.

Now I’ve added support for detecting XFO. It’s a real no-brainer for ASafaWeb as it just involves looking at the response headers of one of the requests it already makes so that’s no additional HTTP overhead by way of additional requests. Here’s what a sample scan looks like when no clickjacking defence exists:

You’ll see that ASafaWeb flags it as a warning and there are a few different reasons for that. Firstly, it may be perfectly legitimate not to set an XFO header because there are cases where you want your content to be framed by other sites beyond what is feasible to describe with an ALLOW-FROM value. It’s rare, but there are cases. Secondly, flagging this an error alongside risks such as an exposed ELMAH log or a page stack trace is not really commensurate with the actual risk it poses. I did exactly the same thing with the excessive headers scan for the same reason. Finally, I’m going to take a guess here and say that 90%+ of sites are going to fail this scan. I do store de-identified logs so I’ll be able to validate this assumption once some data is collected, but marking almost every single scan someone does as having an “error” can be counter-productive, particularly when people also have scheduled scans which are only triggered when an error state occurs.

If this post has sparked your interest, go and drop some of your sites into ASafaWeb and you’ll quickly get an idea of how many are at risk of a clickjacking attack. It will almost certainly be many.

More on XFO

It’s interesting to look at how other websites implement XFO. For example, here’s what Facebook does:

X-Frame-Options: DENY

And Twitter:

x-frame-options: SAMEORIGIN

And even GitHub:

X-Frame-Options: deny

On the other hand, let’s look at what our “Big 4” Aussie banks do:

ANZ – no XFO
Commonwealth – nothing there
Westpac – nada
NAB – nope

Now of course the clickjacking risk can only really be exploited when there’s an advantage to be gained by a victim unknowingly clicking on a link, so for example once they’re actually logged on to their bank account and assuming it’s a mere single link click that doesn’t require follow-up action to actually impact a change. Maybe that usage pattern doesn’t exist behind the logons of those banks but at the end of the day, we’re just talking about a few bytes added to the response header so it’s not like implementing XFO is going to cause any tangible adverse impact.

Ultimately, this is just another one of those little additional security value-add features. It’s not exactly in the same league as SQL injection or cross site scripting, but as I’ve written before, it can be a real nuisance when leveraged against features such as a Facebook “like” buttons. Plus of course there are genuine cases where it can cause damage, particularly when combined with other sloppy practices such as far-reaching session expirations. Just add an XFO header and be done with it.

Here’s why you can’t trust SSL logos on HTTP pages (even from SSL vendors)

2013-05-08T22:24:00.001+10:00

A couple of days ago I wrote about Why I am the world’s greatest lover (and other worthless security claims) and it really seemed to resonate with people. In short, whacking a seal on your website that talks about security awesomeness in no way causes security awesomeness. Andy Gambles gets that and shared this tweet with me:

So let’s check out exactly what’s going on here and you really need video to understand the fatal flaw in the logic of SSL logos coming down over HTTPS:

So there you go – it can be that simple. How I MiTM’d the page so easily is not really the point, the point is that an SSL logo on an unprotected page is as good as worthless (and frankly they’re not much good on protected pages either).

Why I am the world’s greatest lover (and other worthless security claims)

2013-05-06T21:21:00.001+10:00

I’ve been considering purchasing one of these t-shirts:

This shirt would announce to everyone who crosses my path that I am, in fact, the world’s greatest lover. They would know this because I have a t-shirt that tells them so and it would give them enormous confidence in my sexual prowess.

If ever I was challenged on the claim, I could quite rightly say that nobody has ever demonstrated that this is not the case and there are no proven incidents that disprove it.

Sound ridiculous? Of course it is but somehow we’ve come to accept this practice – or at least tolerate it – by virtue of images like these:

The futility of this logo struck me last month when I wrote about 5 ways to implement HTTPS in an insufficient manner (and leak sensitive data). Here was a site that despite the assertions of the owner that it was “secure”, sent sensitive data in the clear, had mixed mode HTTP and HTTPS content, sent auth cookies over an insecure connection, didn’t flag sensitive cookies as secure to begin with and relied on HTTP to load the login form. Oh – and had a “Norton Secured” logo.

The futility of the logo really struck me when I read this forum response from Top CashBack after they were asked “how safe are your bank details in TCB”:

The site is secure because it has logos. Not just one logo, but two logos. This is beginning to be reminiscent of the entirely nonsensical padlock icon bitmap.

So what exactly does this logo get you? According to Norton (or rather Symantec who owns the brand), you get consumer trust:

77% of consumers recognize the Norton Secured Seal.
65% of consumers agree that a website displaying the Norton Secured Seal is safe to browse and won’t give them a virus.
55% of consumers agree that a website displaying the Norton Secured Seal means that the website protects their online privacy.

It’s the last two points that I found particularly interesting so I thought I’d take a browse around at sites displaying the logo. Almost every random example I picked where this logo had been used had basic security flaws. Not obscure hypothetical flaws but rather easily observable, readily exploitable flaws.

Versa Lift has mixed mode HTTP and HTTPS when you go to checkout:

MyBinding.com also messes this up:

And then they let you choose a 3 character password. And email it to you:

Then there’s Tanguito dancewear which has many impressive logos:

And no transport layer protection whatsoever on the login (and no, it doesn’t even post over HTTPS which would still be insufficient anyway):

There’s also no HTTPS on the RareFile login (and we have multi-logos again):

None on Chemical Containers inc. either:

Or there’s iMeds with the simplest of reflected XSS:

Continuing with the non-SSL theme, there’s Telegraph Cottages:

But get one illegal character into the URL and we have a case of Yellow Screen of Death via security misconfiguration courtesy of a misconfigured web.config:

And so on and so forth. The list goes on and on and on and, well, there’s a lot.

Of course there’s (unfortunately) nothing unusual about websites getting basic security practices like these wrong but when they do so and claim to have reached some higher moral security ground by virtue of a Norton or McAfee or any other seal then that’s just downright misleading. Claiming that the website is “safe to browse” or that it “protects [consumers’] online privacy” simply by the presence of a bitmap image is way off the mark. Who knows, maybe these cases have simply abused the acceptable use of the imagery but one thing is for sure; they’ve got their basics wrong on the security front and no number of security logos will change that.

If you believe the marketing hype (and I would definitely take this with a grain of salt), one of these little logos could lead to a 11% improvement in sales and 52% lift in sales from paid search. Suddenly the value proposition to websites becomes a lot more tangible and again, it all comes back to establishing trust. Unfortunately it’s just not warranted in so many of the cases where the logo appears.

But of course it begs the question: what exactly do you need to do in order to display this seal which will boost your appeal with consumers? Have your site audited by security professionals? Scanned by a comprehensive dynamic analysis tool? Self-assess against a set of stringent criteria? Nope, you buy one of their SSL certs or have them check there’s no malware on the site:

Now interestingly, in theory, this also means embedding the seal with a piece of script which appears to go some way to verifying the fact that the page displaying the seal is indeed protected with one of their certs. Clearly this isn’t the case in some of the examples above but how is a consumer to know that? And whilst there’s absolutely nothing wrong with a Symantec SSL cert (at least not to my knowledge), when used as intended the presence of the seal merely verifies that the page in which it is embedded is loaded over HTTPS. The whole idea of OWASP calling part 9 of the Top 10 “Insufficient” Transport Layer Protection is that there is far more to SSL than just having a cert; it has to be used correctly!

At the end of the day, the only real difference between the t-shirt at the start of this post and the website badges above is that it’s simple to disprove the claim of the latter.

Pineapple Surprise! Mixing trusting devices with sneaky Wi-Fi at #wdc13

2013-05-03T11:40:00.001+10:00

I’m pushing the “Publish” button on this just before I go on stage at Web Directions Code because all things going well, what I’m going to talk about in this post will form part of my demo about securing web services.

I’m making some (admittedly very simple) code available and providing some resources that will hopefully help everything I talk about with regards to unprotected wireless traffic make sense. I’d like to begin by introducing you to Pineapple Surprise!

Wait – what?! Where’s my Stack Overflow?! I mean I’m seeing stackoverflow.com in the address bar, what’s going on here?! It gets worse:

That little usr cookie down the bottom – that’s the money shot. Create a cookie in the browser with that name and value while the session is active (yes, it has expired just in case you were wondering) and wammo! You’re now me on Stack Overflow. You can go and respond to every security question about encryption and tell them to use ROT13, you can abuse Jon Skeet for not knowing his covariants from his contravariants and you can respond to any question about “How do I use ASP.NET to…” by telling them to use SharePoint. Except it’s not you saying that, it’s me and I’ll cop the abuse for it.

Let me explain what’s happening here.

All your Wi-Fis are belong to the Pineapple

This is all the work of the Wi-Fi Pineapple which I initially wrote about a couple of weeks back in The beginners guide to breaking website security with nothing more than a Pineapple and then again a few days ago in Your Mac, iPhone or iPad may have left the Apple store with a serious security risk. It’s this little guy here:

You can go and read the detail in those posts so I won’t repeat too much of it here beyond saying that this little device can trick trusting phones, tablets, laptops and anything else that can auto-connect to an open (i.e. no Wi-Fi password) known Wi-Fi access point (which is pretty much everything) into connecting to it instead. What many people don’t realise is that their wireless devices are constantly sending out “probe” requests looking for networks it has previously connected to (secured or not) and would like to connect to again. Just walking around yesterday morning with the Pineapple resulted in 315 unique SSID’s being probed for, sometimes by multiple different unique MAC addresses (the amusing ones are in bold):

#HKAirport Free WiFi, #WiFi@Changi, @yvrairport, _FREE Wi-Fi by inlink., 120wire, 14 Stewart Gibson Place, 2WIRE361, 474Labs-N, 4ten.net, ABC_PSK, ABC_WIFI, ACCESS-StarHub (2 MACs), aconex-wifi, AdshelWifi, Airport Free Wifi, ajfisher, allen, Anchors Aweigh, AndroidAP (3 MACs), AndroidAP5, AndroidHotspot1982, AnthB, ANU-Access, Apple Demo, Apple Store (3 MACs), Auckland Wi-Fi @ Tomizone, Aussieville, AUVIC-AEGIS-WIRELESS00, Axiom 5, B715 (2 MACs), BAIADAWL03, BAIADAWL04, BALoungeWiFi, BAMBI, bazillion, BBY Guest, BigPond022391, BigPond1D0761, BigPond47C6, BigPond4C0F55, BigPondD3DFA4, BigPondD7E713, BIPAC, BLERG, BlingBlingNet, Bliss, BO-AP03, Bordo, Brayza, BTHomeHub2-7J2T, BYOD, Cafe Caldera, CafeScreen_Free_WiFi, camphone, CCLA-HOTSPOT, Centre Wireless, chelagarto, ChinaNet-E3Ex, ChinaNet-Starbucks, ci+reactor, CiscoA4309 (2 MACs), CITWIRE, COKE Zero FREE WiFi, Colonial-One, Connect Free WiFi, Connect2UoM, Crush, Dan's White 64GB 4S, Darling Harbour Hotel2, db155, deblank, deblank2, deblanks, default, DEL C:, devgeeks (2 MACs), DH Studio, dh-int2, DigProd-Mixed, DigProd-N, DJ_Corp, dlink, Dodo, Dragonfly, DrayTek, DWLaptop, E583C-27a3 (2 MACs), Earth-shattering Kaboom!, Eden, Elfin, Emerald Hotspot, f9sml9fX, Fanta Wi-Fi, Finch, FinPa New Media, Flightfox.com, FLOATdroid, fluffyland, fontenayDL001, Four Points by Sheraton, Free wifi (5 MACs), free-hotspot.com, FreeSkydeckWifi1, FRITZ!Box Cubitt, Fuck-Off, FWMM2, FWMM2-guest, GAGAWAVE, Galactica, Galactica Guest, Gareth Edwards...s iPhone4, GoogleGuest (3 MACs), hahd.fr (Cette), Havana, Hertzpert, HH-GUEST, hhonors, Holiday Inn Public Wireless (2 MACs), HollerWF, home, home2ng8wlanv, HOTEL BRUNY FREE INTERNET, Hotelpuri.com, Hotspot-TXL, HTC Portable Hotspot (2 MACs), Hypnotoad, ibahn, Ibis, ii005745primary, iMac G5, Inspire9 (2 MACs), inteddies, Internode (2 MACs), Io, iROOM-Akama 2, ISIS, J and P, j74eX5drDdgf, James's iPhone, Jason, JOHNDEBLANK-PC_Network, JScamp2012, JSConf EU 2012, Kevin Yank...s iPhone, KINWOWLAN (2 MACs), KIT-GUEST (2 MACs), kylevermeulen, L n J, LAX OneWorld Lounge, LAX-WiFi, Link (2 MACs), linksys_reception, linuxconfau, Little Shed, LittleWireless, lovenest, LtBourkeSt, Luana 1207, Macquarie Public, MagicJohnston, Marty McWiFi, MAXSPOT, MAYA, McDonald's FREE WiFi, Melbourne Virgin Lounge, meteorology, metguest, Metro Wifi (2 MACs), met-wlan999, Miller Street Brewery Mobile 4G, Millhood, mka-27784, MOBILE, mojito, monstrouswifi, Mort, MOTOROLA-E5BE7, Movistar-Vex, Mozilla Guest, MPLUX AirPort, MRC-Guest, MTH Functions (6 MACs), museumcg, museumpublic, NDABBAYE, NetComm Wireless, NETGEAR (2 MACs), NETGEAR2, Nexus, no-one here but us chickens, Norah Han...s iPhone, Novotel-Canberra, NPS Wireless, ntegrity.com.au, Ogilvy_Melbourne, OgilvyWiFi, OptimusPrime, Optus E583C f0b5, OPTUS_B1, OPTUSA82B5A1, OptusCD3_365c80, OPTUSV6FF126, OPTUSV8D64B0, Other... (2 MACs), PalaceMeetingRooms, Panasonic Display1, pandy, password: ken sent me, Patient, Pegasus, pgh-wireless, Pluto, Porto, Porty Extreme, pp, PP-AP, Pretty Fly For A Wifi, Pretty Fly for a WiFi..., Prometheus-2-4, public, Qantas Free WiFi, Qantas-Lounge (2 MACs), QANTASWebConnect, RAMMMOODIEWLAN, RCSWIFI_1, redlea (2 MACs), Residence du Rougier 1, rhapsody (2 MACs), Ricky...s iPhone 5, RMIT, Robot, roomlinx, ROSENEATH_WIFI, rtw, Scarlett Extreme, Sceptre, ScottiePippen, Seaport Wireless, SFR_E8C8, Shanghai_Wireless, Sherwood Forest, SH-Wireless, SJS, sky-free-e872b5, SKYMESH, Skynet Global Defence Network, Skynet mobile defence unit, Skynet Mobile Unit, SOH_Guest, SpeedTouch913EE2, Squareweave - We build web apps, squiz.net, State Library of Victoria, StormsEnd, studiocea, Subaru_Customer_Lounge, Super_Dragon, SuperDragon, T1 Free wifi by SYD, t1fg, TASSWEB Wireless, Telecom wireless hotspot, TelerikAPAC, TEWM_0A7E0B, The Lounge Sydney, The Office of Marketing, THE PARLOR (2 MACs), thebrook, theinterweb, TheOffice, thisismyhouse, ThousandPoundBend, tobyandloz, Tomizone @ Movenpick, Tony le Pony, trust me, TULIP (4 MACs), Tygwyn1, UConnect, ULTIMATE-4F77, ULTIMATE-Rhapsody, UniWireless, vanessa's Network, Ventura_Free_WiFi, Verizon MIFI4510L 2412 Secure, vermeulen, Victoria Hotel, VirusProwler, W3710, WANADOO-6058, Wards, Wayport_Access, wdc-a, wdc-b (2 MACs), weatherzone, webteam (2 MACs), webteam2, WIFI@CintaAyu, WIFI@CintaTerrace, wilnet, winboard, wireless, Wireless@SG (3 MACs), wireless01 (2 MACs), WLANadmin, wlan-ap (2 MACs), WME, WME iinet, WME Wireless, www.koodoz.com.au, Xperia S_284e, YBF-b, Young Henrys, Zentrum_Der_Macht, ZyXEL

Tricks are one thing, but it can also act is a normal Wi-Fi access point which people connect to of their own free volition; see an SSID called “Free wifi” – sounds good, let’s go! Once you’re connected, you’re in a whole world of trouble, at least you are if you visit any websites that don’t implement sufficient transport layer protection. And that’s the real story here – unprotected Wi-Fi traffic.

What you saw in the screens above is the work of dnsspoof which in simple terms, was able to intercept the request for stackoverflow.com and rather than routing it to their server, routed it to the web server running in the Pineapple instead. The screens above were served from the Pineapple in response to the Stack Overflow request and in fact configured this way it will respond with that same page regardless of the site being requested, so long as it’s an HTTP request and not an HTTPS one.

What this demonstrates is that the Pineapple controls the traffic – anything sent over HTTP can be manipulated with clever software, including where requests are routed to. Now let’s imagine that there is no DNS spoofing and the Pineapple simply passes requests through to a network bridge and out over an internet connection. It might look like this:

What this means is that the Pineapple and the attacker’s PC it’s connected to now control the unencrypted traffic. Anything sent over that connection – including Stack Overflow’s cookies – may be intercepted by the attacker. As you’ll see in the demo while I’m on stage, that is a very serious security risk.

What’s the risk?

I mean it’s just some cookies, why should you care? Let’s go back to the basics for a moment which means understanding what SSL is about and it boils down to three things:

Assurance of identity – only the legitimate owner of the site should be able to serve up a certificate for it
Integrity – the content moving backwards and forwards over the connection can’t be manipulated
Confidentiality – the content also can’t be eavesdropped on

It’s that last point that most people associate with SSL and they expect passwords and banking info to be kept from prying eyes. But there’s other info that needs to be protected as well and it’s not as immediately obvious. Should the demo gods be kind to me, the audience will see one simple request to a Stack Overflow API appear on the attacker’s PC. It’s a request to the up-vote service and along with the request is the authentication cookie used to identify the user. Because it’s sent over an unencrypted connection it can be intercepted and once it’s intercepted then the session can be hijacked. The attacker will simply recreate the cookie in his browser (that’ll be me) and badaboom – they’re logged on as the victim!

One thing I do want to point out is that the guys at Stack Overflow understand this intimately. As I’ve written before, these are without doubt some of the smartest developers on the planet and they’ve made a conscious decision about the risk versus benefit of SSL. They know exactly what they’re doing. In fact Nick Craver wrote a very good blog post just last week on the road to SSL where he outlines the sort of challenges they need to overcome in order to secure the transport layer. As you can read in this question, clearly there is an intention to make Stack Overflow SSL only so that’s a very positive move in the right direction security wise.

Get Pineapple Surprise! on GitHub

I want to make the implementation of this freely available to the community in part so that others can take it and adapt it (contributions are welcome!) and in part so that it’s clear that despite the obvious opportunity to do evil, it’s not doing anything nasty. You can find it on GitHub here: https://github.com/troyhunt/PineappleSurprise

Told you it was rudimentary! The index page merely replaces the default one on the device that did nothing other than a client-side redirect by meta tag to redirect.php. Replacing the existing index page keeps the URL clean – whatever resource is requested is served over that URL.

There’s some logging that happens right up front in the file but it is very, very consciously only grabbing info that would be logged by a webserver anyway: time stamp, requested address, HTTP accept headers (to identify whether it’s an API call or a browser call), the IP address of the device (helps for looking at associated requests and the user agent (should give you an idea of the client being used).

What’s not logged is far more important and that’s cookies. They’re reflected back to the screen as you can see above, but they are absolutely, positively not logged anywhere and for those that did (do?) come along to my talk, the reason will be crystal clear.

tl;dr

Secure your web services! Anything you don’t want an attacker observing or manipulating needs to be sent over HTTPS and that includes auth cookies. Oh – and turn off your Wi-Fi in public!

Introducing the OWASP Top 10 Web Application Security Risks for ASP.NET on Pluralsight

2013-05-01T07:02:00.001+10:00

I’ve been a little bit busy the last few months and here’s why – my first Pluralsight course, the OWASP Top 10 Web Application Security Risks for ASP.NET. Actually, if I’m honest, it’s been a lot longer than that in the making as my writing about the OWASP Top 10 goes all the way back to right on three years ago now. It begin with the blog series followed by the free eBook then last year the instructor lead training for QA and now finally, a complete online video course via Pluralsight.

For the uninitiated, Pluralsight is what they call “hardcore developer training” and it’s predominantly produced by fellow MVPs, community leaders and other subject matter experts who many of you would be very familiar with (there’s a great little article on TechCrunch with a very glowing overview of Pluralsight here). The quality of Pluralsight’s authors really are top notch and it is an honour to be able to contribute to my own little corner of expertise. The content is subscription based and starts at only $29 per month (and there’s a free 10 day, 200 minute trial if you’re not sure). You can watch it online via the browser or native clients for a variety of devices and depending on your subscription level, even save the courses offline.

Pluralsight as a training service is an absolutely fantastic resource and one I have used on many, many different occasions now. The breadth of content is huge and includes everything from the latest enhancements to ASP.NET 4.5, nitty gritty detail about LINQ, lots of fancy tricks in Entity Framework and a heap more in the ASP.NET space. Then of course you’ve got everything you could want to know about client technologies such as jQuery, CSS, HTML and on and on. Take a spin through the top courses and you start to get a sense of the breadth of content.

One thing I’ve learnt working with a bunch of different people over the years is that everyone has their own style of learning. We all like absorbing information in different ways and what I like about the structure of Pluralsight is that you have the choice to either sit through an entire course and go through in a very structured fashion, pick just one module on a discrete topic and learn everything about it or drill down even further and just pick one clip from within the module.

I’ve used each of these approaches in the past, most recently when I really wanted to get up to speed on Entity Framework 5 enum support. There’s plenty of info out there on this but I knew that Julie Lerman is the person when it comes to EF so I spent 6 minutes watching that topic in her Getting Started with Entity Framework 5 course and had exactly what I needed to, well, get started!

Let me tell you a little more about what I’ve created.

What’s in the OWASP Top 10 for .NET developers course?

Getting back to my own course, there are (unsurprisingly) 10 modules that align to the OWASP Top 10. This now very familiar list includes:

Injection
Cross-Site Scripting (XSS)
Broken Authentication and Session Management
Insecure Direct Object References
Cross-Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Unvalidated Redirects and Forwards

What I think is important though is how I’ve structured these modules. You see, my view is that for developers to really grok security concepts they need to see it in action. Of course they need to understand the principles behind it as well, but there’s nothing quite like seeing password hashes cracked or wireless traffic sniffed, that stuff really hits home. I also believe that it’s absolutely essential that risks are related back to practical instances where they’ve been exploited so every module has an industry precedent it refers to. It’s very easy to treat a risk as hypothetical or academic until someone actually goes and does nasty things with it then suddenly everyone starts paying attention (Firesheep was a great example of this in terms of the risk of not having SSL everywhere).

What all this means is that each module is broken down like this:

An introduction to the topics that will be covered in the course
The OWASP overview of the risk including severity, threat agents and attack vectors
Anatomy of an attack – this is the interesting bit as it involves exploiting the app
The risk in practice where there’s been a precedent of it being exploited in the industry
Mitigation demos – usually four or five ways of mitigating the risk
Further information on the risk via slides or more demos

It’s a very practical course with most of it living in Visual Studio and the browser then where it adds value or just needs further explanation there’s info and graphics on slides. Certainly the preference is always to demonstrate though as again, practical relevance is what really helps security principles hit home.

All in all, there’s 8 hours and 6 minutes worth of content with some modules being relatively short (broken auth and session managements is under half an hour) and others being more comprehensive (transport layer security is nearly one and a quarter hours). I’ve tried to only include content of tangible benefit and break them down into very discrete units. Whilst 8 hours is quite long for a Pluralsight course, there are 121 clips in total so you’re looking at about 4 mins each. The longest is just over 11 mins and demonstrates an attacker sniffing wireless traffic whilst the victim browses a website then has their session hijacked due to insufficient transport layer protection. IMHO this is the best piece of content in the whole thing!

How should you take this course?

Like I said earlier, everyone likes learning differently and I totally get that some people like bite-sized information about discrete topics and others want to absorb things in a more formal, structured fashion. How you take this course will also come down to your familiarity with the topic; you may have a good understanding of the intricacies of SQL injection but CSRF remains a bit strange. Perhaps XSS is familiar but why unvalidated redirects are a risk seems odd.

What I will say though is that many of these risks have interdependencies and the course material does touch on this at multiple stages throughout the modules. I talk a lot about whitelists which are first introduced in the SQL injection module, the membership provider concepts in the third module on broken authentication are then reused at multiple points such as when I talk about cryptographic storage. The course builds on itself, module by module.

Ideally, absorb the whole thing piece by piece and in sequence. The assumptions I make about the material that has already been covered and the knowledge gained will make a lot more sense. There are also various segue ways into tangential security issues throughout the modules so they do cover more than just what the name might imply.

Why should you take this course?

We have a problem. As developers, we’ve got a lot to answer for and you see the results of security shortcuts on the news on a daily basis. As I’ve written before, the problem with website security is us. We are the ones designing the systems which expose excessive data, leak error messages and fail to properly secure credentials. Sometimes these are decisions made beyond our control with full consciousness of the risks but more often than not, it’s “us” thinking that encoding is encryption, that our admin systems are safe because nobody knows they’re there and that salting and hashing passwords is enough. It’s not, they’re not and it isn’t.

In so many of these cases it would have taken just one person on the development team to say “Hey, let’s think twice about this” and disaster would have been averted. But of course you don’t know what you don’t know and that’s why the education component is so critical.

My overwhelming strongly held belief – and this isn’t just about security – is that we must invest in our developers. The difference in cost between the good ones and the bad ones is a paltry sum (if indeed the good ones earn any more at all) but the difference in effectiveness is measured in an order of magnitude. When you do look at it in the context of security, investing in education will always seem like an excellent idea in hindsight. Whilst First State Super was looking down the barrel of losing a $23m contract because the developers didn’t understand the simple risk of insecure direct object references, security education must have seemed like a fine idea and there are many, many similar examples.

If security is important to you as either a developer or someone responsible for a development team, find a day. Just one day and you’ll get all the way through the course. Do it over a week and knock a couple of hours of each day before coffee break and you’re done. For most developers, they’ll end that week having learnt a whole lot of totally new stuff and who knows, it may quite possibly one day save their employer from ending up on the front page of the news.

Inside the sausage factory

Moving away from the course content itself, I thought some people might be interested in what goes into creating a Pluralsight course as there’s a lot more to it than what you might assume from face value alone. Firstly, for a new author such as myself there’s an audition process and a pitch; you’ve got to have both good content and be able to deliver it to Pluralsight’s standard. As an author, there’s a bit of work involved but as a customer, you really appreciate this as it means you get a consistent high-quality experience across courses.

Once all that’s ticked off the real hard work begins. For each module I produced I’d work out a series of clips and create a run-sheet of how I’d execute each one. This involved preparing slides, a sample app and then usually doing a dry-run of each clip before recording it. When everything was ready I’d drop a screen back to 1024x768 (the default video resolution) and try to record the whole thing in one go with Camtasia. Kind of.

I say “kind of” because although it’s one go, every time I so much as stuttered or ummed or rambled ever so slightly, I’d record it again. This is what killed me with this course because I just didn’t want to produce anything I didn’t feel was absolutely perfect. I’ve seen plenty of video material in the past that just wasn’t slick – those little glitches really irk me and I wasn’t going to be letting any of them into my course. What it meant though is that there’s rarely more than 10 seconds of video that was recorded in one continuous flow. That’s not because I continually made errors (there’s a degree of that), but rather because I wanted to get a clear message across then think very, very carefully about what made sense next.

Sometimes I found myself having to stop and say “Ok, when I produce this, go back to that earlier section then overlay the audio I’m about to record into the middle”. Other times I’d have to re-record audio when I listened to it later on during editing because an important part of the story was missing, I’d just skipped it in the excitement of the recording. What it means is that my Camtasia timelines all look like this:

What you’re seeing here is lots of chopping and editing just to get everything lining up perfectly. It ain’t pretty to look at, but it makes a lot of difference to listen to.

All of this comes at a cost – a time cost. Just to give you a rough idea, here’s how I reckon it breaks down for every minute of produced video you watch:

3 minutes of preparation (run sheet, sample app, slides, general research)
2 minutes of captured video
7 minutes of editing
2 minute of producing, packaging slides, app and assessment

In other words, every time you watch a minute of video it has taken about 12 minutes to get it to where it is. Across 8 hours and 6 mins of content that’s about 113 hours of work. That doesn’t sound too bad, but it’s amazingly monotonous, at least the editing is. It basically means I’ve spent my evenings and weekends for the last few months looking at this:

I started all this at the end of Jan and in amongst all this I had numerous dramas to deal with including needing to completely rebuild my machine after a catastrophic crash, trying to schedule recording around noisy kids, re-recording an entire clip due to noisy kids in the background and being away at the MVP summit for a week. It also finally pushed me into getting properly acquainted with my Pineapple (it makes an appearance in the section on transport layer protection) which was a very lengthy (and ultimately very fulfilling) process.

This was an epic piece of work but I’m enormously happy with the result, it’s undoubtedly the most comprehensive, polished tutorial I’ve produced to date.

What’s next?

I have some ideas… no really, over the last six weeks as the end has begun to come into sight I’ve started jotting down notes for a new security course that’s quite a bit different to this one. In fact I think I have a great angle, all I need is for this course to prove popular enough for Pluralsight to want to invite me back, so it’s up to you now!

Your Mac, iPhone or iPad may have left the Apple store with a serious security risk

2013-04-29T16:06:00.001+10:00

Just over a year ago to the day, my wife and I walked into the Apple store in Sydney’s CBD and bought her a shiny new MacBook Air. Macs weren’t familiar territory for us so we happily accepted the offer for a staff member to walk us through some of the nuts and bolts of OSX. That was a handy little starter and we left the store none the wiser that the machine now had a serious security risk that wouldn’t become apparent for another year.

A couple of weeks ago I wrote about my new favourite device, the Wi-Fi Pineapple. Despite its friendly tropical name, the Pineapple is a piece of cigarette-pack-sized professional security equipment I picked up online for $100 to help me demonstrate secure coding practices. Specifically, it’s helping me educate web developers about the risk of not using encryption between browsers and the websites they’re communicating with, something that needs to be built into the design of the site itself.

Among various party tricks packed into this little piece of equipment is a feature called “Karma” and it works like this: When you connect a device to a wireless network – let’s imagine the network is named “WILSON” for the purposes of demonstration – the device then continues to look for that network for perpetuity. What that means is that the device (laptop, smart phone, tablet, etc.) is running around shouting “WILSON, WILSON, where are you WILSON?” What Karma says when it hears this is “I’m Wilson, let’s get connected” and if WILSON wasn’t originally secured with a wireless password, the device connects to the Pineapple automatically. It now looks just like a normal wireless connection and it has been made without any action whatsoever on the user’s behalf.

You didn’t know this could happen? It’s written right there on the wireless network screen of every iOS device, albeit without explaining that “Known” means nothing more than an access point claiming to be exactly what the device has just publicly broadcast it’s looking for:

So what’s the risk of a device connecting to the Pineapple (or any similar equipment – it’s not the only one) without knowing it? It means that every single byte of data that passes through that connection and is not encrypted can be read or changed by an attacker. Passwords, personal information, photos, videos and anything else not properly protected by the website can be intercepted. Links to secure login pages, documents, emails and even banking websites can be manipulated when that protection doesn’t exist.

What’s now evident is that a large number of devices are leaving Apple stores after having been connected to an insecure network leaving them at risk for years to come. Let me explain.

The “Apple Demo” conundrum

When I wrote the blog post I mentioned above I commented that whilst testing the Pineapple I noticed some unexpected traffic flowing through it, traffic that looked like this:

This is my wife’s MacBook Air and I was able to intercept her internet traffic simply because she had wandered into range. This struck me as odd at the time because she had already been connected to our (secure) home wireless that also had a much stronger signal than the Pineapple’s. Sure enough though, she was now connected to the Pineapple’s rogue access point under the name “Apple Demo”:

I made a note of this in the post then moved on.

Then this weekend just gone I was at a Microsoft event in a small room with dozens of fellow techie people, all with their laptops out for hours on end. Some of them were Macs. In amongst participating in the activities of the day, I was also preparing for a conference talk I’m doing down in Melbourne later this week which will involve using the Pineapple to demonstrate the risk of websites that don’t implement sufficient security measures. Without giving away the details of a yet-to-occur event, I had configured the device to simply see if anything would connect to it – and it did. Here’s what happened:

This is a “Probe Request” from a Wi-Fi device which as I explained earlier, is essentially the device calling out “WILSON” except that in this case, it’s calling out “Apple Demo”. The Pineapple then responds with “I’m Apple Demo” and a successful association is made. Had the Pineapple been connected to the internet, all the unencrypted communication between the device and any websites it visited or services any apps connected to could have been logged or manipulated.

In the image above, the first and last lines contain the partially blurred MAC address – the uniquely identifying fingerprint that all network devices have – of the device that connected. The first three sets of two digits are the organisationally unique identifier which tells us who manufactured the device. You can check it up online and you’ll get a result that’s not too surprising:

In the very small amount of testing I’d done with the Pineapple, this was the second Mac that had connected to the same insecure network it had previously been associated to. This was more than just coincidence and far too prevalent for such a small sample size. It was time a visit to the Apple store.

The Sydney Apple store

As is usually the case with Apple, the Sydney store is an impressive piece of architecture with an amazing glass facade:

I’d made an appointment with a Genius to take a look at my iPad and had a bit of time to kill first so thought I’d take a look at what all the display models were connecting to. First up was an iPad mini:

And then a MacBook Pro:

Although not surprising, it’s reasonable validation of the assumption regarding the origin of the other “Apple Demo” machines I’d been seeing. Of course the main thing is that the network is still insecure – there’s no padlock icon hence no Wi-Fi authentication is required. Now none of that matters in this case anyway – you’re not exactly about to do anything of a nature where you’d want to protect your data using floor stock.

I go upstairs for my appointment with the Genius and explain two issues I’m genuinely having with the iPad that irk me. Both issues will require internet to demonstrate. The Genius – let’s call him “John” – is exceptionally helpful and he promptly directs me over to the Wi-Fi settings on the iPad and has me select this:

It’s “Apple Store” rather than “Apple Demo” but the risk is identical – there’s no wireless password and the device will now happily remember this name and attempt to reconnect to it at any time. We finish our session and I leave the store.

I come home, turn on the Pineapple and immediately see this:

My once-secure iPad has now become vulnerable. As soon as I walked out of the store the device started looking to reconnect to anything that would acknowledge it. Consider the consequences of this: as soon as someone walks out of the Apple store after receiving support it’s highly likely that an attacker can begin immediately monitoring their internet traffic. It’s that easy.

What can you do if you own a Mac?

When I looked at the network properties of my wife’s Mac, obviously there was a stored connection to Apple Demo:

What really made the risk hit home though was when I looked at the “Advanced…” settings of the network:

The Apple Demo network is the first on the list and will take priority over all networks that came after it. My wife’s machine first connected to Apple’s network then we came straight home and set it up on our own. Even now, one year later, the machine is still prioritising the first network it connected to and dropping off the newer one. This meant that the Pineapple was able to hijack the connection even when the machine already had a perfectly legitimate association to a wireless access point.

The solution is simply to delete any networks where the Security is “None”. That’s easy on the Mac, not so much on iOS.

What can you do if you own an iOS device?

It’s a little trickier in iOS as there’s no way of viewing the networks the device has previously connected to and consequently no way of removing the insecure ones. In fact the only way you can forget an individual network and not automatically reconnect to it is by selecting it when the network is in range:

This isn't going to do most people much good as they’re not exactly going to travel back to the store just to have their device forget the network. If you think it might have gone through the demo or support process in store or for that matter connected to any unprotected wireless network you’ll need to erase all your trusted ones and start from scratch.

Jump over to “Settings” –> “General” –> “Reset” and then “Reset Network Settings”:

It’s going to make it unpleasant if you regularly connect to secure networks you now need to go and retrieve passwords for again, but it will ensure your iOS device hasn’t left Apple with a serious security risk.

Can’t this happen after connecting to any insecure wireless network?

It sure can. If you go down to McDonalds and jump on their free Wi-Fi and it doesn’t require a password, you’ve got exactly the same problem. The difference, of course, is that McDonalds makes fast food whilst Apple makes devices with networking capabilities. McDonalds (and similar) need to lift their game and secure their network (and of course deal with the usability issues that creates) but to some degree they can be forgiven for the oversight.

When you buy a brand new phone or tablet or laptop you expect to walk out of the store with a secure piece of equipment, certainly one that would take some amount of effort to exploit. That’s not what’s happening after Apple connects it in-store and that’s the real story – it’s insecure by default and vulnerable to a simple attack from day one.

This may well be the case with other stores as well. I don’t know how Microsoft or Samsung or other retail outlets selling similar devices and offering a similar setup service handle wireless connections, but clearly if they’re not using a protected network then they’re leaving consumers with exactly the same risks.

Keeping customers safe is as easy as pie

Paradoxically, there’s a little meat pie shop just around the corner from Apple’s gleaming architectural masterpiece. The pie shop is nothing more than a hole in the wall with a counter one staff member can barely fit behind. Somehow they still manage to offer free Wi-Fi and use an ingenious means of properly securing it for their customers. It works like this:

That’s all it takes – kindly provide customers with a Wi-Fi password when they ask and this entire problem just disappears. Good work by the pie shop!

For the more technically minded

For those who want some more detail, here are a few key points:

Traffic sent via HTTPS can’t be intercepted and either read or manipulated by a man in the middle, at least not without resorting to attacks against the protocol such as BEAST. Apps that make calls to APIs over SSL and validate the certificate are in good shape as are browsing sessions which occur entirely over HTTPS.

Browsing sessions that begin over HTTP are not safe even if they redirect to HTTPS, for example if you simply type americanexpress.com into the address bar and the browser defaults to an unencrypted scheme (read about sslstrip if you want to know more). Webpages which load login forms over HTTP or embed them in an iframe within an HTTP page (even if the login page is HTTPS) are also at risk as the original HTTP request can be manipulated to load any other content an attacker desires (such as a rogue login page). Authentication cookies not flagged as “secure” and sent over an unencrypted network also pose a serious risk.

The Pineapple can detect probe requests for WPA protected networks but devices looking for them won’t automatically or even manually make the association if you try it that way. You’ll see the names of secure networks listed in the device’s Wi-Fi settings but that’s it – the initial authentication handshake won’t occur and the device won’t connect.

In this case, Wi-Fi security isn’t about protecting the network from unauthorised access nor is it about protecting any given client’s data from monitoring by other clients. This is entirely about not leaving the device in an insecure state long after the association with the network in question has ended.

Summary

What all this means is simply this: if Apple helped you set your device up or provided you with support in the store it’s now exceptionally easy for an attacker to monitor and manipulate the majority of internet traffic that passes through it. So long as an attacker can get in range of the wireless (and I’ve already done it accidentally and with good intent on multiple occasions), they own your device.

Obviously this was all tested on devices that had been through the Sydney store (this was the most likely source of the one I observed at the conference on the weekend). I don’t know how other Apple stores in other locations handle the situation described above, but given the carbon copy design, staff and experience in stores across the globe, I’d be surprised if the practice differed.

I’m still a happy iPhone and iPad user. My wife is a happy Mac user. There is nothing about the products per se that is insecure with regards to the information above, it’s simply an in-store process which leaves them vulnerable. It’s also easily rectified by simply putting a password on their wireless – any password and the devices won’t be fooled into connecting to rogue access points in the future. I know that doesn’t make for as slick an experience as it currently is for customers, but it’s the only way to solve the issue short of the staff manually removing the connection again at the end of the session. Unfortunately, all this is also only any good for new devices and I’ll wager that as of right now there are thousands of devices in Australia alone that have been left vulnerable.

Disclosure

Yesterday I contacted Apple and shared the risk regarding their in-store practices:

Recently I've learnt that customers are receiving support for their Apple products in store with the help of Geniuses who connect their devices to unprotected wireless networks, from my experience named either "Apple Demo" or "Apple Store" (certainly this is the case in the George St store in Sydney). The association to a network with no security then leaves the devices vulnerable to inadvertently connecting to rogue access points which respond to probe requests the devices send out specifically looking for the presence of an insecure network it has once known.

In short, when a device leaves an Apple store after having been connected to an insecure network it is now at risk of an attacker hijacking internet traffic. This is a trivial process and easily exploited by those with malicious intent. I've observed this first hand with my wife's MacBook Air and my own iPad as well as observing other Apple devices exhibiting the same behaviour.

Your review and comments would be most appreciated.

I’ll update the post with any responses.

The beginners guide to breaking website security with nothing more than a Pineapple

2013-04-17T20:26:00.001+10:00

You know how security people get all uppity about SSL this and SSL that? Stuff like posting creds over HTTPS isn’t enough, you have to load login forms over HTTPS as well and then you can’t send auth cookies over HTTP because they’ll get sniffed and sessions hijacked and so on and so forth. This is all pretty much security people rhetoric designed to instil fear but without a whole lot of practical basis, right?

That’s an easy assumption to make because it’s hard to observe the risk of insufficient transport layer protection being exploited, at least compared to something like XSS or SQL injection. But it turns out that exploiting unprotected network traffic can actually be extremely simple, you just need to have the right gear. Say hello to my little friend:

This, quite clearly, is a Pineapple. But it’s not just any pineapple, it’s a Wi-Fi Pineapple and it has some very impressive party tricks that will help the naysayers understand the real risk of insufficient transport layer protection in web applications which, hopefully, will ultimately help them build safer sites. Let me demonstrate.

What is this “Pineapple” you speak of?!

What you’re looking at in the image above is a little device about the size of a cigarette packet running a piece of firmware known as “Jasager” (which over in Germany means “The Yes Man”) based on OpenWrt (think of it as Linux for embedded devices). Selling for only $100, it packs Wi-Fi capabilities, a USB jack, a couple of RJ45 Ethernet connectors and implements a kernal mode wireless feature known as “Karma”.

Huh? This is starting to slip into the realm of specialist security gear which is increasingly far away from the everyday issues we deal with as software developers. But it’s exceptionally important because it helps us understand in very graphic terms what the risk of insufficient transport layer protection really is.

The easiest way to think of the Pineapple is as a little device that sits between an unsuspecting user’s PC (or iPhone or other internet connected device) and the resource they’re attempting to access. What this means is that an attacker is able to launch a “Man in the Middle” or MiTM attack by inspecting the data that flow between the victim and any resources they’re accessing on the web. The physical design of the Pineapple means that victims can connect to it via its Wi-Fi adapter and it can connect to a PC with an internet connection via the physical Ethernet adapter. It all looks a bit like this:

This isn’t the only way of configuring the thing, but being tethered to the attacker’s PC is the easiest way of understanding how it works. The point of all this is that it helps tremendously in understanding the risk of insufficient transport layer protection because ultimately, it’s websites that don’t do a good enough job of this that put the victim at risk. More on that later.

But why on earth would a victim connect to the Pineapple in the first place?! Well firstly, we’ve become alarmingly accustomed to connecting to random wireless access points whilst we’re out and about. When the average person is at the airport waiting for a flight and sees an SSID named “Free Airport Wi-Fi”, what are they going to do? Assume it’s an attacker’s honeypot and stay away from it or believe that it’s free airport Wi-Fi and dive right in? Exactly.

But of course that’s still a very conscious decision on behalf of the user. As it turns out, the Pineapple packs a much more subversive party trick to lure unsuspecting victims in…

Karma, baby

The Karma feature is best explained on the Pineapple website:

Most wireless devices including laptops, tablets and smartphones have network software that automatically connects to access points they remember. This convenient feature is what gets you online without effort when you turn on your computer at home, the office, coffee shops or airports you frequent. Simply put, when your computer turns on, the wireless radio sends out probe requests. These requests say "Is such-and-such wireless network around?" The WiFi Pineapple Mark IV, powered by Jasager -- German for "The Yes Man" -- replies to these requests to say "Sure, I'm such-and-such wireless access point - let's get you online!"

Wait, what?! So devices just randomly connect to the Pineapple thinking it’s a legitimate AP? Yep, here it is in detail:

Simple, huh? The problem is that wireless devices are just too damn trusting. Once they establish a connection with an access point they usually happily reconnect to it at a later date. Of course if it’s a protected network they still need to have the right wireless credentials, but if it’s an open network then the Pineapple asks for no such thing, it just lets the device straight in whether the device thinks it’s connecting to a legitimate access point or not.

So that’s how she works, a combination of simply providing an access point that victims connect to on their own free will or being tricked into connecting via Karma. Let’s get it setup and see it all in action.

Windows tethering

The easiest way to access the device and get started with configuring everything is to tether it to a PC with two network interfaces. This can be one with a couple of NICs connected to Ethernet or in most cases (and as with the diagram above), a laptop which commonly has a wired NIC and a wireless one.

What we’re going to do is configure the wired Ethernet NIC which we’ll plug the Pineapple into then share the connection on the wireless adapter so that the traffic from the Pineapple can be routed through it, effectively just passing everything through the PC. This is all pretty straight forward and it starts out from the Network Connections settings:

Just one little note before proceeding: I’m going to obfuscate any SSIDs or MAC addresses used in this post with a grey box simply because they explicitly tie back to my devices (or my neighbours’ devices!) and I’m not real keen on publicly identifying them. Who knows what they might get up to in future…

Jump into the properties of the wireless adapter, and head over to the sharing tab then make sure that “Allow other network users to connect through this computer’s Internet connection” is checked:

That’s that adapter done, now let’s do the wired one. Jump into the properties locate the “Internet Protocol Version 4 (TCP/IPv4)” item:

Now grab the properties of that guy and configure a static IP address and subnet mask and set the DNS server as follows:

That’s it – job done.

Accessing the device

Once tethering is setup and the Pineapple is connected to Ethernet via its PoE LAN port, you should be able to access the Pineapple directly from within your browser via the IP address. You can hit it on 172.16.42.1/pineapple or if running a newer version of the firmware (more on that later), the IP address and port 172.16.42.1:1471. All things going well, you’ll be challenged to authenticate:

The default credentials are username “root” and password “pineapplesareyummy” after which you should be in:

That’s the first bit done, tethering is working and we can actually access the device, now for a bit of preparation.

Housekeeping

Before you start anything, get the firmware up to date. If I’m honest, I’m always scared about updating any firmware on any device because when it goes wrong it’s often a whole world of pain to get yourself back out of trouble again. You’re much better off doing this before you create any dependencies on the device or configure anything. I had a couple of glitches doing mine and it took a few goes, but in theory, you jump over to the “Upgrade” link on the nav, hit “Check for Upgrades” then if required, pull down a package, enter the MD5 hash of it (provided on the upgrade site) and upload the package:

One little thing you want to remember here: if like me, your GUI was originally accessed via 172.16.42.1/pineapple, keep in mind the newer version of the firmware now puts the GUI behind a port so you want to hit 172.16.42.1:1471 instead. If, also like me, you try hitting the old address after the install and reboot you’ll keep getting redirected and not much will happen. Then you’ll think you’ve rooted your device (that’s the Australian rooted, not the American one) and start wondering how in the hell you’re ever going to get it back to a known good state and, well, just remember the port change!

Next up, jump into configuration and change the default SSID. The device is configured to show “pineapple” followed by the first and last octets of the Wi-Fi adapter. Change it to something a little more subtle and make it persistent so that when you fire it back up later you’re not reverting to the default:

The other thing you want to do on the configuration page is to blacklist the MAC address of the machine you’re going to be orchestrating the Pineapple from and any other devices you don’t want inadvertently connecting to it. This is important if you don’t want to “Pineapple yourself”! Seriously though, it can get very confusing otherwise so this makes good sense.

Lastly, let’s change that default password, the last thing you want is someone else taking over your Pineapple whilst you’re pretending to be a l33t hax0r! Over to the “Advanced” link then down to the bottom of the page:

That’s pretty much it for what I felt need to be configured via the UI, let’s go and get a bit low-level and enter the command shell.

SSH’ing in

This is where it gets a bit scary for Windows people! Keeping in mind that the Pineapple is ultimately just a little Linux box with some fancy party tricks, there are times when you’ll need to get your hands dirty and enter the secure shell world. This is something I do very, very rarely and if memory serves me correctly, it was 1999 when I last regularly used a *nix machine so it was pretty unfamiliar territory for me as well.

Moving on, one of the easiest way of SSH’ing into the device from Windows is to go and grab PuTTY. With this in hand, the only configuration you need is the IP address of the device:

Open the connection and you’re into the shell:

Follow the instructions in the screen above enough times and suddenly the shell doesn’t seem to look so bad!

Keep in mind that this is the OpenWrt distro of Linux and being intended for embedded devices, it’s a pretty lean edition. Don’t expect to find all the features you’d normally see in a full blown desktop edition – many of them are not there so keep that in mind when attempting to use commands that might not be supported.

Once you’re SSH’d in you can go ahead and set the time and time zone correctly. This’ll be well outside your comfort zone if Linux shells are a bit foreign to you (and admittedly I had to look much of this up again), so here’s the whole thing step-by-step:

Change the directory to /etc/config: cd /etc/config
Edit the config file in vi: vi config
Navigate down to the “option timezone” line and delete out the existing “UTC” value (unless, of course, you are in the UTC time zone!)
Jump over to the timezones table on the OpenWrt site and find the appropriate one for your location.
Enter the value from the “TZ string” column into the shell: Hit the “i” key to insert then type away

It should look kinda like this when you’re done:
Save the file: Hit the esc key to stop editing then :wq<enter>
Reboot the Pineapple: reboot <enter>

A little tip for new players: every time I tried saving the config change I got the following message and nothing actually saved:

This, quite clearly, means that there is no available capacity on the device and after wasting considerable time trying to work out why I couldn’t use vi correctly, this become quite clear. Welcome to Linux!

Working with ext4 format and USB drives

You’ve got very little space on the device, there’s literally only an 8MB ROM and 32MB of RAM so by the time you load everything into there just required for the device to run, there’ve not much left. It’s certainly not going to be enough to start doing fancy things like storing packet captures which mount up very quickly.

Fortunately it’s all expandable via USB so one of the first things you want to do is grab a spare thumb drive and get it ready for the Pineapple. But there’s a catch – as with many things Linux, this is a slightly different world to good old Windows so you can’t just take your NTFS formatted USB stick and chuck it in, you’ll need to partition it for ext4.

In theory, this is easy enough to do in the Windows world using a tool such as MiniTool Partition Wizard. That sounds just fine – except it’s not and you will only discover this through either banging your head against the wall for hours or reading what comes next. Whilst the aforementioned tool (and I assume others like it running on Windows) seemed like a good idea, I just couldn’t get it to play nice. I’ll spare you the detail as I’ve captured them all on the Hak5 forum, but in short, the USB would mount and be readable from shell but I could never install Infusions to it (think of them as apps for the Pineapple) which I’ll come to shortly. It turns out that additional partitions were being created and that simply made things not play nice with the Pineapple despite no obvious warnings to that effect.

The solution turns out to be that I needed to create the ext4 partition directly from a Linux machine. If this world is unfamiliar to you, there’s a (relatively) low friction process courtesy of an Ubuntu LiveCD. This involves downloading an Ubuntu ISO, burning it to CD (or DVD or bootable USB), running up an in-memory instance of Ubuntu and partitioning the USB from there. I then followed the guidance provided in the very easy to follow page on enabling USB mass storage with swap partition as the swap partition looks like will come in handy later on when you want to start doing some other tricks with the Pineapple.

That sounds like a hassle – running up an entire new operating system just to partition a USB drive – and certainly it was a drama getting to the point of realising that’s what I needed to do, but once you know what needs to be done it’s quite simple. Of course it would have been even simpler if I had a handy Linux machine hanging around somewhere and for many people, that will already be the case.

Once it’s all setup you should see the storage appear under the “USB” menu item like so:

You’ll also probably want to read from the drive back on your Windows machine at some point (I’ll save some packet captures to it a little later on) and I found DiskInternals Linux Reader did the job just fine.

Testing connectivity

Now that we’ve got everything ready to roll, let’s jump into the fun stuff! Back in that first screen grab of the UI, only the “Wireless” and “Cron Jobs” services were running so let’s fire up “Mk4 Karma” and set it to run automatically via the “Autostart” feature so the device just needs to be powered up for everything to kick into action:

Now we should be able to jump over to a device such as my iPhone and see some new SSIDs:

This is a whole lot more interesting once you understand what’s under the grey box (which again, I’ve deliberately obfuscated), so let me explain what’s happening; each unsecured network is the Pineapple responding to a probe request from the iPhone with the name of the SSID it was previously associated with. The names include that of an old wireless router I replaced some years back, my parents’ network I was connected to interstate just the other day and an airline lounge in a far flung corner of the world. All of the secured networks are legitimate (mine, my neighbour’s, etc.)

We’re also seeing the new SSID of the Pineapple that I set earlier (“trust me”) and I’ve gone ahead and explicitly connected to that for demonstration purposes. This now makes the homepage of the GUI much more interesting:

What’s particularly interesting is what you can’t see which are all the SSIDs being probed for. These are predominantly APs I’ve connected to in the past and the MAC addresses doing the probing are predominantly my own (the Wi-Fi strength on the Pineapple is not great so I’m seeing mostly nearby devices), but you do see a few unfamiliar ones pop up which are clearly other people’s devices. It does make you wonder what risks might be present from devices leaking SSID names they’ve previously associated to; “Why is my colleague’s Android trying to connect to ‘Mistress Angeliques BDSM Palace’?!”

Anyway, right at the end of the above image you can see the association of my iPhone to the Pineapple which means we can now drill down and get a detailed report of what’s going on:

This is mostly self-explanatory, the signal strength is kind of interesting as it starts to give you a sense of the distance the victim might be from the device. Of course what will be really interesting is the rx bytes – that’s about one a half MB that the phone has already received through the Pineapple and under normal operating conditions, the user would have absolutely no idea there was an MiTM. Let’s move on to taking a sneaky look at those packets because that’s where things get really interesting!

Packet capturing

Now that we’ve got all the nuts and bolts in place, let’s start capturing the data. There are a couple of different ways of doing this and probably the simplest is to monitor the traffic moving through the Ethernet adapter on the attacker’s PC. Once we start getting into the realm of traffic monitoring we need to start looking at packets and the best way to do this on a PC by a long shot is to use Wireshark.

One of the best thing about Wireshark is that it’s free. This is no lightweight tool either, Wireshark is very full featured and is arguably the de facto standard for monitoring, capturing and analysing packets flying around a network. As powerful as Wireshark is, it’s also relatively easy to get started, just fire it up, choose the network interface you want to capture which in this case is the Ethernet adaptor (remember, this is the NIC the Pineapple is connected to) then jump down to the “Capture Options” button:

The capture options start to give you an idea of the extent of the configurability but we’ll just leave all that as default and start the capture:

Once started, you should immediately begin to see packets flowing through the NIC:

Right about here the penny should drop – this is someone else’s traffic! Ok, it’s really my own traffic from my iPhone but of course as we now know, the Pineapple has the ability to easily trick a victim into connecting to it whether deliberately or by default as their device looks for familiar SSIDs. Long story short is that this could just as easily be someone else’s traffic.

I’m not going to delve into exactly what we can do with that traffic right now because I have subsequent posts planned that will demonstrate that, for now though let’s just filter that traffic down to something a bit more familiar – HTTP. You see, the traffic above includes a whole bunch of different protocols which for the purposes of talking about secure website design aren’t going to be of much use. Let’s add in a filter of “http” and load up a popular website with developers:

As I’ve written before, Stack Overflow serves everything outside the logon over HTTP so it’s easy to monitor that traffic (including the authentication cookie). Once the traffic is captured, you can either save it as a PCAP file for later analysis or right click and follow the TCP stream which then gets you into the entire request and response (including the headers with those valuable auth cookies):

I’ll stop there because that’s enough to demonstrate that everything is working as expected. Just to illustrate the power of the Pineapple, as I was writing this piece and watching the Wireshark traffic, a whole bunch of packets started appearing that weren’t mine:

Turns out that my wife had wandered into range with her MacBook Air and it had automatically associated to the SSID “Apple Demo” which I can only assume is the access point the Apple store connected her to when walking her through the shiny new machine she recently bought. So there you go – right out of the box a brand new machine is already falling victim to the Pineapple without even trying.

Infusions and unattended packet capturing with tcpdump

This is the last configuration I want to touch on simply because it covers couple of important points: Infusions and using the USB drive we setup earlier. With these concepts understood I actually feel reasonably well-equipped to use the thing so they’re worth capturing here.

The physical capabilities of the Pineapple should be pretty clear by now but what might not be quite as clear to the uninitiated is what can now be achieved with clever software. I’ll write a lot more about these capabilities in the future but for now I want to just take a quick look at the concept of Infusions.

Think of Infusions as apps and the Pineapple Bar as an app store for the Pineapple only with a couple of dozen apps that are all free. The Infusions cover a variety of different domains from informational to potentially malicious so there’s a good range of use cases in there. It’s accessible via the Pineapple from the “Pineapple Bar” link in the nav and it gives you some options like so:

As you can see, I’ve already installed the “status” Infusion and by way of example, here’s the sort of info you get from it:

This can be pretty handy info in GUI format, there are also some neat real time graphs for things like CPU utilisation and bandwidth:

The really interesting one, however, is tcpdump. Now tcpdump is not an Infusion in and of itself, it’s an existing project which has been turned into an Infusion so that’s easily installable on the Pineapple and can then be managed from the GUI. What tcpdump offers is the ability to effectively do what we just did with Wireshark in terms of packet capturing but to do so locally within the device itself. What this means is that you can have the Pineapple independently capture traffic without needing to run Wireshark on a PC. In fact if you establish a connection from the Pineapple directly to the web (and there are several ways to do this), you don’t need a PC at all. Imagine just that little cigarette pack sized Pineapple sitting there on its own with its own power source and internet connection and any victims within Wi-Fi shot of it automatically connecting and having their packets captured. That’s powerful stuff.

Now that we have a correctly partitioned USB drive, Infusions can be installed directly to there:

Incidentally, it’s that highlighted “USB Storage” link that I never saw when creating the ext4 partition in Windows.

The thing with packet captures is that there can be a lot of them and they can chew up space really quickly depending on how liberal you are with the data you want to save. You can configure tcpdump to filter out a lot of the “noise” packets and restrict it to, say, only HTTP traffic or even just only to HTTP requests using the POST verb. For now though we’ll just run it up with the defaults to capture all the traffic running through the wired LAN port:

You can now sit back and let the traffic flow whilst the Pineapple captures everything anyone connected to it sends across the wire (or air, as it may be). With the iPhone connected, I browsed over to a site I know doesn’t properly protect user credentials and attempted to logon. Once done you can hit “Stop” and you’ll see a summary of the captured data:

Now we can jump over to the “History” tab and download the PCAP file:

That PCAP file is just the same as what we captured in Wireshark earlier on and you can now load it back up into Wireshark and analyse it in just the same way as you would the packets it captured directly. Alternatively, you can pull the USB out, chuck it into the PC and read it with a tool like DiskInternals which I mentioned earlier. Here’s what we can now see from my brief visit to the site

This site is particularly bad because the credentials just go into a GET request but of course the real story in the context of the Pineapple is that the whole thing is sent in the clear so it’s now easy to see everything sent by the victim and returned by the server. Keep in mind that this was all captured directly on the Pineapple (or at least on the USB) so the whole thing is now pretty well self-contained. That’s a good place to end the traffic capture for today, there’ll be much more in the future though…

Other miscellaneous info

For those of you thinking of getting yourself into a Pineapple (and I know there are a few based on Twitter chats alone), there are a couple of pre-purchase things worth pointing out. Firstly, I went el-cheapo and only got the device itself without any accessories. This means you get an AC adaptor for power and that’s it so it’s definitely not mobile.

Being able to take the Pineapple out in the wild definitely presents all sorts of opportunities not available while it’s plugged in to the mains so the USB battery pack is a must. As the name suggests, this also gives you the ability to power the device directly from USB so you can just plug it into your laptop if the juice in the battery runs out.

The other thing is that the Wi-Fi strength is pretty ordinary. By way of example, here’s how inSSIDer sees the Pineapple (in yellow, of course) versus my usual access point in blue from only about a foot away:

However, mover into the next room and the Pineapple just about drops off altogether:

There are a few different antenna options so if your intended use doesn’t involve connecting to a target within a very, very close distance then this would be worth a look. Other than that though, the only other thing that might be useful is a handy case and given HakShop has a Pineapple with battery and a case going for $115 at the time of writing, that’s probably your best bet.

The other thing that some people might find interesting is that a bunch of the code running on the Pineapple is up on GitHub. This is apparently the www folder of the device so it’s not the firmware itself, but it is a bunch of the PHP files and scripts which is kind of interesting to have a browse through.

Responsible use

I bought the Pineapple for the sole purpose of helping developers better understand the risks of insufficient transport layer security. You’re going to see me writing a lot more about the risks of loading logon forms over HTTP, embedding HTTPS login forms in HTTP pages, mixed mode HTTP / HTTPS and other similar risks. The Pineapple will help me move that discussion from a theoretical “An attacker might do this or could do that” to a very practical “Here, let me show you exactly why that pattern is risky”. Demonstrations of this kind are very powerful and they’re often the only way of getting the message through.

However, there is very clearly scope for misuse and abuse of unsuspecting victims. That incident I mentioned earlier where my wife walked into the room and suddenly I was watching her network traffic is a perfect example of how easy it is to do potentially evil things, sometimes without even trying. For those reading this and considering how they might use it, there are some great use cases for penetration testing or demoing (in)secure web app design but there is also some very, very thin ice out there. Caveat emptor.

What next for the Pineapple?

The great thing about the Pineapple is that it makes it dead easy to demonstrate a whole bunch of concepts that I often write about but haven’t always shown in execution. For example, why it’s not ok to load login forms over HTTP even if they post to HTTPS. Another one that has come up a few times (including in the Top CashBack post) is not embedding a login form that is loaded over HTTPS within an iframe in an HTTP page. There’s a whole heap of things that will be easily demonstrated within a controlled environment.

Then there’s the uncontrolled environment – the public. There’s a lot of grey area there about what can be done for the purposes of research and education without crossing the line into outright eavesdropping and getting on the wrong side of people. I do have some thoughts on it, but I’ll hold onto those for the moment…

Regardless, I’ll start producing some video material to demonstrate the ease with which this thing does its work because it’s immensely impressive to see in real time – at least I was impressed! I’ve already created a bit of video for a training program I’m putting together (more on that another day), and I reckon it comes up great. Stay tuned, there’s much, much more to come.

Useful Links

Markiv: What We Know And What We Don't Know – good general overview of features and configuration
Mark 4 setup script – very handy for seeing how to configure various things via the shell.
You just can't trust wireless: covertly hijacking wifi and stealing passwords using sslstrip – good view of defeating SSL with the device
Main Wi-Fi Pineapple site - all things Pineapple start from here

5 ways to implement HTTPS in an insufficient manner (and leak sensitive data)

2013-04-03T21:00:00.001+11:00

HTTPS or SSL or TLS or whatever you want to call it can be a confusing beast. Some say it’s just about protecting your password and banking info whilst the packets are flying around the web but I’ve long said that SSL is not about encryption.

As an indication of how tricky the whole situation is, OWASP talks about insufficient transport layer security. Not “have you done it right” or “have you done it wrong”, rather have you considered all the little nuances that go into the correct implementation of this invaluable security feature.

Naturally, when this tweet from Mark Hemmings popped up on my timeline was a little intrigued:

We’ve all seen this before right? Clearly it means your valuable password is being sent over the wire in plain text and the ghosts in the wires will immediately harvest them and do frightful things with them, won’t they? Apparently not:

This is not your usual customer service rhetoric – these guys know about iFrames! They continue:

The key here is the word “key” in that sentence. Hang on – so other pages aren’t sent over secure connections? What happens if you’re already logged on?

This is a great opportunity to revisit the quirks of HTTPS because as it turns out, Mark is spot on and there are some very insufficient practices going on here. Let me break it down into 5 discrete problems and why each one of them undermines the HTTPS implementation not just on Top CashBack, but on many other sites following the same patterns.

Problem 1: Sending sensitive data over an insecure connection

Of course you can see where the problem begins right here:

That’s right, it’s a registration form loaded over HTTP. Before we even get to looking at the claim of the login being loaded over HTTPS, we’ve got a serious problem. This isn’t even one of those common misunderstandings along the lines of “Oh but it’s safe because it posts to HTTPS” because, well, it doesn’t (and it isn’t). Watch the HTTP request after completing the form and it looks like this:

POST http://www.topcashback.co.uk/light-box/join/ HTTP/1.1

And here’s the form variables in the request body:

Yes, that really is the password I created and yes, it really is sent from my PC through all the wires to their server in plain text. In fact after registering there were 140 requests made by the browser to load assets onto the page and some of them were made over HTTPS; one to Facebook, one to Google, one to Doubleclick but zero to Top CashBack!

Problem 2: Mixed mode

Moving on, after registering I was sent a verification email and I duly followed the link. Good news – it’s an HTTPS address! Bad news, it’s not secure:

See the error at the bottom of the browser? This is your classic mixed-mode HTTPS problem where the page has been requested over HTTPS but it then embeds assets requested over HTTP. The risk here is that the integrity of those assets can no longer be verified – they could have been manipulated. Now imagine you can manipulate the JavaScript loaded into a website to do whatever you want it to; change all the links on the page, rewrite the contents, steal the cookies and so on and so forth. In short, once content has been loaded insecurely you can no longer trust the page that embedded it, even if it was loaded over an HTTPS address.

Problem 3: Sending auth cookies over an insecure connection

Clearly we’re now logged on which gives us an opportunity to move onto the next problem. Let’s jump back to the homepage and you can immediately see the issue:

You see that?! Let me help: this page has been requested over HTTP but somehow it knows that I’m logged on as it’s able to display the “My account” and “Log out” links in the top right. How can it be?

Let’s take a step back and I’ll provide some context. HTTP is a stateless protocol which means that every time your browser makes a request it’s over a whole new connection with no implied continuity between them. This is problematic because it means that you can’t persist information across requests such as an identity and the fact that you’re logged in. To work around this limitation we have the cookie, those little bytes of data that are sent between client and server in request and response headers. When you log on to a website, it’s (almost always) a cookie which is sent to your browser in the response and then sent back to the server with each request to ensure it knows who you are and that you’re authenticated.

The problem is this: if someone else can get hold of that cookie then they can become you! This is called session hijacking and it involves nothing more than an attacker intercepting the cookie, setting in their own browser then voila – they’re you! This is what Firesheep did a few years back and caused such a fuss. It was arguably a significant factor in websites such as Facebook implementing HTTPS everywhere so that sessions couldn’t be hijacked in this fashion. In fact many websites got the message very quickly, but some did not…

This risk is easily verified as the HTTP request to the page above contained the following cookie:

.TCBAUTH=33813F16896A3527C7B4AC6B8988CE50A694329C9403579EB798A74B1AF938251C6AE61C703CB4FC761A587BE9F6BA4BAC46EE62A015A07E57E3252469C7954A7EBA0AA43121620BC66A7767F85B0064906D5B0F24CBF6D5A17F3AF0392D8889F9F04B80B1AEB3AC3E7376A205D8BB795A1C64BE30AA8073FCD89289A2B8AEBF914D0F4F4EA439BB8A8F16B353AB47EECE0997D089088D8BEDB847B038A9E41FDE9E320935772FB4CAE29FF767702D30C0608FC6054F51BDF4EED3747234AC0212D359B1;

Here, I’ll show you: I copied the cookie above, inserted it into a Chrome session using Edit This Cookie, loaded up the account details page and here’s what I now have:

That’s my details! In my “attacker mode” I never saw a password, all I needed was those few bytes from the cookie sent over the insecure connection and I’m in. There are many, many ways that an attacker can get the cookie from an insecure connection. One of the easiest is simply sniffing wireless traffic as I’ve previously demonstrated, then there the good old physical wiretap or simply observing the traffic through any of the legitimate nodes it passes through; router, gateway, ISP, etc.

Once you have the cookie, you have access to everything that an authenticated user can see. For example:

I’m sure Top CashBack probably feels they’re being secure by sending this over HTTPS (and certainly that’s a good thing in and of itself), but as an attacker, it doesn’t matter one bit because I’ve already hijacked the session when the cookie was sent insecurely. All the HTTPS on the page above does is allows the attacker to load the page securely!

Problem 4. Not marking auth cookies as “secure”

This is closely related to the previous point and it’s one I wrote about just last week in C is for cookie, H is for hacker – understanding HTTP only and Secure cookies. Let’s log back in again via Chrome and inspect that auth cookie we looked at earlier on. Here it is:

See that “Secure” option? Well obviously it isn’t! The problem this creates is it means the browser will happily send this cookie across an insecure connection and indeed that’s the problem we saw above when the page loaded over HTTP was able to recognise that we were authenticated. In this case I suspect it’s actually by design (which is even worse) as if the cookie was actually secure then you’d never be able to see your authenticated state reflected on those insecure pages.

Flagging a cookie as secure means that the browser simply will not send it over an insecure connection which is exactly what you want when we’re talking about auth cookies. All the HTTPS in the world won’t save you when there’s just one single inadvertent HTTP request which discloses the auth cookie and we saw earlier, this one simple mistake could mean disclosing serious data such as banking info.

Problem 5. Relying on HTTP to load login forms

It’s taken until the last point but let me get back to the original assertion about the login form being loaded over HTTPS. Firstly, we’ve already registered over HTTP and sent our password via an insecure channel then sent that auth cookie flying around in the clear so by now the value presented by HTTPS has pretty much been shot to pieces anyway. But let’s push on.

When you hit the login button you’re presented with this following:

You know it’s secure because it has a padlock bitmap and it says “SECURE LOGIN”, right?! What actually happens here is that the browser makes a separate request to this page containing the login form which is indeed requested over HTTPS. The question is how did the browser know to request that page? I’ll tell you how, the page we originally loaded – the one requested insecurely over HTTP – has the following markup in it:

<a class="login-toggle" href="#" title="Login" onclick="ToggleLogin('https://www.topcashback.co.uk/login?RedirectURL=http%3a%2f%2fwww.topcashback.co.uk%2fhome');return false;" ><span>Login</span></a>

The problem, of course, is that when you load a page over HTTP then there’s no protection against a man in the middle manipulating the contents of the page. For example, there’s nothing to stop an attacker from changing that login path to a website of their own, they could then easily replicate the login control layout and the victim would be none the wiser. Tampering of this kind is nothing new, in fact it’s something we’ve seen many times before including in the Tunisian government example I reference here.

So how does this differ to other more secure implementations? The main thing is that “none the wiser” bit; because the login page is loaded into an iframe there’s no ability for the user to see the certificate loaded into the browser, you know, the one that’s usually perfectly clear in the address bar:

In fact on that basis alone – the fact that the certificate can’t be seen – it means the implementation is relying on the user’s trust rather than explicitly showing them “Hey, here’s the HTTPS address and the certificate”. Without either of these the user can only draw the assumption that Mark did right back at the beginning which is that their credentials are being sent in plain text.

Norton secured (so it must be secure!)

One of the great ironies with this site is the “Norton Secured” logo down the bottom right hand corner:

This gives a very reassuring report of the site:

I’ve included this to make the point that whilst it may be reassuring, in this case it’s totally useless. The seal is on a page loaded over an HTTP address so in theory, it could have come from anywhere. But that aside, the whole assertion that a logo on a page implies some form of security when there are such blatant holes is a bit ludicrous.

Summary

The point with all the HTTPS in the Top CashBack site is simply this: it doesn’t matter how many pages you’re loading securely or how many padlock icons or vendor certifications you drop on the site, one you start sending auth cookies around insecurely, you’re toast. It’s completely pointless to secure those banking details in transit but then let the auth cookie which can load the financial data back up float around in the clear. That is a very insufficient use of HTTPS indeed.