Bulletproof Security will block access to the readme file. I think Better WP Security will to, and perhaps Wordfence.

I actually don't have a problem with security-through-obscurity, provided it's the first of many layers, but in this case I don't think the benefits of hiding the version number outweigh the benefits of the readme file, especially since it's easy to 403 the file with one of those plugins or a custom htaccess rule.

Serious, most of the security plugins do stuff that isn't needed at all. If you believe in fake security you should install the plugin.
The only feature I would say that should be in core is limiting the login amount.

Closing the ticket since this kind of conversation shouldn't happen on trac.

Some of the security plugins out there do a few decent things that can improve the security of a site. Pretty much every example is things that we could not reliably do in core, for reasons such as wide server support. Most plugins — and most things done by even some of the good plugins — are overzealous, dangerous, ill-informed, or resort to scaring users with things that they don't need to be bothered with or take action on. All in the name of "security".

The file shows the version number of WordPress easily ... Security (Version disclosure)

With publicly accessible web application software, there is no way to prevent version detection. The readme and generator versions are just the fairly cheap ways to do it. My favorite is looking at publicly accessible CSS and JS files, but there are many others. Script kiddies blindly attack sites. They don't sniff version numbers first. Even if they did, this means they're looking for core vulnerabilities. (Of which there are few, and anything of note requires a user account these days, at a minimum.) So, you're either running an out of date version — don't hide the version number, *update* — or you're running the latest (at which point, that's on us, and no suppressing that version is going to help you).

There's one thing I could go for, as proposed here: on one-click upgrades, don't copy readme.html back over if it is gone. Same we do for bundled default themes. But I'm not agreeing to this for security reasons. Beyond license.txt, it's the only non-PHP file shipped in the root. Maybe someone wants to remove those because they have OCD. Now that we have about.php for in-dashboard upgrades (and most installs happen by hosts, not users), the very existence of a readme file isn't that helpful anymore.

Given the ​sheer number of security vulnerabilities that WordPress has had in the last two years, and changes in cybersecurity and increasing occurrences of hacking that have happened in the last 3 years, I think it's definitely time to reopen this topic, and to start taking a more aggressive approach to WordPress security.

While not the most important security flaw, it is still a poor security practice to reveal software version numbers in web software. If you want to hack a site, the first thing you want is to get the type of software and version number. This is known as fingerprinting.

The IETF (Internet Engineering Task Force) has this to say in ​RFC 2068:

"Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes."

Web framework[*] fingerprinting is an important subtask of the information gathering process. Knowing the type of framework can automatically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabilities in unpatched versions but specific misconfigurations in the framework and known file structure that makes the fingerprinting process so important....
[*] Please note that this article makes no differentiation between Web Application Frameworks (WAF) and Content Management Systems (CMS). This has been done to make it convenient to fingerprint both of them in one chapter. Furthermore, both categories are referenced as web frameworks.

And...

Remove any unnecessary or unused files on the server. This implies text files disclosing information about versions and installation too.

Which is exactly what we're asking for here...to remove the readme and license files.

Rsponding to a couple of @nacin 's previous comments (granted, I realize they are 3 years old, but this for others considering this issue now):

With publicly accessible web application software, there is no way to prevent version detection. The readme and generator versions are just the fairly cheap ways to do it. My favorite is looking at publicly accessible CSS and JS files, but there are many others.

Right...so let's fix that. If these are areas that can be used to find out the software version, then why not remove it from them? In CSS and JS files, the version numbers have no advantage over some type of hashed key.

While that used to be true (in 2013 when your response was posted), that's simply not the case anymore. In 2016, they absolutely do sniff version numbers. With the sheer number of exploits out in the wild now, it's not really practical to just attack blindly. That would be an easy way to be detected, and not to mention it takes a lot of bandwidth for the hacker. Sure, there are still bots employed by script kiddies that just try to hit a site with a variety of common exploits. More often though, hackers set bots to not try any attacks on their first pass...they are merely scanning sites collecting data for a targeted attack in the next step. They are building a list of sites that have specific vulnerable software versions. They can either be hit again automatically right after the data is collected. Or, the hacker employing the bot, can review the list manually and single out interesting targets. Either way, the bots are sent again, this time going for specific vulnerabilities and that's when they attack. This has a much higher success rate, and is harder to catch.

Even if they did, this means they're looking for core vulnerabilities. (Of which there are few, and anything of note requires a user account these days, at a minimum.)

That's absolutely not true anymore either...There have been exploits in every version of WordPress released, as revealed over the last two years. There is no such thing as 100% secure software. We have to assume that sooner or later, a vulnerability will be found in every single version of WordPress.

So, you're either running an out of date version — don't hide the version number, *update* — or you're running the latest (at which point, that's on us, and no suppressing that version is going to help you).

Very true...but ​WordPress.org's own usage stats show that approximately 48% of WordPress users aren't even updated to the 4.4 (current) branch so that leaves about half of WordPress' users out of luck if a more proactive approach to security isn't taken. 31% are still using PHP 5.2 and 5.3, so this shows pretty clearly that a high percentage of users are not practicing good security. So, we as developers need to help them out and make it as secure as possible. Not everyone has expert security consultants helping them, or a good working knowledge of security. (This can change if we educate users but it will likely take years.) While I'm with you that people need to upgrade (and believe me, I preach it), we can't lay all the responsibility on users.

One idea for securing the readme and license files is to have it secured somewhere in the admin with the relevant info. It could even be a link to readme and license files hosted on WordPress.org for that particular version. Or, if they were available on a page of the admin, the files/data should only be accessible by .php, not .txt or .html, so no version numbers would be revealed externally.

Regarding removing version numbers from CSS and JS files: As I mentioned above, replace the version number with a salted hash (or other unique random key) that changes each time the version is updated.

Regarding the version numbers in the page head...Code located in general-template.php on line 3451 (v4.5-RC2) for example:

One option would be to have WordPress but leave out the version number....just cut

get_bloginfo( 'version' )

It really isn't necessary. Almost every security plugin removes this generator code completely. (And that is not being over-aggressive.)

It's also being proposed to add the WP version number in Etags, and this is already implemented in v4.5-RC2, which is also not a great idea. Please see my comments on the ticket here.

Not revealing version numbers is merely one aspect of following establshed good security principles, so this shouldn't be seen as an odd request. I've seen requests similar to this keep getting shut down over the years and it makes me scratch my head.

If we can make some relatively easy changes to remove all the version number leakage throughout WordPress, and reduce the number of successful hacks (even if only by a small percent), for nearly half of WordPress users that don't upgrade as quickly, doesn't it seem like that's something we should do?

IETF's recommendation 14.39 in RFC 2038 refers to a header that was previously used for intra-network communication for use in identifying the processing software or for general use server surveys. This specific header would contain information about a level that is higher than the application layer of WordPress, and thus should not be construed as guidance to projects like WordPress or other software that runs at the same layer as WordPress. An example of data previously contained in this header was:

CERN/3.0 libwww/2.17

This header no longer exists. In fact the RFC you referenced was written in 1997, and was itself invalidated and supersceded by RFC 2616 in 1999. As of the 1999 RFC, no RFCs since, about the HTTP protocol have contained similar guidance, partially because the header in question doesn't exist beginning in RFC 2616.

The license.txt file contains the GPL license text which is a component of the GPL license which WordPress uses.

Regarding removing version numbers from CSS and JS files: As I mentioned above, replace the version number with a salted hash (or other unique random key) that changes each time the version is updated.

This would break backwards compatibility that plugins can rely on, and it doesn't solve the problem that it's just as easy to compare the contents of the file as it is to parse the version out of the url.

Moreover, there appears to be a suggestion that even if you remove these files, hide the meta generator tag, and randomize the version appended to strings, somehow that will plug all of your version concerns. However, if one really wants the version number you can simply run a string comparison on the outputted css or js files. Moreover, the WordPress REST API framework requires versioning, which inherently must be public in order for the feature to use, and that versioning can be directly mapped to versions of WordPress. That itself cannot be prevented.

We have to assume that sooner or later, a vulnerability will be found in every single version of WordPress.

Using a version detection library attached to a standard exploit library set such as metasploit, one can simply just run through all vulnerabilities ever found for WordPress just as quickly as detecting the version on a site that's done what you've prescribed. The fact of the matter is that security by obscurity (version hiding being an example), does not make the site any more or less secure (as pointed out in the OWASP). In actuality in certain penetration software it makes it faster. Many frameworks, upon being unable to deduce a version number of an application, simply iterate over all vulnerabilities anyways.

Very true...but WordPress.org's own usage stats show that approximately 48% of WordPress users aren't even updated to the 4.4 (current) branch so that leaves about half of WordPress' users out of luck if a more proactive approach to security isn't taken.

This is a soon to be obsolete argument. WordPress is moving towards Chromium style updates, where major versions are done automatically. Existing tail end WordPress installs are automatically being updated major versions now, even if they were not previously by a combination of WordPress outreach to major web hosting companies and other relevant parties. As this continues to occur, the number of sites on the current major version in perpetuity will continue to grow. It wouldn't surprise me if after 2 years, that's up to 85-90% of all installs always on the current major version.

Furthermore, on sites where WordPress has autoupdate minor releases (all sites since 3.7, so about 80%+ of all WP installs), any newly discovered vulnerabilities can be pushed and patched in real time. Hiding versions does not in any way, shape or form help make any site newer than 3.7 more secure than they already were.

It's also being proposed to add the WP version number in Etags, and this is already implemented in v4.5-RC2, which is also not a great idea. Please see my comments on the ticket here.

That's not a proposal, it's a merged feature that will ship with WordPress 4.5 in 2 days.

Not revealing version numbers is merely one aspect of following establshed good security principles, so this shouldn't be seen as an odd request. I've seen requests similar to this keep getting shut down over the years and it makes me scratch my head.

If we can make some relatively easy changes to remove all the version number leakage throughout WordPress, and reduce the number of successful hacks (even if only by a small percent), for nearly half of WordPress users that don't upgrade as quickly, doesn't it seem like that's something we should do?

These are only successful because either users fail to upgrade major versions (something that again will not be as significant if at all an issue in the future) or have something else that's vulnerable, generally a plugin, which does not in any way have anything to do with WordPress version number "leakage". In the meantime, the users who don't upgrade will never see this update to remove the version numbers, so in the end, this type of thing provides a net benefit of helping no one. A site is either up to date and thus secure via security releases, or doesn't update and will never see this update anyway.

Note, I'm going to reclose this ticket, however, a closed ticket does not mean discussion has to stop. You (and others) can continue commenting on the ticket while it is closed.

I'm glad that you all are open to discussion even if this is closed for now. Let's keep the discussion going.

However, I do have to say that I am a bit disappointed by your response though, as it seems to immediately dismiss what I'm saying. It really seems that the WordPress core dev team is (and has been) resistant (in general) to user suggestions about certain security issues. I would understand this if people were making suggestions that are not good security practices, but this is an established security best-practice, and no security best-practice should be ignored, however seemingly small.

I would think that with the discovery of security flaws in nearly every WordPress release for the past two years, the global rise in hacking, malware, etc, that you all would start to make hardening WordPress a bigger priority. I hope this becomes true. If you need recent examples in the news...just look at the Panama Papers scandal for example. Granted...they were using outdated plugins, so it is squarely on them, but please hear my overall point here. WordPress is becoming a bigger and bigger part of the whole global cybersecurity scene. Some of the security issues that arose in the last couple years with WordPress were predictable because WordPress did not follow good security practices 100%. Seemingly small things that seemed like an unlikely attack vector got ignored. And unless something was an immediate critical threat, users were often shut down, which discouraged them from reporting security issues altogether.

Even if a user quotes a credible source to back up the point, it is ignored and shut down. However, when one of the WordPress core dev team members responds, instead of quoting a credible source to back up their point, it is with usually with one of these types of arguments:

"That's the way it's always been done..."

"That will break stuff..."

"That's not a real security issue..."

"Well, you can always find that info another way..."

These are circular arguments, and end up sounding like "the company line" because almost everyone gets some version of the same few responses. I know for a fact that you all are good people, and do not intend things to come off this way.

Don't get me wrong, I have a ton of respect and love for you all, and the WordPress community in general. WordPress is by far the best CMS out there, and I am glad to see it's influence on the web increase as it has. (I hope that I can be a positive contributor in this community.)

For years, users have been requesting that version numbers be removed from the front-facing side of WordPress, and the core team has shut down each of these requests...for years. There is definitely a disconnect between the core team and users in this area. Being a plugin developer I'm caught in between. I understand both points of view. I've been developing plugins for 10 years, but have not gotten into contributing to the core until now, but I'm definitely changing that moving forward.

WordPress core definitely needs some hardening. I've spent years dealing with security issues in both the military (here in the US and deployed in combat zones) and civilian sectors, and not just web/IT, but physical security, and COMSEC (communications security) as well, which give you some interesting insight into security issues and hacking that you don't get if you only work with web/IT security.

So, to continue the discussion, I'll respond to some points you made.

If you would allow me to make an observation based on your responses: You're thinking like a developer, not a hacker. When dealing with security issues, you need to think like a hacker. (And it's not just you, so I'm not trying to make that any kind of insult.)

IETF's recommendation 14.39 in RFC 2038 refers to a header that was previously used for intra-network communication for use in identifying the processing software or for general use server surveys.

Actually, I think you may have misread that...14.39 actually references the "Server" header which is still a standard header in use. The rest of what you mentioned wanders a bit off the topic as the full reference actually was: "Example: Server: CERN/3.0 libwww/2.17", which was merely an example of server header revealing version numbers.

Additionally, I was not specifically referencing section 14.39, as this quote is mentioned again in section 15.4:

Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.

Take a step back for a second and look at the overall picture of what I'm saying here...I think you had focused a bit too much on one detail, and were missing my overall point. :)

The point wasn't about the specifics or the RFC itself...it was about the general security principle. The Internet Engineering Task Force (IETF) are making a clear point that web server/software version numbers should not be revealed. This is a general security principle, and whether an RFC is updated or replaced, doesn't affect that. The IETF are merely one example, and I quoted them because of their role in the development of the web and standards. (ie... the man, Tim Berners-Lee...)

Again, it's about a security principle, not the RFC.

Regarding removing version numbers from CSS and JS files: As I mentioned above, replace the version number with a salted hash (or other unique random key) that changes each time the version is updated.

This would break backwards compatibility that plugins can rely on, and it doesn't solve the problem that it's just as easy to compare the contents of the file as it is to parse the version out of the url.

Exactly what backward compatibility would be broken?

The only purpose for the query string is cache-busting.

The particular string that's used is not relevant. The way it is currently implemented, it just needs to be unique and stay the same until the site updates to the next WordPress version.

CSS (.css) files don't access the WordPress database, so they don't know what the string is that's attached to the URL. Nothing would break here unless it's poorly coded.

JS (.js) files don't directly access the WordPress database either, so even if they detect the query string on their URL, they have nothing to compare it against, meaning they don't care what the particular string is either.

I'm intimately familiar with WordPress, have worked intensely with WordPress site development, security, speed optimization, theme development, and plugin development for 10 years (plus an additional 10 years before that in web development as well), and have not seen where this would be true, and that it would break anything.

WordPress is adding the query string to the .js and .css be a cache buster, so that when a site is updated to the next version of WordPress, it can update the CSS and JS scripts, and break any existing caches in a user's browser. It's not necessary for the query string to reference the WordPress version number in that query string: It could be any unique string that changes when the site is updated. Easy fix! There a million ways to create a unique random string that would stay the same until the site is updated.

However, that's ignoring the website speed performance issues created by adding query strings to .css and .js URLs, because it specifically makes the files uncacheable by browsers. I realize that's the intention, but these query strings are added to every script and style that is run through the enqueuing process.

So, instead of using these cache busting query strings, use alternate methods, which are better practices anyhow. Caching can be completely managed by headers: Cache-Control, Surrogate-Control, Expires, Last-Modified, Vary, and Etag Headers, and should be done that way instead of adding query strings.

A major principle in WordPress speed optimization is to concatenate and minify CSS and JS scripts, along with ​removing query strings from static resources, which renders that whole argument invalid. If you have a specific example of a plugin that it would break, please share it.

Your argument:

This would break backwards compatibility that plugins can rely on...

Argument busted. I've provided you with more than one alternative and shown that this is not a web development best practice, and not only that, it has a negative impact on website's performance by preventing CSS and JS files from being cached.

Moreover, there appears to be a suggestion that even if you remove these files, hide the meta generator tag, and randomize the version appended to strings, somehow that will plug all of your version concerns.

The WordPress version info needs to be entirely scrubbed from the front facing side of WordPress. The areas I've mentioned include (but are not limited to):

The Meta Generator

Query Strings (or remove these altogether)

Readme/License File

Etag headers being added in v4.5 to the load-scripts.php and load-styles.php files:

header("Etag: $wp_version");

Code comments in .js (I found 5 doing a quick grep of the .js files)

REST API

If there is anything I'm not aware of or have left out, then let's add it to the list, set up a project and get it done!

Your argument:

Moreover, there appears to be a suggestion that even if you remove these files, hide the meta generator tag, and randomize the version appended to strings, somehow that will plug all of your version concerns...

Argument busted. This is not a reason not to fix things. As I've shown, if my list isn't complete, then let's make a complete list of things and fix the entire issue. It's not that huge a project. Sign me up.

However, if one really wants the version number you can simply run a string comparison on the outputted css or js files.

That's not how hacking with bots works. They don't want to hit a lot of files on your site when they are scanning. They don't want to use a lot of bandwidth or set off red flags. If there isn't a generator tag with a number, or something easy like .css/.js. URLs (or Etags) that they can glean, they move on to the next. If they are doing a deep scan of your site it can make it easy to get caught, even by newbies. (This is the same reason they don't scan for an entire library of exploits...there are far too many now, so it would take too much bandwith, and could trigger red flags.)

We're not talking about the combination of James Bond/NSA/Navy Seals trying to break into your site. If someone wants to compare files against a repository to see if the file signatures match, that's a whole different different ballgame and not what you're dealing in 99.9999% of cases. (Again, that would take a lot of bandwith, and be noticeable.)

That's an easy fix: Remove the version number from the comments in the .js files. Or better yet, remove the comments altogether. Good minification/concatenation plugins do this anyway.

Your argument:

However, if one really wants the version number you can simply run a string comparison on the outputted css or js files...

Argument busted. We're not talking about pro-level hackers trying to break into your site. I'm talking about the obvious stuff: Don't make it easy.

Moreover, the WordPress REST API framework requires versioning, which inherently must be public in order for the feature to use, and that versioning can be directly mapped to versions of WordPress. That itself cannot be prevented.

That's not really a valid argument. There is nothing about REST principles that requires the software version be exposed.

Even if it did, then why accept that flaw? Why not create an improved API and fix the issue?

REST principles are not set in stone yet, and there is room for change, modification, etc. WordPress should lead the way.

In web development, we don't just accept that a poor security practice is necessary because something uses it...that's faulty logic. We fix the system so it doesn't require poor security practices.

Your argument:

Moreover, the WordPress REST API framework requires versioning, which inherently must be public in order for the feature to use, and that versioning can be directly mapped to versions of WordPress. That itself cannot be prevented....

Argument busted. Simply not accurate.

Most of the arguments you've used so far are circular arguments. You haven't quoted any security experts that promote revealing version numbers as a good idea, or any web development best practices as to why it should be done. If the WordPress core dev team is going to be so staunchly for revealing and using version numbers, then there should be some really solid reasons why. I'm happy to hear them.

Again, I'm not attacking you guys...I truly do love you all, and think you all are incredibly talented, brilliant people who are making an incredible contribution to the world. I just am hoping that some of these points help spark a different way of looking at things.

If you're worried about the amount of effort to fix it, I will be happy to help! I will be happy to contribute my time, and I'm sure many others would as well.

Using a version detection library attached to a standard exploit library set such as metasploit, one can simply just run through all vulnerabilities ever found for WordPress just as quickly as detecting the version on a site that's done what you've prescribed.

Um, no. Just no. Effective hacking is not done like that. That takes too much bandwidth to make it scalable. It isn't stealthy and it isn't practical. To say something to the effect of "one can simply just run through all vulnerabilities ever found for WordPress", shows me you are clearly unaware of exactly how many vulnerabilities there are out there for WordPress. Hackers and thieves value discretion. You do recon first...data gathering, then select targets, and strike. Have you actually ever tracked how hacks happen? I have. Tracking bot activity and hacking patterns is something we do, and has been for a long time. We've studied hack attempts happening in real time. What you're saying is commonly repeated info, but not how it actually works.

The fact of the matter is that security by obscurity (version hiding being an example), does not make the site any more or less secure (as pointed out in the OWASP). In actuality in certain penetration software it makes it faster. Many frameworks, upon being unable to deduce a version number of an application, simply iterate over all vulnerabilities anyways.

SMH. That's not what "Security by Obscurity" means. That phrase gets thrown around a lot in online forums, in the WordPress community, and by word of mouth, without people understanding the actual principle.

The security principle you are incorrectly referencing is: "Avoid Security by Obscurity".

What it actually means: Do not make obscurity your only security method. - I cannot say this enough: YOUR ONLY METHOD. Example: Using a unique file URL instead of a login to protect something sensitive. That's overly basic but you get the idea.

What it does not mean: Don't bother using obscurity as part of your security strategy.

The security principle: "Defense in Depth" supersedes this and means:

Use a robust layered security strategy.

By all means, use obscurity in your layers! Why make it easier for the hacker? Restrict info from those who do not need it.

Use redundant measures so that if one fails during an attack, another can backstop it.

And a lot more...

You mention this:

...[version hiding being an example], does not make the site any more or less secure (as pointed out in the OWASP).

If using version hiding was your only "security" measure, then that would be ridiculous, and would fit the true definition of trying to use "security by obscurity". But, no one is suggesting that. I don't think anyone reading my comments who is being honest would interpret what I've written to say that that's what I'm suggesting.

Again, you have to think like a hacker my friend, not like a developer.

And where exactly is this quoted in OWASP? That's not what it says anywhere in OWASP.

Very true...but WordPress.org's own usage stats show that approximately 48% of WordPress users aren't even updated to the 4.4 (current) branch so that leaves about half of WordPress' users out of luck if a more proactive approach to security isn't taken.

This is a soon to be obsolete argument.

That's assuming a lot. What defines soon? It's not going to obsolete for at least a few years, and there are plenty of hacks to be had in that time.

WordPress is moving towards Chromium style updates, where major versions are done automatically. Existing tail end WordPress installs are automatically being updated major versions now, even if they were not previously by a combination of WordPress outreach to major web hosting companies and other relevant parties.

That's fantastic...and very exciting. But, that's assuming that users don't disable the auto-updating. Not everyone wants to update right away. Should they? Yes, I think so. Will they? Not in my experience.

As this continues to occur, the number of sites on the current major version in perpetuity will continue to grow. It wouldn't surprise me if after 2 years, that's up to 85-90% of all installs always on the current major version.

I hope you're right, but that would seem to be overly optimistic.

Furthermore, on sites where WordPress has autoupdate minor releases (all sites since 3.7, so about 80%+ of all WP installs), any newly discovered vulnerabilities can be pushed and patched in real time.

Again, that's assuming that auto-update is not manually disabled. Unfortunately, we've run across many who don't want to update.

In my experience, it's really only the users on the most recent branch that are even close to up-to-date on the minor versions. Stats back this up. We'll take a look at some stats in a minute.

Hiding versions does not in any way, shape or form help make any site newer than 3.7 more secure than they already were.

I'm sorry, but you are flat out incorrect when you say this. Statements like that demonstrate a complete lack of understanding of security principles. Just because you don't understand the full security implications,does not mean it is not a security issue. When you hear me say that something is a security risk, I think you think I'm saying that that revealing the version number is like giving someone a password to your site or key to your house. That's not what I mean at all. Revealing version number does not directly enable the act of penetrating a site. That's where you guys seem to be assuming that if something doesn't directly enable access to a site, that means everything is secure. Nothing could be farther from the truth. That's like saying, "Hey, if a thief doesn't have the key to my house, then it's secure." Sure, if the only way in is the door, or if they're "polite" enough to NOT kick your door in. But there are a million ways into a house (just like a website), and thieves/hackers and the ilk are anything but polite. Security is a complex scale of skill/motivation/resources vs difficulty. That's where you have to understand that some seemingly peripheral things like this are security risks. Security encompasses a lot more than just the single act of penetrating a site.

Before a hacker breaks into a site, they gather data and pick their targets. Revealing site software versions makes it really easy for hackers to target sites with specific version/vulnerability combinations.

Hacking doesn't start and end with someone breaking into your site. A direct quote from the one of OWASP's guides on fingerprinting during the information gathering process - ​Fingerprint Web Application (OTG-INFO-009):

Test Objectives:
Identify the web application and version to determine known vulnerabilities and the appropriate exploits to use during testing.

I'll use key points from an OWASP guide to give you the basics, so you all can see why you need to stop saying, "That's not a real security issue when people point out why WordPress should not be revealing version numbers".

The basic process:

It starts with research, aka ​Information Gathering. I'm going just give a little info about each point. Read the guides for more info.

​Fingerprint Web Application Framework (OTG-INFO-008) - In this case, Web Application Framework is synonymous with CMS. Basically, get the details of the CMS or framework. Specifically mentions mitigating some of this by removing install files like the WordPress readme and license, as well as removing code comments (ie the comments in WordPress' JS files that contain the version number, and META generator tags.

​Fingerprint Web Application (OTG-INFO-009) - This involves getting the application's details, including version number, and WordPress is specifically used as one of the examples, and they specifically reference the META GENERATOR tag used in WordPress:

<meta name="generator" content="WordPress 3.9.2" />

*​Enumerate Applications on Webserver (OTG-INFO-004) - Basically, figure out what apps are running, versions, and determine vulnerabilities. Regarding WordPress, this would relate specifically to plugins. "A paramount step in testing for web application vulnerabilities is to find out which particular applications are hosted on a web server. Many applications have known vulnerabilities and known attack strategies that can be exploited in order to gain remote control or to exploit data. In addition, many applications are often misconfigured or not updated..."

After the information gathering stage is finished, move on the hacking/penetration.

Let me show you a brutally simple, and low-skill way to gather a list of sites that have vulnerable versions.

You'll get a quick list of sites that are using vulnerable version 4.3.1.

From there, just import the data into your target list, and run your bot.

The better way is to employ a bot that will cruise through sites and build a list for you of sites with the specific version you're looking for, but like I said, using Google requires no skill, and anyone can do it.

Now, each one of those sites is a potential target for hackers, even low-skill ones, so tell me again how that is not a security risk?

Ok, now let's take a look at some stats. The following are the percentage of WordPress users on each major branch (4.2, 4.3, 4.4, etc) that are using versions with security vulnerabilities:

So based on this, if we're only counting users on branches 3.7-4.4+, approximately 14% of your total user base is using one of 63 WordPress versions with known vulnerabilities. But, we need to add in the rest...so adding in users on the branches below that as well, then approximately 20%+ of the WordPress' user base is using a version that has known vulnerabilities. That's 1 in 5. 1 in 5.

If WordPress powers 26% of the web, then that means that roughly 5% of the world's websites are a WordPress site using a version with a known vulnerability. (Well, from 1-25+ vulnerabilities to be specific.) That's of course, not counting potential plugin security issues, which would increase that percentage dramatically.

20% of those: 52,686,125 websites using versions of WordPress with a known vulnerability. (Again, not counting plugins.) 50...million...websites. With major security flaws.

No offense, but while you guys are excellent developers, you are not security experts, and you need to be realistic about that. The WordPress core dev team should really not be shutting people down so quickly about these security issues that users are pointing out. The overall security of WordPress needs to be taken a bit more seriously.

Let's look at things another way...real life examples.

Real life Physical Security principles that apply to web security:

According to law enforcement and FBI statistics, what is the # 1 way to prevent auto break-ins?

Don't put your valuables in plain sight.

If you have a load of awesome, valuable stuff, like cameras, stereo, TV, high-end jewelry or anything else desirable, you can lock your doors all you want, but you are giving the thief huge motivation, and if they really want your stuff, they will go to almost any length to get it. Locks aren't going to stop them.

Notice, the # 1 way is NOT to simply lock your door, or get an alarm system. Should you lock your door? Of course! That's a no-brainer. Should you get an alarm? Probably a good idea. But if you create enough motivation in a potential thief, they will find a way...even a fairly unskilled thief. They'll get a backhoe and smash it up if they have to.

The same holds true of websites.

If you're securing a physical building containing a safe holding millions of dollars, would you lock the doors, and turn on the alarm system, but then post a notice on the front door with a map showing how to get to the safe, what model the safe was, and what the model of the security system was?

No, you would not, because that would be ridiculous.

With that info, an average skill-level thief could research how to disable that specific alarm system, crack that specific safe model, and they would have a map to the goods.

Without that info, a thief is not going to randomly go up to your building, and attempt to try hacks for every type of alarm system out there. That would take forever, and trigger alarms. They will move on to an easier target that they know more about.

That is essentially the exact same thing is being done by not hiding version numbers. It's essentially the WordPress model number.

What on earth would make it seem that this is a safe thing to do with WordPress websites?

When someone points out to you guys that the version numbers are revealed by readme files, or meta generator, or anything else you all keep saying, "Well, it's not like they couldn't get that info another way."

That's like saying, "Well, the other 2 doors to my house are unlocked, so why bother locking any of them." That's a ridiculous way of thinking. Just go lock all the doors.

Obviously, these points are oversimplified...but they get the point across.

Security is about reducing risk, and lowering the statistical probability of a successful attack. You can never eliminate risk fully, and there is no such thing as 100% impenetrable security, even with the best measures in place.

By increasing the level of security for your site or application, you are shrinking the pool of hackers that have the [skill|experience|time|resources|desire] to hack your site. In most criminal acts, it's about following the path of least resistance — if you increase the difficulty of success then often the hacker will go somewhere else. That's why every percentage of security improvement really does make a difference. (There still needs to be a robust layered security strategy...not saying to skip any of that.)

You can often cut things off right at the beginning by removing any potential data leakage. That prevents a hacker from making your site a target during the initial information gathering stage.

This is why version number leakage needs to be removed from WordPress.

I really hope that no one takes any of what I've said as an insult or offense to the WordPress core dev team, because that is not my intent. My intent is to spark more of a wake-up call regarding WordPress security and hardening.

You all are awesome, and I have much respect for your skills and contributions.

@RedSand I don't have a substantial comment to add here, but just to keep in mind: long Trac comments (~5.5k words) are highly likely to go unread, as they're a lot to read through and many of us simply don't have the time unfortunately. Please try and be as succinct as possible in your comments so they're easily digestable. :)

It would probably be more accurate to call it a "research paper" than a "comment". :)

All kidding aside, I'm a pretty smart guy...I realize that long comments aren't likely to be read.

TL;DR

I just pointed out that more than 20% of WordPress installations (over 50 million websites) have major security issues, and you're more concerned that my comment was too long.

I really am concerned when expedience is of a higher importance to the WordPress core team than website security.

For the last decade, when users have brought up similar security issues, the common response from the WordPress core team has been some variation of "that's not a real security issue" and patently shut them down without further consideration. I've searched through the tickets going years back and read ticket after ticket like this. Yet, when someone has valid points as to why they are wrong, and these are legit security issues, no one on the core team seems to want to hear that.

The Long Version

I know you mean well when you tell me that my previous response is likely to go unread, but do you realize exactly how exasperating that is when you put in context? Let me break it down:

Previous users report the security issue.

WordPress core team responds, saying "That's not a real security issue," and closes the thread.

3 years go by.

During that time, WordPress sites get hacked many, many times, and security flaws are starting to be discovered in WordPress at a rapid pace, getting to the point where every version has some vulnerability discovered within a month or two of release.

I reopen the thread, saying, "Hey guys, it's a real, honest-to-goodness security issue, WordPress has been hacked a bunch of times...take it serious now, yeah?"

WordPress core team member ( @chriscct7 ) gives the familiar response, "That's not a real security issue," and again closes the thread.

I respond, showing why it actually is a real security issue. Since the previous responder from the core team does not understand the security implications of the particular issue, it required education and a long response.

Not reading it allows WordPress core team members to stay in the dark and keep telling people that "it's not a real security issue."

Sites will continue to get hacked.

The core team will be surprised. "Whoa! How'd that happen? WordPress doesn't have any security issues!"

Vulnerabilities will only get fixed when reaching critical status and proof of concepts are passed around the web.

More users will raise the red flag and point out that security best practices are being (willfully?) ignored, and they will keep getting told, "That's not a real security issue."

And the cycle will continue. "All of this has happened before, and all of this will happen gain."

Does anyone see the problem with that?

It's ok for the core team to tell users they are wrong. (Even when they are not.)

However, if we take the time and effort to show that in fact you guys do have a thing or two to learn, we get the response that we should write shorter responses, and that you all are too busy for that.

So...my time is less valuable than yours? SMH.

Don't you think proper website security is worth a few minutes of time when the code you write impacts over 25% of the internet, and when the potential impact of hacked websites can destroy people's lives and businesses.

The previous response from WordPress core team members demonstrated a severe lack of understanding of security issues and required a fairly long response.

You guys have not been good at anticipating potential hacks because you all have been failing to see where seemingly small or peripheral issues fit into the big picture of security as a whole. Security isn't binary, it's not on or off, it's not black or white. Security exists in shades of gray, it's in percentages, it's about leveraging small cracks in the armor, and hackers understand this.

Many of us who are pointing out these issues can anticipate potential hacks because WordPress is blatantly ignoring certain security best-practices. Yet yet you guys still have the hubris to keep shutting us down and telling us "that's not a real security issue". (I really don't enjoy having to say that because I truly do love WordPress, the WordPress community, and I consider every fellow WordPress developer a friend.)

My comments are worth taking the time to read as they will open some eyes a bit. I was careful to make sure that everything I wrote is backed up by data, and quotes respected resources. Every single point I made can be verified independently. Top security researchers, experts, the NSA, etc will echo what I said.

I took several hours of my life to write it...people can take a few minutes out of their life to read what I wrote.

I didn't spend all time to write it for fun, or for my health...I took the time to write it because it's a serious issue, and it needed to be said. Trust me...that was the succinct version.

I've been doing this a long time, and have extensive experience when it comes to security. You would do well to consider my points.

I took several hours of my life to write it...people can take a few minutes out of their life to read what I wrote.

If you spent months writing a book about this topic, that would be impressive, but it would still be inappropriate for a comment on Trac. Consider that your comment is not the only one left on Trac today, nor is reading Trac the only thing we need to do. Having gigantic comments makes it harder to keep on top of what's happening, and I don't think any of us have the mental space to keep track of all of it even when comments are succinct.

I think you've also mischaracterised my involvement in WordPress; I am a guest committer, and am not on the security team, nor a lead developer. My time spent here is also voluntary. If you have security concerns, you should email security@… with them. I merely dropped in to mention that your comment is probably too long to be digestable.

I also find the tone you've replied with here to be inappropriate. I'm trying to help you get your concerns across, and instead you've attacked me. Let's keep calm and discuss this. :)

I took several hours of my life to write it...people can take a few minutes out of their life to read what I wrote.

If you spent months writing a book about this topic, that would be impressive...

I would hope that it would not require writing a book on the topic to get the core team to follow security best practices. :)

...but it would still be inappropriate for a comment on Trac.

If that's true then technical limitations should be set in place to prevent long comments.

Also, if that's true, then it should be considered inappropriate for core team responders to instantly shut users down without really considering their points or admitting that they need to research the topic, or consult someone more specialized. It forces us to write long comments to prove the point.

Consider that your comment is not the only one left on Trac today, nor is reading Trac the only thing we need to do.

Yes, I understand. While I do appreciate your hard work, we're all in the exact same situation.

With each new release of WordPress, we have to check our plugins for compatibility, potential new security issues, and make sure nothing gets broken or compromised by the new release. With each new major release in the last couple years (and all but the most recent minor releases), vulnerabilities have been discovered within weeks, so please understand why I'm pushing for some change here.

Having gigantic comments makes it harder to keep on top of what's happening, and I don't think any of us have the mental space to keep track of all of it even when comments are succinct.

I understand. But keep in mind that we have to protect our clients' websites from security issues, and when WordPress devs don't follow all best-practices, it requires a lot of extra work for those of us tasked with protecting people's websites, businesses, and livelihoods. We have to do a lot of extra research, coding, and testing to create additional layers of security to compensate. You talk about mental space...I understand...we get extremely exhausted too. :)

I think you've also mischaracterised my involvement in WordPress; I am a guest committer, and am not on the security team, nor a lead developer. My time spent here is also voluntary. If you have security concerns, you should email security@… with them. I merely dropped in to mention that your comment is probably too long to be digestable.

I understand. This particular issue is something that people have been bringing up for years. I think it's better discussed publicly because WordPress is open source, and the published process is to use the bug tracker ticket system. However, I will email security as well.

I also find the tone you've replied with here to be inappropriate. I'm trying to help you get your concerns across, and instead you've attacked me. Let's keep calm and discuss this. :)

I think you misinterpret my tone. I apologize if anything I said was perceived as an attack. I think you may be confusing "disagree" and "challenge" with "attack". I certainly didn't intend to attack you. :) Notice there was no name calling, derogatory anything...I was just pointing out that the overall process tends to run people in circles, and exasperate those who report issues. At no point did I have any negative feelings toward you, disrespect, or intend insult. :)

Disagreement, or pointing out problems with how things are being handled should not be discouraged, though.

As noted in my "research paper" comment, I have nothing but love and respect for you all guys. I'm a blunt person. Sometimes I use sarcasm, especially when needing to break up a dry topic like this. No offense is meant. I can have conversations where I disagree with people, but at the same time have nothing but the utmost of respect for them.

If it isn't clear, I'll say again:

WordPress is the best CMS out there.

I have nothing but love and respect for the WordPress devs, and all involved.

I can disagree with you and point out a flaw without disliking you or being angry at you.

I only invest my time in things that I care about.

I'm trying to help improve WordPress.

You all are brilliant, talented, and changing the world...keep doing great things.