Valve and HackerOne: how not to handle vulnerability reports
blog.jakegealer.me
blog.jakegealer.me
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 URL (https://store.steampowered.com). Without TLS, an attacker can impersonate the Steam store server and steal credit cards or trick users into installing malicious apps.
The author reported this as:
>The vulnerability is that an attacker can perform a man in the middle attack by spoofing an HTTP request pretending to be from store.steampowered.com. While the client does check for an eventual HTTPS redirect, it can redirect to an HTTPS URL.
There's so much ambiguity and missing information in that writeup:
* Who does the attacker send an HTTP request to? I think the author meant to say an HTTP response.
* In "it can redirect," does the word "it" refer to the "the client" or "redirect?"
* I think "it can redirect to an HTTPS URL" was supposed to be "any HTTPS URL."
* Why is the client vulnerable? What should they be doing instead?
Also, the author's exploit scenario is to just make the Steam app load his portfolio page, which might have further muddled things. It sounds inconsequential that an attacker can trick Steam users into visiting a developer's portfolio page. It might have been a clearer report if the proof-of-concept redirected to a website that looked like the Steam store but had a warning saying, "I'm an evil copy of the Steam store that will steal your credit card number."
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 not to upgrade to TLS then it's more likely a conscious decision than an oversight.
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 between HTTP and HTTPS and why you would use the latter for an online store.
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 and other aspiring penetration testers.
So in the end, everyone could have done better.
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.
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.
It really helps us filter through the nonsense reports we get.
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.
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 that the response has the steampowered.com domain and is https:// then that's not a vulnerability, despite the fact that an attacker can MitM the plaintext HTTP part.
I would recommend that Steam just do everything over HTTPS for the sake of defense in depth, but I definitely wouldn't award a bounty to someone for proving they could MitM my load balancer and cause no damage. The worst the attacker can do in that scenario is cause the app to see network failures (specifically, TLS handshake failures), but if the attacker is middling traffic, that's possible regardless.
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.
One would still need a justification for that design IMHO, but I don't think it is vulnerable to what you describe.
Immediate things I worry about are around URL parsing.
Is evil.com<insert something here>steampowered.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.
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.
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.
I 100% agree that people shouldn't design systems this way, and if I were still a pentester, I'd write it up if I found it. But if the implementation correctly checked the domain and verified it was https:// (and maybe did some cert pinning), I couldn't justify anything higher than low severity.
We've kind of gone way into the weeds on my made up example, but it was initially in response to this:
>> > 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.
I just disagree with the idea that any plaintext HTTP request in an app inherently is a vulnerability.
I'm more of an absolutist about HTTPS than you are, though. :)
I feel like every once in awhile I need to plow face-first into the brick wall of a friendly comment like this just as a signal to dial it back a bit. It's been a challenging couple weeks. I'll dial it back a bit! Thanks again.
I’m going to take this as what the intention was when designing this solution.
> 3. App verifies that the domain ends with "steampowered.com" and starts with "https://"
I’m going to take this to be what would have actually been coded in this solution.
I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https.
This solution is fragile. Why not just do the whole thing over TLS to begin with and avoid this vulnerability in the first place?
Yeah, that's a good point. That's my mistake in spitballing, but the vulnerability wouldn't exist in an implementation that properly checked the domain.
Again, I 100% agree with you that it's fragile and not a good idea. I wouldn't design a system this way, and I would flag it if I reviewed an app that did this. I was just objecting to the idea that the discovery of any plaintext HTTP request is a bounty-worthy vulnerability.
If the application does some sort of SSL pinning you may have to MITM the handshake but that's not outside of the realm of possibility for a sophisticated attacker.
I know it's just an example of how something COULD work but I strongly disagree that the following is correct:
> The worst the attacker can do in that scenario is cause the app to see network failures
Also - it's worth noting that all of this DNS talk really makes the whole SSL discussion moot. This is exactly why things like DNSSEC exist. If I'm able to point your traffic wherever you're done.
DoH: different story.
I guess I always assumed that DNSSEC would blow up when changing the destination of the point but have never really dealt with may DNSSEC rollouts outside of light maintenance.
Thanks for a great response, I'm going to formally learn on DNSSEC because this is a good flag that I need better understanding. Also DoH is a new topic to me too so definitely going to "dig" on that as well ;)
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).
I've got about 20 years of experience as a software dev. I probably would have written it differently, but at the same time .. I fully understood what he was saying immediately. There's nothing difficult to understand there.
We're never even talking about HSTS or certificate pinning. We're just talking about the very first call from the mobile app to their website/api.
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.
"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.
If the attack is redirecting traffic away from the server at what point does the server believe it is communicating with the user? The server cannot validate the user traffic since it does not have it.
> The WP definition is the commonly accepted one too, not a case of WP getting it wrong.
That is the opposite of what I said.
That being said, I do think the article's documented report clearly demonstrated how the app was vulnerable to MITM even if the PoC didn't implement the attack all the way. And as a word of advice to the vendor, you probably don't want to train all your well meaning vulnerability researcher pals to productise their vulnerability PoCs into production quality exploits, lest they get the temptation to sell them on other types of markets...
e.g. OWASP: https://owasp.org/www-community/attacks/Man-in-the-middle_at...
It only lists one example about key exchange. That is different than certificate exchange, but not for the point of this conversation.
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.
I agree that it is a valid finding, but its reported in wildly different terms than what you just described. That is just cause to triage a reported incident as low priority.
The blog post writeup isn't the best in the world, but the actual H1 submission seems fine.
In order for a MITM attack to occur the attacker must establish trust with both end points, which isn't happening in this case.
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.
That is the software defect, and that alone. Everything else is completely working as designed even if the results not expected. That does not rise to the level of a MITM.
> 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"
In that scenario the store would never believe it is talking with one of its user's because the traffic was relayed to an alternate location. Therefore its an impersonation and not a MITM.
You're not gaining any ground by claiming the existence of "levels" of MITM. A MITM vulnerability is failing to validate who you're communicating with. The Steam App did this. Thus Steam is vulnerable to a MITM attack.
> In that scenario the store would never believe it is talking with one of its user's because the traffic was relayed to an alternate location. Therefore its an impersonation and not a MITM.
I don't understand what this means? The Store (store.steampowered.com) believes that the user is anyone who can produce the user's credentials. The App represents the user by holding the user's credentials. The App tries to connect to The Store and believes that the world is thus: The App -> The Store. But The App fails to validate this and can be tricked into the world where: The App -> Attacker -> The Store (this is the MITM). The Store never has any more information than 'Someone with The User's credentials is connecting': Someone (with User's credentials) -> The Store. The Store's picture of the world is identical in both cases, it cannot distinguish a true user from an attacker if both have the user's credentials. This doesn't have anything to do with The Store and everything to do with The App.
It did not, because it cannot validate what it does not have. The reverse proxy in question redirects traffic away from the server to an unrelated location. As such there is nothing for the server to validate since the user traffic is somewhere else.
> Thus Steam is vulnerable to a MITM attack.
The traffic did not go through the attacker to the intended end point. It just went to the attacker.
> I don't understand what this means?
Impersonation is pretending to be somebody else. MITM is more than impersonation in that it must fool both end points, not just the user, of the connection.
> The Store (store.steampowered.com) believes that the user is anyone who can produce the user's credentials.
You are insinuating a replay attack, but there is no evidence of a replay attack. In a replay attack one end of the communication sends a message and an intercepting attacker replays the message for the distant end.
https://en.wikipedia.org/wiki/Replay_attack
Literally all that happened is that the attacker intercepted traffic and redirected it to a different location that is not the intended server. That is IP address spoofing, which is bad but far less bad because its easy to find if you looking for it. For this to be a MITM the attacker would have to intercept the traffic and route it to the intended server. MITM attacks are severe, because they are very challenging to detect since both end points believe the attacker is their intended end point and both end points are exchanging data without indication that trust is violated.
* https://en.wikipedia.org/wiki/IP_address_spoofing
* https://www.techopedia.com/definition/4020/masquerade-attack
You are correct, this particular implementation of the attack did not demonstrate MITM directly. But it did successfully demonstrate that a MITM attack was possible, because MITM directly follows from the client not validating the authenticity of the server. The fact that this implementation displayed their own page instead of proxying store.steampowered.com and logging the requests is utterly immaterial to vulnerability's viability as a tool for a MITM attacker.
If you're saying that this is not a MITM vulnerability because the vulnerability demo loaded their own page instead of Valve's... well that's a stupid argument, and it doesn't refute anything about the client application being vulnerable to MITM.
> You are insinuating a replay attack
I am not. The statement "The website believes that the user is anyone who can produce the user's credentials." is a universal truism that applies to every service ever created. This has nothing to do with replay.
> Literally all that happened is that the attacker intercepted traffic and redirected it to a different location that is not the intended server.
So literally all that server would have to do is respond with the actual html content from the store, and suddenly you would change your mind about whether this effectively demonstrates a MITM vulnerability? Your arguments are not making sense.
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.
That is exactly what I am saying for 2 reasons.
1. If the connection is HTTP instead of HTTPS there is no trust. MITM is trust violation attack, which cannot be present if there is no trust to attack.
2. All kinds of software and hardware redirect traffic under normal operating conditions. That isn't a MITM merely because the path of traffic, or even the end point, is different than expected. For instance a load balancer could route you from an expected location to different physical data center, which is a completely different end point both physically and logically but its not necessarily an attack if you are still where you want to be and both end points trust each other.
The reason why trust is available with HTTPS and not HTTP isn't even because the pipe is encrypted, but because HTTPS uses certificates and HTTP does not. MITM is all about a trust violation. Certificates are not required with HTTPS, but your browser yells at you when a certificate is absent or untrusted.
I understood the issue clearly on first read.
You're absolutely right that it could have been explained more clearly, and that there is some ambiguity in the wording (not everyone's a perfect communicator). But if I (a very normal, non-security-focused software engineer) can grok this, it's the absolute least I would expect from someone working for HackerOne! Their entire job is to be able to understand this sort of thing in depth.
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.
>This is my first blog, but I felt like this is something I needed to get off my chest after months. If people enjoy this blog post, I will probably do more in the future.
I'm sure this blog will probably learn a hard and fast lesson on writing thanks to your post. This can't be any easy topic to explain. You did a solid job, thank you again.
The fact that Valve decided to pay money to this company implies that they don't care about security. You can't blame them for not fixing the vulnerabilities when HackerOne is interfering heavily in the process but you can blame Valve for knowingly choosing a company with a horrifyingly bad track record.
Just some suggestion on how to report these kind of things, because there is an actual underlying issue here worth fixing. It's good that you didn't mention the reverse proxy. Next, don't say "spoofing an HTTP request" in your first sentence of the report, that's an immediate red flag. If you have access to spoof something on the network, it's already not an issue for 99% of people and an instant low priority. Instead, say "Steam insecurely relies on a redirect response to upgrade the hosted content from HTTP to HTTPS, instead of directly establishing the HTTPS connection". How this can be exploited is now much more general than just being a spoofing issue, with both the problem and solution clearly stated.
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 supported use case for steam and you do not wish to leave your users at risk.
IMO There is really no need to blow this out of proportion. It's just a typo. Developers make typos all the time. Bet they're more likely to double check something trivial like that if pointed to.
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.
Again I'm saying this based on real world experience with why someone would use http instead of https, so my point is just a guess. I might be giving Valve too much credit and trying to explain something that is just a mistake. 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.
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).
There is a lot of software that assumes that all connections signed with a given CA are trusted. You wouldn't want to use a public CA in that case because random people could access your services. Want to encrypt mongodb traffic? Create your own private CA. Want to encrypt zookeeper (or etcd for kubernetes) traffic? Create your own private CA. Each server and client gets its own certificate signed with that private CA and since only that private CA is marked as trusted it can be used to authenticate servers and clients. It's basically the same idea as if you had a cryptographically signed token such as JWT. (the private key of the CA is the shared secret)
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 against GitHub that is "working as intended" for months now. 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.
trying to fix bug
maybe this?
fuck
idk
idk
idk
maybe works
k ready nowThose messages could contain very detailed descriptions of how a companies product works, or how a companies fraud controls operated.
I was assuming a relatively lazy commit message as an example. You're correct in identifying that certain organizations might put a lot of information into a commit message.
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
If only Valve could hire a subcontractor whose task it was to triage and clarify theses reports...
Eventually I demonstrated the attack on Techcrunch's site to a Techcrunch reporter, showing him the titles of their upcoming news stories for the coming week, including embargoed news. They got in touch with HackerOne/Wordpress and it finally got resolved a month or two later.
I don't feel like HackerOne added anything positive to the mix, other than a layer of confusion/delay.
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.
Not paying out the promised bounty, to me, basically spits in the face of independent (and ethical) security researchers.
As a security team employee, I think it's easy to react defensively to every vulnerability report, to take them as critiques of the quality of your work. So it's natural for the first reaction to be jumping to "this is not a real report" or "this is a dupe".
But people in this position should think about the upside/downside of their actions.
ACCEPT - Upside: You show that your security team is responsive, you build trust with an active security community member. Downside: Your company pays out some fee (so tiny in big picture)
DENY - Upside: Your company doesn't pay out a fee. Downside: Usually a net negative for your company's reputation in security community, some chance you cause PR issues for your company.
* In that *very* small slice of hackerdom who can manage consistently a $10k bounty a month
* Working a pretty favorable currency and CoL conversion
It's possible Valve is trying to get out of paying the bounty. It's also possible and even likely that they're honestly just bad at handling reports as an organization.
That would make sense. At this point in time the primary reason to have a bug bounty program is so that you can can say you have one. Most will maybe get a handful of reports a quarter about low-hanging fruit.
But occasionally the “oh f#%^” report comes in...
To state the probably obvious, remember that primarily what you see are the negative interactions. You're unlikely to see many posts about the positive interactions. People don't tend to post so much when things go as expected, they do when they go wrong.
I feel like it’s the same with any type of bad news, it can easily blow out of proportion and wrongly indicate that things are going very very badly. I guess this is why the news are addicted to shocking and breaking news.
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.
I took djb's "Unix security holes" class in 2004 and he advocated for just disclosing the security hole immediately, things like this haven't changed my mind. I know people want the money, but it's peanuts and doesn't seem worth the hassle unless you're really young. Nobody is going to spend months looking for obscure bugs for $10,000 when they could get paid that in a week to write the bugs (accidentally) in the first place.
It all makes very little sense to me. If you care about security, you'll have a team like Project Zero. Anything else is just applying the "gig economy" to engineering work, and the results are pretty predictable. It's kind of sad.
There was a big discussion about this in the 90s. Vendors would sit on bugs forever, frequently simply to suppress knowledge of them rather than fixing them. Hackers rebelled; some simply published what we now call 0days, others would publish on a non-negotiable timeline. Eventually, "responsibly disclosure" became a norm.
Looks like companies have once more figured out how to game the process, so their counter-parties are going to renegotiate. And the cycle of life is complete.
No tedious 3 day whiteboard interviews there I bet.
I tend to sneak these little things into my PRs cause I cant stand to see them linger w/o cause
I'll go even further and say that price negotiation should happen at every disclosure. If you're not satisfied with the price you're getting, go ahead and make the vulnerability public ASAP - assuming it is legal to do so -. It's about time companies that have invested nothing in security compared to their profits and their parasitic middlemen like HackerOne acquire proper incentives. Right now, they are getting away with having the public subsidize their security procedures AT MASSIVELY REDUCED costs. This has to stop.
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).
>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.
Unfortunately such a strategy could also be gamed by a bug bounty. If I split 150% of the bounty between all people who reported the bug within a time interval, I could just tell a buddy who has moved out of town about it and end up with a bit more money between the two of us. Either in exchange for him giving me half his bounty, or by returning the favor later.
Now it seems it takes forever (I have reports waiting to be paid from them too, even ones they have already fixed.)
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.
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.
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.
Why would they "most likely" be using a self-signed cert? That would be an extreme edge-case in my mind, not the standard.
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 they will make an effort. Most places (like Google) have effective systems in place for dealing with such queries.
That's blackmail. An expedient way of getting your door breached.
This kind of pressure is helpful, because otherwise stories of OP will be dominant and security problems will stay unpatched.
that's the difference
and a blog: https://googleprojectzero.blogspot.com/
and a Github org: https://github.com/googleprojectzero
and their members do tweet about their findings on their personal accounts.
But no, they don't have an official Twitter account.
I'm assuming vntok's legal conclusion and claim of the type of law enforcement response is true (please do not make things up on hackernews).
In which case my former support for the police and low and order is SERIOUSLY diminished.
You have a non-violent offense, that is not an actual offense, and they are doing swat door breaches on you. wow! The priorities of these companies and law enforcement is backwards then.
I guess folks are being told to just sell it to a zero day vendor (which also happens to work for the same govt agency that will bust down your door if you disclose publicly). Pretty appalling behavior here!
Yeah, that kind of bullshit won't fly in any sane criminal justice system. Now replace "launch nukes" with "download every movie you're working on" or "flash-crashing the stocks market at any time", you'll see that the argument doesn't change: it doesn't fly anywhere.
But I would say that if you're doing this sort of thing for the first time, I would strongly advise you to talk to a lawyer who knows this corner of the law, and to someone who has done this before.
Smarts do not substitute for experience and domain-specific knowledge.
A public reply isn't much of a benefit, and my understanding is that the vulnerabilities will be disclosed eventually within a reasonably limited timeframe.
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.
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 thing, shall be fined under this title or imprisoned not more than one year, or both.
In cases like this one, "bragging rights" are easy to prove as deemed valuable by the blackmailer: they can bring anything from job prospects to donations from activists to free beers at Blackhat.
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.
it wouldn't even be unethical. responsible disclosure starts with engaging with company at eye-level. all that these bug bounty platforms do is take away exactly this power and allow the company to consolidate the contract to a single entity (e.g. preferred supplier). they deserve even less respect than any shady recruiter or typical outsourcing sweat-shop.
giving these people power is like talking to a cop without a lawyer - regardless of what they say, they don't have your interest in mind and you have lost before the game has even started.
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.
An insecure request to switch to a secure protocol would just be elided by an attacker. If the client is coded to expect such a switch and fail if it doesn't happen, that client is at best implementing a more complicated, ad-hoc secure protocol.
That's what makes this bizarre – the negligence of developers, the triviality of the fix and the complete lack of understanding from people who are supposed to be reviewing security issues.
It wouldn't hurt to say that they simply have a typo in the URL. http instead of https.
So by MITM any unencrypted connection to Steam server either credentials or payment info.
From what I understand. It seems the steam app is connecting to plain http http://store.steampowered.com/ so it could be man in the middled.
Unless I am missing something, it's way overblown. Valve please fix the URL to https and send that guy a $50 Amazon voucher.
Usually machines will follow the DNS server they get from DHCP. You don't have to hack an ISP DNS, just have control over the router the user is connected to.