WordPress vulnerability?
-
There’s a vulnerability in WordPress’s XMLRPC implementation, that permits trackback spam – even when you disable trackbacks. The only way to prevent this spam is to disable XMLRPC entirely.
Does this apply to WordPress 3.5 also (the latest version)?
-
Here’s a link from esmi explaining how to disable xml-rpc:
http://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/
I don’t know if it’s really accurate to call the situation a “vulnerability” since the code is doing exactly what it is designed to do. Trackback spam has always been a concern and there have been countermeasures available.
What I notice is that about a day after the new WordPress core release came out turning xml-rpc on by default the web started getting dotted with all these claims about a “new” vulnerability.
My philosophy is that if you do not need a functionality, then, to the extent possible, you should not have code for that functionality on your site. As more and more gets bolted on to the core, it becomes increasingly difficult or impossible to “only keep what you use.”
Heck, I think lots of what’s in core should be outsourced to addons — like the whole Media Library should be a plugin. But woe betide the community if that were the approach; much tearing of hair and gnashing of teeth would ensue! <chuckle>.
Thanks for your reply and link, gcaleval.
It might not be a bad idea to break WordPress in to “moduls” and be able to enable, disable or choose another supplier.
About the XMLRPC; the author of this plugin links to this information (dated December 17, 2012), and the problem is much wider than pingback spam:
This can be abused in at least fours ways:
- WordPress is trying to resolve the Source URL and will return different error messages if the Source URL exists (host exists) or not. This can be abused by attackers to try to guess hosts inside the internal network. The attackers can use URLs like http://subversion/ or http://bugzilla/or http://dev/to see if these hosts exist in the internal network.
- If the Source URL is resolved, WordPress will try to connect to the port specified in the URL. Therefore, if an attacker will use a URL like http://subversion:22/, WordPress will try to connect to the host subversion on port 22. The responses are different if the port is open or closed. Therefore, this functionality can be used to port scan hosts inside the internal network.
- This can also be used for distributed DOS (Denial of Service) attacks. An attacker can contact a large number of blogs and ask them to pingback a target URL. All of these blogs will attack the target URL.
- From the tests I’ve carried out, I’ve seen that WordPress is also supporting URLs with credentials. So, an attacker can use a URL like http://admin:admin@192.168.0.1/changeDNS.asp?newDNS=aaaa to reconfigure the internal router like in the email hack attack.
And How do you protect against this vulnerability? Currently there is no fix. Disabling pingbacks and trackbacks from the Discussion Settings page doesn’t fix the problem either.
If this is true then our servers can be abused and get blacklisted, and that is reason for concern.
How do you protect against this vulnerability?
The link I shared from esmi explains how to disable xlmrpc, which is complete protection against the kinds of probes being descrived.
What ticks me is that this is all being presented as a “new” threat. The DoS attack was completely viable against any site allowing pingbacks before 3.5. So was trackback spam. XML-RPC also always supported user credentials — that’s how remote blogging tools like LiveWriter and ScribeFire work — they use XML-RPC to authenticate you into the site.
The only one I’m not sure about is the internal network mapping.
What’s really new is just the fact that it is turned on by default now and you have to take an extra manual step to disable it.
But as someone who watches security threads and has vulnerability alert notices coming from many sources, I get a little angry that some “security” sites take any opportunity to trump up something into a “threat” when it really is at most an annoyance.
I’m convinced that there are many self-proclaimed security experts out there who are more interested in “scaring” up traffic to their sites or selling their services than they are in monitoring, reporting and defending against actual threats.
After installing this plugin the mobile app on my iPad can no longer access my admin panels. The error indicates it is looking for the file this plugin is disabling. If I deactivate the plugin, the mobile app works. Any idea how to address this?
@matthew2582 The answer is no. The WordPress mobile app connects using XMLRPC. And this plugin disables WordPress’s XMLRPC functions. Therefore, if Prevent XMLRPC is activated, then the WordPress mobile app doesn’t work.
Under the plugin’s FAQ, it says:
Windows Live Writer, and other similar services, use the XMLRPC interface to “talk” to your WordPress site, so it won’t work while this plugin is active.
xmlrpc.php appears to be only used by the admin(s) for publishing and managing the wordpress via mobile or via a client as opposed to using the web interface. it does not appear to be necessary for end users. Is this true or false? It is very difficult to find a straight answer to this question on the Internet. There are all kinds of discussions about xmlrpc.php, but nowhere does anyone come right out and say: “It is only used by admin.”
If it is only used by admin, then it will be a simple matter to restrict access to it based upon user-agent or IP address.
Forsett, how would one do the restriction? I have a static IP that I access from. I am the only admin user. Would I put something in the .htacess and if so what?
I just had an attack of xmlrpc which used up all of my bandwidth for the month in just a few days. Money down the drain to some CRU sucking bot. I have removed the xmlrpc file for now as doing so does not seem to interfere with my site at all. Other than the mobile app are there other consequences?
@forsett it is not correct that xmlrpc is only used by Admins. It is also the vector in for a range of web services such as IFTT and others where interaction with your site is required to provide the service. If you use a service that involves server-server communications which require authentication, it is possible they are using xmlrpc.
@pubwvj if you don not use it for these purposes or for WP mobile then you are likely safe to just disable it as explained in the second post of this thread.
The simplest test is to disable it and watch what happens for a few days. If everything is working fine, you’re god to go. If not at least you should be able to see exactly what it is breaking so you can look for an alternative to that function / service.
I would like to leave the xmlrpc alone and have WP properly protect things however the problem I ran into was that a bot was requesting the xmlrpc file over and over, using up 5GB of bandwidth. My guess, correct me if you think differently, is it was trying to login/command through that entry point. Eliminating the xmlrpc file stopped the bandwidth sucking.
So far no users have reported any problems with not having the xmlrpc file available. I get about 1,000 to 3,000 readers a day between the two blogs and I warned readers of the issue, that I was disabling xmlrpc and to let me know if they had any trouble. So far, so good.
Any insights are appreciated.
@pubwvj The following htaccess rule will prevent any access to the xmlrpc file from any IP other than your own (obviously you need to swap in your own proper IP address). But if you are using a mobile app to admin your site, you’d have the problem of knowing all the possible IP addresses that may be signed to your phone or device over time. In theory that’s possible, but I don’t know enough about how cell providers assign IPs.
So if you are actually using a mobile app to administer your web site, htaccess rules are not a viable solution. If you are using Windows Live Writer from your home system, then this will work fine until your IP changes at which time you have to FTP in and change the rule for the new IP.
RewriteCond %{REMOTE_ADDR} !^999.999.999.999 RewriteCond %{REQUEST_URI} /xmlrpc\.php RewriteRule .* - [F]A better solution to the problem you faced may well be ZBBLock. It does a very good job of catching bad IPs and blocking them from ever getting into WordPress, but manual installation is necessary as no one has created a plugin for it yet.
@pubwvj If you don’t need it at all, then yes, you are good to go without it. I have it disabled on a number of sites.
What I do is redirect unacceptable requests to my bot-trap. You do have a bot-trap installed along with a honeypot, don’t you?
I ban about eight hundred thousand IP addresses as known spam and scraper bots.
- The topic ‘WordPress vulnerability?’ is closed to new replies.
