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

61–70 of 162 posts

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

#61

Post by restingrobot »

>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 is not nearly as simple as just updating all of the urls in the app to https:// and the fix could very well take a few months. Furthermore, loading the store page is not necessarily a vulnerability to valve as if you are able to re-direct it, you wouldn't have access to any of the Steam user specifics, (like account data). It wouldn't be much different than putting a shady link somewhere on the internet, and people navigating to it.

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

#62

Post by djsumdog »

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…

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, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com, have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam.

You can't just have a plain text load balancer redirect to https because someone else can intercept you BEFORE that redirect takes place.

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

#63

Post by pm_me_ur_fullz »

Responsible Disclosure does not mean waiting for arbitrary and unilateral decisions from a company just to be undervalued.

If your argument for responsible disclosure equally applies to this post, a $100 payout and to a $100,000 payout - as long as its from the company that needs to patch the exploit, then re-evaluate your argument.

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

#64

Post by detaro »

djsumdog wrote: post #62
mtlynch wrote: post #52

Earlier quoted context omitted.

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…

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.

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

#65

Post by restingrobot »

user5994461 wrote: post #38
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…

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.

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

#66

Post by djsumdog »

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 is absolutely a fix that can be done and we should all know how to do. It should have also been made a security priority and pushed through.

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

#67

Post by kbenson »

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 exploit, and then the story will come out how you both sniped someone else's find and possibly caused damage on purpose for your five minutes of fame.

To be clear, it's the initial monetary request and actions because it was denied that makes this entirely mercenary and would not reflect well on you. You were obviously willing to sit on the exploit for a while for some cash, so you no longer have any moral arguments to rely on for your behavior if you release it immediately, and the fact that it's not original just makes it worse. I imagine your reputation for security matters might never recover.

There are ways to get the moral defense back, but it requires waiting a while to see if it actually gets fixed and not taking it public immediately (so it actually is for their unresponsiveness and not just because they didn't pay).

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

#68

Post by kidintech »

Taek wrote: post #50
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…

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

While I can see what you're saying, you also have to properly compute, on your end, a cost for a False Positive and a cost for a False Negative.

In my opinion, in the case of security, I think a False Negative should weigh a lot, and thus measures to prevent it should be in place (i.e. not having an intern mindlessly looking through issues and sorting them into buckets).

Of course, the cost of each will depend on your app/company, its industry, its size, and so on.

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

#69

Post by djsumdog »

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.

But why even deal with that complexity? It's another place where thinks can break or you forget something. You can verify the doamin there too, but that still doesn't mean you can just make the request for the redirect over http and think that's okay.

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

#70

Post by Hitton »

>This means 1 of 2 things:

>They're trying to get out of paying bug bounty money: I guess this is the more extreme perspective to take here, but considering the whole experience, a definitely possible one. I wasn't here for the bug bounty money, I have work by this point, but if there's some younger child trying to get into security research doing this, this could be enough to massively demotivate them if they were promised it from the HackerOne page.

>They had someone who posted the same bug either weeks or months in advance: This means that Valve left someone else hanging for an insanely long time. This is equally messed up.

I can't understand that in the age of blockchain buzzword bullshitting companies, in one instance where the immutable public ledger would actually be useful (for instance with sha512 hash of initial report) it isn't used. It wouldn't be very complicated and it would immensely help their trustworthiness.

Post reply on HN