Hacker News Reader

Comment by MrStonedOne | Hacker News Reader

Way back when I saw a report on hackernews about secret exposure from websites that deployed directly via a git repo as a webroot and didn't block access to .git/

I added a cheeky message to my site's .git/ folder if you attempted to view it.

About 2 or 3 months later I started getting "security reports" to the catch all, about an exposed git folder that was leaking my website's secrets.

Apparently because my site didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me.

Got like 4 or 5 before i decided to make it 404 so they would stop, mainly because i didn't want to bring false positive fatigue on to "security exploit" subject line emails.

I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs. Might as well just rip that bandaid off now and stop trusting anything besides the debian security mailing list.

View on HN

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

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.

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.

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.

Thank you for sharing. Very useful.

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.

Be thankful you only receive automated security reports about an open .git directory. There is some guy/company who goes around running a web spider connected to some shitty antivirus which automatically submits false abuse reports to site ISPs claiming that their customers are hosting viruses. This happened to me twice; I think after the second time my ISP started rejecting these reports outright since I haven’t seen any new ones for a few years now, even though they’re clearly still at it (or, maybe, finally stopped last year after getting DDoSed?)[0].

Automated security scanning by people who don’t know what they are doing has become an enormous hassle in so many ways and really is damaging the ability to find and handle true threats.

[0] https://twitter.com/badlogicgames/status/1267850389942042625

Speaking of "security exploits" consisting of reading publicly available information: Tarsnap has public mailing lists with public mailing list archives, and at least once a month I get an email warning me that my "internal emails" are accessible.

> I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs. Might as well just rip that bandaid off now and stop trusting anything besides the debian security mailing list.

Red Hat (my employer), Canonical, and SUSE are also CNAs. I can only speak to ours, but I think our prodsec team does a great job with the resources they've been given. Nobody is perfect, but if you take the time to explain the problem (invalid CVE, wrong severity, bad product assignment, ...) they consistently take the time to understand the issue and will work with whatever other CNA or reporter to fix it. Generally we have a public tracker for unembargoed CVEs, so if it affects us and isn't legitimate or scoped correctly, you might get somewhere by posting there (or the equivalent on Ubuntu/SUSE's tracker).

Perhaps it is just the nature of the open source community Linux distros are a part of, though, that lets them apply it to CVEs as well.

Doesn't help with personal reports though. :-)

Curious, did you get CVE assignments against your personal site? 0.o

> I have a feeling CNAs are bringing this kind of low effort zero regard for false positive fatigue bullshit to CVEs.

Yes, being the discoverer of a CVE is a major resume item. Pen testers who have a CVE to their name can charge more. Companies can charge more for sending them.

Is there a way to return a custom 404 error handler for .git and a different one for a regular 404 in Apache? Never tried that before.

Check the ErrorDocument directive for .htaccess files.

That directive doesn't have to reside in .htaccess files. It works just as well inside a Directory, Virtual Host and Server contexts as well.

    ErrorDocument 404 /404.php
    
    <Directory "/.git">
        ErrorDocument 404 "Ah ah ah! You didn't say the magic word"
    </Directory>

https://httpd.apache.org/docs/2.4/mod/core.html#errordocumen...

How do they contact you? I have never got any report.

emails to addresses like security@domain.name or webmaster@

> Apparently because my site didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me.

There's no good reason that folder should exist except for a joke, so how is this not a helpful message in the vast majority of cases? All lint rules have exceptions, doesn't make them not useful.

Well according to the post, the OP returned a cheeky message and any MK I Eyeball should clearly spot it as an intended condition. Automated scan-spam gets on your nerves pretty quickly.

I run a small vulnerability disclosure program and receive a ton of it - people clearly run automated scanners, which I presume create automated vulnerability reports, on things that are not even remotely dangerous AND have been specifically ruled out of scope for the program.

It's not helpful, it's time consuming and often people will complain if you don't answer their reports.

This is not a helpful message in the vast majority of cases. Lots of servers out there that always return 200

> Lots of servers out there that always return 200

That's poor configuration for most public websites that you want indexed by search bots that's worth fixing. It's called a soft 404, and makes it troublesome to detect when links are invalid, break or have moved. Google will even warn you about it: https://developers.google.com/search/docs/advanced/crawling/...

The vast majority of servers on port 80 are not public websites that you want indexed by search bots.

I didn't ask you to lint my code (or server) though.

There's plenty of cases where a .git directory is just harmless; I've deployed simple static sites by just cloning the repo, and this probably exposed the .git directory. But who cares? There's nothing in there that's secret, and it's just the same as what you would get from the public GitHub repo, so whatever.

That some linting tools warns on this: sure, that's reasonable.

That random bots start emailing me about this without even the slightest scrutiny because it might expose my super-duper secret proprietary code: that's just spam and rude.

> That some linting tools warns on this: sure, that's reasonable.

To clarify, I'm not condoning annoying spam but if say e.g. Netlify or GitHub added a ".git folder should not exist on a public site" lint rule when you personally deploy your site, I would say it would be a net benefit.

> There's plenty of cases where a .git directory is just harmless

Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule.

> Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule.

A responsible person running such a linter does a sanity check before taking their positive and bugging someone else with it. An irresponsible one potentially causes harm by assuming every single hit is a major finding that should turn into a bounty payout.

> A responsible person running such a linter does a sanity check before taking their positive and bugging someone else with it. An irresponsible one potentially causes harm by assuming every single hit is a major finding that should turn into a bounty payout.

I already tried to clarify that I was talking about the general concept of good lint rules, not about people emailing for bounty payouts. We're in agreement that emails about bounty payouts for non-issues is stupid.

The reason you're getting downvoted, so you know, is that your original response heavily indicated you _were_ talking about the email reports.

You replied to someone complaining about getting emails and defended it with "but that directory shouldn't exist", implying you disagreed with their take.

You're arguing about something here that no one else is trying to talk about. The poster you originally replied to was only talking about the email case, so your response is contextualized in that case already.

If you original post had been "Yeah, I agree. That would make sense as a CI rule that you run, not as a scanner someone else runs" then you wouldn't have gotten any pushback, but your post was strongly implying a position you apparently don't hold.

> > There's plenty of cases where a .git directory is just harmless > > Pretty much all lint rules have false positives so this isn't a good yardstick. Can it potentially cause harm when you do it and is there's no beneficial reason to do it? If yes to both then it's an ideal candidate for a lint rule.

Yeah sure, it should be a lint rule, we can quickly agree on that. But that wasn't really my point: my point was that random people from the internet are running these kind of high false-positive linters without asking and start emailing people about it.

Reply on news.ycombinator.com