I’ve just wrapped up a couple of Hack Yourself First workshops down closer to home in Australia and true to usual form, attendees found some absolute zinger security implementations. Previous workshops have found various vulnerabilities ranging from realestate.com.au’s lack of HTTPS in their Android app (pro tip: don’t 301 HTTP requests to APIs!) to the one that really made headlines earlier this year which was the insecure Nissan LEAF app.
One of the modules in the workshop looks at enumeration risks, that is the ability to check the existence of someone’s account on a website. There’s a perfect illustration of this in the post I did on Ashley Madison last year which showed that even before the data breach, affairs on the website were never discreet; their password reset feature readily disclosed whether an email address already existed on the site.
I’m used to seeing sites with enumeration risks in the password reset, registration and login features and frankly, it’s an exception when a site doesn’t leak data through one of these. (Check the timing of logins too: slow hashing algorithms often disclose if an account exists by virtue of several hundred milliseconds delay when the username exists.) But this time, the class I ran a few days ago found a far worse level of enumeration:
— Troy Hunt (@troyhunt) August 16, 2016
This is exactly what it looks like: enter a username – any username – and the site will give you the email address. John, Mary… troyhunt all resulted in an email address being publicly shown. This doesn’t happen by accident; this is something that someone decides is a “feature”. I always picture your typical marketing manager defending the position – “People need to know what email address we just sent the password reset to because… usability!” – which of course is an indefensible position anyway.
I regularly use the marketing manager example because I’ve had one spin precisely this rubbish before. I once privately reported a raft of issues in the Aussie Farmers Direct website including plain text password storage, passwords sent via email, weak password requirements, mixed mode HTTPS warnings, auth cookie not flagged as secure or HTTP only, reflected XSS and more that I won’t go into here. Someone who literally had the title of “Marketing Manager” responded with:
To date we’ve not had a single security issue stemming from new customers being emailed their password, and I know for a fact 90% of the sites I personally sign up to online also follow that same process.
Good on you mate! But the laissez-faire attitude to security and disdain for ethical reporting paved the way for many interesting follow-up blog posts including how they implemented “remember me” by storing the password in a cookie (also not HTTP only) and how they sent off a bunch of personal data to a tracker over an insecure connection. It should come as no surprise that a short while later, they found themselves in the headlines:
Aussie Farmers Direct hacked, user details posted online: https://t.co/7MkGhor2jp
— Troy Hunt (@troyhunt) October 30, 2015
But getting back to enumeration, to their credit, Essential Baby now no longer leaks email addresses, they just leak the presence of your username like so many others do. (Big shout out too for all the people that subsequently tested my username on that site!)
Now that was bad and foolish and as much as it must have seemed like a good idea at the time, at least they fixed it promptly once brought to their attention. Unlike Strawberrynet whose approach to personal information disclosure is, well, “special”. Now before I go into this, they do know about the issue and they’ve concluded that it’s a feature that people want so I’m comfortable outlining it here (after which they may well decide it’s a feature they don’t want).
So here’s the issue: you find something nice then hit the “buy now” button which presents a checkout dialogue which you enter an email address into. This can be any email address, after all it’s nothing more than a text field:
Now, as a reasonable person you’d look at this and say “well clearly after this the site will probably either ask me to create an account or log in which yes, may be an enumeration risk but 90% of sites on the web do that…” But here’s what happens next:
Furthermore, our website operates on an S.S.L. Secure Server, which is the industry standard for encrypting all information submitted through our website so that it cannot be read by anyone else over the internet.
What this means is that whilst someone harvests their customer database, anyone malicious sitting in the middle of the connection won’t be able to see the traffic. Right…
The individual reporting it clearly saw the error of their ways and pushed back. Thing is, he didn’t realise this was actually a feature so they set him straight:
Please be advised that in surveys we have completed, a huge majority of customers like our system with no password. Using your e-mail address as your password is sufficient security, and in addition we never keep your payment details on our website or in our computers.
I’m really not sure what else to add here, I mean clearly the customers like it so that’s that, right?! This conversation was some time ago and clearly Strawberrynet still believes this is in customers’ best interests. It’s not. They may not know it’s not, but it’s not. Their view may change after this post and often it takes a bit of social pressure to make that happen.
Examples like this remind us how low the bar is often set with security. That you can have a bunch of people in a workshop sit around in a room for a couple of days learning security fundamentals and easily discover stuff like this on a regular basis continues to amaze me. That it can actually be considered a feature genuinely leaves me speechless.