Steam Bug Allowed Password Resets Without Confirmation

An anonymous reader writes: Valve has fixed a bug in their account authentication system that allowed attackers to easily reset the password to a Steam account. When a Steam user forgets a password, he goes to an account recovery page and asks for a reset. The page then sends a short code to the email address registered with the account. The problem was that Steam wasn't actually checking the codes sent via email. Attackers could simply request a reset and then submit a blank field when prompted for the code. Valve says the bug was active from July 21-25. A number of accounts were compromised, including some prominent streamers and Dota 2 pros. Valve issued password resets to those accounts with "suspicious" changes over the past several days.

Comments

That's funny

[Anonymous Coward]

That's pretty funny considering the NIGHTMARE I went through getting my steam account reset as the email account I used to register (DOH!) was a previous work email that is no longer active, so sending me an email asking if I want to change my email is pointless. And now I find out that if I had have waited, it wasn't even verifying the code?

FFS

If something like this slips through testing

[gweihir]

Then testing either sucks completely or ignores security functionality. This really is an absolute basic thing to test, just as testing that giving a wrong password does not give you access. The state of practical software engineering seems to still be abysmal, even after this problem has been known for a few decades. It is high time to legally bar amateurs from doing software that has any security functionality that protects customer assets and data.

Re:If something like this slips through testing

[gweihir]

Possibly. If the summary is correct, this would be abysmally bad. Although it seems the vulnerability was only there for a short time, and they possibly did not fix, but roll-back to get rid of it. Fixes take some time, roll-backs are almost instantaneous. Roll-backs can only be done for an not very old previous version though, so they likely had one that was still fine.

Re:If something like this slips through testing

[Bengie]

Obviously they don't unit test their failure cases, only their success cases. I've programmed many security APIs for stuff around validation and authentication, and there are many many more failure cases, but you need to test them all. My general rule of thumb is to unit test all edge cases I can think of.

The only thing more important than something working how I want it is for it to fail how I want it.

Re:If something like this slips through testing

[omnichad]

Probably a bad SQL query join that checked for the existence of a value. If you mistype a code it might be found. If you enter no code, there might be matches.

Re:If something like this slips through testing

[ArhcAngel]

I called to get support for software I was using. After explaining the problem the support person said they were confused and asked me to elaborate. I said the x was no longer working and I had tried a, b, & c to fix it. The tech was like our product doesn't do x! And I was like well I've been using it to do x for months. It seems a feature I had been using for months turned out to be a bug and gotten fixed in the newest release.

Re:If something like this slips through testing

[Bengie]

I can't say one way or the other for whatever you bug was, I like to do validation as much as possible in my code until there is a valid performance issue. Several times in the past few years I've had outside developers start using my code only to have their front-ends blow up with some helpful error messages. They would complain that my backend code was causing their frontend code to fail, but I explained that they were making undefined calls and my backend code was just making sure calls were being used in a way consistent with the envisioned data model.

I've gained a reputation for thoroughly checking edge cases that I am now "that guy" people go to first. This can be annoying because 95% of the time it's an issue with the frontend, but the person who made the frontend doesn't do any useful logging and lets default exception handling drop a "object null" error or whatever. Even the frontend devs come to me asking why their program is breaking. JUST PASS SOME VALID PARAMETERS! They're too used to things silently failing, leaving stuff in invalid states, but only causing errors when they attempt to use the invalid state.

My goal is that when using my code, it either works beautifully or fails spectacularly with a clear reason why. The sooner code breaks, the better. None of this code seems to work but something is in an invalid state and someone forgot the check the state. No, it goes BOOM and is never in an invalid state. All states are accounted for and how you can use something in a certain state is enforced.

A simple example is authentication. I've seen people write auth APIs where the programmer is supposed to request the user object, if found, then attempt to validate it. I don't do that. I let you pass in the auth data, and I'll pass back an immutable user object if the validation was successful. With the other way, I've seen programmers who have forget to validate the user object. oops.

Another example is SQL sprocs. Many programmers like to use internal identifiers. Yay incrementing integers, no chance of accidentally flipping around some arguments and still getting a valid response because those identities exist in more than one table. /sarc Nope, UniqueIdentifiers. Virtually no chance of accidentally passing in a UUID to the wrong parameter and not getting an error. But UUIDs fragment the index more quickly... boo freaking hoo. I'll worry about it when it becomes a performance issue.

Re:If something like this slips through testing

[Bengie]

[ResetCode] check( [ResetCode] > '') NOT NULL

Re:If something like this slips through testing

[omnichad]

Seems a little silly to put the user input checking in db code instead of server code.

Re:If something like this slips through testing

[Bengie]

Until some knob-head inserts an empty string into the database and breaks code that assumes empty will never happen. If something should NEVER happen, then make sure it never happens. That's the whole point of constraints in databases, forcing the business logic to at least conform to basic data model rules.

Re:If something like this slips through testing

[Anonymous Coward]

Valve doesn't have testers. They literally have zero testers. Developers are supposed to test their own code but many of the teams have zero automated tests. The 'contract' with the customers is basically that will Valve will ship cool stuff and the customers will forgive their mistakes.

This contract works okay for the games, mostly, but falls down pretty hard for Steam. Steam does have tests, but not really enough.

TL;DR Many Valve developers have a shocking disregard for code quality and failures like this are not surprising. I should know, I used to work there.

Re:If something like this slips through testing

[gweihir]

Sounds very plausible.

Re:If something like this slips through testing

[gweihir]

On the other hand, a check whether the result of the DB query matches an expected format is easy to do. Of course, real men do not verify assumptions. They just know.

Re:If something like this slips through testing

[gweihir]

Indeed. Incidentally, a professional penetration-test does exactly that.

Re:HL3HL3HL3

[jones_supa]

The Half-Life wiki has a good article called Future of the Half-Life series where you can follow the latest developments.

On March 19, Gabe Newell, when asked about Half-Life 3, replied: "The only reason we'd go back and do like a super classic kind of product is if a whole bunch of people just internally at Valve said they wanted to do it and had a reasonable explanation for why [they did]." This, like all of Valve's other statements regarding Half-Life 3, neither confirms nor denies the possibility that the game will eventually be made.

Re:HL3HL3HL3

[drinkypoo]

"WHY"? The most idiotic thing he could ask.

If you're in the game for the long haul then you don't just throw away your reputation. You make the game when it makes sense to make the game. You have some new level of competence to display, usually. That's when HL2 came out.

They tell you to ignore it too...

[Anonymous Coward]

I got one of the password reset emails during this "attack". The email you receive specifically states:
If you are not trying to reset your Steam login credentials, please ignore this email. It is possible that another user entered their login information incorrectly.

Yep, if you didn't try to reset your password, ignore the fact that you got the password reset email.

Lucky me, apparently I enabled Steam Guard back in 2013.

Re:They tell you to ignore it too...

[Bengie]

I had a similar thing a month ago. I got an email that stated I got a password reset request. Just to test things, I logged out of Steam and logged back in. It said someone else from another IP "logged in" to my account, that was after I entered my original password. That left me confused. How could someone log in if my password was the same. I saw a reset request, but I never got an email that my password got changed.

I decided to change my password, and just to test things out I issues a password reset instead of just changing my password the normal way. I got the email saying a password reset was requested, then I changed my password and I got another email saying my password was changed.

since nothing was amiss, I assume that someone did not log into my account but only issued a password reset. This scares me. To me this indicates that the web page thought the Chinese IP address actually logged in. If I was to write a program to notify a user that an unknown IP logged into their account, I would tie that in with the authentication logic that on a successful login, an email get sent. Does this mean the Steam code that handles password resets technically calls a code path that authenticates as that user? Shitty programming is all I can say.

Re:Continuous Deployment!

[chuckugly]

Ageing security professional, but close enough. CD is OK *IF* all the other stuff is in place but it seldom is all in place, often unit testing and CD and "ship it". For a graphic example of why unit testing isn't enough, spend 90 seconds watching the initial launch of Ariane 5 pass it's unit tests all over the place.

Come on now...

[JustAnotherOldGuy]

....stop complaining about these hidden features and start thanking the developers for making it so easy for $random_hacker to ruin years of work.

It's funny, though, because resetting the password on a STEAM account the way you're supposed to can be a total clusterfuck that will leave you cursing for days, if not weeks. Ask me how I know.

Re:Come on now...

[Binestar]

Ask me how I know.

How do you know?

Re:Come on now...

[JustAnotherOldGuy]

How do you know?

I tried it once, and to put it succinctly, I'd rather have back-to-back root canals than go through that shite again.

Wait, what?

[JustAnotherOldGuy]

> The problem was that Steam wasn't actually checking the codes sent via email.

Really, Steam? Really? You really, truly didn't even bother to check the code you sent as "confirmation"? The code that is the raison d'être for sending the code in the first place?

This is the kind of mistake I'd expect from a newbie who's still getting the hang of "Hello, World!", not from a multi-million dollar team of professional developers.

Re:Wait, what?

[ledow]

I think it's more of a side-issue.

If there was a code in the box, it checked it. And refused incorrect codes.

But nobody tested it when there wasn't a code in the box.

Still pathetic, but a little less so.

Re:Wait, what?

[Bengie]

The fact that the front end logic implements the business logic that handles password reset is a bad practice. The front end should call an internal API that has a signature like this "bool TryPasswordReset(string username, string resetCode, out userObject user)". If unccessfuly user is null, but if the try is successful, then user is a valid user object that can be passed into the change password API that looks like this "bool TryChangePasswordWithReset(UserObject user, string newPassword, string resetCode)".

This API could be unit tested to hell and back to make sure the business logic works, and it keeps the front end dev from making stupid mistakes that affect security.

Shit like resetCode being null, empty, or whitespace will throw a lovely exception that the front end dev should have checked for. Not to mention that resetCode must be a valid value.

Re:Wait, what?

[drinkypoo]

If there was a code in the box, it checked it. And refused incorrect codes.

But nobody tested it when there wasn't a code in the box.

In what world is (null) not an invalid code? What color is the sky there?

Re:Wait, what?

[ledow]

You're missing the point (though the practical implications are the same).

The check on whether the code was valid was only run if the user typed a code into the box. Typing in random letters wouldn't validate. Typing in a valid code would.

It was an oversight that the checks existed but never actually took place in the case of null, not that they were not capable of validating codes.

As such, rather than just "Let's make up random codes and then ignore them and validate anything", the thought process was "Let's generate codes, validate them properly, but oh shit, we forgot to validate this path".

Although the results are the same, the implication that they never intended to use the code for checking against is wrong. As such, it appears to be a coding oversight which allows an authentication bypass, rather than deliberate laziness masquerading as security.

Re:Nafarious intent

[JustAnotherOldGuy]

I know, it's like they're teasing us.

Re:HL3HL3HL3

[Qzukk]

At this point, HL3 (or even just "HL2 episode 3") is going to become Valve's Daikatana or Duke Nukem Forever. Just following on from the end of Hl2e2 is going to be a huge hurdle (their writer must be at least this good in order to get on this ride) never mind whatever Source engine technology they want to show off.

I think that Newell sees only two possibilities: 1) they never make the game or 2) they make the game and everyone hates it.

Re:HL3HL3HL3

[PRMan]

They need to mix Half-Life 3 and Portal 3 with a great story. THAT would be an amazing game.

Microsoft had something similar

[RogueyWon]

Microsoft's Xbox Live system had something similar a few years ago. In that case, the "bug" was actually a flaw in their online and phone support protocols and is pretty well documented here.

This was used to compromise a large number of accounts in 2011 and 2012, with the compromised accounts generally being used to make tradeable FIFA DLC purchases, allowing Xbox Live purchases to be laundered back into real cash.

I got stung by it myself, which utterly shocked me as my XBL password was a strong password that had only ever been entered into my 360 console - so even if my PC were compromised (and I was pretty sure it wasn't), the password certainly hadn't been extracted via a keylogger. MS were very prompt in responding and gave the impression that they were dealing with a lot of these cases. They refunded the £50 that the scumbag had spent and gave me 3 months free XBL Gold subscription as well, which seemed odd given I was still convinced the slip-up must have been on my end.

Wasn't until I saw that Kotaku article a few months later that I realised what had happened. The irony is that this was going on at the same time as the Sony PSN breach and, unlike the PSN breach, it resulted in accounts actually being compromised and fraudulent purchases being made. But as it was a steady drip-drip-drip of compromised accounts rather than an eye-catching big-bang "hack", the mainstream media never picked up on it.

Re:Microsoft had something similar

[RogueyWon]

Ugh, lost the link - here.

Dear Valve - please try Kaje Picture Passwords

[garyebickford]

"Dear Valve: Please go to http://ka.je/ to see a solution to your authentication problem. The Kaje Picture Password SAAS removes all passwords from your website, eliminates transmission of passwords across the net - they are converted to an encrypted hash in the browser - and prevents phishing attacks. The Kaje SAAS never knows anything about the user, so there is no way (short of hacking two different operating systems run by two different companies on completely separate networks, at least one of which is designed to prevent even a hack from being useful) for a black hat to get the user's info and password or other Proof of Knowledge. Kaje has built-in features to prevent keyboard and mouse snooping as well, and the vendor works diligently to know nothing about the user. There is no more private and secure method for user authentication or step-up authorization. And since the user uploads his/her own test challenge (picture or other), it acts automatically as two-factor authentication - much better than that "site key" that some banks are using, while being easier to remember."

Proofs of Knowledge include picture passwords, text passwords, cognitive self-tests, Captcha's and a bunch of others. NB - I work for the company. The founder is also the inventor of Self Encrypting Drives and has several patents related to online security.

Re:HL3HL3HL3

[Pubstar]

Speaking of Source 2, it should be released in full with some games at some point. Its already powering the DotA 2 Reborn client.