Comment by Shank | Hacker News Reader

Comment by Shank | Hacker News Reader

Parent Full thread

This is quite common. If you run a security@ mailbox at a company, you're bound to receive hundreds of bug bounty/responsible disclosure requests because of known software quirks or other design choices. They'll cite precisely one CVE or HackerOne/BugCrowd report, and then proceed to demand a huge payment for a critical security flaw.

I've seen reports that easily fail the airtight hatchway [0] tests in a variety of ways. Long cookie expiration? Report. Any cookie doesn't have `Secure`, including something like `accepted_cookie_permissions`? Report. Public access to an Amazon S3 bucket used to serve downloads for an app? Report. WordPress installed? You'll get about 5 reports for things like having the "pingback" feature enabled, having an API on the Internet, and more.

The issue is that CVEs and prior-art bug bounty payments seem "authoritative" and once they exist, they're used as reference material for submitting reports like this. It teaches new security researchers that the wrong things are vulnerabilities, which is just raising a generation of researchers that look for the entirely wrong things.

[0]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

Yup, according to these "researchers" having robots.txt on your website is enough to warrant a CRITICAL vulnerability.

No, I'm not joking. That's one of the reports I saw in November. I've also had to triage the claim that our site supposedly has a gazillion *.tar.xz files available at the root. All because the 404 handler for random [non-production relevant] paths is a fixed page with 200 response.

As far as I'm concerned, running a bulk vulnerability scanner against a website and not even checking the results has as much to do with security research as ripping wings off of flies has to do with bioengineering.

Oh god. One client I work for does automated scans, and we had an s3 bucket set up as a static site.

They freaked out when /admin/ returned permission errors, essentially a 404, because it was information leakage about admin functions of the website.

That happens when you disable directory enumeration (or whatever name that has) on S3. In that case, it sends 403s (permission denied) instead of 404s.

I know, but try explaining that to someone in very small words. There is no admin. There is no login. The api has open CORS because we want reuse and there’s no risk because there’s literally no concept of identity in the app. Everything is public data or f(public).

Scanners see things through their eyes, and they’re not used to static/public.

I the end, It was easier just to rewrite 403 into 404.

Can confirm this; we've gotten more than 20 reports and demands for bounties for "public access" on our open data subdomain (backed by S3), which literally is `public.`.

Then they beg to have the report closed as "informative". We don't comply unless it really is an honest mistake; I don't like the idea of low-quality reporters evading consequences again and again, sending scattershot bug reports in a desperate attempt to catch a team not paying attention.

You're absolutely right I get a barrage of these. I've got to think someone out there is selling software to scan for these and spam them around.

One bad ([1]) side aspect of this that low signal to noise rate leads to fatigue. At some point it can lead to high priority information (in this case: real bug bounties) being missed. Instead of manually plowing through it you could automate declining obvious bogus information (such as spam) but it might lead to the same. Hence when sometimes real mail gets lost in spam folder.

[1] Arguably bad, depending on your interests. Because such can be intended by an adversary.

Thank you for sharing. Very useful.

Reply on news.ycombinator.com