15 ms·
Valve and HackerOne: how not to handle vulnerability reports
- dlgeek 7y agoHackerOne 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.
- baby 7y agoI 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 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.
- aasasd 7y agoYeah, 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.
- munk-a 7y agoEeeh, 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.
- imtringued 7y agoYeah, it should be the opposite. HackerOne should have a pool of experts that small companies wouldn't be able to afford and large companies don't have to hire security experts that sit idle most of the time.
- applecrazy 7y agoAnd if the claims of HackerOne/Valve trying to get out of paying a bounty, that's just terrible, because a lot of these exploits can be sold to nefarious actors for much much more. Not paying out the promised bounty, to me, basically spits in the face of independent (and ethical) security researchers.
- andrenotgiant 7y agoTrying to put myself in the shoes of the Valve employee: I don't think they were trying to save their company money, but it still wasn't a smart move. 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.
- Kalium 7y agoBounties are only a decent income if you're: * 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 takes a lot of discipline and well-developed process to handle vulnerabilities well. Many companies don't manage this. Instead, they are often earnestly bad at it. 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.
- idunno246 7y agoOne of the big problems is the reports are bad. Like some person just shotgunning the output of an automated script to every company in there without really understanding. Or we get a lot of “I can squat an s3 bucket with the company name in it and make it public” - no way! So filtering through to the good ones takes too many hands, and often times they’re like this one where it’s like...yea technically true but an acceptable enough risk. But occasionally the “oh f#%^” report comes in...
- ChrisSD 7y agoIs the issue HackerOne, or is it HackerOne doing as Valve (their client) instructed them? It seems Valve were aware of the issue for weeks or months before he reported it and still hadn't added an "s" to "http" after 3 more months. Why is that?
- Twirrim 7y ago> 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. 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.
- tptacek 7y agoHackerOne 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.
- RyJones 7y agoI do not understand why HackerOne has such good reputation. My experiences are almost uniformly bad.
- rasz 7y agoImportant life lesson: drop 0days on twitter, you wont get bounties, but at least you will get recognition and job offers.
- maallooc 7y agoThis. F responsible disclosure.
- _jal 7y agoMy guess is that, like the crypto wars, disclosure fights are going to happen every generation. 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.
- TwoBit 7y agoI feel like OP should have made an initial concise statement: "I will publish this in 60 days. Your move."
- rasz 7y agoApparently Microsoft hired SandboxEscaper, notorious non responsible disclosure 0day dropper, proving my point rather succinctly. https://twitter.com/SandboxBear/status/1210133985478791171 https://twitter.com/SandboxBear/status/1210133985478791171 No tedious 3 day whiteboard interviews there I bet.
- tcd 7y agoJust drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. 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.
- vntok 7y ago> 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.
- gruez 7y agoThat's similar to how project zero (by google) works. Exploits get released in 90 days unless the developers can provide a plausible justification why that deadline can't be reached.
- hmage 7y agoGoogle 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.
- bllguo 7y agobut do they trumpet on twitter that they have an exploit and will release it in 90 days? that's the difference
- driverdan 7y agoThey have a public issue tracker (issues are withheld from public for 90 days): https://bugs.chromium.org/p/project-zero/issues/list https://bugs.chromium.org/p/project-zero/issues/list and a blog: https://googleprojectzero.blogspot.com/ https://googleprojectzero.blogspot.com/ and a Github org: https://github.com/googleprojectzero 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.
- user5994461 7y agoHow is that vulnerability? If the ISP DNS gets hacked people can intercept traffic. Seriously this is the best attack scenario he could come with with? From what I understand. It seems the steam app is connecting to plain http http://store.steampowered.com/ 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.
- maerF0x0 7y agoat this point they should send him $250 for having to deal with their atrocious bureaucracy
- mixedCase 7y ago> If the ISP DNS gets hacked people can intercept traffic. 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.
- klohto 7y agoValve is notorious for ignoring any vulnerability reports
- maerF0x0 7y agoany other sources?
- jtylr 7y agoOnly anecdotal, I once tried to report a persistent XSS issue on the game "hub" pages. After weeks of going back and forth with support (this was before the likes of hackerone) the ticket was closed and the issue was ignored.
- iancarroll 7y agoOn the other hand, before they started moving to HackerOne, they fixed several issues I reported either the next day or within a week or so. Their security@ was incredibly responsive. Now it seems it takes forever (I have reports waiting to be paid from them too, even ones they have already fixed.)
- XMPPwocky 7y agoYup. Have dozens of issues reported to security@, and responsiveness was great- usually human response same day, often in hours. H1 is veeeery slow by comparison, but, hey, I've made five figures off it so...
- 7777fps 7y agoThere was this one last year: https://arstechnica.com/information-technology/2019/08/valve-says-turning-away-researcher-reporting-steam-vulnerability-was-a-mistake/ https://arstechnica.com/information-technology/2019/08/valve...
- hexpwn 7y agohttps://hexpwn.github.io/2020/two-plus-year-old-steam-vulnerability/ https://hexpwn.github.io/2020/two-plus-year-old-steam-vulner...
- vageli 7y agoHow is this a vulnerability?
- MaxBarraclough 7y agoThe software is vulnerable to a MITM attack. There's no reason it should be.
- vageli 7y agoFrankly, I'm surprised the site didn't respond with a 302 redirect to SSL to avoid this kind of thing entirely (versus relying on client to specify the correct protocol).
- MaxBarraclough 7y agoI don't follow. That's quite obviously not a proper fix.
- cwillu 7y agoThe client _must_ use the correct protocol, that's precisely the issue. 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.
- tadzik_ 7y agoThe vulnerability, on the high level, is that the Steam app doesn't verify that the store page comes from Valve, meaning that if you own a Wifi hotspot you can potentially scam and cheat the users of the Steam app. This wouldn't have been possible with basic use of SSL by the app. 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.
- user5994461 7y ago
- kaibee 7y agoI know barely anything about encryption, but this reads to me like the parties involved don't understand that public key cryptography defeats MITM attacks (at least as I understand it)?
- deleted 7y ago[deleted]
- britmob 7y agoThe vulnerability is that there was no public key encryption, hence allowing a MiTM to redirect the steam app to their own site.
- maerF0x0 7y agoThis is an overall problem at bigger companies. The machinations that decide priorities often do not understand engineering things and thus never prioritize the fixes. It's not uncommon to see engineering items that would take 30 minutes to fix get hours of engineering man hours in discussion about "should we fix it?" and "when?" . I tend to sneak these little things into my PRs cause I cant stand to see them linger w/o cause
- rapsey 7y agoWait steam client does not even use https??
- kuroguro 7y agoIf I read it correctly, the mobile app first connects to the store page on http, which then gets redirected to the https version by their server. So probably a typo / misconfiguration in the app. The store itself uses https everywhere. If you intercept the first request you can display whatever you want to the user tho.
- mtlynch 7y agoI 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 http://store.steampowered.com) instead of the TLS-authenticated URL (https://store.steampowered.com 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."
- gnfargbl 7y agoSo 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 not to upgrade to TLS then it's more likely a conscious decision than an oversight.
- deleted 7y ago[deleted]
- Saaster 7y agoCompanies 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 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.
- user5994461 7y agoSimply say that there is a typo in the steam configuration, it is connecting to the (insecure) URL http://.. 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 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.
- restingrobot 7y agoThis 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.
- kbenson 7y ago
- armitron 7y agoI 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'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.
- kbenson 7y ago> 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).
- deleted 7y ago[deleted]
- sitzkrieg 7y agohas there ever been good news about hackerone?
- restingrobot 7y ago>For a simple MITM exploit that can be fixed by replacing "http://" http://" with "https://" https://", this is simply unacceptable. I think the author is really not understanding the complexity of updating to an https:// 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:// 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.
- odensc 7y agoSteam 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.
- restingrobot 7y agoI meant most likely as in a as to why they do the http to https redirect. I have seen this from several other apps, I don't think its extreme, but my guess is just based on the redirect seeming to be intentional. I should probably have said "this could possibly be because", rather than "most likely".
- djsumdog 7y agoWhy 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:// 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.
- pm_me_ur_fullz 7y agoResponsible 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.
- Hitton 7y ago>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.
- hinkley 7y agoI've had or heard quite a few conversations about patent bounties inside of companies that love patents, and there's a very common rule (that ends up being gamed) that each of the first N contributors gets X dollars, and if more than N authors exist then they all split NX dollars. 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.
- Hitton 7y agoI don't think that splitting is usually necessary. If the company can prove that someone already reported it and there are not too long delays to fix the vulnerability, I would think that people would accept that this time they were not the first and they will try next time knowing that no one tries to screw them.
- zaptheimpaler 7y agoIn a way, this is the same problem that we see with tech hiring & recruiting. Most gatekeepers are less technical than the most tehcnical developers they gate-keep, but still necessary because 80-90% of reports(in case of security)/applicants(in case of hiring) are unqualified. Anyone who is qualified enough to screen without false positives can probably get a better job.
- jodaco 7y agoI’d like to add a different take to this. I have contacted Valve support in the past, clearly stated my problem, and got a response that looked like they read half of my question and responded without reading the entire thing. If the same team that responds to their customer support reads this stuff, which seems crazy, they didn’t bother to understand the problem before responding.
- hexpwn 7y agoI have gone thru similar issues with Valve/Hackerone recently... https://hexpwn.github.io/2020/two-plus-year-old-steam-vulnerability/ https://hexpwn.github.io/2020/two-plus-year-old-steam-vulner...
- samcrawford 7y agoI've reported one bug to HackerOne so far, which was a bug with Wordpress that allowed you to access the title of unpublished posts. Months went by with no reply, despite clear demonstrations of how it could be exploited. 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.
- bikingbismuth 7y agoYou can't actually do arp spoofing/hijacking at an ISP level. This is because arp/mac addresses don't have much impact on traffic when crossing a layer 3 (network/router) boundary.
- jrockway 7y agoThis HackerOne thing seems weird. It's like they looked at Google and decided "let's apply their customer service, but for security researchers." With this model, things like this blog post inevitably follow -- including the "they ignored me until I complained on Twitter, then they instantly fixed it". (Classic.) 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.
- mekane8 7y agoReading stories like this really make me hate these customer service walls we've put up everywhere. Only a couple of times in these exchanges did it seem like there was a functioning, thinking human intelligence on the other end. All of the robo-responses are depressing, including the human-generated ones. And it's even more discouraging when you have to hear about their company's internal chaos and disorganization. Really gives me a low opinion of this HackerOne organization.