10 ms·

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_BJo

by watbe 11y ago

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.

baby 11y 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)
- cookiecaper 11y 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.
  - andrewchambers 11y ago
    In this particular case, the advice to avoid it is more simple. When designing test cases choose the extreme values, no text, too much text, etc.
  - deleted 11y ago
    [deleted]
  - Taek 11y ago
    There is something you can do about it, but it's expensive and different from what you are used to. Safer languages is a good place to start. Input validation can be made to be machine-verified, and anit-patterns can be learned and avoided. Static analysis tools can raise red and yellow flags. Finally, frameworks are being built for handling security critical things like account validation, crypto key handling, an related tasks that are important to get right. As the space continues to evolve, things like this will become less common, and someone who is aware of the trade and is diligent will be less likely to make mistakes.
    - LoSboccacc 11y ago
      > anit-patterns can be learned a spell checker didn't save you from a typo. not nitpicking, just using this example to illustrate a point: for an app to be secure, developers have to be 100% of the time on ball, while an attacker just has to be lucky once. the weight is so much in favor of attacker than only few of the biggest can afford to pay for a competitive level of security, it being a race: security is effective not when perfect, but when it costs more to attack a site than what you'd gain of it.
      - mdpopescu 11y ago
        Or even when the gain/cost ratio for attacking YOUR site is greater than the one for other sites. (You don't have to outrun the bear, you have to outrun the other people.)
      - ethbro 11y ago
        > a spell checker didn't save you from a typo Believe this is where parent's preference for high-quality, easy-to-use libraries handling common security operations comes from. It's a lot easier to make a typo (or logical mistake) in 250 lines of your own code than in (hopefully) <250 lines of a library invocation. Honestly, library functionality like this in any given language should be thought of as an analog to infrastructure spending. We're finally seeing reinvestment from end-users and value capturers (Facebook, Google, MS, etc) back down the chain to the OSS projects they depend on. Language guiders (and in some cases the support businesses who are attached to languages) should be equally serious about this. If your language doesn't have high-quality, easy-to-use libraries to mitigate attack surfaces, that's a fundamental weakness in your language eco-system... (Aka the "Perl+CPAN is better than a lot of more advanced languages, because code" argument)
    - georgerobinson 11y ago
      > Safer languages is a good place to start. Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. > Input validation can be made to be machine-verified Likewise, can you elaborate on this? How does the machine know what type of input this is? If input is tagged by the developer, what's to stop the developer from forgetting to tag the input correctly?
  - weavie 11y ago
    This is precisely the sort of error that Fuzz testing should have uncovered.
    - baby 11y ago
      When you have such a huge application (steam) how can you afford to Fuzz everything? Also to setup fuzzing for every parts of your applications
  - InclinedPlane 11y ago
    There's plenty that can be done about it, but it imposes a cost that most software shops don't want to pay today, despite the enormous costs of these breaches. Formal code reviews. Longer pipelines between checkin and deployment. Penetration testing during pre-release. Better QA, both manual and automated. Better security policies in general. And so on. Making a change to security related code should trigger a process that represents and avalanche of attention. There should be a shit-ton of scrutiny on any such change. The fact that something this simple wasn't caught is indicative not that "nothing can be done" but rather that most security related code today is handled in an amateurish way by teams who barely care about the consequences of their actions.
- on_and_off 11y 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.
  - gauravagarwalr 11y ago
    Not exactly sure how forgivable this is. But yes, unit testing and writing a few negative scenarios would have caught this problem early on.
- Strilanc 11y 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 https://www.youtube.com/watch?v=vKA4w2O61Xo
  - tripzilch 11y ago
    Watching that, it amazes me how many people don't get that. Not long ago there was an article on HN about this very experiment (from NY Times, IIRC). Now I can imagine, if you're not a software-tester by heart, that you'd maybe try to "win" the first or two tries, out of habit. I'm not a professional tester, just a coder, and reading the aforementioned article, I also first tried 3/6/12 and then some arbitrary increasing sequence, before catching myself and realizing if I want to figure out the rule I need some negative examples. Is this something you need to be a programmer to realize? Or maybe you need to have a "scientific" mind or something? I'm going to try this on some of my friends, see if I can figure it out. I expect a big part of it to be some psychological barrier against "failing" or getting "no" as an answer, especially if you're being put on the spot about some math-related puzzle. Many people feel uncomfortable with maths and perhaps fear giving a "wrong" answer and appearing "stupid". But "fear of maths" isn't what I'd be testing for, it's "willingness/realization to try an experiment with an (expected) negative outcome". So I'll make sure to formulate the problem in an appropriate manner, just like the guy in the video did, that the goal is to figure out the rule, not to finish the sequence. Try to make them comfortable, but not as far as saying "It's okay to ask me about a sequence that does not follow my rule", because that would obviously bias the experiment. Though I wonder now, there's some really interesting studies to be done (probably many already have been done), what if the puzzle is about some other rule for a sequence of three, that doesn't have anything to do with numbers? Say the rule is "objects of increasing size", but the (similarly misleading) example is bicycle / car / train.
    - jdmichal 11y ago
      I would think the phenomenon is basically equivalent to confirmation bias. A hypothesis is formed immediately upon seeing the question. Then, only further information which confirms their hypothesis is tested. Testing the negative is something that should be fairly routine in a scientific-testing mindset. For instance, medical experiments testing both placebos (negative) and medicine (positive) and looking for differences.
cookiecaper 11y 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 11y ago
  How did the string go from "" to nil automagically?
  - krainboltgreene 11y ago
    Bad database constraints obviously.
    - deleted 11y ago
      [deleted]
  - cookiecaper 11y ago
    I explained it incorrectly. It actually wasn't as simple as leaving the recovery code blank, because as you note, that would result in an empty string. What they did was delete the recovery_code element from the form entirely and then submit. It was a Rails project, so when the application requested params[:recovery_code], it would get back nil, since Ruby gives nil when you request a key that doesn't exist in a hash. If you left the box blank, you wouldn't hit the bug, because "" != NULL.
  - ajanuary 11y ago
    It wasn't the case here, but Oracle effectively treats empty string and null as the same value.
ars 11y 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.
- brobinson 11y 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/ http://codahale.com/a-lesson-in-timing-attacks/
  - tomjen3 11y ago
    True, but I don't think Steam allows you enough tries to make it viable.
  - deleted 11y ago
    [deleted]
  - kibibu 11y ago
    Also not a bug, but putting strlen() inside the loop condition makes my eyes twitch
- deleted 11y ago
  [deleted]
- jwiley 11y 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
  - ars 11y ago
    If you wrote it like that this bug would happen in every language. There is nothing in there that is worse because of C.
deleted 11y ago
[deleted]

by watbe 11y ago

baby 11y 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)

cookiecaper 11y 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.
- andrewchambers 11y ago
  In this particular case, the advice to avoid it is more simple. When designing test cases choose the extreme values, no text, too much text, etc.
- deleted 11y ago
  [deleted]
- Taek 11y ago
  There is something you can do about it, but it's expensive and different from what you are used to. Safer languages is a good place to start. Input validation can be made to be machine-verified, and anit-patterns can be learned and avoided. Static analysis tools can raise red and yellow flags. Finally, frameworks are being built for handling security critical things like account validation, crypto key handling, an related tasks that are important to get right. As the space continues to evolve, things like this will become less common, and someone who is aware of the trade and is diligent will be less likely to make mistakes.
  - LoSboccacc 11y ago
    > anit-patterns can be learned a spell checker didn't save you from a typo. not nitpicking, just using this example to illustrate a point: for an app to be secure, developers have to be 100% of the time on ball, while an attacker just has to be lucky once. the weight is so much in favor of attacker than only few of the biggest can afford to pay for a competitive level of security, it being a race: security is effective not when perfect, but when it costs more to attack a site than what you'd gain of it.
    - mdpopescu 11y ago
      Or even when the gain/cost ratio for attacking YOUR site is greater than the one for other sites. (You don't have to outrun the bear, you have to outrun the other people.)
    - ethbro 11y ago
      > a spell checker didn't save you from a typo Believe this is where parent's preference for high-quality, easy-to-use libraries handling common security operations comes from. It's a lot easier to make a typo (or logical mistake) in 250 lines of your own code than in (hopefully) <250 lines of a library invocation. Honestly, library functionality like this in any given language should be thought of as an analog to infrastructure spending. We're finally seeing reinvestment from end-users and value capturers (Facebook, Google, MS, etc) back down the chain to the OSS projects they depend on. Language guiders (and in some cases the support businesses who are attached to languages) should be equally serious about this. If your language doesn't have high-quality, easy-to-use libraries to mitigate attack surfaces, that's a fundamental weakness in your language eco-system... (Aka the "Perl+CPAN is better than a lot of more advanced languages, because code" argument)
  - georgerobinson 11y ago
    > Safer languages is a good place to start. Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. > Input validation can be made to be machine-verified Likewise, can you elaborate on this? How does the machine know what type of input this is? If input is tagged by the developer, what's to stop the developer from forgetting to tag the input correctly?
- weavie 11y ago
  This is precisely the sort of error that Fuzz testing should have uncovered.
  - baby 11y ago
    When you have such a huge application (steam) how can you afford to Fuzz everything? Also to setup fuzzing for every parts of your applications
- InclinedPlane 11y ago
  There's plenty that can be done about it, but it imposes a cost that most software shops don't want to pay today, despite the enormous costs of these breaches. Formal code reviews. Longer pipelines between checkin and deployment. Penetration testing during pre-release. Better QA, both manual and automated. Better security policies in general. And so on. Making a change to security related code should trigger a process that represents and avalanche of attention. There should be a shit-ton of scrutiny on any such change. The fact that something this simple wasn't caught is indicative not that "nothing can be done" but rather that most security related code today is handled in an amateurish way by teams who barely care about the consequences of their actions.
on_and_off 11y 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.
- gauravagarwalr 11y ago
  Not exactly sure how forgivable this is. But yes, unit testing and writing a few negative scenarios would have caught this problem early on.
Strilanc 11y 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 https://www.youtube.com/watch?v=vKA4w2O61Xo
- tripzilch 11y ago
  Watching that, it amazes me how many people don't get that. Not long ago there was an article on HN about this very experiment (from NY Times, IIRC). Now I can imagine, if you're not a software-tester by heart, that you'd maybe try to "win" the first or two tries, out of habit. I'm not a professional tester, just a coder, and reading the aforementioned article, I also first tried 3/6/12 and then some arbitrary increasing sequence, before catching myself and realizing if I want to figure out the rule I need some negative examples. Is this something you need to be a programmer to realize? Or maybe you need to have a "scientific" mind or something? I'm going to try this on some of my friends, see if I can figure it out. I expect a big part of it to be some psychological barrier against "failing" or getting "no" as an answer, especially if you're being put on the spot about some math-related puzzle. Many people feel uncomfortable with maths and perhaps fear giving a "wrong" answer and appearing "stupid". But "fear of maths" isn't what I'd be testing for, it's "willingness/realization to try an experiment with an (expected) negative outcome". So I'll make sure to formulate the problem in an appropriate manner, just like the guy in the video did, that the goal is to figure out the rule, not to finish the sequence. Try to make them comfortable, but not as far as saying "It's okay to ask me about a sequence that does not follow my rule", because that would obviously bias the experiment. Though I wonder now, there's some really interesting studies to be done (probably many already have been done), what if the puzzle is about some other rule for a sequence of three, that doesn't have anything to do with numbers? Say the rule is "objects of increasing size", but the (similarly misleading) example is bicycle / car / train.
  - jdmichal 11y ago
    I would think the phenomenon is basically equivalent to confirmation bias. A hypothesis is formed immediately upon seeing the question. Then, only further information which confirms their hypothesis is tested. Testing the negative is something that should be fairly routine in a scientific-testing mindset. For instance, medical experiments testing both placebos (negative) and medicine (positive) and looking for differences.

cookiecaper 11y 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 11y ago
How did the string go from "" to nil automagically?
- krainboltgreene 11y ago
  Bad database constraints obviously.
  - deleted 11y ago
    [deleted]
- cookiecaper 11y ago
  I explained it incorrectly. It actually wasn't as simple as leaving the recovery code blank, because as you note, that would result in an empty string. What they did was delete the recovery_code element from the form entirely and then submit. It was a Rails project, so when the application requested params[:recovery_code], it would get back nil, since Ruby gives nil when you request a key that doesn't exist in a hash. If you left the box blank, you wouldn't hit the bug, because "" != NULL.
- ajanuary 11y ago
  It wasn't the case here, but Oracle effectively treats empty string and null as the same value.

ars 11y 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.

brobinson 11y 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/ http://codahale.com/a-lesson-in-timing-attacks/
- tomjen3 11y ago
  True, but I don't think Steam allows you enough tries to make it viable.
- deleted 11y ago
  [deleted]
- kibibu 11y ago
  Also not a bug, but putting strlen() inside the loop condition makes my eyes twitch
deleted 11y ago
[deleted]
jwiley 11y 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
- ars 11y ago
  If you wrote it like that this bug would happen in every language. There is nothing in there that is worse because of C.

deleted 11y ago

[deleted]