Advice sought regarding HackerOne and vulnerability submission | Hacker News Reader

Advice sought regarding HackerOne and vulnerability submission

3 pointsMax-Ganz-II8 comments

I would like advice regarding HackerOne.

I am an Amazon Redshift specialist.

I know of an issue with Redshift such that any user who can create a table and issue a query on that table is able, with normal but specially crafted table and query, to crash the cluster about ten seconds after the query is issued.

I reported this to HackerOne as a vulnerability, providing the DDL for the table and the SQL for the query.

HackerOne triage (not AWS) have come back with;

> We are happy to review this further if you are able to leverage this into a practical exploitation scenario that results in an impact to Amazon assets or data. [Your] report will be closed as Informative.

Which is not what I expected.

I am thinking I have misunderstood something fundamental.

Can anyone here with experience or knowledge in this matter provide advice?

View on HN

I'd double check whether a denial of service is out of scope, it often is.

Additionally, I'm not intimately familiar with Redshift, but being able to create a table suggests the attacker would already need a fairly high privilege level to begin with, no? If there are other ways to invoke denial of service conditions from that existing privilege level, this finding may be somewhat moot out of redundancy, similar to how a submission for "a root user with the ability to execute arbitrary commands can cause a denial of service condition in XYZ" would be moot - XYZ is not needed for an adversary with those perms to cause a DoS.

Being able to create a table and issue a query means being a normal user on the cluster - so you have an account and can log in. It's enough to issue `CREATE USER [blah] PASSWORD [pwd];`, which is the minimum create user command.

So we're looking at malicious or disgruntled employees, and also normal queries where users do not realize what they're doing will kill the cluster.

People with access to change systems have access to crash systems. This is fairly true across all tech, and all you did was prove it for Redshift. I think what you are missing is that for it to be a vulnerability, it would need to be something that extends that ability to do damage beyond your current scope. If you can crash someone else's cluster, that is a vulnerability. But not if you can only crash your own.

I may be completely wrong, but that seems a bit narrow a definition - attackers move laterally once they penetrate organizations.

I can also imagine disgruntled or malicious employees or contractors.

"once they penetrate organizations."

Yep, that is the key. Crashing your own org hasn't done that. Unless I'm misunderstanding what you are claiming?

No. It's not a way to get in, but it is a way to crash a system (which should not be crashable) if you are in.

I think you are describing a bug, not a vulnerability. Is it bad? Sure. Is it a security vulnerability where you can impact anyone else? Doesn't sound like it.

This makes sense and I see it, but there is one matter which gives me pause; when I came to submit the issue, there's some kind of standard severity rating system, which you have to fill in. Questions like - can this issue be exploited over a network, or do you need local access? how many privileges are required? what's the consequence of the issue - degraded service, complete denial of service? questions like this. The issue here fitted into this framework of questions - there was no point where it didn't fit, and the severity rating system was evidently thinking in different terms.

Reply on news.ycombinator.com