You are cordially invited to hack me first (and get free stuff!)

05 September 2013

No really, that’s the whole idea and it goes back to my post from a couple of days ago about my new Pluralsight course. You see what normally happens when you create a course is that you hand over all the code used in the videos and then if you’re a plus subscriber you get to download it and have a play. That’s just great, but the thing with my Hack Yourself First course is that it’s aimed at everyone – if you’re a PHP developer then this course is equally relevant to your ASP.NET brethren because it’s entirely focussed on common risks you can identify in the browser. The only problem is that if you want to actually run the code yourself then you need .NET. And IIS. And SQL Server. And you need to know how to make them all work!

As I described in that post to launch the course, I’ve actually wrapped everything up into a single site, thing is that it’s a single site absolutely chock full of lousy security practices. So how do we make this useful to people taking the course? I had a good chat with the Pluralsight guys and what we decided to do was just stand the site up so it’s public. You don’t need to be a plus subscriber in fact you don’t need to be a subscriber at all – when I say “public” I mean really public. It’s right here:

I’m excited about this approach because it makes a very valuable component of the course accessible to everyone. For many readers there will be some very common risks you're aware of already either from my own writing or just because, well, some of them are pretty damn obvious. For others there will be a heap of new stuff in there and the reality of it is that a significant swathe of the Dark Matter Developers won’t be aware of the breadth and depth of risks staring them in the face. And that’s the whole point of the course.

There are 50 vulnerabilities

Yep, fifty. 50. Half a hundred really shoddy practices that you can go and find in the browser right now. Many of them are just hanging out there a couple of clicks away, others reveal themselves as you delve into risks a bit earlier in the pipeline. It’s like a little “choose your own adventure” story; depending on the path you take you’ll discover new things. Broken things.

Those 50 vulns are spread across the eight modules I described in the launch post so that means you’re going to see areas that are at risk of SQL injection, XSS, MitM attacks, clickjacking, CSRF, dodgy cookies (my technical description), sloppy password practices and much, much more. Sometimes you’ll find the same risk in multiple places and each individual instance goes towards that 50 count.

Find vulns – get free Pluralsight passes!

I’m writing this whilst at TechEd Australia and I managed to spend a bit of time with the Pluralsight guys who’ve very kindly given me a bunch of free passes that’ll get you a whole heap more viewing time than the free trial available online. If you can find vulns on the site above and leave it in the comments below, you get a free pass. Of course I’d love you to use those passes to watch the Hack Yourself First course but there’s around 700 other courses of awesome content that these passes will also get you into.

A few guidelines:

You can name as many vulns as you like – but you only get one pass (plus of course the adulation of your peers for your lee7 haX0r skills)

You need to explain where the risk is (page, field, etc.) and how it could be exploited by an attacker

Once someone leaves a vuln in the comments, that’s it – someone else can’t call it out (unless it’s in a different part of the app)

I’ll ping successful candidates via the comments below and get them to email me for a free pass

Be nice in your pwning of the app - I'll be regularly (and automatically) returning the app to a default state, please be conscious this is a public site designed to help people understand web app security so don't do anything too nasty (please)!

That’s it – let the hacking of myself begin!

Spoiler warning: I’ve got an update below with a list of discovered risks, if you actually want to search for vulns yourself, don’t read beyond here!

Update – winners and how to get their prize

Here’s the folks who bravely ventured into the bowels of the app and found vuln upon vuln. They’re listed by name and were the first to discover each particular risk. I’ll continue to update this list as more are found but for the folks below, email me at troyhunt@hotmail.com and I’ll get back to you with your pass (also tell me your name below if it’s not immediately obvious).

Ricardo Rodrigues – unhandled internal exceptions are exposed to the end user (these can then be used to fund subsequent vulns)

Scott – password field is limited to 10 chars and restricts the use of “special” characters, credentials are sent via email on signup, there’s no sanitisation of user input on the voting firm, the password change field pre-populates the fields with the current password plus there’s an account enumeration risk in the password reset feature and it also has a denial of service risk (you can immediately lock someone out of their account by resetting their password), the “remember me” feature stores the base64 encoded password in a cookie plus the auth cookie isn’t marked with the HttpOnly flag (it subsequently be accessed via client script in an XSS attack)

Dan Puzey – password resets emails a new password, the vote API doesn’t validate the user ID (you can vote on behalf of another user) plus it allows multiple votes from the same user (the web page tries to prohibit this by hiding the vote button)

chaoaretasty – there’s a SQL injection risk in the comments box of the voting feature, the SQL account used by the web app has excessive rights (shouldn’t be able to do things like delete cars and makes) plus there’s a persistent XSS risk in the vote comments

7sharp9 – the leader board page has a SQL injection risk via the orderBy parameter in the URL

JoKerTheFirst – the auth cookie can still be used even after the user logs out