A tale of my first foray into security reporting

On a recent rare foray onto Facebook, I stumbled across an interesting blast from my past:

Catan Anytime might not have made massive waves, but it had some major backing behind it. The project was first launched by Microsoft in July 2014, announced via the windows blog ( "Sheep for wheat, anyone? Internet Explorer releases preview of new social Catan web experience" ) and with a stream of promotional articles from other tech outlets. The site's primary purpose - aside from offering a persistent online version of one of the best board games of all-time - was to promote the power of html5, and in particular how Internet Explorer (so often the punching-bag in these kinds of discussions) was at the forefront of supporting the new standard.

So when I heard about the game's announcement, I was approaching it from two different perspectives: firstly (being a massive Catan fan) as a potential user, but also - as always - with my tester's mindset.

What I didn't realise was that it was actually going to turn into my first real-world experience of disclosing security issues.

What's a polite time to wait between finding/reporting security flaws in a major site, & going public? @gcluley @Scott_Helme @TheTestDoctor

― Neil Studd (@neilstudd) July 30, 2014 What I discovered

These were early days for me, in terms of exposure to security testing techniques, and also with regards to participating in online testing communities. I wish I'd known then what I know now; I took Troy Hunt's Hack Yourself First course a few months after this incident, which would have helped me to better communicate the problems that I found.

A lot of the issues that I discovered were visual/UX related, and I certainly wasn't going out of my way to discover security problems. However, the deeper I went, the more obvious the problems were, even if I didn't quite have the words to explain them back then.

Among the major WTFs were:

Login & change password requests being sent over secure HTTP ...but with the username/password in the URL in plain-text

https://www.catananytime.com/jsonp.php?controller=users&action=login_with_jsonp&email=test%40example.org&password=Password123

Although the URL and its querystring parameters will be sent as part of an encrypted data packet, there are still places where this information will surface itself. For instance, the full querystring will be visible in web server logs, user bookmarks/history, and can get sent in referrer headers. This is a big no-no! Read more about sending querystring parameters over SSL.

Forgot Password dialog allows account enumeration

"Our system does not recognize this e-mail address. Please try another."

By producing different responses from your account retrieval system depending on whether or not an email address is registered, you're revealing the existence of an account. This might not be a concern for a simple online gaming site, but the problem can easily have darker implications; see Troy Hunt - Understanding account enumeration, the video tutorial edition .

mysql query details leaking into the browser, offering vectors for enumerating database content

That screenshot contains my original comments which I sent to the developers (more about that contact in a moment). In doing so, I was trying to demonstrate "hey, I've got a feeling that something's not right here, but I can't quite express what it is, and I certainly haven't tried to proceed any further". What I'd stumbled upon is a SQL (in this case, MySQL) injection vulnerability. I thought that I'd need to know some magic values to tease this vulnerability any further, but I've since learned about a variety of incredibly scary tools (such as Havij) which can take the mere presence of an opening like this, and use it to brute-force the entire contents of a database. More referral traffic for Troy Hunt: Hacking is child's play - SQL injection with Havij by 3 year old .

No brute-force protection against unsuccessful logins et al

This just makes the previous problem all the more scary. Once a user had discovered a possible injection vector, there were apparently no systems in-place to prevent repeated queries against that page (e.g. I made 10 unsuccessful login attempts, and my account was never locked-out).

No authentication for sensitive functions (e.g. Forfeit Game)

https://www.catananytime.com/jsonp.php?controller=users&action=leave_game&player_id=11041&game_id=1407

Authentication throughout the game elements was also extremely shaky. See that URL above? That's the URL that gets hit if I click the Forfeit Game button to resign from the current match. The problem is, if I changed that player ID to any other player's ID (these IDs were discoverable, see the next problem below) then I could force them to resign from the game - a good way to eliminate the competition!

Worse, when experimenting with a malformed query, it became clear that there was an UPDATE query being run against the game database to SET abandoned=1 for the given player/match, but there was no LIMIT - so one carefully-crafted URL could have made every player resign every match in the database!

{"error":"There was a database error.","success":false,"db_error":"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' AND game_id=1407' at line 1","sql":"UPDATE game_players SET abandoned=1 WHERE user_id=11028' AND game_id=1407"}

Player/game information exposed through console commands

Finally, the game itself had some fundamental exploits. Namely, most of the game data was accessible by querying the game_data object through the console: by looking inside development_cards and active_players I was able to see the details of every player (including their email addresses), and what cards they were currently holding! Imagine if this was a poker game, or there was real money on the line!

What I did next

I'd uncovered some potentially scary issues. The game didn't hold much in the way of data - mostly usernames/emails, and potentially passwords, though the screenshot above suggests these were likely hashed/salted. Nevertheless, my feeling was that these issues would be potentially embarrassing for a company such as Microsoft, so I set about trying to contact the relevant parties privately.

I quickly learned that this was far from an easy exercise. When you're dealing with a company of that scale, there's no obvious single point of contact for raising security issues. (It's even more complicated with Catan Anytime, which - as per the Windows blog post that I linked at the start - was a collaboration with several external software houses.)

Here's the timeline of my disclosure:

24-Jul-14 : Game launch announcement. 28-Jul-14 : My first playtest, discovering the above issues. 28-Jul-14 : Emailed the game's support@ email address, as per the Help/Feedback section of the website. 30-Jul-14 : No response, so I tried to guess the email address of Justin Garrett (author of the Windows blog post) 30-Jul-14 : Email bounced back. 30-Jul-14 : Posted the frustrated tweet that I linked above, was DM'd a few words of advice by Scott Helme. 31-Jul-14 : Managed to find Justin Garrett's LinkedIn profile, and reached out with a private message. 31-Jul-14 : Response from Justin, confirming that he had forwarded the details to Bontom Games. 31-Jul-14 : Email response from Bontom Games, acknowledging the issues and asking to talk further. 1-Aug-14 : I replied to Bontom expressing my openness to further discussions, but no response was ever received.

So, things moved relatively quickly once I managed to get things kickstarted. I wish more companies would have a highly-visible point of contact for issues such as this; if there'd been a more prominent/dangerous vulnerability, I don't think I could have escalated any faster than I managed to. And it's not just because I was a rookie - the professionals have these problems all the time too, as you can see from the "Disclosure timeline" section of Troy Hunt's Nissan LEAF vulnerabilities .

However, it wasn't just the difficulty of the disclosure which I found frustrating, but also the responses I eventually received. Here's what one respondent told me:

I think there's definitely opportunity to improve the game as we come out of beta. In the meantime, the purpose of the site is to show what's possible on the web - the "turn-based" asynchronous nature of the game across browsers, across devices is what we focused on the for beta.

Short version - security isn't important to us right now.

Did things get better? To some extent, yes. I re-checked some of the previously-offending issues in September and October, and some headway had been made. I feel that I was probably in a position where I could/should have attempted further contact; I didn't feel that there was enough information stored in their database that there was any value in a public disclosure timeline, but I think I could have pressed on with further urgency.

What I learned

Security is HARD. Not just for those who are implementing it, but also for people who discover vulnerabilities. I gained a great deal of appreciation for those who make their living as security researchers, and a growing sense of dread for how exposed some of our systems could be. It's fair to say that I subjected my own company's systems to a much more vigorous security audit after this incident!

It was also a jump-start into my own journey into the world of security testing. In the past couple of years, I've learned an immense amount by following Troy Hunt's Pluralsight courses , attending workshops by Bill Matthews and Dan Billing , and reading about the activities of researchers including Scott Helme and Graham Cluley . I've also become involved in the security guild in my current workplace, which included getting Troy Hunt to run his classroom-based version of Hack Yourself First earlier this year.

It's a never-ending, always challenging, rarely dull process, and incidents like this have been a vital part of my learning. I'm still far from an expert, but I've become much more competent at uncovering issues, and advocating for remedying them.