Hacker News Reader

As someone on the other side - we get spurious reports and people who cause DoS but only for that account in non-realistic scenarios regularly. Unfortunately it is hard to tell the two apart or wise to get into debates about these topics - people start demanding money for "issues" you and every other web host in your industry is aware of (for example client side XSS modifying what appears on the screen... yes, really, they'll argue for cash).

> Unfortunately it is hard to tell the two apart

That's kinda a "you had one job" situation. Yes, it's hard to review security reports, and separate legit ones from bogus ones. But that's what these plattforms advertise they do. They regularly do a very bad job.

I think you misunderstood GP:

> Unfortunately it is hard for the reporter to tell the two apart

>As someone on the other side

that's the reviewer of the report, it's actually:

> Unfortunately it is hard for the reviewer to tell the two apart

> That's kinda a "you had one job" situation. Yes, it's hard to review security reports, and separate legit ones from bogus ones.

Security engineers aren't telepaths.

Yes sometimes reviewers dont do a good job, but i think you are severely underestimating how incomprehensible incoming reports can be sometimes. It is not always worth it to spend 6 hours trying to figure out what someone is talking about.

> Yes sometimes reviewers dont do a good job, but i think you are severely underestimating how incomprehensible incoming reports can be sometimes.

Yes, and this also goes for bugs filed by the public, sometimes comments/requests in public Open Source projects. There are lots of examples of incomprehensible communication and then there's also argumentative communication (that usually gets increasingly argumentative and ad hominem as the reply chain continues). Based on viewing a sampling of public bug reports my company gets (including security incident reports), I would not want to be the agent who acts as liaison by replying and clarifying with the bug reporter. Most public reports are polite and constructive but it's shocking how high a percentage are not, and become increasingly unprofessional as the discussion continues.

I can confirm that, we have had extremely annoying ones but they are a minority. Some of the participants are really good and that compensates.

> crash [...] as an unprivileged user.

DoS stuff typically wouldn't qualify for most bug bounties. Thats probably why you got ignored.

Most services aren't awfully interested in fixing this sort of thing - they'll just wait for someone to try and DoS at scale, then have the oncall team put in some extra regex on the input which blocks that specific expensive/crashing query.

so what are you saying is to sell it and then it will get fixed :P

well good luck finding a buyer, there's very little practical use for a DoS on a service that is usually not exposed to the public internet

If you can find a buyer…

> One line of reply was that this is not an exploit, but a bug

Denial of service is absolutely a security problem, so I don't think whoever gave this advice is correct. Sounds like a frustrating experience.

Not if you DoS your own instance only

But who gives DDL/SQL access to untrusted users? It seems to be a rather unusual scenario.

It is AWS redshift - a Postgres compatible SQL service. You interact with it via SQL.

Yes, but generally you don’t give SQL access to the internet or completely unauthenticated users.

Any user could likely cause issues for Redshift by running completely nuts queries that exhaust all the servers resources. Is “shit SQL” a bounty worthy issue

I see, I misunderstood.

Yes, having the power to crash your own instance might not be a security issue per se.

Good point.

The problem I know of is a bit different, in that it is a direct and immediate server crash. It's not a denial of service by making the cluster slow. It's run-query, crash-server.

You are right of course that any normal user can issue crazy queries which hog resources, and hammer performance.

I would just reach out to AWS directly: why go through hacker one?

They have a direct email and are responsive. If the issue meets their criteria then you get a payout.

I Googled for AWS bug bounty programs.

I found nothing.

Do you have a URL of any kind, for more information about this, including contacts?

https://aws.amazon.com/security/vulnerability-reporting/

I wouldn’t expect a bounty for something like this, but I believe the above is the correct avenue for reporting it.

aws-security@amazon.com - it’s very clearly the first result when you search “AWS security report”.

A scenario where as an attacker:

- You have raw access to the DB

- You don't have enough privileges to get something more valuable than crashing the DB

- You don't care to get noticed/caught

Does sound pretty unlikely

Just as an aside, I don't think your query is directly logged.

I've not actually checked, so I don't know, but knowing how logging works on RS, I think the cluster crashing will mean your killer query is not logged.

Your session will have been logged by the time the cluster crashes. OTOH, maybe you were logged in for some time first, or there's connection pooling, or you slipped the query into an existing connection's query stream, and so on.

Actually, thinking about it, I think you could reduce the problem to a single query, rather than two, which would help cover tracks.

I assume the exploit only takes down your own instance, not the whole AWS redshift service. If it's the latter, it should obviously be rewarded with big $.

Yes and yes :-)

“Yes” as in “yes, my exploit takes down all of redshift”? Or “yes” as in “yes it only takes down my instance” ?

> I assume the exploit only takes down your own instance, not the whole AWS redshift service.

First yes for this.

> If it's the latter, it should obviously be rewarded with big $.

Second yes for this.

:-)

I see you have never reported a DOS on H1. High-profile millionaire engineers will go out of their way to argue with you that DOS of their TOP100 website is in fact not a security problem.

These people don't even know about CIA triad and are gatekeeping four-figure bounty payouts while earning five figures or more every month. I'm extremely salty about this.

One of these days I'll move to Cuba and run all the long list of exploits I've been told aren't exploits by overpaid idiots.

https://www.youtube.com/watch?v=pQMuSotWCEs

> Denial of service is absolutely a security problem

"Security problem" isn't a binary. DoS can be an issue, but often it is acceptable risk. Especially if your DoS is minor. E.g. i can crash the server by sending 50 Gbps of data to it, is not usually a security issue in context.

In the parent post they implied they needed privleged access to exploit. That probably makes it not a security issue as it can only be triggered by a trusted user.

Additionally most bug bounty programs disallow DoS, due to some combination of reports being low value, and testers being idiots, so it might be out of scope right from the bat.

Bugcrowd is no different. The folks doing Triage often don’t comprehend even simple security issues.

I’m convinced it’s largely designed to keep people from going full disclosure rather than actually getting bugs fixed.

As someone who worked on the other side (i.e. at a previous job i handled incoming bug bounty reports) a big part of why we used H1 is that it can be exhausting dealing with reporters. Often the reports are non sensical. Even the one's that are real, often there will be very minor issues that the reporter feels should get top payout. Sometimes reporters are very demanding and rude. At the same time you can't just throw out the crazy reports, because sometimes the crazy looking emails actually have the legit vulns.

H1 exists because once you start offering money the crazies start to show up, and its a lot of work to keep up with it.

(That's not to say that you are entirely wrong either. I am sure some less scrupolous companies do have that goal. However a lot of the time its simply that the vuln has low impact so its low priority. Depending on how the company is managed, often there is dysfunction where the security team lacks the ability to get things prioritized)

Oh yeah, I’d absolutely not want to have a raw unfiltered inbound bug bounty and be first line of triage, so paying H1 or Bugcrowd is the way to go.

But you’re also paying them to make sure the serious bugs absolutely do get to you, and if researchers give up, you’re not getting the value you need.

I suspect the problem is that the type of folks who are prepared to do front-line triage which is most commonly large volumes of nonsense and a few mediocre bugs, are early career security folks who can’t easily spot a really serious P0 and a researcher who clearly knows what they’re talking about.

I feel the same. IMO H1 is a face-saving filter layer for megacorp tech employees so the issues don't bubble up to their bosses via media reports. They tarpit you, send junior people into the ticket who don't understand the issue, and in the end they try to refuse payouts as much as possible.

Meanwhile megacorp tech employees with wikipedia articles spend time to explain how "their platform" is not affected by an issue, even though you show them a POC. Of course, things like DOS is not in scope. It's worse than arguing with layers about a contract, because there is so much face-saving and CYA going on.

Thank you everyone who replied.

I feel like I have a better understanding now of the situation and what happened with H1, and I feel better about it.

I will now see if I can figure out how to wipe everyone's RS clusters instantly with a single command, so I can report something on H1 after all :-)

Yeah, sure, and if someone gives me access to their redshift, I could just run "SELECT digest('foo', 'sha256');" in a loop, which takes redshift CPU and thus costs them lots of money.

If you give an attacker access to run arbitrary queries in your database, it's already pretty bad news, even without a crash.