6 ms·

I have to say, I did not have a positive first experience with H1. Probably mainly my misunderstanding, but H1 did not help in any way. I opened an account, f

I have to say, I did not have a positive first experience with H1. Probably mainly my misunderstanding, but H1 did not help in any way. I opened an account, filed a report - I can easily crash Amazon Redshift as an unprivileged user. Provided the DDL/SQL to do so - dead simple, two statements, issue them and boom. I received a reply, something like, "we have closed the report, if you can demonstrate a working issue we'll investigate further". I was confused, replied and asked for explanation. No reply. I tried going to their Support, 403 - doesn't work via Tor browser - no use for an anonymous report. And that seems to be it - end of road. I don't understand, no replies, no support, and I've disclosed valuable information and I have no idea what H1 have done or are doing with it (if it's been made public, for example). (I asked on HN for advice. One line of reply was that this is not an exploit, but a bug, which I can see. OTOH, when I filled in the severity rating form, there was nothing in that where I was evidently going against the grain of what was expected, so I'm not wholly sure. Any further advice in replies now gratefully received.)

londons_explore 2y ago
> 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.
- nicman23 2y ago
  so what are you saying is to sell it and then it will get fixed :P
  - arbll 2y ago
    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
  - saagarjha 2y ago
    If you can find a buyer…
cnity 2y ago
> 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.
- vdfs 2y ago
  Not if you DoS your own instance only
- olalonde 2y ago
  But who gives DDL/SQL access to untrusted users? It seems to be a rather unusual scenario.
  - andyferris 2y ago
    It is AWS redshift - a Postgres compatible SQL service. You interact with it via SQL.
    - orf 2y ago
      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
      - andyferris 2y ago
        I see, I misunderstood. Yes, having the power to crash your own instance might not be a security issue per se.
        deleted 2y ago
        [deleted]
      - Max-Ganz-II 2y ago
        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.
TheDong 2y ago
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.
authorfly 2y ago
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).
- hannob 2y ago
  > 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.
  - bornfreddy 2y ago
    I think you misunderstood GP: > Unfortunately it is hard for the reporter to tell the two apart
    - bugtodiffer 2y ago
      [flagged]
    - fouc 2y ago
      >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
  - bawolff 2y ago
    > 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.
bflesch 2y ago
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.
deleted 2y ago
[deleted]
Max-Ganz-II 2y ago
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 :-)
wepple 2y ago
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.
- bawolff 2y ago
  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)
  - wepple 2y ago
    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.

londons_explore 2y ago

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

nicman23 2y ago
so what are you saying is to sell it and then it will get fixed :P
- arbll 2y ago
  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
- saagarjha 2y ago
  If you can find a buyer…

cnity 2y ago

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

vdfs 2y ago
Not if you DoS your own instance only
olalonde 2y ago
But who gives DDL/SQL access to untrusted users? It seems to be a rather unusual scenario.
- andyferris 2y ago
  It is AWS redshift - a Postgres compatible SQL service. You interact with it via SQL.
  - orf 2y ago
    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
    - andyferris 2y ago
      I see, I misunderstood. Yes, having the power to crash your own instance might not be a security issue per se.
      - deleted 2y ago
        [deleted]
    - Max-Ganz-II 2y ago
      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.

TheDong 2y ago

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.

authorfly 2y ago

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

hannob 2y ago
> 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.
- bornfreddy 2y ago
  I think you misunderstood GP: > Unfortunately it is hard for the reporter to tell the two apart
  - bugtodiffer 2y ago
    [flagged]
  - fouc 2y ago
    >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
- bawolff 2y ago
  > 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.

bflesch 2y ago

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.

deleted 2y ago

[deleted]

Max-Ganz-II 2y ago

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 :-)

wepple 2y ago

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.

bawolff 2y ago
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)
- wepple 2y ago
  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.