Hackers Find Fresh WordPress Sites Within 30 Minutes
Last week our team attended Black Hat and DefCon in Las Vegas, two of the biggest information security conferences on earth. DefCon alone attracts approximately 20,000 information security professionals, researchers, government employees and fans. To say it is very busy is an understatement.
One of the interesting presentations at DefCon this year discussed a way for attackers to quickly find new WordPress installations to target. The presentation was given by Hanno Böck, and in it he discusses a method attackers can use to find a WordPress website just 30 minutes after it has been installed for the first time.
About three weeks ago, we published a blog post titled “The WPSetup Attack: New Campaign Targets Fresh WordPress Installs” where we discuss how we are seeing attackers specifically target fresh WordPress installs and how to avoid being attacked. Hanno expands on this risk in his presentation.
Certificate Transparency is an open standard that allows the online community to monitor SSL certificates that have been issued to websites. This allows, for example, websites like Facebook to monitor if someone has ordered an SSL certificate for one of their domains. It also allows security teams to monitor if a certificate authority (companies that issue SSL certificates) has mistakenly issued a certificate it shouldn’t have.
Anyone can use certificate transparency data to see new SSL certificates that have been issued. The data includes the website domain name. Hanno’s research showed that within 30 to 60 minutes of a new SSL certificate being issued, attackers can see it in the certificate transparency report. This provides attackers with a way to discover new websites to attack.
The sequence of events would go something like this:
- You order a new website hosting package from a hosting provider. Your order includes a free or paid SSL certificate for your domain.
- The SSL certificate is issued once your order completes.
- 30 minutes later, attackers see your fresh website listed in the certificate transparency report.
- At that time – 30 minutes later – you are halfway through completing your website setup and are just beginning to install WordPress.
- An attacker is constantly monitoring your new domain, and as soon as they see the setup script, they run it, install a back door and then reset your site to the state it was in so that you don’t notice.
We described how the WPSetup attack works in our post three weeks ago. This new technique gives attackers a way to reliably find and attack fresh websites as they are being set up.
Last week we also discussed the risk of using utility scripts like searchreplacedb2.php which don’t have any authentication, and that anyone on the Internet can access. The technique described above to discover freshly installed websites could also target these utility scripts. Thirty minutes after installing a new website, you probably think no one knows about it yet and that it is OK to install a utility script that isn’t protected by a password. Using the above technique, an attacker can scan your site for temporary utility scripts and also use them to gain entry if they are unprotected by a password or authentication.
To avoid all of the attacks above while you are setting up your new website, we suggest either limiting access to your IP or setting up basic authentication. Both of these can be done using .htaccess.
How to Limit Access to Your Site Based on IP Address
You can limit access to your website so that only your IP address can access the site. Here are the steps to do that.
- Find out what your IP address is by visiting whatsmyip.org.
- Create a file called .htaccess in your website root directory.
- Place the text below in the file and replace the marker with your IP address.
order deny,allow deny from all allow from <your ip>
That should block anyone who isn’t from your IP address from accessing your web applications. Test it by using FTP or SSH to change the IP slightly and you should lose access to the website. Make sure you aren’t using a web based file manager, or you will block yourself when you do this test.
Once you have set this up so that only your IP can access your site, you can go ahead and continue setting up WordPress and anything else knowing that no one else can abuse your setup scripts.
To remove the access control, simply delete the above lines from your .htaccess file and access for everyone else will be restored.
How to Set Up Basic Authentication
Setting up basic authentication is a bit more complex. You will need access to a Linux shell to be able to create your password file. Once you have set up basic authentication, your browser will pop-up a prompt to enter a username and password whenever you access your site. The basic procedure is as follows:
First you need to use the htpasswd utility on the Linux command line to create a password file. The command to create the file looks like this. Replace ‘mark’ with your own username. You should be prompted for a password.
htpasswd -c /homedir/webroot/.htpasswd mark
If you need to install htpasswd to run the above command, you can find it in the apache2-utils package on Ubuntu Linux. If you don’t have access to htpasswd, we suggest you contact your hosting provider for help creating the password file.
Once you have created the password file, you need to add the following to a .htaccess file in your website root. Make sure you replace the path to the .htpasswd file with your own path to your password file.
Authtype Basic AuthName "Put anything here" AuthUserFile /homedir/webroot/.htpasswd Require valid-user
Once you are done, you should see a prompt for a username and password when you try to access any part of your website. Enter your username and password to access your site and continue setup. This will prevent an attacker from accessing your site while you are busy setting it up.
To remove the above access control, delete the above lines from your .htaccess file and access for everyone else will be restored.
Stay Vigilant
This is another great example of attackers using evolving techniques to identify targets and attack websites. We now know that attackers can easily identify new websites and attack them while they are being configured. As long as you use the techniques described above while your site is in setup mode, you should be safe from this kind of attack. Please share this post with the community to make them aware how attackers quickly find fresh WordPress installs.
Comments
8:36 am
Does it mitigate the ability for hackers if we install Wordfence as the first plugin with every install of Wordpress?
1:44 pm
I would strongly recommend that. But Wordfence won't be active until WordPress is fully installed.
7:49 pm
Mark,
About the WPSecurity attack, a possible solution would be as follows:
- WordPress comes with an htaccess file, containing a basic auth with user "admin" and password "WordPress"
- WordPress refuses installation if the user is "admin"
- The user has to change the username to something else before installing, via FTP
- Basic auth is removed automatically after installation
I think this could work. Attackers wouldn't be able to guess a specific username in such a short period of time, I believe.
8:39 am
Thank you for this!
Another (possibly) easier - and still safe - option:
* First set up Wordpress using your best-practice safe method, and THEN set the SSL after completion.
* You can then just navigate to the https version of the wordpress login.
* Once logged in you re-set the site URL address using permalinks (and add in your .htaccess redirect to https if required)
...no?
Stevo :-)
10:09 pm
This is the way that I always did until I started building locally instead. By building locally and always password protecting the working directory during migration & until launch, pretty much does the trick usually.
5:29 am
The issue with this is that some hosting includes the SSL, and they set it up at purchase, before you've even gotten into your account to set anything up. So it's not always an option to set it up before SSL.
8:46 am
Dumb question, maybe .. but would another workaround be to simply not enable SSL until after the initial WordPress install/setup has been completed?
1:44 pm
I wouldn't rely on that. There may be other ways to discover new sites.
8:46 am
Thank you, Mark, for yet another terrific post!
A question for you: when you provide instructions for how to implement something in htaccess (such as IP restrictions or password protection, as you mentioned in this post), have you considered providing either an equivalent solution or a link for how to do the same on a Windows/IIS setup (e.g. in a web.config file), provided it's not something that would require you to invest much time into looking up?
Before anyone reading this jumps at the opportunity to tell me that I shouldn't be running WordPress on Windows/IIS, I am well aware that Linux is better suited for WordPress, and the company I work for does plan to ultimately move WordPress and other non-ASP.NET websites to Linux hosting. We are a "Microsoft shop" that does a lot of server/network support for companies with Microsoft products, including Active Directory, Hosted Exchange, Office 365, etc., so currently all of our systems are Windows, hence the Windows/IIS hosting.
I know that Linux is far more common for hosting, but there are plenty of sites out there running on IIS (whether by choice or not), so I'm sure there are others who would definitely appreciate IIS-equivalent tips for implementing certain things.
Thanks again for a great product, and for the regular informative posts! I can't imagine running WordPress without Wordfence.
Ben
1:43 pm
Hi Ben,
If you could provide brief instructions here that would help the IIS community.
Thanks,
Mark.
8:58 am
Your plug-in is the best thing for WP sites since sliced bread!
In all seriousness, I have recommended Wordfence in several forum posts including referrals to your blog posts which I find to be excellent.
IRT this post and as a means to expand the use of Wordfence, would it be possible to implement the two recommendations above, i.e., IP blocking and Authentication, into Wordfence so if you install Wordfence before getting your SSL you could click a few optional settings and it would be implemented for you semi-automatically?
9:07 am
Another option, on the security through obscurity aspect, is to install the website in a subdirectory.
That may be simpler for beginners, and it works for users who don't use Apache (e.g. those who use IIS) because htaccess and htpasswd are Apache-specific.
This is security through obscurity. The installation is not secure, it's just hidden. However, with this attack targeting very specific and short lived installations, that may do the job.
Installing WP in a subdirectory is usually good practice regardless.
9:32 am
This seem to be a serious threat. A lot of indie authors rely on setting up Wordpress who might not know how to use .htaccess. Is there any advice for them?
1:43 pm
Hi Bill. We included instructions on how to use .htaccess. It's as easy as creating a file with three lines of text.
9:44 pm
Hi Bill,
Another option is installing WordPress using something like Installatron (http://installatron.com/wordpress). Not all hosts offer it, but if your host does you can go to cPanel and install WordPress through it. It will ask you to enter login details for an admin account it creates as it installs. This means that there is not time between starting the install and completing setup when the hackers can get in.
As Mark says, "As long as your WP installation isn't left in a state that lets an attacker complete the installation, you should be fine."
7:45 am
Appreciate the information. I'm working on a book for new indie writers and this will be very helpful.
9:48 am
If I implement the above in my .htaccess file will the front facing (public) side of the site be still available to everyone?
Is this only for the back-end of the Wordpress site?
10:10 am
Hi Ralph,
If you block everyone except traffic coming from your IP address using the method recommended in this post, that will block traffic to your entire website - both front and back end. Hope that helps!
10:10 am
Wouldn't this solution of limiting the access to a new site only to our IP address be useless on shared hosting? I ask this because i know that hackers also use the hosting services available, in order to attack other sites on the same shared IP address.
Thanks
11:53 am
Hi Maria,
The IP address referred to in the blog post is the IP of your own Internet connection, not your web server's IP address. If you're on a shared network, such as a work or public Internet connection, then that IP address would be shared by anyone connecting to the Internet on that same network, but a shared web host server will have a completely different IP address. Hope that helps!
1:21 pm
Thanks !
10:30 am
So, is this to say that unless someone is Linux-capable and has the skills, setting up a WordPress site is no longer a safe activity? Doesn't this leave out most of the WordPress sites that have ever been set up over the past few years?
Also, is there a way to detect the attack, after it happens? A way to correct it?
1:42 pm
WordPress need to change their setup procedure to make it secure by default. We need to move away from applications using installation procedures that give anyone on the Internet remote code execution for a few minutes during setup.
You don't need Linux skills to use the IP blocking technique. Just create an .htaccess file with your IP and you're done.
Mark.
10:53 am
Personally I do my development on a local VVV-based virtual server and then use a deployment script to set it up. This avoids the wp setup script ever existing and mitigates the problems listed in here. Not going to help less technically minded developers though who are using the installers that come with hosting accounts...
11:31 am
My isp keeps changing my ip address so using this method will lock me out of my own website.
Is there a safer way to implement this?
12:04 pm
Yes, use basic authentication as described in the post.
12:04 pm
Thanks.
... and if you use an Ngnix server?
1:40 pm
Good question. Nginx doesn't respect .htaccess. However if it is front-end to Apache then you can still just use .htaccess because Apache will block access. If you are running purely Nginx with FPM then you may have to adjust Nginx config to limit access on IP.
4:10 pm
What if we use the app installer in the cpanel /plesk?
4:14 pm
As long as your WP installation isn't left in a state that lets an attacker complete the installation, you should be fine.
4:45 pm
Never gonna happen on the WPE sites I set up cause they are cloaked (hidden) until I release them. ALL Traffic blocked while in development mode. You just need to use a managing hosting provider that supports this.
6:43 pm
Which host do you use? I'd be interested in testing this.
6:12 pm
Is this a problem only for the first installation of a WP at a given host, or does it also apply to add-on domains setup later under the same account?
6:42 pm
It applies to add-ons too.
6:59 pm
Hi Mark, how about we install the Wordpress locally first and once finish only move to live domain. Is this help?
7:45 pm
If you can do that it will help. But deploying WP from a test server to live can be a bit tricky.
7:02 pm
If you use cPanel (which a lot of people do), setting up Basic Authentication is easier than the steps listed above, and you don't need shell access (which a lot of people DON'T have).
It's called Directory Privacy, and it's quite easy to follow the steps there. You'd simply click on the public_html directory, and fill in the relevant fields to password protect it.
10:48 pm
two way authentication on your WHM and your cPanel account and your wordpress panel helps too on top of the other
10:52 pm
An other great explanation, somehow started to understand the way to protect my websites. Still I think it's far to reach master level. Thank you...
11:17 pm
Hi,
another example of the inherent insecure nature of Wordpress installs.
You should right an article on what happens to an unsecured install of Wordpress. Like those videos of apples rotting.
If you choose Wordpress. Its not a case of when a site will be hacked, its a case of how many times.
The rush to placate Google by installing a 'secure' certificate was just a way for them to get a bigger pipe for more data, not a safer Internet.
David
11:56 pm
If attacker can discover new websites within the half hour with SSL certificate transparency, can they use domain services to discover newly issued domain names? Because domain information also public.
7:42 pm
That is true Anvar. I would say though that usually when someone gets an SSL certificate they are busy configuring a new website. So attackers may have more success at finding new sites by looking at the transparency report. But I don't have data to support that.
7:03 am
I'm trying to add a .htaccess file, but what folder does it need to go under? Thanks.
7:41 pm
It should go into your web root. That will usually be the one that contains a folder called 'wp-content/' and 'wp-includes/'. It make have the name 'doc_root' or something similar.
12:52 pm
Did anybody think about what happens, if my IP-Address changes because my provider assigns them dynamically? Isn't that very common? I think the change often happens overnight. So never forget to delete that htaccess-entrys after installing WP :)
7:40 pm
IPs on broadband routers don't change that often. I think a more likely scenario is if you are using a VPN provider, you may block yourself. That is why we don't recommend whitelisting IPs in general. This is a special case where the IP will stay whitelisted for just a few minutes while you complete install.
2:52 am
My webhost does not permit creating a htaccess file in their CPanel file manager. However they do have option for leech-protecting folders within. I guess using Leech Protect is another way to mitigate this risk?
7:17 am
Two other ways you could avoid this problem
1) Before purchasing an SSL certificate. Deploy the website to the server, and force your hosts file to look to the new server. You can then test the website is working and make it secure before purchasing an SSL certificate and launching the website.
2) Have a solid, automated deployment script. This would minimise the window in which attackers had to do damage
I don't see this as something solid workflows and processes could not fix.
9:46 am
Thanks a lot for all the info, I have a dumb question; when you say "Make sure you aren’t using a web based file manager, or you will block yourself when you do this test." I got confused because as I know, all cpanel are web based. And that is the only way I know to access and work on my domains. (or else I use filezilla). Sorry if I am confused. Do you mean if we do that change to .htaccess we can not access by cpanel even from our own authorized ip?
11:33 am
Good question. Your CPanel is probably on another IP address so if you do this test you probably won't block your cpanel file manager.