Hacker News Reader

Comment by thrwawy0001 | Hacker News Reader

Can you elaborate on the automated reports a bit more? What makes them uninteresting?

I don't run a bug bounty but I do sit on a security@ inbox. I don't believe I've ever seen a report I would want to pay out on even if I could, but if you discount blatant spam (often peddling EV certificates), I've received reports asking about bounties for:

- nginx version disclosed in headers - "Feature-Policy" header missing - DNSSEC not set up on zone - Domain not in HSTS preload list

Responding to this sort of thing with "not a vulnerability" is intensely difficult because the of the potential for a PR backlash about "poor security" from people who just don't know better, particularly when the company is definitely not a tech company.

If I remember correctly VLC regularly receives bug bounty reports declaring it as a security vulnerability that their source code is available...

And for softwares like VLC that have a special place in our hearts ('K-Lite Codec Pack' [1] was my special friend until the moment I discovered VLC many-many years ago), there is or there should be a firewall rule that says Enabled-Block-Any-Any-In&Out.

[1]: https://www.codecguide.com/download_kl.htm

Ps: remember those days that we were looking for codecs for our Windows Players back in the Win95-98-2000-XP days???

If you were to do some of these (like removing the nginx version), do you think they'd start demanding payment?

Just silence the version header advertisement for the web servers. Make them actually test for vulnerabilities not just check the version

I remember back in the day I used to field security scan reports for a client I consulted for, and the amount of things I had to mark as "not actually a problem" because all they did was check Apache header versions was staggering. This is slightly better than and slightly worse than your situation at the same time. Slightly better in that they were looking for versions that had actual exploits known in them, but slightly worse in that they had no way to deal with distros that back-patched for vulnerabilities, like RHEL (which was the distro in question). "Yes, I'm aware that that the version of Apache you are noting contains a vulnerability. No, it's not actually a problem or exploitable, since I already applied the patched update. Just like last week. And the week before that."

Examples of "vulnerability" reports I've received:

- Dump of CVEs for "Web App X" or "Server X", even though literally zero of them apply to the version that I'm currently running.

- Dumps of port scans with warnings like "Running SSH on port 22 is not recommended" and "Server accepts HTTP. Always use HTTPS".

I assume there are tools that generate these reports because the reports use decent English but the accompanying emails are written in very broken English.

I miss the days when nessus was good enough to justify being cool.

Then again my favorite bug back in the day was veritas backup acting as a reverse shell. I only learned of that by running nessus.

What's the justification for running a host that responds to HTTP and doesn't immediately upgrade to HTTPS?

I'm having a hard time imagining a scenario where I manage a web server that is accessible to anonymous people running pen scanners on it that has a justifiable reason for broadcasting port 80.

No that's the point, the generation script recognizes that the server issues an HTTP-compliant response (which 301 Moved Permanently is) on port 80 and dumbly generates that false-positive, not understanding that the only responses on port 80 are to upgrade to HTTPS.

Oh, that makes sense. That does sound annoying.

If you connect remote communities with poor bandwidth http allows a shared cache behind the bandwidth bottleneck. And other caching scenarios.

Could you elaborate on this? I'm curious as to how a setup like this would work in practice. Many people in my family live in rural areas so the topic of restricted bandwidth/poor connection quality is of great interest to me.

https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites...

“But there I stood anyway, hoping my requests to load simple web pages would bear fruit, and I could continue teaching basic web principles to a group of vocational students. Because Wikipedia wouldn’t cache. Google wouldn’t cache. Meyerweb wouldn’t cache. Almost nothing would cache. Why? HTTPS.”

Thanks for the excellent link, discussed on HN a while ago [1]. For those that think an sslstriping proxy would solve it please remember that this would degrade the security for requests that really have to be encrypted.

[1] https://news.ycombinator.com/item?id=17707187

I remember https://sectools.org/tag/vuln-scanners/ for one. There are other software tools that run from your PC and can 'target'/scan a single IP or a range of IPs and they return some generic results. I won't get to the metaspoil discussion/area.

Imho (and sorry to intervene) it is uninsteresting because each of us can and DO run these tools and get the same reports, and since we do care enough, these are low hanging fruits that we have all assessed on day1, and either addressed, or ignored for a valid reason (e.g. on a client site, someone was making noise for a vuln on a system that was a standalone server, disconnected from any network. I understand that security requires that all layers are secure, but we need to use sense and logic before we start yelling 'fire!! fire!!'.

Reply on news.ycombinator.com