Comment by billyhoffman | Hacker News Reader

Comment by billyhoffman | Hacker News Reader

Parent Full thread

It's simple: "No Easy Buckets".

Yes, some people just want to compromise a lot of sites, and don't care what they are. Those attackers will just blast huge swaths of the internet with an automated tool. But there is a spectrum of attackers, and "someone who only uses an automated tool" is just one extreme of it. Many attackers want a specific site, and Wired is a good example of a high profile target that attracts that kind of attention.

If you are telling me your version number, andthere are known CVEs, but an automated exploit seems to be failing, I will try other things. Maybe there is a WAF or IDS in place I need to evade. Maybe there is an encoding issue I can use to work around it. Maybe its just a honey pot and you are lying to me about the version number. Or maybe there are no known issues, but I take the version number and go look at the source...

Your security posture should not be "I don't think this will help an attacker, so its OK". It should instead be, expose as little information as possible for the site to function.

(Update: Years ago during an audit, I found a version string inside an HTML comment. The software was open source, and I learned that this version stored sensitive data in an oddly named file in the web root. This sensitive file was not on a list of juicy files like what you find in Nikto or a similar tool. The version number is what did it. Granted, this was a targeted attack, but Wired is the type of site that gets targeted attacks from determined attackers who do more than run w3af or Nikto or Nexpose with default options)

> If you are telling me your version number, andthere are known CVEs, but an automated exploit seems to be failing, I will try other things.

But that has nothing to do with you knowing the version number. The problem there is running an old version with known CVEs. In that scenario you're vulnerable whether the version number is public or not.

Keep your software up to date and it won't matter if an attacker can get the version number, because all it will tell them is that there's no old exploits they can take advantage of.

It is not a given that an older version will be unpatched. For example, RHEL (and by extension CentOS) backports patches without updating the version number.

Ok, you have a good point that version numbers do have a security implication.

However, I'm now going to say something a bit different and claim that it is what I meant the whole time. ;-)

Hardening applications, like any development, is a matter of focus, and I would argue that hiding version numbers should be pretty far down the list of priorities.

In your update example, the real problem is that the software stored sensitive data unsecured in the web root. Solving the problem would mean patching the software so that the sensitive data is properly secured. Once that's done, it no longer matters that you know the version number.

So: I agree with you that version obscurity can help, but I think it's only a little. I think most teams can find more productive ways to spend their security time.

> Hardening applications, like any development, is a matter of focus, and I would argue that hiding version numbers should be pretty far down the list of priorities.

Actually, for as simple of a task as it is, I'd consider it to be low hanging fruit.

For Nginx:

    server_tokens off;
    fcgi_hide_header via;
    fcgi_hide_header X-Powered-By;

etc.

Reply on news.ycombinator.com