5 ms·

I think Valve and HackerOne handled this poorly, but I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I worked

I think Valve and HackerOne handled this poorly, but I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I worked as a penetration tester for a while, and I had trouble understanding what the author was saying. The headline should have been that the steam mobile app makes requests to the plaintext HTTP URL (http://store.steampowered.com http://store.steampowered.com) instead of the TLS-authenticated URL (https://store.steampowered.com https://store.steampowered.com). Without TLS, an attacker can impersonate the Steam store server and steal credit cards or trick users into installing malicious apps. The author reported this as: >The vulnerability is that an attacker can perform a man in the middle attack by spoofing an HTTP request pretending to be from store.steampowered.com. While the client does check for an eventual HTTPS redirect, it can redirect to an HTTPS URL. There's so much ambiguity and missing information in that writeup: * Who does the attacker send an HTTP request to? I think the author meant to say an HTTP response. * In "it can redirect," does the word "it" refer to the "the client" or "redirect?" * I think "it can redirect to an HTTPS URL" was supposed to be "any HTTPS URL." * Why is the client vulnerable? What should they be doing instead? Also, the author's exploit scenario is to just make the Steam app load his portfolio page, which might have further muddled things. It sounds inconsequential that an attacker can trick Steam users into visiting a developer's portfolio page. It might have been a clearer report if the proof-of-concept redirected to a website that looked like the Steam store but had a warning saying, "I'm an evil copy of the Steam store that will steal your credit card number."

gnfargbl 7y ago
So in a nutshell, could we summarise the issue here as "Valve didn't use TLS and thus Valve's users are vulnerable to the exceptionally well-known consequences of not using TLS?" If so, then... okay, but I don't know what the blog author was expecting when he reported this. Pointing out that HTTP has MiTM possibilities is kind of up there with pointing out that the sky is blue. If, in 2020, a site has made the choice not to upgrade to TLS then it's more likely a conscious decision than an oversight.
- deleted 7y ago
  [deleted]
- minitech 7y ago
  It was an oversight. They had HTTPS support. Going by the bug report, the client checked for a redirect to HTTPS, but didn’t check that it was to the correct domain.
  - gnfargbl 7y ago
    OK, that's a little more understandable. I assume that the initial use of HTTP is an intentional tactic that Steam uses to discover whether it is behind a captive portal or similar. That being the case then yes, the Steam client shouldn't rely on the data returned from the HTTP request, and this seems like a bug.
- karagenit 7y ago
  The author stated that Valve ended up patching this and switching to fully-HTTPS, which makes me think that this was a bug and not intentional.
michaelt 7y ago
> I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. You simply cannot do that job right if you need the attacker to hand-walk you through the difference between HTTP and HTTPS and why you would use the latter for an online store.
- capableweb 7y ago
  Do note that mtlynch is not saying that it's all the authors fault and Valve/HackerOne couldn't handle this better. What you've written can be true as at the same time, what mtlynch has written is true too. Everyone could do better here. But most likely, giving feedback to Valve/HackerOne via a Hacker News thread is likely to not be read. The feedback to the author is more likely to be read by the author themselves and other aspiring penetration testers. So in the end, everyone could have done better.
  - munk-a 7y ago
    I feel like that issue translation step is part of what HackerOne is actually there to do though - they serve as a collection and initial triaging point... if they are bad at doing a first pass of issue triaging and clarification then what are they even doing? Additionally the person at hackerone did ask for some clarification around the issue, that's great as it is helping with identification but probably also needs to encompass expressing the problem to make it clearer to read.
    - capableweb 7y ago
      Indeed, I agree with you. Poorly handled. But that doesn't mean you as a penetration tester can do better _also_, to avoid similar future scenarios where they handle things poorly.
- Taek 7y ago
  Respectfully disagree with this one. We don't even have a bounty program, and we get at least 10 non-issues for every actual potentially exploitable report. I can definitely see someone reviewing this and accidentally putting it in the "not a problem" bucket. From our perspective, the best vulnerability reports look like: "This potential exploit can crash your node" "This potential exploit can steal user funds" Etc. It really helps us filter through the nonsense reports we get.
contravariant 7y ago
That first sentence is a trainwreck but the steps that follow do at least clearly outline the issue.
lucideer 7y ago
I'm not a security expert. I am a software engineer; as such make it my responsibility to understand something of network security, but I have no formal training in such and I don't work in a specifically security-focused role. Nor do I work for an explicitly security-focused company. I understood the issue clearly on first read. You're absolutely right that it could have been explained more clearly, and that there is some ambiguity in the wording (not everyone's a perfect communicator). But if I (a very normal, non-security-focused software engineer) can grok this, it's the absolute least I would expect from someone working for HackerOne! Their entire job is to be able to understand this sort of thing in depth.
- oehpr 7y ago
  Exactly! I was sitting there scratching my head on this one. I get that Joe Shmoe wouldn't understand the risks of a MITM and the potential areas it could be exploited, even John Q Programmer I wouldn't guarantee to understand the risks. But a person working at Hacker One who's job is assessing vulnerabilities doesn't understand the threat of a MITM? What?! Does everyone at Hacker One think the whole move to HTTPS was just pointless security theater or something? How is that possible? How does this chain of events even happen? It looks like the author spoke to multiple people at Hacker One who were genuinely not understanding the threat, after it was explained to them. We must be missing some side of this here. That's too absurd to be real.
  - flatiron 7y ago
    I skimmed it. He saw a bunch of http gets and the setup a dns server and ohh I see where he’s going with this. Yep a picture of a weird page in the steam app ok I get it.
tvladeck 7y ago
I'm not even a software engineer. Lowly MBA that writes R code. even I understood the gist. But the part that I understood well is that _this was a HackerOne managed program_, meaning that it's HackerOne's job to take a raw submission and turn it into a well designed report that can be triaged and fixed.
ngold 7y ago
Thank you. This was a bit confusing. It helped that this was the first paragraph. >This is my first blog, but I felt like this is something I needed to get off my chest after months. If people enjoy this blog post, I will probably do more in the future. I'm sure this blog will probably learn a hard and fast lesson on writing thanks to your post. This can't be any easy topic to explain. You did a solid job, thank you again.
imtringued 7y ago
No, the problem is that HackerOne isn't actually a "Bug Bounty as a Service" company. It's a "Cover Corporate Asses as a Service" company. They don't care if they don't understand your vulnerability. Their primary value add is that their customers can stick their heads into the sand and still create the impression that their software has no security flaws. What happens is that HackerOne forces security researchers into one specific workflow. They have an incentive to close as many bug reports as out of scope to avoid paying a bounty. There is no incentive to have qualified staff that actually have the technical background knowledge to determine if your report is actually a security problem or not. The fact that reporters have to create a hackerone account means that HackerOne can ban you from their platform and you automatically lose the ability to report bugs for other companies. What often happens is that they simply ignore your report and try to pretend that it never existed in the first place. When the reporter decides that public disclosure is the the path of last resort then HackerOne will respond immediately and blame the reporter for not following the HackerOne workflow and ban the account of that reporter. The fact that Valve decided to pay money to this company implies that they don't care about security. You can't blame them for not fixing the vulnerabilities when HackerOne is interfering heavily in the process but you can blame Valve for knowingly choosing a company with a horrifyingly bad track record.

gnfargbl 7y ago

So in a nutshell, could we summarise the issue here as "Valve didn't use TLS and thus Valve's users are vulnerable to the exceptionally well-known consequences of not using TLS?" If so, then... okay, but I don't know what the blog author was expecting when he reported this. Pointing out that HTTP has MiTM possibilities is kind of up there with pointing out that the sky is blue. If, in 2020, a site has made the choice not to upgrade to TLS then it's more likely a conscious decision than an oversight.

deleted 7y ago
[deleted]
minitech 7y ago
It was an oversight. They had HTTPS support. Going by the bug report, the client checked for a redirect to HTTPS, but didn’t check that it was to the correct domain.
- gnfargbl 7y ago
  OK, that's a little more understandable. I assume that the initial use of HTTP is an intentional tactic that Steam uses to discover whether it is behind a captive portal or similar. That being the case then yes, the Steam client shouldn't rely on the data returned from the HTTP request, and this seems like a bug.
karagenit 7y ago
The author stated that Valve ended up patching this and switching to fully-HTTPS, which makes me think that this was a bug and not intentional.

michaelt 7y ago

> I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. You simply cannot do that job right if you need the attacker to hand-walk you through the difference between HTTP and HTTPS and why you would use the latter for an online store.

capableweb 7y ago
Do note that mtlynch is not saying that it's all the authors fault and Valve/HackerOne couldn't handle this better. What you've written can be true as at the same time, what mtlynch has written is true too. Everyone could do better here. But most likely, giving feedback to Valve/HackerOne via a Hacker News thread is likely to not be read. The feedback to the author is more likely to be read by the author themselves and other aspiring penetration testers. So in the end, everyone could have done better.
- munk-a 7y ago
  I feel like that issue translation step is part of what HackerOne is actually there to do though - they serve as a collection and initial triaging point... if they are bad at doing a first pass of issue triaging and clarification then what are they even doing? Additionally the person at hackerone did ask for some clarification around the issue, that's great as it is helping with identification but probably also needs to encompass expressing the problem to make it clearer to read.
  - capableweb 7y ago
    Indeed, I agree with you. Poorly handled. But that doesn't mean you as a penetration tester can do better _also_, to avoid similar future scenarios where they handle things poorly.
Taek 7y ago
Respectfully disagree with this one. We don't even have a bounty program, and we get at least 10 non-issues for every actual potentially exploitable report. I can definitely see someone reviewing this and accidentally putting it in the "not a problem" bucket. From our perspective, the best vulnerability reports look like: "This potential exploit can crash your node" "This potential exploit can steal user funds" Etc. It really helps us filter through the nonsense reports we get.

contravariant 7y ago

That first sentence is a trainwreck but the steps that follow do at least clearly outline the issue.

lucideer 7y ago

I'm not a security expert. I am a software engineer; as such make it my responsibility to understand something of network security, but I have no formal training in such and I don't work in a specifically security-focused role. Nor do I work for an explicitly security-focused company. I understood the issue clearly on first read. You're absolutely right that it could have been explained more clearly, and that there is some ambiguity in the wording (not everyone's a perfect communicator). But if I (a very normal, non-security-focused software engineer) can grok this, it's the absolute least I would expect from someone working for HackerOne! Their entire job is to be able to understand this sort of thing in depth.

oehpr 7y ago
Exactly! I was sitting there scratching my head on this one. I get that Joe Shmoe wouldn't understand the risks of a MITM and the potential areas it could be exploited, even John Q Programmer I wouldn't guarantee to understand the risks. But a person working at Hacker One who's job is assessing vulnerabilities doesn't understand the threat of a MITM? What?! Does everyone at Hacker One think the whole move to HTTPS was just pointless security theater or something? How is that possible? How does this chain of events even happen? It looks like the author spoke to multiple people at Hacker One who were genuinely not understanding the threat, after it was explained to them. We must be missing some side of this here. That's too absurd to be real.
- flatiron 7y ago
  I skimmed it. He saw a bunch of http gets and the setup a dns server and ohh I see where he’s going with this. Yep a picture of a weird page in the steam app ok I get it.

tvladeck 7y ago

I'm not even a software engineer. Lowly MBA that writes R code. even I understood the gist. But the part that I understood well is that _this was a HackerOne managed program_, meaning that it's HackerOne's job to take a raw submission and turn it into a well designed report that can be triaged and fixed.

ngold 7y ago

Thank you. This was a bit confusing. It helped that this was the first paragraph. >This is my first blog, but I felt like this is something I needed to get off my chest after months. If people enjoy this blog post, I will probably do more in the future. I'm sure this blog will probably learn a hard and fast lesson on writing thanks to your post. This can't be any easy topic to explain. You did a solid job, thank you again.

imtringued 7y ago

No, the problem is that HackerOne isn't actually a "Bug Bounty as a Service" company. It's a "Cover Corporate Asses as a Service" company. They don't care if they don't understand your vulnerability. Their primary value add is that their customers can stick their heads into the sand and still create the impression that their software has no security flaws. What happens is that HackerOne forces security researchers into one specific workflow. They have an incentive to close as many bug reports as out of scope to avoid paying a bounty. There is no incentive to have qualified staff that actually have the technical background knowledge to determine if your report is actually a security problem or not. The fact that reporters have to create a hackerone account means that HackerOne can ban you from their platform and you automatically lose the ability to report bugs for other companies. What often happens is that they simply ignore your report and try to pretend that it never existed in the first place. When the reporter decides that public disclosure is the the path of last resort then HackerOne will respond immediately and blame the reporter for not following the HackerOne workflow and ban the account of that reporter. The fact that Valve decided to pay money to this company implies that they don't care about security. You can't blame them for not fixing the vulnerabilities when HackerOne is interfering heavily in the process but you can blame Valve for knowingly choosing a company with a horrifyingly bad track record.