I’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.
Valve and HackerOne: how not to handle vulnerability reports
101–110 of 162 posts
Re: Valve and HackerOne: how not to handle vulnerability reports
#102Re: Valve and HackerOne: how not to handle vulnerability reports
#103Earlier quoted context omitted.
Do note that mtlynch is not saying that it's all the authors fault and Valve/HackerOne couldn't handle this better. 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 a…
I feel like that issue translation step is part of what HackerOne is actually there to do though - they serve as a collection and initial triaging point... if they are bad at doing a first pass of issue triaging and clarification then what are they even doing? 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…
Indeed, I agree with you. Poorly handled. But that doesn't mean you as a penetration tester can do better _also_, to avoid similar future scenarios where they handle things poorly.
Re: Valve and HackerOne: how not to handle vulnerability reports
#104Earlier quoted context omitted.
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…
> 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.
This sounds far worse than just leaking branch names. They said it’s leaking entire commit messages.
Those messages could contain very detailed descriptions of how a companies product works, or how a companies fraud controls operated.
Re: Valve and HackerOne: how not to handle vulnerability reports
#105I have gone thru similar issues with Valve/Hackerone recently... https://hexpwn.github.io/2020/two-plus-year-old-steam-vulner...
Re: Valve and HackerOne: how not to handle vulnerability reports
#106I'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.
Re: Valve and HackerOne: how not to handle vulnerability reports
#107Earlier quoted context omitted.
Why would they use a self signing cert? They could use a real Cert. It's Steam. They can afford real certs, or just use LetsEncrypt. There is absolutely no reason for the app to connect to a login/authentication service (or any service) over plain text, period! There should be unit tests that scan for http:// and will fail the build if found in the code or resources. I know some things are not simple fixes, but this…
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.
Re: Valve and HackerOne: how not to handle vulnerability reports
#108Earlier quoted context omitted.
> 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.
This sounds far worse than just leaking branch names. They said it’s leaking entire commit messages. Those messages could contain very detailed descriptions of how a companies product works, or how a companies fraud controls operated.
Sorry, that's what I meant. I should rephrase: a commit message for a commit on the dev branch.
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.
Re: Valve and HackerOne: how not to handle vulnerability reports
#109Earlier quoted context omitted.
> 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.
Joke's on you: trying to fix bug maybe this? fuck idk idk idk maybe works k ready now
But also: "fix stupid fucking sql injection"
Re: Valve and HackerOne: how not to handle vulnerability reports
#110>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 p…
I'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 w…
I 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.