
Valve and HackerOne: how not to handle vulnerability reports - andrenotgiant
https://blog.jakegealer.me/valve-a/
======
mtlynch
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](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."

~~~
michaelt
_> 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 between HTTP and HTTPS and
why you would use the latter for an online store.

~~~
austincheney
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](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](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.

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

~~~
austincheney
> "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"

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.

~~~
fulafel
My comment was just on the misconception of what MITM is.

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

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

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

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

~~~
chias
Joke's on you:

    
    
        trying to fix bug
        maybe this?
        fuck
        idk
        idk
        idk
        maybe works
        k ready now

~~~
Cpoll
But also: "fix stupid fucking sql injection"

------
samcrawford
I'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.

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

~~~
applecrazy
And 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
Trying 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.

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

------
rasz
Important life lesson: drop 0days on twitter, you wont get bounties, but at
least you will get recognition and job offers.

~~~
_jal
My 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.

------
maerF0x0
This 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

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

------
armitron
I 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
> 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).

------
RyJones
I do not understand why HackerOne has such good reputation. My experiences are
almost uniformly bad.

~~~
7777fps
The reputation was earned years ago.

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

------
hexpwn
I have gone thru similar issues with Valve/Hackerone recently...
[https://hexpwn.github.io/2020/two-plus-year-old-steam-
vulner...](https://hexpwn.github.io/2020/two-plus-year-old-steam-
vulnerability/)

------
klohto
Valve is notorious for ignoring any vulnerability reports

~~~
maerF0x0
any other sources?

~~~
jtylr
Only 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
On 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
Yup. 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...

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

~~~
djsumdog
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://](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.

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

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

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

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

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

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

~~~
thoraway1010
The idea that your would get a no knock forcible entry for disclosing a bug is
appalling and potentially an indictment of our entire criminal justice system.

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!

~~~
vntok
"Hey, @WhiteHouse, while interacting with your systems with the intent to find
security flaws and obtain unauthorized access (I wrote scanners and tools and
payloads so you know I really wanted to succeed here), I've found a security
flaw that allows me to launch nuclear warheads from my garage in Misouri. I
will publish this info online if you don't meet my demands. You have less than
a month to comply."

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.

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

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

------
sitzkrieg
has there ever been good news about hackerone?

------
kaibee
I 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)?

~~~
britmob
The vulnerability is that there _was_ no public key encryption, hence allowing
a MiTM to redirect the steam app to their own site.

------
rapsey
Wait steam client does not even use https??

~~~
kuroguro
If 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.

------
vageli
How is this a vulnerability?

~~~
tadzik_
The 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
The report could have been better worded IMO, it hardly explains the trivial
issue or the trivial fix. Preferring to go at length about what if the ISP is
hacked and other crazy scenarios.

It wouldn't hurt to say that they simply have a typo in the URL. http instead
of https.

------
user5994461
How 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
at this point they should send him $250 for having to deal with their
atrocious bureaucracy

