Valve and HackerOne: how not to handle vulnerability reports • Hacker News Board

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

#121

Post by detaro » Tue, Apr 14, 2020, 7:24 PM UTC

austincheney wrote: post #118

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…

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

The wikipedia article you cite as evidence lists several examples where no cryptography is involved as MITM attacks. As do many other sources.

e.g. OWASP: https://owasp.org/www-community/attacks/Man-in-the-middle_at...

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

#122

Post by wizzwizz4 » Tue, Apr 14, 2020, 7:26 PM UTC

fulafel wrote: post #120

austincheney wrote: post #118

Earlier quoted context omitted.

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

You are contradicting thr WP description, there is no cryptography required to meet the definition: "In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other" The WP definition is the commonly accepted one too, not a case of WP gett…

But here, there's no communication with store.steampowered.com. I mean, there could be— oh, yeah, getting it now. That's much worse than I thought it was; you could extract money from the account via gifts without even getting the user to re-enter their bank details.

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

#123

Post by tptacek » Tue, Apr 14, 2020, 7:27 PM UTC

austincheney wrote: post #118

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…

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

I do not understand the distinction you are trying to make. MITM has nothing in particular to do with certificates, and describes any attack in which Alice Bob, cryptographically or otherwise, and Mallory intercepts and controls communications via Alice Mallory Bob. Essentially every malicious proxy attack is a MITM.

The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first contact with Steam's backend. That's a legit finding. The "requires physical access" thing seems pretty obviously to be a misapplication of the H1 scope.

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

#124

Post by tptacek » Tue, Apr 14, 2020, 7:31 PM UTC

mtlynch wrote: post #116

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

> 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. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to ht…

1. Nobody competent would do this in a modern design.

2. Any security engineering team would flag this design.

3. Allowing https:// (anything) .steampowered.com / (anything) allows for arbitrary redirection into any property under that domain, some of which could be user (or customer) controlled. Does that matter on this domain? Who cares? Why have a design where you even have to ask?

The first contact with the load balancer should be HTTPS.

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

#125

Post by bllguo » Tue, Apr 14, 2020, 7:31 PM UTC

hmage wrote: post #32

vntok wrote: post #20

Earlier quoted context omitted.

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

Google Project Zero is doing exactly that -- disclosing them in 90 days no matter if they're fixed or not. This kind of pressure is helpful, because otherwise stories of OP will be dominant and security problems will stay unpatched.

but do they trumpet on twitter that they have an exploit and will release it in 90 days?

that's the difference

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

#126

Post by restingrobot » Tue, Apr 14, 2020, 7:32 PM UTC

nicholashead wrote: post #107

restingrobot wrote: post #71

Earlier quoted context omitted.

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.

The bottom line is, there's no reason to request the non-HTTPS connection in the first place. And there's apparently no checks in the app to make sure it's connected to their real server.

>The bottom line is, there's no reason to request the non-HTTPS connection in the first place.

The example I gave wasn't to excuse the issue, it was to maybe explain why the fix is taking so long.

> And there's apparently no checks in the app to make sure it's connected to their real server.

I don't think you can make that statement. The description of the issue only attempts to hi-jack the session, he didn't actually try to do anything with it. There may very well be checks in place.

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

#127

Post by user5994461 » Tue, Apr 14, 2020, 7:33 PM UTC

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…

Can you publish more details? Consider pastebin, github, personal blog, anywhere you can really.

Enterprises, as in publicly traded companies, should definitely not be leaking products and roadmaps because this affects their stock values. I bet you regulators won't like that and it will be fixed in a heartbeat.

edit: there is the CEO owner of github commenting on another front page article, might want to drop a word. https://news.ycombinator.com/item?id=22867627

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

#128

Post by infogulch » Tue, Apr 14, 2020, 7:33 PM UTC

austincheney wrote: post #118

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…

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

> MITM is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other. - Wikipedia on MITM

1. The steam client ("The App") thinks that it's communicating with Valve Inc. via store.steampowered.com ("The Store")

2. The App fails to validate that it is actually communicating with The Store by not using https

3. Thus, an attacker with control of an external network (e.g. a coffee shop wifi) can "secretly relay and possibly alter the communication between The App and The Store who believe they are communicating with each other"

I don't know how this could be any less than the definition of a MITM by wikipedia's own standard. That this kind of attack is also related to cryptography is immaterial to the fact that a reverse proxy is a MITM. It doesn't somehow make it not MITM because they weren't using any cryptography, it means that they failed to implement a protocol that sufficiently protects against MITM.

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

#129

Post by tptacek » Tue, Apr 14, 2020, 7:35 PM UTC

dlgeek wrote: post #2

HackerOne started with such promise, but stories like this keep coming out. It makes you wonder how many people were even more patient than OP. Unfortunately, despite all the HackerOne claims, it still seems to take public disclosure and embarrassment to make companies actually take things seriously. Seems sunlight is still the best disinfectant.

HackerOne is a business operating in a field with a maximal cross-product of drama and customer service overhead. Of course you're going to see story after story about them. What else would you expect?

Here's a story about someone with a decent but low-severity finding, apparently a duplicate of someone else's (unsurprisingly, since it's pretty obvious once you actually look at this app) who had a hard time getting Valve to take that finding seriously. It looks like H1's triage did not-the-greatest job in vetting the submission; also: not unheard-of.

And? I'm not sure there's a punch line here? "Tech worker has unsatisfying customer support experience with first-level security tech support" doesn't make for a zippy headline, but I think it sums up the story.

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

#130

Post by tgb » Tue, Apr 14, 2020, 7:42 PM UTC

austincheney wrote: post #118

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…

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

> If the violation occurred over port 80 its a safe bet there is no man in the middle attack. If I were doing security triage and I saw "man in the middle" and anything about HTTP or port 80 I would not consider this a priority ticket.

Can you explain this more? Are you just arguing that it's unencrypted and therefore by definition not MITM? I'm skeptical that this is common usage of the term (the Wikipedia article you linked to seems to disagree with you). And this seems a little like saying that you wouldn't be concerned about a privilege-escalation attack since you're inadvertently running everything as root.