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

81–90 of 162 posts

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

#81

Post by munk-a »

aasasd wrote: post #51
baby wrote: post #47

Earlier quoted context omitted.

I think what you’re all missing is the asymmetry that most bug reports are bad. If you understand this then you understand that hackerone has respected its promises to companies hiring them: they perform the first set of triage. With the number of reports they are going through, the number of bad stories we’re hearing about them is pretty abysmal. I feel like it’s the same with any type of bad news, it can easily blo…

Yeah, as far as I understand the entire model of HackerOne is that it's a first-line force for the security team, just like an outsourced support. And the first line tends to be cheap instead of well-trained.

Eeeh, I think that's a false assumption - it may in fact be the case but specialized first line teams like this don't need to be cheap, they can instead work the margins and be economical by being focused. Not every company is going to have a full security team, so it does make some sense to try and pool those resources into one specialist company that serves the first line triage needs of a bunch of other companies.

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

#82

Post by restingrobot »

detaro wrote: post #76
restingrobot wrote: post #75

Earlier quoted context omitted.

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.

It depends on how the app is displaying the link. They could be setting all sorts of cookie info/metadata in the original http request. There are many answers as to why it is accepted. I'm obviously not the developer of the valve app so I can't tell you exactly.

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

#83

Post by karagenit »

gnfargbl wrote: post #33
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…

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…

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.

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

#84

Post by Cpoll »

mtlynch wrote: post #52
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…

Plaintext HTTP in itself isn't a vulnerability. Suppose that Steam ran some kind of load balancing server at http://loadbalancer.steam.com (no TLS). Its only job is to respond to HTTP GET requests with the URL of the least-busy steam server like " https://a.store.steampowered.com" or " https://b.store.steampowered.com" . If the mobile client makes the request to the load balancer over plaintext HTTP and then verifies…

> verifies that the response has the steampowered.com domain and is https://

But you're trading an easy solution (only use https://) for several points of failures (validate potentially untrusted input all along the chain).

> verifies that the response has the steampowered.com domain

An attacker is going to look for any exploits on steampowered.com (open redirect, xss, etc.). So now your domain name check is insufficient, you also need to make sure that all of steampowered.com is secure (which, odds are, is managed by multiple teams).

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

#85

Post by kbenson »

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…

I understand, I mis-typed. I meant self-signed cert. That should have been pretty obvious from what I actually posted though.

https://store.steampowered.com is the official steam marketplace. It does not use a self-signed certificate.

> There are many benefits to using a self-signed SSL cert over purchasing a CA one.

I'm sure there are (not that any are immediately coming to mind), but this is the official web marketplace. It is NOT self-signed. It's signed by DigiCert, Inc, which is easy to check if you go there.

To clarify, store.steampowered.com is not some special app store subdomain. It's the official store, and where you are redirected in a browser if you go to steampowered.com. It is very unlikely they are using a self-signed certificate given it's an actual web address used by many tens of millions of people in their browsers primarily.

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

#86

Post by Cpoll »

dsl wrote: post #57
Saaster wrote: post #25

Companies receive so many "First, you have to be on the other side of this airtight hatch, then you..." reports that anything that looks even remotely like it will just get summarily closed. My personal favorite ones start with some form of "I copied the user's cookies from device A's file-system, and..." Just some suggestion on how to report these kind of things, because there is an actual underlying issue here wort…

I've been on both sides of this, and sadly having HackerOne/BugCrowd as intermediaries often hurts more than it helps. On one hand I've had to sort through the never ending stream of "if you bypass the safeguards first" issues and some guy in India copying and pasting open source vuln scanner reports. I get why people don't want to deal with this and outsource it. On the other hand, I have a legitimate exploit agains…

> No amount of back and forth is going to convince them that leaking commit messages on enterprise accounts is serious apparently.

If true, this deserves a write-up.

I'm sure a few enterprise accounts might agree, if anyone can see their dev-branch commit named "feature xyz" a month before they announce it.

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

#87

Post by detaro »

restingrobot wrote: post #82
detaro wrote: post #76

Earlier quoted context omitted.

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

It depends on how the app is displaying the link. They could be setting all sorts of cookie info/metadata in the original http request. There are many answers as to why it is accepted. I'm obviously not the developer of the valve app so I can't tell you exactly.

What doe cookies and metadata have to do with certificate validation?

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

#88

Post by odensc »

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…

Steam is not using self-signed certs. store.steampowered.com is their main user-facing storefont.

Why would they "most likely" be using a self-signed cert? That would be an extreme edge-case in my mind, not the standard.

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

#90

Post by staticassertion »

detaro wrote: post #64
djsumdog wrote: post #62

Earlier quoted context omitted.

No. No. No. No! Everything about this is wrong. The load balancer ABSOLUTELY should be HTTPS only and all request from the app, from the very first request, should be over HTTPS. If you want more security, add Strict Transport security as well as certification pinning in the app. But at a very basic level, there is absolutely no excuse for this app to making HTTP plain-text requests to steam at all. In your example,…

> and then verifies that the response has the steampowered.com domain and is https://* One would still need a justification for that design IMHO, but I don't think it is vulnerable to what you describe.

It's definitely a fine sanity check but I'd have to really think about whether it's a barrier.

Immediate things I worry about are around URL parsing.

Is evil.comsteampowered.com going to pass as "steampowered.com" when it isn't? Will it handle punycode? All sorts of shit can go wrong when parsing a URL, and it's a real world problem when people implement the mitigation you're describing[0].

https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...

This is just for starters. I think if I were being paid to think about it I'd probably be able to come up with some more. Can I mess with DNS? Can I inject some other malicious payload into the page, to take advantage of other vulns? etc etc etc

I would be extremely wary of this technique as a real boundary rather than just an assertion in code.

Post reply on HN