Steam hit by major security breach

http://masterherald.com/steam-hit-by-major-security-breach-many-accounts-hacked/23239/

by aestetix • 11 years ago

300 245 11 years ago

watbe• 11 years ago

The exploit has been fixed, and this video shows how easy it was to perform: https://www.youtube.com/watch?v=QPl_BJoBaVA

TL;DW: Steam accepted blank recovery codes for password resets, enabling passwords to be changed without needing access to the recovery email account.

I hope someone is writing a new test case.

baby2• 11 years ago

This is just insane how crazy this is easy to exploit. What did the developers think?? Also for how long was this exploitable? If it was a long time, this could show that we tend to over estimate the security of our websites... (a huge amount of people took a long time to find a super easy bug)

cookiecaper6• 11 years ago

There is absolutely a mess of little oversights like this in every non-trivial software project (I just fixed one not 30 minutes ago). The effects are sometimes very serious, as in this case. Cyber-warfare is scary precisely because of this. There is nothing we can do about it IMO, though things like SELinux/AppArmor and even good filesystem-level permissions help a little bit.

on_and_off• 11 years ago

Writing such an exploitable code is entirely forgivable. However, I would expect such a critical module to be thoroughly unit tested. I am going to venture that it probably was not the case.

Strilanc2• 11 years ago

They were thinking about how to make it work instead of how to make it break. Classic mistake (e.g. [1]).

1: https://www.youtube.com/watch?v=vKA4w2O61Xo

cookiecaper6• 11 years ago

I worked on a big name project that had this same problem, which we found because users had begun exploiting it. The problem was caused when a user would intentionally prevent the recovery_code from submitting with the rest of the form, which resulted in recovery_code being nil, which resulted in "SELECT something FROM users WHERE recovery_code IS NULL AND email = targeted_email" hitting the database. This wouldn't work if you'd requested a password reset code and not yet used it, but everyone else was vulnerable. Sounds like something similar happened here.

EDIT: Updated explanation of problem because I originally explained it wrong (required omission of the value on submission, not just a blank value).

johansch• 11 years ago

How did the string go from "" to nil automagically?

Eleopteryx• 11 years ago

For this to happen, wouldn't it mean that recovery codes never expired?

javadocmd• 11 years ago

Yet another example of why allowing nullable values anywhere is a bad idea.

EarthLaunch3• 11 years ago

This would not happen with normal use of a modern framework.

ars3• 11 years ago

Steam accepted blank recovery codes for password resets

Sample buggy code (that I just made up):

(user_token is user supplied token, token is the correct token)

  for(i = 0; i < strlen(user_token); i++) {
    if(user_token[i] != token[i]) return false;
  }
  return true;

If code is blank this will falsely return true. This is also subject to truncation attacks.

I'm trying to think of a bug where blank fails, but truncated versions do not.

brobinson2• 11 years ago

Another not-so-obvious bug with your example buggy code: it's also vulnerable to timing attacks.

http://codahale.com/a-lesson-in-timing-attacks/

jwiley• 11 years ago

No idea or visibility into Steam's backend. Hope to god they are not using C for this very reason. Great for games, terrible for SAS

pja2• 11 years ago

Yeah, strcmp() exists for a reason!

valgaze• 11 years ago

Try it out here: https://jsfiddle.net/valgaze/wpL2La7d/

If this is in fact how how things worked, what a great showstopper bug

mikeash5• 11 years ago

A "goto fail" style bug could allow for blankness but not truncatedness. Basic idea:

    if(!check_params()) {
        failed = true;
        goto fail;
    }
    if(some_other_check()) {
        failed = true;
        goto fail;
    }
    if(token_length == 0) {
        goto fail; // oops, forgot to set failed
    }
    ...check the token...
    fail:
    if(failed) {
        return auth_failure;
    }

I have no idea if this is anything like what actually happened, of course.

mcgroarty• 11 years ago

That's one possibility. Another possibility is they were merely comparing the submitted nonce to the nonce on file. If a nonce had never been generated for a user, the database may have contained an empty string. An empty string in the db would match an empty string submitted by an attacker.

ekianjo11• 11 years ago

This is what concerns me the most with Valve: you build a library of games over the years, and one day someone hijacks your account (because of improper testing on Valve's side) and you lose it or it becomes banned, and you are left with nothing but your eyes to cry.

At least with GOG this would never happen (at long as you save your games locally), but the GOG catalog is way smaller than Steam's.

NamTaf3• 11 years ago

The good thing with Valve is that although they make comically terrible mistakes like this, they know they're bad at getting stuff right and put traceable information on everything

Get falsely VAC banned? They'll detect this and know exactly what happened and revert the issue. Have your account hijacked? They'll trace exactly what happens and fix it all up. Not to mention that this change triggered the standard 'you can't trade or market any games/items on your account for 7 days' block, so even when someone takes your account you don't actually lose anything.

Valve makes some incredibly bad bugs in their software (games as well as Steam itself), but at least they track and trace everything so they can unwind their screw-ups.

ekianjo11• 11 years ago

Valve makes some incredibly bad bugs in their software (games as well as Steam itself), but at least they track and trace everything so they can unwind their screw-ups.

Well for the recent but on Steam Linux that erased your hard drive if you moved the Steam library folder somewhere else, there was nothing they could do to "unwind their screw-ups", except fixing it in the code once the damage was done.

bluejellybean2• 11 years ago

Disclaimer: I currently make my living thanks to valve software

Hah, maybe if you're lucky enough to actually hit a human. Valve has ludicrously terrible support. There have been tons of reports of 1-2 week wait times after submitting a ticket, only to receive an automated response with nothing to do with the actual ticket (even experienced this myself a few times, not fun).

People are quick to praise valve but I don't think it's truly deserved anymore. Sadly the days of them caring about their products and communities are long gone..

cookiecaper6• 11 years ago

Emailing Gabe directly was helpful in getting a WINE issue debugged in the days before native Linux support (actually turned out to be a Linux kernel bug). I don't want to encourage people to spam someone whose time is surely scarce, but perhaps if all other avenues are exhausted and the stakes are high, this may be a reasonable approach.

codexon7• 11 years ago

They may have logs but they don't have perfect logs.

I know people who got banned for having debuggers open not attached to the game.

The VAC system is also incredibly intrusive. It was scanning random processes on my computer, and I know this because when I tried to recompile my program, it failed because it couldn't delete the executable because Steam had an open handle on it...

You would never hear about Valve failing in these cases because no random person would trust testimony from random people over Valve.

rlu2• 11 years ago

Umm...I guess 'citation needed' on the VAC ban part? Valve has a very strict zero-tolerance policy w.r.t VAC bans. As far as I know, reversals are rare and only happen in mass when VAC bugs out and detects a legit program as a cheat which results in an incorrect ban wave which then gets reversed.

I'm pretty sure that if I got access to your account and got your account banned, you'd be SOL.

On the other hand, VAC bans now only affect the single game that the cheat was used in, so your entire Steam library won't be trashed. Exceptions to this include early Source games (e.g. cheating in CS:S will get you banned in TF2) and HL engine games (e.g. CS 1.6 ban also affects DoD)

https://support.steampowered.com/kb_article.php?ref=7849-RAD...

gizmo686• 11 years ago

Not all Steam games include DRM. Even if Valve turns malicious and tries to activly delete your local copy of the games. As long as you have a backup of the Steam directory, you would still have access to the non DRM games you had downloaded.

ekianjo11• 11 years ago

I know, but the list of non-DRM games is just a fraction of the whole catalog (and especially most AAA titles are DRM-ed).

ejcx3• 11 years ago

One little know cool thing steam has done for a while is encrypt passwords with a RSA public key before they are sent server side.

Yes, js crypto is not worth a whole lot but it is a valuable security tool to be used with TLS. There are some neat things they could be doing with this encrypted password (other than plainly decrypting it) that add a fair bit of security (no more than just a regular hash though).

codexon7• 11 years ago

No not really. It highlights how incompetent Valve is at security.

If you cannot trust the webserver or whatever is being served to you, JS crypto isn't going to do anything. They could just send you a login script that sends your unencrypted password elsewhere.

ejcx3• 11 years ago

    It highlights how incompetent Valve is at security.

Adding one feature shows they are incompetent at security? Great real.

Without more information about the scheme there's nothing to know. Whether useful or not it is still neat and can be used for benefit, but not for something TLS like.

phlo2• 11 years ago

[...] JS crypto isn't going to do anything. It may have provided a little bit of extra protection in some scenarios. For example, many trojans will grab any HTTP(S) POST data from your browser. If such a trojan is not specifically configured to grab Steam data, hashing/encrypting client-side will provide some protection.

akaiser• 11 years ago

The final goal this probably had is already achieved (a lot better) by properly configured TLS. I think this only prevents having the password in clear text at some specific point in time on the servers and (accidential) logging. OK, maybe some active MITM software (hi Lenovo!) that have not specifically been adjusted to replace the JS crypto may have been a concern. But probably someone just wanted to play around with JS crypto ;-)

They could have made this easier and faster by simply having the client apply a hash (have the server provide a temporary salt and mix it with a client-generated salt if you want to prevent accidential logging on your server) and handle this result as if it was the user's password (and hence hash this hash properly server-side). As already noted, the (only) upside is that now you don't ever even process a user's password on your server, so you don't have to worry that a user's password might be stored in your logs or even MITMled in your own (unsecured) network. I wonder why I have never read about somebody handling logins this "double-hashing" way? Anything I'm overlooking security-wise?

nodesocket• 11 years ago

Wow reset token blank worked. How in the world could their backend not check for an empty token, or even how is this validating true against the value in the database?

curiousjorge• 11 years ago

I'd expected better but it's quiet perplexing as to how they missed it.

XMPPwocky4• 11 years ago

They don't seem to have any automated or manual testing before deployment (or at least, extremely little)- for example, one recent bug was that all the prices on the store disappeared, and nobody could buy anything.

tptacek6• 11 years ago

Take a few minutes and re-evaluate your password reset scheme. They are treacherously difficult to get right. Every pentest we did, we made a beeline for the password reset functionality; it was often a cheap, quick gameover bug.

_asummers3• 11 years ago

What are some examples of ways you've seen people screw them up?

tptacek6• 11 years ago

* Not being very careful with the lifecycle of a token.

* Encrypting tokens and expecting users to feed back the same encrypted token, and failing to authenticate.

* Simple parse errors and SQL injection on the tokens themselves.

* Exploitable generation (for instance, non-cryptographic RNGs) for the tokens themselves.

* Having multi-page flows starting from the receipt and validation of a reset token, and then having standard web flaws somewhere in that flow (for instance: userid is validated only at the start of the flow).

* Mishandling of cases where users have multiple outstanding reset requests.

* Accepting the email address to send token to from web user, validating the address, and then using the user input directly as the email address to send the token to; as in: systems that will send token to user@real.com;attacker@evil.com.

One bug everyone has in their password resets: they don't cancel outstanding tokens when users change their passwords, so that long after a user has reset their password, their email boxes still contain password-equivalent tokens. That's not a high-severity bug, but it's a meaningful one.

nstart• 11 years ago

just throwing in my experience here. I've seen a few sites that actually had the password reset request send them a url that was formatted as:

example.com/password_reset?username=<username>

You could basically type that in and replace <username> with any username you wished and reset their password.

The sad part was how obscenely long it took them to close those holes (couple of weeks).

MattHeard2• 11 years ago

I spent a week consulting for a small education software start-up and was horrified when I saw that their password reset process was the following:

1. An anonymous person sends a message via Google Chat to the support Gmail address.

2. A staff member would ask the anonymous person for the username of the account for which to reset the password.

3. The anonymous person would present the username.

4. The staff member would reset the password and create a temporary password and would then give that anonymous person the password. The staff member would then explain how to change the password once the anonymous person had logged in with the temporary password.

I spent too long trying to explain to the staff and the CEO why it was a problem that any person could gain access to any account...

ForHackernews• 11 years ago

It wasn't a YCombinator startup, was it?

gauravagarwalr2• 11 years ago

If what you are saying is true; did they store the passwords in plain text as well?

keithpeter• 11 years ago

I'm a teacher in the UK. Educational systems range from the ridiculous like the one you mention to the ones who take it very seriously.

One employer some time ago would only do password reset if you turned up in person with photo ID. That organisation had quite a lot of students spread over a number of sites so it was labour intensive - the library staff used to be able to reset passwords and they had access to the student and staff badge photos. IT staff at a University I taught at for a year would only reset password if you went on a conference call with a manager level staff member who could confirm recognising your voice.

For a general access Web site available nationally and not tied to an institution I imagine you would have to fall back to the usual email reset code with challenge question type systems.

duncanawoods• 11 years ago

Which libraries would you recommend for password handling?

pfg3• 11 years ago

This usually depends heavily on your language/framework. Coming from a ruby/rails background, I can recommend devise.

newman314• 11 years ago

Any list of best practices to follow?

0xffffabcd• 11 years ago

https://www.owasp.org/index.php/Web_Application_Security_Tes...

rdudek• 11 years ago

How long has this been active? Reason I ask is that I once had my account hacked many years ago, it took a few days but I got it back.

skymt• 11 years ago

Until recently Steam handled password resets through the client. The new web-based reset interface was introduced less than a month ago: http://steamcommunity.com/groups/SteamClientBeta#announcemen...

I'd assume that this bug was added then.

andrewchambers2• 11 years ago

Does anyone know if you are liable for disclosing bugs irresponsibly?

nness2• 11 years ago

You could be liable when disclosing bugs responsibly too, as some researchers have learned when investigating voting machine security.

lawnchair_larry• 11 years ago

No, mainly because there is no such thing as "irresponsibly".

tracker1• 11 years ago

This is why the bigger you are, the more important it is to log almost everything that you can... It sucks from one side, because it is a security risk to log potentially sensitive information, on the other hand it's critical to be able to diagnose problems in the wild.

In this case, if requests for password resets are logging the codes sent (even if the error is present), they would be able to determine which accounts were affected, and return them to the appropriate registered email address (if they were changed).

On the one hand, the storage and compute costs for these kinds of things suck.. but this is exactly what big table solutions are for, be they C*, ElasticSearch, Google, Azure or AWS table storage solutions. If you have more than 10K users on your system, and logging everything possible isn't routine, it should be.

Access to read that log data is another issue entirely.

fivedogit• 11 years ago

The first thing that came to mind when I read this headline was Valve's famous structureless work environment. If there's no structure, who handles all the grunt work noboday wants to do... like security?

Even if somebody is explicitly assigned to security, I'm not very confident they'd have the authority to make all these freewheeling ad hoc teams adhere to good practices.

codexon7• 11 years ago

And you are correct. Bug fixes from Valve are few and far inbetween with many bugs being unpatched for years.

https://github.com/ValveSoftware/Source-1-Games/issues/assig...

XMPPwocky4• 11 years ago

And that includes security issues; there's one notable vuln where a malicious server or custom map can execute arbitary code on clients. Reported that a few months ago, it's fixed in CS:GO and TF2, but other Valve games apparently aren't receiving fixes (Portal, Portal 2, Left 4 Dead, Left 4 Dead 2, Counter-Strike: Source, HL2DM...)

And that's not to mention the folks who license the Source engine from Valve, who I'm currently trying to contact en masse and get them to fix this (and many other security-critical issues). Apparently, Valve doesn't push security patches downstream to them...

manachar• 11 years ago

Plenty of places with deeply hierarchical systems have had major security bugs.

jschwartzi• 11 years ago

Indeed, it's less a matter of organizational style and more a matter of people in the company valuing QA enough to hire dedicated personnel, and then getting out of their way.

PhasmaFelis2• 11 years ago

If I (somehow) got hired at Valve, I would dedicate myself to fixing Steam's deeply shitty UI. Just off the top of my head, trailer videos on Steam don't buffer more than a few seconds ahead unless you watch the entire video, and it is literally impossible to return to the exact beginning of a video without first switching away from it (you can only navigate by clicking--not dragging--the progress slider, and it lacks the resolution to go back earlier than the first second or two). And of course it doesn't recognize universal-standard keyboard commands, like Space to play/pause and arrows to navigate. They only recently let you play/pause by clicking on the video instead of on the tiny button.

Trailers for pre-Greenlight games are actually better, because they're forced to use YouTube since Valve isn't willing to invest streaming video bandwidth in them yet. It's wretched.

degenerate2• 11 years ago

I'd totally do this too. I would enjoy fixing the bugs, actually. Some have drove me mad for years on end...

kevingadd• 11 years ago

A few months back I had a discussion with a Valve developer about the sandboxing they use for the Steam Overlay and its embedded web browser. I was describing how their sandboxing was inadequate and vulnerable, and he responded by explaining how they had done things correctly and listing the measures they took.

Then I explained that the measures were incomplete and the embedded browser wasn't actually secure (among other problems, the sandbox was running as Administrator with the debug privilege...) He investigated, and saw that the sandboxing was never finished by the engineer who worked on it. So he took some time to go finish it himself. Up until that point, Valve had been operating under the assumption that they had a working sandbox - worse than if they had no sandbox at all.

The above is merely an anecdote, but I've heard a lot from current/former Valve employees to the effect that engineers are rewarded for doing high-profile/high-impact work and not encouraged to do much else. If you interact with them as a game developer you can really see this in action with how they ship Steamworks updates - major features break without warning, bugs go unfixed, no real support channel, incomplete documentation.

I spent a couple weeks building out Steam Workshop support for a title. Doing this required identifying and working around a handful of strange, undocumented bugs and API limitations. In the time since we launched, Steam updates have broken the workshop support at least twice, requiring me to spend a day or two figuring out what broke and ship a patch. I've seen similar issues with other titles.

Akkuma• 11 years ago

My own interaction with two developers there several years ago was that the web was clearly the redheaded stepchild of Valve. I think they said something like maybe 7 people worked on those features back then, one of those two only sort of worked on it. Additionally, they only really had something like 3-4 people focusing on it most of the time.

For years they had prototype.js included, yet the library was essentially dead at that point for at least a year. Now they have jQuery and are running 1.8.X version, which means they are using a 2.5 year old version. I think this kind of speaks for itself.

nness2• 11 years ago

This isn't one of those "change your passwords" moments, is it? Based on how this exploit worked, I would assume you'd already know if your account was breached and that there is no on-going risk after the fix?

dhagz• 11 years ago

I changed mine anyway; I've been meaning to change to a more secure password. I definitely think that if your account wasn't compromised, you don't need to change your password.

MichaelGG2• 11 years ago

What a hyperbolic article. Valve will undo any damage. It's absolutely silly to think that they'd enforce a VAC ban due to abuse on their system.

ewillbefull• 11 years ago

It's a bit hyperbolic, but historically Valve have been very strict about VAC bans. If your account is hacked and someone cheats, they can get it permanently VAC banned and Valve will not negotiate or be lenient about it -- ever. I know this from experience and it's well known. In this case Valve will probably remove the VAC bans because it's such a high profile mistake on their part, but you can see why people are concerned -- especially when they haven't said anything publicly yet.

Strom• 11 years ago

This exploit was mostly used to hit Twitch streamers. People whose job involves using their Steam account. They had hours of reduced revenue due to this attack and I find it unlikely that Valve will even acknowledge any opportunity costs, let alone reimburse them.

MichaelGG2• 11 years ago

Nor should they. Is someone paying Valve for a particular SLA? I'd guess not.

I was talking about stolen items and VAC and so on. As if this was a physical robbery where priceless stuff could be lost.

keypusher• 11 years ago

Enable Steam Guard, and it will force anyone logging in from an unrecognized device to submit a code they send you via text or email.

hav• 11 years ago

From the post:

It’s not yet clear if Steam Guard offers sufficient protection from the exploit, as there have been some reports from users claiming that their accounts have been compromised even with Steam Guard enabled.

It's always good to have some kind of 2FA active, but it's unclear if it helped in this case.

shin_lao• 11 years ago

If you get hacked from a machine your previously authenticated I guess Steam guard will not work.

ninja_to_be2• 11 years ago

As part of one of my academic projects, I did a bit of research on password reset functionality of about a dozen major websites. It was interesting to note that each and every website had implemented it in a different manner. So much difference in the process and the lack of a standard procedure was shocking, though understandable. It was interesting to brainstorm and discuss about the rationale behind each of the password reset process and the User Experience decisions involved.

I also noticed a frighteningly large number of small websites that get 'password reset' absolutely wrong, compromising their users' accounts. It is something that is very difficult to get right, unless thought through completely before implementation. Whenever I signup for a new user account on a fairly new website, I try to use a dummy throwaway password on the first attempt and then try the password reset option to see if the website is actually serious about security. It is like a litmus test for me to decide about continuing to use the website and trusting them with more of my data.

fr0styMatt22• 11 years ago

Can you give some examples of what you'd consider red flags in a site's password reset procedure? I'd be really curious; this is an area that I've thought about as a "necessary but horrible-for-security thing".

ninja_to_be2• 11 years ago

A few examples of unacceptable practices followed by certain websites include:

- Sending your password to your email in plain text. - Allowing user to set new password just by answering simple personal details like DOB, Zip code etc which might be known to a number of your friends and family members.

Often it is simple enough to implement a password reset functionality with a reset-link that contains a GUID which expires after a certain period of time. It could be more secure, but is a tradeoff between providing greater security and a longer reset process.

One of the major risks of websites with very naive reset procedures is that many people use the same password with multiple websites. So if a user's password gets compromised on a site, then the attacker can easily try those passwords with other services and gain easy access to user data.

coherentpony• 11 years ago

This site raises my blood pressure; I can't view the content because of nonsense popups giving me definitions of words like "account".

degenerate2• 11 years ago

No need to have a stroke. Just install ublock origin. Underline and ad-popups are gone. Done.

fr0styMatt22• 11 years ago

FYI Steam also has a mobile authenticator as part of the Steam app now; I remember seeing a banner for it pop up in Steam news not too long ago:

https://support.steampowered.com/kb_article.php?ref=8625-WRA...

koyao• 11 years ago

Did Steam just go down? Maybe from the load that Hacker News is generating?

https://isitup.org/store.steampowered.com

store.steampowered.com seems to be down!

Chilinot• 11 years ago

Considering the ammount of people visiting the store page each summer sale (well any sale), i dont think hacker news can generate that large amount of traffic.

orf• 11 years ago

I highly doubt the HN traffic caused Steam to go down, their statistics page[1] shows how much traffic they process each hour (and it's a lot).

1. http://store.steampowered.com/stats/content/

noelsusman• 11 years ago

It's been down off and on for the last 3-4 days.

fsiefken• 11 years ago

Is it advisable to change your password in this case? Is there anything other you can or should do to secure your account even though some report it is fixed?

farresito• 11 years ago

Now I understand how I lost my account a week ago. Not that I used it too much.

tcfunk• 11 years ago

How is it that I don't see anything about this exploit on any of their sites? It's not on the steam store website, not on the Valve site, and not in Valve's news feed.

Pxtl3• 11 years ago

The big disappointment is how long it took them to acknowledge the issue. I was freaking out thinking my gmail account had been compromised. Was up into the wee hours of the morning trying to scrape log-files from my Android devices trying to figure out which one was leaking, since Google said nothing else was connected to my account.

I found out because somebody on Steam forums linked me to a Reddit thread on the subject.

Yeah, this is one of those "let the users know ASAP!" things.

Pxtl3• 11 years ago

Text of the message sent to Steam users:

"Dear Steam User,

On July 25th we learned of a Steam bug that could have impacted the password reset process on your Steam account during the period July 21-July 25. The bug has now been fixed.

To protect users, we are resetting passwords on accounts that changed passwords during that period using the account recovery wizard. You will receive an email with your new password. Once that email is received, it is recommended that you login to your account via the Steam client and set a new password.

Please note that while your password was potentially modified during this period the password itself was not revealed. Also, if you had Steam Guard enabled, your account was protected from unauthorized logins even if your password was modified.

We apologize for any inconvenience."

tripzilch6• 11 years ago

Please note that while your password was potentially modified during this period the password itself was not revealed.

Why would you tell people this? :-) The worst that can happen is that they figure out password re-use is a bad thing, panic and change it on all those other sites they use it ;-)

Pxtl3• 11 years ago

Dollars to donuts somebody wrote an overly-permissive NULL check. Nullity ruins everything.

xianglifei• 11 years ago

……

Steam hit by major security breach

Related Stories