Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Valve and HackerOne: how not to handle vulnerability reports

blog.jakegealer.me

Post reply on HN
Print view View original

71–80 of 162 posts

Re: Valve and HackerOne: how not to handle vulnerability reports

#71

Post by restingrobot »

djsumdog wrote: post #66
restingrobot wrote: post #61

>For a simple MITM exploit that can be fixed by replacing " http://" with " https://" , this is simply unacceptable. I think the author is really not understanding the complexity of updating to an https:// url inside of a mobile applicaiton. Valve is most likely using a self signed cert so that would require bundling the certification in with the app so that Apple/Android allowed it to load inside of a webview. This…

Why would they use a self signing cert? They could use a real Cert. It's Steam. They can afford real certs, or just use LetsEncrypt. There is absolutely no reason for the app to connect to a login/authentication service (or any service) over plain text, period! There should be unit tests that scan for http:// and will fail the build if found in the code or resources. I know some things are not simple fixes, but this…

A self signed cert is a a real cert, its just not provided by an CA authority. I guarantee you this http just redirects to an https location, (just tested it on my own device), so there is no plain text transfer. In the mobile industry this happens all the time as backend endpoints grow and change.

Re: Valve and HackerOne: how not to handle vulnerability reports

#72

Post by tvladeck »

mtlynch wrote: post #23

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 ) instead of the TLS-authenticated…

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.

Re: Valve and HackerOne: how not to handle vulnerability reports

#73

Post by kbenson »

restingrobot wrote: post #65
user5994461 wrote: post #38

Earlier quoted context omitted.

Simply say that there is a typo in the steam configuration, it is connecting to the (insecure) URL http://.. . This allows steam network traffic to be intercepted. It can be fixed by correcting the URL to https. For example, somebody using steam from a coffee shop could have his credentials/cookies/accounts intercepted by the coffee shop operator or any other visitor. I believe coffees and other gaming venues are a s…

This is most likely not a typo. The redirect from http to http is most likely due to valve using a self signed ssl certificate and not directly exposing it to ATS, (iPhone). If they went directly to the https endpoint the OS would block the traffic to an invalid, (not CA authority signed), SSL certificate.

store.steampowered.com is a fully web accessible site with a CA signed certificate though. It's the main steam marketplace. I think the whole point is that they are leveraging this for their app, so using a self-signed CA doesn't make a lot of sense in that case (not that I'm sure it ever would for a company these days, SSL certs are cheap).

Re: Valve and HackerOne: how not to handle vulnerability reports

#74

Post by [deleted] »

kbenson wrote: post #67
armitron wrote: post #43

I don't get the "this issue is a duplicate so we won't pay" business. If I find a serious issue that's still unpatched and someone tells me "Ops it's a duplicate sorry!" I'm still going to ask for payment. If I don't get it, it's a given that I'm going public - assuming it is legal to do so -. Why doesn't everyone do that? I'll go even further and say that price negotiation should happen at every disclosure. If you'r…

> If I find a serious issue that's still unpatched and someone tells me "Ops it's a duplicate sorry!" I'm still going to ask for payment. If I don't get it, it's a given that I'm going public. Probably because I think what you've just described could be viewed as extortion, which is illegal in many locations? Also, it doesn't really do you any favors, I think. You'll get a week or less of recognition as finding an ex…

[deleted]

Re: Valve and HackerOne: how not to handle vulnerability reports

#75

Post by restingrobot »

kbenson wrote: post #73
restingrobot wrote: post #65

Earlier quoted context omitted.

This is most likely not a typo. The redirect from http to http is most likely due to valve using a self signed ssl certificate and not directly exposing it to ATS, (iPhone). If they went directly to the https endpoint the OS would block the traffic to an invalid, (not CA authority signed), SSL certificate.

store.steampowered.com is a fully web accessible site with a CA signed certificate though. It's the main steam marketplace. I think the whole point is that they are leveraging this for their app, so using a self-signed CA doesn't make a lot of sense in that case (not that I'm sure it ever would for a company these days, SSL certs are cheap).

I don't think you understand. There is no such thing as a "self-signed" CA cert, (its one or the other). This not about money, it's about control. There are many benefits to using a self-signed SSL cert over purchasing a CA one. However, Apple and Android inherently distrust self-signed certs so you have to actually provide the cert directly to ATS/Android OS which involves bundling it within the app, (a messy process). The current industry "hack" is to use http within the app, and then re-direct to https, (which is exactly what the steam app does).

Re: Valve and HackerOne: how not to handle vulnerability reports

#76

Post by detaro »

restingrobot wrote: post #75
kbenson wrote: post #73

Earlier quoted context omitted.

store.steampowered.com is a fully web accessible site with a CA signed certificate though. It's the main steam marketplace. I think the whole point is that they are leveraging this for their app, so using a self-signed CA doesn't make a lot of sense in that case (not that I'm sure it ever would for a company these days, SSL certs are cheap).

I don't think you understand. There is no such thing as a "self-signed" CA cert, (its one or the other). This not about money, it's about control. There are many benefits to using a self-signed SSL cert over purchasing a CA one. However, Apple and Android inherently distrust self-signed certs so you have to actually provide the cert directly to ATS/Android OS which involves bundling it within the app, (a messy proces…

Why does the redirected request accept a self-signed cert, but the initial request doesn't? That seems weird.

Re: Valve and HackerOne: how not to handle vulnerability reports

#77

Post by oehpr »

lucideer wrote: post #56
mtlynch wrote: post #23

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 ) instead of the TLS-authenticated…

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 i…

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.

Re: Valve and HackerOne: how not to handle vulnerability reports

#78

Post by kbenson »

vntok wrote: post #20
tcd wrote: post #7

Just drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. Make sure to deal with an actual human and that everything is done according to best practice. You may even get publicity this way and even if it's unethical it can be sold or used to your advantage. If they care, trust me when I…

> Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. That's blackmail. An expedient way of getting your door breached.

No, the disclosure is disconnected from payment, so it's not blackmail. Notifying companies is a courtesy, and considered good form. Companies offering rewards is to incentivize this behavior. Researchers releasing vulnerabilities after a time period no matter what is to incentivize companies to actually fix the problems (not just pay to shut up the researcher). Both are useful for a well functioning system of independent researchers finding vulnerabilities in companies that then get fixed.

Releasing the vulnerability because you weren't paid, regardless of whatever timelines you would have followed? That's blackmail. I imagine having a very clear and consistent policy as a researcher that is not based on money (but can be based on company participation and whether they seem like they are actually trying to fix the problem) will go a long way towards clearing you of any suspicion of blackmail.

Re: Valve and HackerOne: how not to handle vulnerability reports

#79

Post by munk-a »

capableweb wrote: post #49
michaelt wrote: post #42

Earlier quoted context omitted.

> 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 be…

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 a…

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.

Post reply on HN