Sometimes you eat the code, and sometimes the code eats you. Here’s a short timeline of this morning in an apparent WordPress zero day attack.
About 5 AM to 5:50 AM. I was online with one my sites, responding to comments and updating my FAQ page on the upcoming SY0-501 Security+ Study Guide (Woo Hoo! Kindle version now live!).
About 6 AM. the site went down, giving this error:
“Your PHP installation appears to be missing the MySQL extension.”
About 6:10 AM. An alert user sent me an email asking if I was hacked by a PHP WordPress Zero-Day attack. He pointed me to few posts describing the attack.
Hackers Exploit WordPress Zero-Days in the Wild to Take Over Vulnerable Sites
Three WordPress Plugin Zero-Days Exploited in the Wild
3 vulnerable WordPress plugins affecting 21,000 websites
Plug-ins Impacted by this WordPress Zero Day Attack
The three reported plug-ins affected by this attack are:
- Appointments by WPMU Dev (fixed in version 2.2.2)
- Flickr Gallery by Dan Coulter (fixed in version 1.5.3)
- RegistrationMagic-Custom Registration Forms by CMSHelpLive (fixed in version 184.108.40.206)
If you’re using one of these, make sure they’re kept up to date.
However, I don’t have any of these plug-ins and I’m aggressive at keeping WordPress and the plug-ins up-to-date.
Great Support from Liquid Web
I rent a couple of servers from Liquid Web and typically receive awesome support when an issue pops up. Gratefully, their techs once again provided awesome support.
After opening a ticket with them at about 6:15 AM, they successfully restored the site within about an hour.
Here’s what they discovered:
- The php.ini file was modified. It is not known how it was modified.
- The modification caused the site to look for deprecated PHP extensions.
- Removing the php.ini file resolved the problem.
- Looking at the php.ini file, the techs discovered two additional lines.
extension_dir = “/usr/local/…
They commented out the lines by adding a semi colon at the beginning of each and restored the php.ini file to its original location.
;extension_dir = “/usr/local/…
Note: I’m not showing the full line to avoid giving an attacker the code to cause a problem. However, if you have this problem, you can search your php.ini file for lines starting with the same text and comment them out to see if it resolves it for you.
Was This A Zero-Day Exploit?
Unfortunately, I don’t know what made this change. It might have been an exploit from an attacker. It’s also possible that an errant script for the server control panel made this change.
You can bet that I’ll be up before 6 AM tomorrow morning to ensure the site is operational both before 6 Am and after 6 AM.
Wordfence Aware of Zero-Day Exploit
Wordfence, a WordPress security plug-in, was aware of the exploit and wrote about it on October 2. It also mentioned that they pushed out new rules to the web application firewall (WAF), which would protect systems.
The affected site does have the premium version of Wordfence and has the firewall enabled. Normally. However, when the site was operational again, it showed a prominent message indicating the firewall should be enabled.
I’d like to say that the prominent message wasn’t there when I working on the site from 5 AM to 5:50 AM. Unfortunately, I can’t claim 100 percent awareness at that time.