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

111–120 of 162 posts

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

#111

Post by buildbot »

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…

The domain and what they are reading off of that filesystem matters though. Like for example, if there was a credential that is in the clear/poorly encrypted and used in other parts of your system.

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

#112

Post by kbenson »

restingrobot wrote: post #93
kbenson wrote: post #85

Earlier quoted context omitted.

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

I'm not a valve developer so I can't tell you exactly what is happening, but you most certainly can serve different certificates to browser vs mobile. The apps are using WebViews which are not the same as Chrome and Mobile safari. It would make sense to us a CA cert for normal browser traffic as it is fairly sandboxed as far what you can and cannot do, the WebViews are a completely different environment. Again I'm sa…

> I am basing my theory on the fact that the http endpoints immediately re-direct to https ones, so it seems to be intentional for one reason or another.

I don't know, that seems pretty bog-standard to me. You redirect to HTTPS when someone requests HTTP when you want your traffic to all be secure. At least, that's how it used to be, these days browsers be be more aggressive in trying to hand you to the HTTPS version of sites if port 80 doesn't respond, and in that case it might make more sense to turn down port 80 as long as all browsers do the right thing.

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

#113

Post by flatiron »

oehpr wrote: post #77
lucideer wrote: post #56

Earlier quoted context omitted.

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

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.

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

#116

Post by mtlynch »

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

>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 http://loadbalancer.steam.com

2. Load balancer responds with a URL string like "https://a.steampowered.com"

3. App verifies that the domain ends with "steampowered.com" and starts with "https://"

4. If verification passes, app loads the response URL in the in-app browser

In that case, replacing http://loadbalancer.steam.com with a spoofed page doesn't do anything because the app's internal logic sees the response, not a human user. If you replaced it with anything but a https://*.steampowered.com, the app would refuse to load the URL, so I don't see the vulnerability.

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

#117

Post by kbenson »

vntok wrote: post #96
kbenson wrote: post #78

Earlier quoted context omitted.

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

That is false. In many jurisdictions, blackmail does not require a financial transaction, merely obtaining something deemed valuable by the blackmailer in exchange for keeping the blackmailee's information private. See [1] for the US: Whoever, under a threat of informing, or as a consideration for not informing, against any violation of any law of the United States, demands or receives any money or other valuable thi…

> merely obtaining something deemed valuable by the blackmailer in exchange for keeping the blackmailee's information private.

Exactly. That's why if you have a policy about when the information goes public which is entirely independent of any benefits provided by the company in question, it's not blackmail.

You're not saying "unless you give me X benefit I do Y", you're saying "I'm doing Y at Z date, but I may extend that if you show you're working on the problem." which isn't a benefit to you specifically, but to those affected. As long as you make sure any benefit to yourself is removed from that decision, I imagine blackmail would be very hard to prove.

Bragging rights aren't really the company's to give, since you have the information and will be making it public, unless someone else beat you to it. In that case, going live early unless the company says you found it does impart a real benefit to you that you extracted from the company. That's not what I viewed this thread as about though. Saying you'll release the vulnerability you were already going to release (if you had a clear policy applied consistently) is not so much a threat as giving the company an appropriate chance to respond.

I agree in the case of private companies with little or no public component it does get less clear cut. I'm not sure what those would be though.

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

#118

Post by austincheney »

michaelt wrote: post #42
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 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 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.

This incident is just a software defect rather than a security violation from the unexpected use of a reverse proxy: https://en.wikipedia.org/wiki/Reverse_proxy

An unsupported reverse proxy was only possible because the site was transmitting over HTTP instead of HTTPS.

> If that isn't clear to someone

It isn't clear merely because you used the scary term: MITM. A trained security professional performing triage would devalue the security ticket pending further investigation.

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

#119

Post by Arnavion »

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…

>There is no such thing as a "self-signed" CA cert, (its one or the other).

Not sure what you're trying to say here. What a cert is signed by and what a cert's usage is set to are orthogonal things. There are CA certs that are self-signed (look in your OS's trusted roots cert store) and there are CA certs that are signed by other CA certs (intermediate CA certs).

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

#120

Post by fulafel »

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…

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 getting it wrong.

Post reply on HN