Who I am
- I am a system administrator and programmer who develops web applications and supports High Performance Research Computing at the University of Michigan.
- In my previous job, I was in charge of of the main central web infrastructure for the University of Michigan for 5 years, including providing hosting for WordPress sites at U-M.
- 19 years of experience dealing with computer security compromises / break-ins.
- 11 years of experience dealing with web application security compromises / break-ins, including WordPress.
Who I am NOT
- A security expert (much more knowledgeable than me).
- A bad guy (much more capable than me, with access to "bad guy tools").
This presentation could be much scarier if done by either a security expert or a bad guy.
Both security experts and bad guys will have much more time and focus than a generalist such as I am.
Bad guys have access to malware, including very sophisticated toolkits to compromise web sites, "black hat" forums, and more. Toolkits and exploits are routinely bought and sold for Bitcoin or dollars on black market sites.
This presentation uses only "good guy tools" because I don't want to use untrustworthy software or wind up on a law enforcement agency's lists.
Demonstration - the target
http://myblog.catseye.org/
Demonstration - the target
- WordPress 3.8.1 (latest version available as of this presentation.
- Plugin: W3 Total Cache 0.9.2.8 (has a security problem! current version is 0.9.3)
- Running on Ubuntu Server 12.04.3 LTS 64 bit (current LTS release), fully patched/updated.
Everything was set up according to the instructions at wordpress.org and ubuntu.com. The only extra things that were done were:
- Allow comments to appear without a commentator having a previously approved comment (makes the specific attack we'll be using easier).
- Turn on pretty permalinks (required for W3 Total Cache page caching).
- Turn on Apache URL rewriting and
.htaccess files (required for pretty permalinks).
- Turn on Apache
mod_expires and mod_headers (for W3 Total Cache).
- Turn on SSH (to allow easier command-line administration).
If WordPress is left at it's default — comments only appear if the commenter has a previously approved comment — the attack will still work: we just submit a legitimate comment first, wait for it to be approved, and then launch the attack.
We're using Ubuntu Server LTS because it is the most popular choice for people who run their own server.
Demonstration - the attacker
badguy.catseye.org
We're using the latest release: Kali Linux 1.0.6, which is based on Debian 7 "Wheezy".
Demonstration - the attacker
Kali Linux, http://www.kali.org/
- A "good guy" tool that lets companies test their own networks for security problems.
- It's actually a collection of over 300 security tools, including tools to assess security as well as tools to recover from attacks (forensic tools).
- It is a complete Linux system that can either be run as a "Live CD" or installed onto a computer.
- We're using it because it is the quickest, easiest way to launch our attack: download, boot, attack.
- We're actually only going to look at two of the tools Kali Linux provides:
- WPScan: Finds security problems on WordPress sites and performs brute-force discovery of WordPress usernames and passwords.
- Metasploit: A very sophisticated security testing framework that includes a web interface to let us launch attacks without needing in-depth technical expertise.
Instead of using Kali Linux, we could just download and install WPScan and Metasploit. This requires only a tiny bit more technical knowledge than using Kali Linux, plus a bit more configuration work, and is very do-able. We're just being extra lazy.
Demonstration - WPScan
To find out how to use WPScan, run it with the --help option:
Demonstration - WPScan
Let's look at http://arc.research.umich.edu/
This is a WordPress site I use a lot at work.
WPScan can tell that the server runs Apache, but not what version.
Despite the #1 thing for keeping people from breaking into your site being to always keep up-to-date with the latest versions of everything, this site is still running WordPress 3.5.1. That's very bad; unfortunately, it's not uncommon.
WPScan found eight security vulnerabilities. Many are probably not anything that would be useful to the casual attacker, but some might be. Read the details at each of the reference URLs that WPScan provides to find out more.
WPScan found one theme ("orci"), and six plugins. There are likely more which could be found by running WPScan with an exhaustive plugin search ("wpscan --enumerate ap").
Demonstration - WPScan
Now our site, http://wordpressannarbor.com/
Here is an example where we have to give WPScan a little extra help. But it's not hard — we just look at the HTML that the site sends our browser, figure out where the plugins reside (in wp/wp-content/plugins instead of wp-content/plugins) and run WPScan again with an extra command line option to tell it.
This site is running W3 Total Cache, but WPScan was not able to determine the version number (perhaps because someone deleted the plugin's readme.txt file, or disabled directory listing just for this one plugin?), so it's printing a list of potential security problems that could exist if the site is using an old version of the plugin. Let's hope it's not, since one of them is the same vulnerability we're planning on exploiting in a minute when we do our attack on http://myblog.catseye.org/.
Demonstration - WPScan
Finally, our intended target, http://myblog.catseye.org/
WPScan was not only able to tell what web server software is being used, but also the version.
WPScan found the W3 Total Cache plugin, and, in this case (unlike the previous example) was able to determine (correctly) what version it is (likely because the plugin's readme.txt file is there and accessible). We'll make a note that this severe vulnerability exists for the site, and use that information in a little bit when we launch our attack.
Demonstration - Metasploit
Metasploit is available in four editions:
- Metasploit Framework (free and open source, command line only)
- Metasploit Community (free, includes web interface)
- Metasploit Express, Metasploit Pro (commercial)
To run the Metasploit web interface under Kali Linux:
service postgresql start
service metasploit start
Then go to http://badguy.catseye.org:3790/
Everything we're doing in this presentation can work with Metasploit Framework or Metasploit Community. We have a 7 day trial license for the Pro edition, however, in case someone wants to see the additional functionality.
Demonstration - Metasploit
Basic steps:
- Create a Metasploit user account.
- Get a license key (Community, Express, Pro editions).
- Create a project.
- Do a discovery scan.
- Choose and run an exploit, breaking into the target's site.
- Do what you want to the target's site.
Steps 1 and 2 have already been done, we'll start with step 3.
A project is like a container that keeps track of systems that are being tested, and results of the tests.
The scan finds out what is available to be tested.
Demonstration - Metasploit
Metasploit web interface - main page:
This is the page a user gets after they create a Metasploit user account, request and enter a product key, and log in. The copy of Metasploit shown has been licensed with the 7 day free trial of the Pro edition, but the Community edition can do everything needed for this demonstration.
Click on the New Project button to begin.
Demonstration - Metasploit
Just enter a name for the project and either the networks or IP addresses you'll be testing and then click the Create Project button.
To speed things up, since we're working with a single target, we'll specify just its IP address instead of specifying a network.
Demonstration - Metasploit
Project overview page:
In order to try to exploit a vulnerability, we need to have a host (that is, server). Currently, we don't know about any hosts. Click the Scan button to scan the IP addresses or networks that we specified when we created the project and look for hosts.
Demonstration - Metasploit
Starting a scan:
The IP address we specified when we created the project is automatically filled in for us, just click the Launch Scan button.
Demonstration - Metasploit
Scan results:
The scan has finished and discovered the server we're interested in. Click "Overview" in the top menu bar to return to the project overview page.
Demonstration - Metasploit
Now that we know about a host, we can do a lot more. The "Exploit" button will attempt to automatically break into the site. But, since we know from WPScan that this site is running a vulnerable plugin, to save time, click on "Modules" in the top menu and select "Search...". Then search for "wordpress".
We're actually using Metasploit far below the level of complexity for which it is intended, so many of the graphs and statistics wind up being overly simplistic.
Demonstration - Metasploit
List of Metasploit WordPress exploit modules:
Click on "Wordpress W3 Total Cache PHP Code Execution".
WordPress has a lot of vulnerabilities that are not listed here. If we're interested in anything not shown, we can create an exploit module for it ourselves, or exploit it outside of Metasploit.
Demonstration - Metasploit
There are a lot of options on this page. The only one we want to change is the payload, which should be changed from "Meterpreter" to "Command Shell". Then click the "Run Exploit" button, which is not shown in the screen shot but is at the bottom of the page.
The payload is the code to run on the compromised server after the exploit succeeds. It can be as simple as a single command or as complex as a large, sophisticated program that gives you full control over the computer.
The Meterpreter payload is actually a lot more impressive and has more features than the Command Shell payload, but the Command Shell is more appropriate for this demonstration.
Demonstration - Metasploit
Running the exploit:
Note that there is a (1) next to "Sessions" in the top menu, indicating that we now have an open session to the compromised server. Click on Sessions.
Demonstration - Metasploit
The session list:
Click on the session name in the left-most column to go to that session.
Demonstration - Metasploit
The session:
Click the Command Shell button to get access to the remote shell that was started on the target server when the exploit succeeded.
There are a lot of information gathering tools available under the "Post-Exploitation Modules" tab, but we won't look at those here.
Demonstration - Metasploit
Click the Command Shell button to get access to the remote shell that was started on the target server when the exploit succeeded.
This is the remote shell on the target server. Each command entered is executed separately, there is no context between commands as you would have in a real shell. This means, among other things, that you can't change directories (the current directory is the root directory, /).
Here we're taking a look at some directories on the compromised server.
Demonstration - Metasploit
More fun with the shell:
The attacker will probably have access to a lot of things on the server that are not normally available via WordPress, such as the home directories of Linux users.
Demonstration - Metasploit
Here, we extract the database information from the wp-config.php file. If we didn't know where it was, we could look around using the ls command; or, the Meterpreter payload contains a point-and-click file browser that could be used.
Once we have the database information, we can connect to the database and dump all of the WordPress user account information, including hashed passwords. The hashed passwords can be run through a password cracking program which will often recover the original passwords from the hashes.
If we wanted to, we could modify the database — for example, to add a new admin user, letting us log in via the web interface and control the whole site. Or, we could create a new post or page just by writing to the database.
We can run any command we want as the user that the web server runs as (user www-data in this case), but we don't have administrative control of the server — we'd have to use a second exploit (if we could) to compromise the operating system and become the root user.
Demonstration - Metasploit
Let's set up an online store!
Demonstration - Metasploit
The changes for our store:
Note the new directory named "store" which didn't exist before we ran the last command.
Demonstration - Metasploit
Demonstration - Metasploit
Let's look at the side effects of the exploit.
Note the garbage comment posted by the exploit. The comment contained an HTML comment (not shown) that contained PHP code that was inappropriately executed due to the vulnerability in the W3 Total Cache plugin.
Comments like this may be evidence of a break-in (as this one is), but can also indicate an unsuccessful attempt to break into the site (if you were not running W3 Total Cache, or if the version you were running did not have the vulnerability).
If we were attempting the exploit by hand, rather than via Metasploit, we could make the comment seem legitimate, get around first-time comment moderation, or get around a CAPTCHA, if we want to go to the trouble of doing these things.
Window of vulnerability
The window of vulnerability is the amount of time from when anyone knows about the security problem until a fix for the problem is actually deployed for a specific WordPress site. For the W3 Total Cache remote execution vulnerability we just looked at,
- The vulnerability was made public around February 25, 2013. It affected the then-current version of the plugin (0.9.2.8) and most previous versions.
- The vulnerability was fixed in W3 Total Cache 0.9.2.9 on April 17, 2013.
This assumes that no one knew about the vulnerability privately before the plugin authors learned about it.
Some people who discover vulnerabilities will inform the authors in private; this is the best-case scenario, if the authors respond in a timely manner (many do not).
Sometimes vulnerabilities are publicly discovered when people start noticing that WordPress sites that are not vulnerable to any known attack are getting compromised anyway, and the vulnerability gets pieced together through log files and other forensic evidence. This is the worst-case scenario.
Window of vulnerability
How long a specific site was vulnerable depends on how often the site updates the plugins they use. If a site checks for updated plugins...
- Daily: they would have been vulnerable for about 52 days.
- Weekly: they would have been vulnerable for up to 59 days.
- Monthly: they would have been vulnerable for up to 83 days.
Currently, it's been 338 days since the vulnerability was publicly announced, but it's pretty likely that there are still many sites which have not updated yet.
These sorts of windows of vulnerability are not uncommon — in fact, they are fairly typical, which is why it's important to update frequently. I recommend updating at least once per week.
Note that since April 17th, four new versions of the W3 Total Cache plugin have been released: 0.9.2.9, 0.9.2.10, 0.9.2.11, and 0.9.3.
How bad is the situation?
A recent report (September 24th, 2013) examined over 42,000 of the most heavily visited WordPress sites worldwide. The good news:
- 18.6% (7,814 sites) were running WordPress 3.6.1, which had only been available for 12 days at that point. (3.6.1 included several important security fixes.)
- 31.0% (13,034 sites) were on WordPress 3.6, which was the current release until September 11th.
The bad news:
- 73.2% (30,822 sites) were vulnerable, based solely on the version of WordPress they were running. If you also factor in vulnerable themes or plugins, the number is likely to be higher.
- 50.6% (21,258 sites) were running versions of WordPress older than 3.6, including 3.2.x, 3.3.x, 3.4.x, and 3.5.x
Personally, I assume that if a site is popular (in the Alexa Top 1 Million), it gets a lot of content updates — perhaps even has a staff — and therefore would be more likely to get WordPress, theme, and plugin updates regularly than a small personal site would. This assumption may or may not be a valid one.
It's the last number above that is really concerning: 1 out of every 2 of the top WordPress sites in the world were significantly out of date.
How bad is the situation?
Software authors, security companies, and agencies collaborate to maintain a list of vulnerabilities, that are assigned CVE IDs. WordPress (including 3rd party themes and plugins) has 223 CVE IDs assigned to it.
There are also WordPress vulnerability statistics for every WordPress vulnerability that has been assigned a CVE ID.
The National Vulnerabilities Database, maintained by the National Institute of Standards and Technology (NIST), contains 590 vulnerabilities for WordPress.
Another good source of information on WordPress vulnerabilities is http://www.exploit-db.com/ which contains information on 376 WordPress vulnerabilities.
"CVE" stands for "Common Vulnerability and Exposure".
Many vulnerabilities never get a CVE ID, because this takes some effort to get. For example, the W3 Total Cache remote code execution vulnerability we looked at was supposed to be assigned the ID CVE-2013-2010, but although this ID was reserved for the vulnerability, no one ever completed the process, so it does not contain any information.
Types of bad guy
Script Kiddie
- Uses tools written by others — much as we have been doing here — rather than discovering new vulnerabilities themselves and developing exploits for them.
- Often motivated by trying to impress others, personal empire building, or malicious entertainment ("lulz").
- They are often beginning hackers, or computer security hobbyists/amateurs.
- The most numerous type of bad guy, but also the easiest to defend against.
"lulz" (a variant of "lol") denotes laughter at someone who is the victim of a prank.
Types of bad guy
Hactivist
- Motivated by gaining publicity to increase awareness of their cause, or sometimes by trying to directly advance their cause.
- May deface web sites, especially large or famous web sites, in order to gain publicity.
- May build botnets for use Distributed Denial of Service (DDoS) or other attacks against their real targets.
- Examples of hactivist groups include Anonymous and the Syrian Electronic Army.
Types of bad guy
White Hats
- Encompasses security researchers, penetration testers, auditors, and other security professionals. Sometimes known as "white hats".
- White these are good guys, they should be treated as bad guys for the purposes of defending your WordPress sites.
- Most will only break into systems belonging to their employer or clients, as a part of their job. However, some will seek find new vulnerabilities in order to make names for themselves or to draw attention to security problems that could negatively affect users.
In the picture is Jon Oberheide, a security researcher who lives in Ann Arbor and co-founded the local company Duo Security.
Types of bad guy
Organized crime and other professional bad guys
- Motivated by financial gain.
They may break into your site to:
- Use it in a botnet of compromised sites and servers.
- Set up malware on the site designed to infect and take over the computers of people who visit the site (e.g., to build a botnet).
- Set up black market stores (e.g., black market pharmacies).
- Set up link farms to subvert search engine rankings.
- Mine digital currencies (e.g., Bitcoin).
- Identity theft (password cracking, etc.).
- These are the bad guys most likely to break into your WordPress site today.
For both botnets and identities, the attacker will most likely sell them to yet another bad guy for cash; there are thriving underground markets for both. Or, the attacker could use these themselves.
The two most common purposes of botnets are to send spam or wage Distributed Denial of Service (DDoS) attacks. A DDoS attack could be for ideological reasons, to serve as a diversion for another attack or theft, or as to extort payment for not disrupting business.
Identity theft is most likely to be financial. While most WordPress blogs don't handle credit card information, an attacker will go after password hashes (for WordPress or operating system accounts) and attempt to crack them, or set up keystroke loggers. Many people use the same password for multiple web sites, or use an obvious password pattern or scheme. Knowing WordPress account passwords is not very valuable, but this could lead to compromising email accounts, merchant accounts (e.g., Amazon), or work accounts and building up enough information to be worth using or selling.
Types of bad guy
Spies
- Either government or corporate espionage.
- While the other types of bad guys will probably target your site at random, government or corporate espionage would probably target you for a specific reason, if they did.
- The most dangerous — but least likely — type of bad guy.
Levels of compromise
An attacker who exploits a security vulnerability can wind up at one of several levels of compromise.
- Log in using stolen credentials (guessed, phished, intercepted). Allows the attacker to do things that the person the credentials were stolen from can do.
- Subvert the web application. Allows the attacker to do things that are not normally allowed, such as get private information from the database or modify posts.
- Subvert the account that runs the web application. Allows the attacker limited control of the server to run arbitrary code as the web server user.
- Subvert the server that hosts the web application. Allows the attacker complete control of the server, operating system, and all sites hosted on the server.
Frequently, an attacker will compromise the site at one level and then use the information and access that that level of compromise gives them to compromise the site at more thoroughly.
For example, an attacker might subvert the WordPress to become a blog author, allowing them to take advantage of a vulnerability that is exploitable only by authors to run any code they want, and then use this level of access to exploit an operating system vulnerability that can't be exploited remotely, only by local users, in order to become root (the superuser) on the server.
If someone compromises the server ("gets root" or "roots it") it becomes much harder to regain control again, since the attacker can hide code in the operating system kernel or libraries. The best course of action in this case is to reload the machine and restore the sites and other data from a known-good backup.
In our demonstration, we were able to go directly for #3 and stopped there. Many attackers will try to continue on to #4, if it is easy enough for them to do so (e.g., if the operating system has not been kept up to date) or if they are determined.
Stealth
Skilled attackers who are not seeking publicity will try to hide their presence on your site or server for as long as possible, since if you find them you'll kick them out and address the vulnerability which which they originally got in. It may not be obvious that your site has been compromised.
An attacker may:
- Hide their files deep in the WordPress tree
- Give their files and URL legitimate-seeming names (e.g.,
wp-comments-page.php which is not actually part of WordPress).
- Put their files in hidden directories (on Linux/Unix servers, directories whose names start with a period are not shown by default).
- Put their files in directories that are hard to detect (e.g., a directory whose name is a single space character).
How to secure your WordPress site
Short version:
- Check for updates to WordPress, themes, and plugins at least once a week and perform the updates right away.
- Do all of the stuff in the WPsecure.net Basic guide. These are practices rather than configurations.
- Do all of the stuff in the WPsecure.net Secure WordPress guide. These are mostly configuration changes.
WPsecure.net also has an Advanced Security guide and an guide. I don't recommend most of the things in these two guides as they are of limited effectiveness.
How to secure your WordPress site
Updating:
- Check for updates to WordPress, themes, and plugins at least once a week and perform the updates right away.
"But I don't want to break anything!"
- Have a "development" site where you try new things first before you do them on your live site. This could even be a WordPress installation on your laptop, if you don't want to pay for hosting another site.
- Wait no more than 2-3 days after an update becomes available, check forums for reports of problems, and if there are not any, then upgrade.
- In the unlikely event that an upgrade breaks something, either downgrade to the previous version (via shell or SFTP access) or restore from backup (you do make regular backups, don't you?)
You can download for free the BitNami Stack for WordPress from the Mac App Store for a very easy way to run a development WordPress site on your laptop.
A bit more work is using WAMP (Windows) or MAMP (Mac).
Or, for the most control, you can set up a server running Linux as a virtual machine on your laptop and use either a WordPress appliance or roll your own server.
How to secure your WordPress site
Password concerns:
- If the only people who log in to your site are you and authors, limit where people can log in from (via web server configuration).
- Otherwise, use a plugin such as Limit Login Attempts or Login Security Solution that limits the number of login attempts to prevent brute-force password guessing.
- Don't make it easy for people to know what WordPress account names exist. Don't have an account named "admin" (replace it if you have one), and make sure the names displayed for authors are not their login names (set up nicknames instead).
How to secure your WordPress site
Password concerns:
- Password guidelines:
- Do not use the same password for multiple sites or accounts.
- Do not have a "pattern" of passwords between multiple sites or accounts.
- Make sure passwords are both long and complex.
- Best: use random passwords with a password manager such as 1Password or PassPack.
- Or: use four or more unrelated words ("correct horse battery staple").
- Or: use the first letter of each word from a sentence, adding in some numbers and punctuation.
Ars Technica published an article in March 2013 showing how easy it is to crack passwords.
If choosing words, don't use any phrase — make sure the words are unrelated to each other. Even obscure phrases are easy to crack.
You are protecting two things: make your password hard to guess, and if one of you passwords get stolen (from this or another site) make sure that the attacker cannot use it for anything else.
Because password cracking is so easy, it is also a good idea to limit where users can log in from. Do you really need to log in to your site — without using a VPN — from a coffee shop in Vietnam?
How to secure your WordPress site
Hosting and SSL:
- Choose a reputable host that has a good security track record (ask them about guarantees they provide).
- Prefer a host that lets you install and fully manage WordPress and all its themes and plugins yourself — this way, you are fully in control of your WordPress site's security.
- Prefer a host that maintains the operating system, web server, and database server for you, and also does backups for you.
- Regularly check with your hosting provider to make sure they are staying up to date and running the latest versions of the operating system patches, web server, and database server for whatever distribution they use, and that they are not using a no-longer-supported distribution.
- Enable SSL (HTTPS) for both your site's login and admin pages.
- If you don't use SSL, your username and password will be sent across the network in clear text, and could be intercepted.
- Prefer a host that takes care of getting an SSL certificate for you, managing/renewing it, and configuring the web server for SSL so that all you have to do it enable it in WordPress.
Don't just select a host based on cost!
How to secure your WordPress site
Web server and filesystem:
- Block access to
wp-includes and wp-admin/includes
- Block access to
.htaccess files
- Block access to or remove
.txt files and README files.
- Set up a
robots.txt file to prevent well-behaved crawlers from trying to index feeds, admin pages, includes, etc.
- Make sure you never have any file or directory that is writable by anything other than the user that the web server runs as. (The last digit of permissions should always be 0, 4, or 5, never 6 or 7).
How to secure your WordPress site
Miscellaneous:
- Secure your database:
- When installing WordPress, choose a database table prefix other than
wp_.
- Remove the
test database.
- Remove anonymous database users.
- Make sure that the database is not accessible from the Internet.
- Enable file editing only when you need it to make changes to your themes. The rest of the time, keep it turned off by having the following line in
wp-config.php:
define('DISALLOW_FILE_EDIT', true);
Scan your site with WPScan.
Turning on DISALLOW_FILE_EDIT may be a little paranoid.
What to do if your site gets compromised
- Take the site offline (put it into maintenance mode). This prevents the attacker from doing further damage or resisting your attempts to regain control while you are fixing things.
- Notify your hosting provider so they can help.
- Make a backup of the compromised site in case you need to study it later.
- Look at the web server log files to determine how the attacker got in. This will help you know how to fix the problem and what else you might need to look for that the attacker did.
- Upgrade everything that can be upgraded.
- Remove any files, pages, posts, comments or processes added by the attacker. If in doubt as to whether you got everything, set up a new WordPress site from scratch and then restore your last known good backup into it.
- Change all passwords used by the site. Also change your hosting provider and database passwords.
How to minimize the severity of a compromise
- Don't have registered WordPress users for anything except for author and administrator accounts. Use social media accounts for commenters.
- Don't deal in sensitive information on your site (credit cards, social security numbers, health information, etc.)
- Set up automatic daily backups (of both files and database) and test the backups monthly.
- Keep good notes on how you've set up your site, so that you know how everything is supposed to be configured.
- Have a plan for what to do if you get compromised — who to contact, what to do, how to do it.
Not using WordPress accounts for commenters removes a large trove of what are very probably horribly weak passwords associated with email addresses.
Keeping good notes serves several purposes: first, you'll have a record of how things are supposed to be, so you'll be able to tell if an attacker changed something; second, you'll be able to set up a new site with the same settings if needed without worrying if you got everything correct; third, it forces you to be more aware of the choices you've made and you'll have a clearer understanding of the big picture for your site.
References
If you want to know about vulnerabilities and how attackers exploit them, the OWASP Top 10 list (above) is a good place to start.
Also of interest for advanced readers is the analysis of the PHP object serialization vulnerability that was one of the major vulnerabilities fixed in the September 2013 release of WordPress 3.6.1:
Questions?
