Vulnerability Reports Miss The Mark

Lately I’ve been getting a lot of ‘vulnerability’ reports.

I use the term loosely because the reality is these are not actually serious vulnerabilities. A couple months ago I started getting a lot of weird reports like this:

A FLAW FOUND ON YOUR WEBSITE!

Website Security Vulnerability Notification

Hello, a security researcher reported a security vulnerability affecting [your] website via [company] coordinated and responsible disclosure program:

Those can be super scary! Is there really a massive issue?

No. But I know why it feels that way. And frankly I think a lot of these people are targeting the wrong group. Let’s get into it.

Scare Tactics

In the case of all the ones I got, there was only one that I felt actually was. But first, here’s what people reported:

• The PHPInfo Page was public
• Directory indexing
• People can list users (aka User Name disclosures) via the REST API
• Your xmlrpc is showing
• Incomplete SSL Protection
• Your email records allow spoofing/DMARC compliance

The last one? Absolutely an issue. I thanked that person and kicked them some money. But the others? They’re issues, but they’re also incredibly minor! Heck, this user name listing ‘vulnerability’ does not take the following into consideration:

1. It’s on a site where every author has a page
2. We have an ‘about us’ page that lists everyone anyway
3. Strong passwords are enforced
4. We have a firewall

The only way I could really improve that would be to enforce 2FA, which I’m contemplating for admins. But that begs the question… is this a vulnerability?

Okay, let’s ask why does this work? It’s known that WordPress has a REST API. This API can be used to list public information about registered users. Now the API does ‘expose’ the user data for everyone who’s authored a public post that is shown in the REST API. Posts and pages and some custom post types included. If the user hasn’t authored posts, you won’t have permission. So again, we’re only able to list public authors. Okay.

Could that be bad? Sure. In the same way having a front door could be bad if someone kicked it in. But ‘security’ isn’t why I would ever consider blocking that. We literally list all the authors publicly already. If someone wants to use wp-json to grab them, cool. It only shows public information we displayed already, after all.

Why would I consider blocking? To ensure stability. That is, people hammering my site to find out that I’m not user #1 on HalfElf (surprise!) makes my site slower. But… I have a firewall and Mod_Security, and IP Tables, which means if you hit my site enough, it’ll block you. Also a lot of stuff is cached, like it should be. Which means this is not a ‘vulnerability’ but more of a ‘best practice notice’ in my opinion.

And finally … FFS why are you telling individual site owners this!? If you really think it’s a security issue, take it up with WordPress!

How Do You Stop Them?

Well, generally you fix the ‘issues.’ Even if you think it’s full of shit, you fix it. So okay, what do we do?

PHPInfo? Locked it down. I use it for regular checks of other things. If you’re not, just delete it.

Directory Indexing? I put this at the top of my .htaccess (and yes, you should, I’d removed it for some tests):

### Prevent Directory Browsing ###
Options All -Indexes

XMLRPC? I said “Nope, not gonna change.” Because I use the WordPress iOS App.

SSL? You’ll want to check your setup on things like SSL Checker or Immuniweb or SSL Labs. I found SerpWorx’s tool to be invaluable for spelling out what was missing. The easiest by far was SecurityHeaders.com. For that, I ended up adding this to my .htaccess:

### Extra Security
<IfModule mod_headers.c>
	Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
	Header set X-XSS-Protection "1; mode=block"
	Header always append X-Frame-Options SAMEORIGIN
	Header set X-Content-Type-Options nosniff
	Header always set Expect-CT "max-age=7776000, enforce"
	Header set Referrer-Policy "same-origin"
	Header always set Permissions-Policy "geolocation=(); midi=();notifications=();push=();sync-xhr=();accelerometer=(); gyroscope=(); magnetometer=(); payment=(); camera=(); microphone=();usb=(); xr=();speaker=(self);vibrate=();fullscreen=(self);"
</IfModule>

The one thing I left out was Content-Security-Policy because that one is crazy complex and needs a lot of testing since a lot of content on the site is remote and needs special rules.

Email/DMARC? That took a lot longer, and I had to talk to my email provider to sort it out. But you can run your domain through the MXToolBox checker and see what you’re missing. It’s going to make you cry. Email sucks.

Okay but I wanna hide users!

I hear you. You can do this in .htaccess:

### Block User ID Phishing Requests
<IfModule mod_rewrite.c>
    RedirectMatch 301 ^/wp-json/wp/v2/users(.*) /about-us/

	RewriteCond %{REQUEST_URI} !^/wp-admin [NC]
	RewriteCond %{QUERY_STRING} author=\d
	RewriteRule ^ /about-us/ [L,R=301]

    RewriteCond %{QUERY_STRING} rest_route=/(.*) [NC]
    RewriteRule (.*) /wp-json/%1 [L,R=301,QSD]
</IfModule>

Now. This means on that site if you go to example.com/?author=1 you will not go to someone’s page. But if you go to example.com/author/ipstenu/ you still would. Which IMO points out how stupid that ‘vulnerability’ is. Yes, I am aware you can see the authors. Oooooh. You’re supposed to!

Conclusion?

A lot of those vulnerability emails are bullshit. I politely reply “Thank you for your concern however we are not blocking access to that because the API is used by other things. It’s considered to be public knowledge anyway.” I may end up writing a form letter.

And the sucky thing is that one of the sites that collects all that stuff relies only on the reporter to determine if it’s resolved. Both issues they have for the domain in question? 100% resolved. But they say ‘unpatched’ … probably because I told both reporters I’m not paying them.

I added this to my profile:

We do not accept reports of basic WordPress functionality, such as the Rest API being active, the use of xmlrpc.php, the enumeration of users, etc. Those are an acceptable risk. Please don’t bother reporting them, they should be addressed with WordPress directly, not end users.

By the way. The bug bounty program that keeps emailing me? Uses WordPress. And guess who’s site has /wp-json/wp/v2/users available to list all their public authors? Yeah. Because it’s not a goddamn major issue.

I know someone’s gonna point out it could be a major issue. Sure. Like having a window means your house or car could get broken into. That doesn’t mean you remove all the windows!