WordPress Exploit – AMP Plugin

AMP for WP -Accelerated Mobile Pages allows your site to be faster for mobile visitors. Along with last week’s report, the AMP plugin has also been added to the list exploited. The AMP for WP plugin was reported on October 20, 2018, by its developers. Luckily, the newest version,, of this plugin has patched for their known security flaws. This exploit has the means of putting 100,000+ users at potential risk, so its best to check if you are utilizing this plugin. In this tutorial, we will be checking if you use this plugin. Along with updating, we will also show you how to check if your site for compromises.

In the vein of the WP GDPR plugin exploit, the AMP hack allows code vulnerability to make site-wide changes. Bots scan for sites using the AMP plugin and use an XSS security bug to create a new user that has admin-like privileges. The vulnerable versions’ (below code didn’t cross check to see if registered users had the permissions to perform some actions. With administrative like privileges a hacker can hide their code within your WordPress files to use to take over your website. Additionally, they can upload files, update plugins, read files, and inject posts.

Identify If You Use AMP for WP

By logging into your WordPress backend you can easily see if you are subject to this exploit.

Step 1: Enter the WordPress backend by going to yourdomain.com/wp-login.php in your browser.
Step 2: Login with your WordPress username and password and navigate to Plugins and click on Installed Plugins on the left-hand side of your screen.
Step 3: Scroll down through any installed plugins to see if you have Accelerated Mobile Pages within your list, followed by its version. Any version below is still vulnerable and you’ll have to perform a few actions to protect yourself.
The Plugins section in WordPress will allow you to see if you are utilizing AMP.

Upgrade AMP – Accelerated Mobile Pages

Note: It’s recommended to backup your website before pushing any updates.

Step 1: Follow the steps above in the section “Identify If You Use AMP for WP” to login and locate your Plugins menu.

Step 2: Locate Accelerated Mobile Pages. If you are running an outdated version you’ll see a message providing you a link to update. Click “update now” to automatically update to the latest version.


In the WordPress backend click the "update now" link to protect yourself from the AMP hack.

Have You Been Hacked?

A site hack is possible even without noticing any visual differences to your site. For a closer inspection below are some of the characteristics of the AMP exploit.

  • Characteristics of the AMP hack:
  • External Calls to sslapis.com
  • New creation of WordPress admin user “supportuuser”
  • Post injections
  • Registered user can manipulate code
  • Code vulnerability in ajax hooks
    • ampforwp_save_steps_data
    • wp_ajax_ampforwp_get_licence_activate_update
    • wp_ajax_ampforwp_deactivate_license
    • wp_ajax_ampforwp_save_installer
    • wp_ajax_amppb_export_layout_data
    • wp_ajax_amppb_save_layout_data
    • wp_ajax_ampforwp_get_image

If have identified your site is compromised from above characteristics, you’ll want to remedy it immediately since other sites on the same server can potentially be affected.

  • Liquid Web customer can purchase a Malware Clean Up package
  • Manually remove the code from the infected files
  • Restore from a backup dated before October 20, 2018 (keep in mind this will still have the old version and your site will still be in danger).

As time goes by, more plugins will give way to more vulnerabilities but there are some proactive steps to ensure your site’s security. For insight into ways of protecting your WordPress site look into our article on the subject, The Best Ways to Protect Your WordPress Site.


Protecting against CVE-2018-14634 (Mutagen Astronomy)

There is a new exploit, rated as 7.8 severity level,  that affects major Linux distributions of RedHat Enterprise Linux, Debian 8 and CentOS named Mutagen Astronomy. Mutagen Astronomy exploits an integer overflow vulnerability in the Linux kernel and supplies root access (admin privileges) to unauthorized users on the intended server. This exploit affects Linux kernel version dating back from July 2007 to July 2017.  Living in the kernel, the memory table can be manipulated to overflow using the create_tables_elf() function. After overwhelming the server, the hacker can then overtake the server with its malicious intents.

As mentioned this vulnerability is present in RedHat, Debian 8 (Debian 9 are not vulnerable), and CentOS 6 and 7 but its limited to affecting only 64-bit versions. The 32-bit versions do not have the address space to overwhelm the server and thus no patch is needed.  Along with 64-bit versions, the exploit is limited to Linux kernel versions 2.6.x, 3.10.x, and 4.14.x. (Read our article How To Check the Kernel Version to see which version you are running)  Proof of concept reported on August 31, 2018, and remediation from a one-year-old patch was backported to most LTS (long-term support) kernels, CentOS and Debian 8 remain vulnerable. Luckily, patches CentOS 6 /7 and RHEL 7 are below but the world waits for RHEL 6 and Debian 8 remedy.  Check back here for updates as they become available.


CentOS 6 and 7 Patch for Mutagen Astronomy

Step 1: Utilizing SystemTap.

Use SystemTap to extract, filter and summarize data to diagnosis performance or functional problems.

yum install systemtap systemtap-runtime

Step 2: Create a File

Using your preferred text editor create a file name mutagenastronomypatch.stp and copy and paste the following info:

// CVE-2018-14634
// Theory of operations: adjust the thread's # rlimit-in-effect around
// calls to the vulnerable get_arg_page() function so as to encompass
// the newly required _STK_LIM / 4 * 3 maximum.
// Complication: the rlimit is stored in a current-> structure that
// is shared across the threads of the process. They may concurrently
// invoke this operation.
function clamp_stack_rlim_cur:long ()
struct rlimit *rlim = current->signal->rlim;
unsigned long rlim_cur = READ_ONCE(rlim[RLIMIT_STACK].rlim_cur);
unsigned long limit = _STK_LIM / 4 * 3;
limit *= 4; // multiply it back up, to the scale used by rlim_cur
if (rlim_cur > limit) {
WRITE_ONCE(rlim[RLIMIT_STACK].rlim_cur, limit);
} else
probe kernel.function("copy_strings").call
l = clamp_stack_rlim_cur()
if (l)
printf("lowered process %s(%d) STACK rlim_cur to %p\n",
execname(), pid(), l)
probe begin {
printf("CVE-2018-14634 mitigation loaded\n")
probe end {
printf("CVE-2018-14634 mitigation unloaded\n")
Step 3: Run the Script

Lastly, execute the newly created script:

stap -g mutagenastronomypatch.stp

RHEL 7 Patch for Mutagen Astronomy

Step 1: Log in to your CentOS server

ssh root@ip

Step 2: Yum Updates to the Kernel

yum update kernel



Protecting Against CVE-2016-3714 (ImageMagick)


A security vulnerability has been discovered in the ImageMagick software suite that can potentially allow remote code execution.


All versions of ImageMagick are affected. An updated version has been committed and should be rolling out to repositories in the near future. Until a patch is available for all systems, Liquid Web is taking steps to block the offending payloads. Additionally, a direct modification to ImageMagick’s policy file can reduce the risk of an exploit due to the vulnerability.


A full resolution is not possible until a patch is released and applied. While that is anticipated to be available soon, in the interim, policies specifically blocking known exploits can be added directly to ImageMagick’s policy file, policy.xml. The file will be located in one of two possible directories, depending on how the software was installed:

  • /etc/ImageMagick/policy.xml
  • /usr/local/etc/ImageMagick-6/policy.xml

Once located, open policy.xml in your preferred text editor and add the following nine lines to the bottom of the file to help minimize the risks of exploit:

<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="coder" rights="none" pattern="TEXT" />
<policy domain="coder" rights="none" pattern="SHOW" />
<policy domain="coder" rights="none" pattern="WIN" />
<policy domain="coder" rights="none" pattern="PLT" />
<policy domain="path" rights="none" pattern="@*" />

Note: This post has been updated to reflect policies for four additional coders identified as potentially vulnerable, and one that prevents indirect reads entirely. ImageMagick still should be upgraded when the latest release is made available even if the policy file has been manually edited.

Managed customers who need help editing the policy file may contact Heroic Support® for assistance.

How To Protect Your cPanel Server Against CVE-2016-1531


On March 2, Exim announced via its mailing list that it had discovered a vulnerability in all versions of its mail transport agent. Exim is the default MTA on cPanel servers. The latest version patches the vulnerability, and the latest cPanel update resolves the issue.


Exim says that all installations of its MTA were vulnerable to a condition in which an attacker with any level of privileges on the server could gain root privileges. The versions of cPanel & WHM listed below are protected against the attack on Exim. Any version prior to the current versions listed below are vulnerable:

  • 54.0.18
  • 55.9999.106 (EDGE tier only)

Is Exim Vulnerable on Your Server?

If your cPanel server has automatic updates enabled, then the patch will already have been applied.

You can confirm that your server is protected simply by logging into WHM and checking the version listed at the top of the screen, as shown in the image below:

Check WHM version

Note: the “build” listed after the version represents the final digits in the release version. In the example above, WHM 54.0 (build 18) indicates that the version is 54.0.18.


If you are not already on the latest version of cPanel, follow these instructions to enable automatic updates. Once you click the Save button to change your settings, you will have the option to update the server to the latest version immediately by clicking the link in the confirmation message as shown below:



Is Your cPanel Server Protected Against CVE-2016-0800 (DROWN)?


A new flaw has been found in the Secure Sockets Layer version 2.0 (SSLv2) protocol. An attacker could theoretically exploit this vulnerability to bypass RSA encryption, even when connecting via a newer protocol version, if the server also supports the older SSLv2 standard.


As a result of several similar but unrelated vulnerabilities, including POODLE, most server administrators already have removed support for SSLv2 and other weak ciphers. For instance, cPanel removed SSLv2 support on core services by default beginning with version 11.44 in 2014.

Servers running older, End-of-Life operating systems may still support SSLv2.

Test: Does Your Server Support SSLv2?

To test whether your web server supports SSLv2, you can run this command from a terminal on a Linux or Mac OS X, substituting your domain name for the example below:

openssl s_client -connect www.yourdomainname.com:443 -ssl2

If the server is not vulnerable, the output of that command should include “ssl handshake failed” as seen in the example below. Note that your output will be different, but as long as you see ssl handshake failed somewhere in the output, you’re protected:

[root@host]# openssl s_client -connect www.yourdomainname.com:443 -ssl2
95090:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s2_pkt.c:427:

You can test SSLv2 support on other services by substituting the secure http port (443 in the command above), with the appropriate port for the service you’re testing (note that these are the default ports; if you’ve changed the port a service runs on, you’ll want to use that value):

  • WHM: 2087
  • cPanel: 2083
  • Secure SMTP (Exim): 465
  • Secure IMAP: 993
  • Secure POP3: 995
  • Secure Webmail: 2096
  • Secure WebDisk: 2078

If you’re using a different operating system or are otherwise unable to check the server directly, you also may visit a test site such as drownattack.com and enter your site’s URL into the test field.

If your server fails any of the tests listed above and you’re not able to update cPanel to the latest version, feel free to contact Heroic Support® for assistance.

Protecting Against CVE-2015-7547


The Google Security Team and Red Hat have discovered a flaw in the way that certain types of DNS lookups are handled on some Linux servers. By exploiting this critical vulnerability, an attacker could gain full control over the system.

Liquid Web is proactively ensuring that all Managed servers are patched, and will be notifying customers directly of the relevant details. As long as we’re able to access the server, no further action should be required on your part. If you’re not certain whether we have your server’s current password on file, you may wish to update your server password in Manage, and you also may wish to check that automatic operating system package updates are enabled in cPanel/WHM.

Managed Liquid Web customers may, depending on notification preferences, receive a cPanel notice referring to “Altered RPMs” after the patch is applied. This notification indicates that operating system packages have been updated outside of cPanel, and in this case is no cause for alarm. While the subject of the message may sound ominous, it is not related to the vulnerability itself. Rather, the notice is a result of the fact that the server’s operating system packages were upgraded. For more information, you may refer to Altered RPMs. If you need further assistance, feel free to contact Heroic Support®.

Liquid Web customers with self-managed servers will want to follow the instructions in this article to determine whether their server is vulnerable and to upgrade their operating system packages.


The code that causes the vulnerability was introduced in a 2008 update to the GNU C Library (glibc). That package contains a library against which all GNU/Linux programs are linked, and the flaw affects the version of glibc included in a number of current Linux distributions:

  • Red Hat Enterprise Linux 6 and 7
  • CentOS 6 and 7
  • Fedora 22 and 23
  • Ubuntu 12.04 LTS, 14.04 LTS, and 15.10
  • Debian 6 (squeeze), 7 (wheezy), and 8 (jessie)


On affected servers, glibc needs to be updated and the server rebooted. Managed Liquid Web customers do not need to take any action: All managed servers will be updated and rebooted as outlined in the notification sent to customers. Only self-managed servers will need to be manually updated and rebooted.

Step #1: Check the Current glibc Version

  1. On CentOS 6 and CentOS 7 servers, run:

    yum list glibc

    That will produce output similar to:

    [root@host ~]# yum list glibc
    Installed Packages
    glibc.x86_64     2.17-106.el7_2.1     @system-updates-released
    Available Packages
    glibc.i686     2.17-106.el7_2.1     system-updates-released

    The currently installed version is listed under Installed Packages.

  2. On Fedora 22 and Fedora 23 servers, run:

    dnf list glibc

    That will produce output similar to:

    [root@host ~]# dnf list glibc
    Installed Packages
    glibc.x86_64     2.21-5.fc22     @System
    Available Packages
    glibc.i686     2.21-5.fc22     fedora

    The currently installed version is listed under Installed Packages.

  3. On Debian (6, 7, and 8) and Ubuntu (12.04 LTS, 14.04 LTS, 15.10) servers, run:

    ldd --version

    That will produce output similar to:

    [root@host ~]# ldd --version
    ldd (Ubuntu EGLIBC 2.21-0ubuntu4.1) 2.19
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    Written by Roland McGrath and Ulrich Drepper.

    The currently installed version in this example is 2.21-0ubuntu4.1.

Step #2: Is the Installed Version Vulnerable?

If the version returned by the command you ran above matches (or exceeds) the version listed below for your operating system, then the vulnerability already has been patched:

  • Patched versions:
  • CentOS 6: glibc-2.12-1.166.el6_7.7
  • CentOS 7: glibc-2.17-106.el7_2.4
  • Fedora 22: glibc-2.21-11.fc22
  • Fedora 23: glibc-2.22-9.fc23
  • Debian 6 (squeeze): eglibc 2.11.3-4+deb6u11
  • Debian 7 (wheezy): eglibc 2.13-38+deb7u10
  • Debian 8 (jessie): glibc 2.19-18+deb8u3
  • Ubuntu 15.10: libc6 2.21-0ubuntu4.1
  • Ubuntu 14.04 LTS: libc6 2.19-0ubuntu6.7
  • Ubuntu 12.04 LTS: libc6 2.15-0ubuntu10.13

If the version returned by the command you ran in Step 1 is lower than what’s listed above for your operating system — and you have a self-managed server — you will need to proceed to Step 3 to upgrade and reboot.

Step #3: Update glibc on a Self-Managed Server

The update only needs to be applied manually on self-managed servers. If you have a self-managed server, you can run these commands as root to update and reboot:

  1. On Debian (6, 7, and 8) and Ubuntu (12.04 LTS, 14.04 LTS, 15.10) servers:
    apt-get update
    apt-get dist-upgrade

  2. On CentOS 6 and CentOS 7 servers:
    yum clean all
    yum update glibc

  3. On Fedora 22 and Fedora 23 servers:
    dnf clean all
    dnf update

Note: Please remember that following these steps, you must reboot the server in order for the update to take effect and ensure you’ve been secured. If you need assistance with this, feel free to consult Checklist Prior to Reboot and How to Reboot via Liquid Web Management Interface.


Protecting Against CVE-2016-0728


A critical vulnerability in the Linux kernel was announced on Jan. 14, 2016, by security researchers at Perception Point. The vulnerability has existed since 2012, and is present in all devices running version 3.8 of the Linux kernel and higher.


The Linux kernel above version 3.8 is affected by CVE-2016-0728, including computers, servers, and mobile devices using the following operating systems:


  • Red Hat Enterprise Linux 7
  • CentOS Linux 7
  • Scientific Linux 7
  • Debian Linux stable 8.x (jessie), and testing 9.x (stretch)
  • SUSE Linux Enterprise Desktop, Server and Workstation Extension 12 and 12 SP1
  • Ubuntu Linux 14.04 LTS (Trusty Tahr), 15.04 (Vivid Vervet), and 15.10 (Wily Werewolf)
  • Opensuse Linux LEAP 42.x and version 13.x
  • Oracle Linux 7


  • Devices running an Android version below 4.4 (KitKat)

A patch for the Linux kernel is available now and may already have been applied to managed servers. Google, which still is investigating the vulnerability on Android devices and believes the scope may be overstated, has issued a patch to its partners.


On a server running a version of the Linux kernel above 3.8, a user with any level of access could exploit the vulnerability to execute code as root. The researchers noted that a malicious app on an Android device could do the same thing, although possibly with more difficulty.

The researchers found that a reference leak in the mechanism that encrypts and stores credentials and other security data for use by applications can be used in what’s referred to as a “use after free” exploit.

At this time, neither the researchers who discovered the vulnerability nor Red Hat have detected any sign of the vulnerability currently being exploited in the wild.

Is Your Server Affected?

If the Linux kernel on your server already has been patched due to proactive measures by your web host or a service such as KernelCare, the changelog will include reference to CVE-2016-0728.

Servers equipped with KernelCare

Many managed Liquid Web servers are equipped with KernelCare. To check whether the patch already has been applied, run this command:

kcarectl --patch-info | grep CVE-2016-0728

That should produce output similar to the following:

kcarectl --patch-info | grep CVE-2016-0728
kpatch-cve: CVE-2016-0728
kpatch-cve-url: https://access.redhat.com/security/cve/CVE-2016-0728

Servers without KernelCare

A server which does not have KernelCare installed will output “command not found” when running the “kcarectl” command above. If that is the case, then you will need to check the kernel changelog for a reference to the CVE to know whether it’s been patched. On a CentOS or Red Hat server that does not have KernelCare, you can check with the command:

rpm -qa --changelog kernel|grep CVE-2016-0728

Note that servers with KernelCare will not display any output using the above command. As long as the expected output is present following the first command, the kernel has been patched.


To apply the patch, you will need to update the kernel and reboot the server for the patch to be applied.

You can use the instructions in our Knowledge Base to update the kernel on CentOS and Red Hat servers, and you can follow these instructions to reboot your server following the update.

Note: Your server will need to be rebooted following the kernel update in order for the patch to be applied.

If you need any assistance or prefer to schedule the server’s reboot for a specific time, please do not hesitate to contact Heroic Support®.


cPanel TSR-2016-0001


On January 18, 2016, cPanel announced that it had discovered vulnerabilities affecting all current versions of its control panel software. At the time of the announcement, cPanel issued a Targeted Security Release for each software tier, which the company said addresses 20 vulnerabilities in cPanel and WHM.

Because the issues were discovered internally by cPanel, and cPanel does not believe that there are any exploits of the vulnerabilities in the wild, they are not yet releasing any additional information on the exact nature of the issues. The company will allow sufficient time for potentially vulnerable servers to be updated before providing additional information.


    • All servers running a version of cPanel/WHM lower than the versions indicated below are affected. All servers running a version of cPanel/WHM equal to or greater than those below are not affected:
      • 54.0.4 (WHM 54.0 build 4) on the CURRENT and EDGE Tiers
      • (WHM 11.52.2 build 4) on the STABLE and RELEASE Tiers
      • (WHM 11.50.4 build 3) and (WHM 11.48.5 build 2) on the Long-Term Support (LTS) Tiers
    • There are no known “in the wild” exploits of the cPanel vulnerabilities at this time.
    • cPanel’s regular update process automatically will download and apply the appropriate new software version for your chosen tier, addressing all known vulnerabilities.


If your cPanel server is configured to automatically check for updates, no action is required on your part, and the patch automatically will be applied at the server’s next check. If you have disabled automatic updates, you can follow the instructions in our tutorial, How To Upgrade and Patch cPanel to manually update cPanel. If you require any assistance, please contact Heroic Support®.

Is Your Server Affected?

To determine whether your cPanel server already has had the patch applied, you need only to log into WebHost Manager and check the version number, which is located at the top-center of every page in WHM:


In this example, on a server set to the CURRENT release tier, you can see that the cPanel/WHM version is 54.0.4 (54.0 build 4), and thus is not vulnerable. If you are on a different release tier (LTS, STABLE, RELEASE, or EDGE), you will need to check your version against the list above.

Note: cPanel dropped the “11” from its cPanel/WHM version number beginning with 54 (which would have been 11.54). You still may see the current version referred to as both “54” and “11.54” in different places in the cPanel/WHM interface as the change in version numbering populates throughout the user interface.


The latest version of cPanel, 54.0.4 (54.0 build 4), is patched against the vulnerability. An upgrade to the current release version of cPanel/WHM will address the vulnerabilities and resolve the issues discovered by cPanel.

To upgrade, follow the instructions in our tutorial, How To Upgrade and Patch cPanel. If you require any assistance in verifying your current version or manually updating cPanel, please contact Heroic Support®.

To check or change your current cPanel release tier, or ensure that automatic updates are enabled, click on “Update Preferences” in WHM’s left menu:


After changing any settings, click the “Save” button at the bottom of the page to apply them.



Protecting Against CVE-2016-0777 and CVE-2016-0778


A flaw in OpenSSH, discovered and reported by Qualys on Jan. 14, 2016, could potentially allow an information leak (CVE-2016-0777) or buffer overflow (CVE-2016-0778) via the OpenSSH client. Specifically, an undocumented feature called roaming, introduced in OpenSSH version 5.4, can be exploited to expose a client’s private SSH key.


The roaming feature, which allows clients to reconnect to the server automatically should the connection drop (on servers supporting the feature), can be exploited in the default configuration of OpenSSH clients from versions 5.4 through 7.1p1, but is not supported in the default configuration of the OpenSSH server.

All versions of OpenSSH clients from 5.4 through 7.1p1 are affected for anyone who connects via SSH on the following operating systems:

  • Linux
  • FreeBSD
  • Mac OS X
  • Windows when using OpenSSH for Windows

The following are not affected:

  • OpenSSH servers in default configuration
  • Windows users utilizing PuTTY to connect
  • Connections not authenticated via an SSH key


A connection made from an affected client to a compromised or malicious server which uses an SSH key for authentication potentially could expose all or part of the user’s private SSH key.

If the key utilized to authenticate the connection is encrypted, only the encrypted private key could be exposed. However, a malicious party could attempt to brute-force the password offline after obtaining the encrypted key.

Is Your SSH Client Vulnerable?

You can check the version of your SSH client by running the following command:

ssh -V

That will produce output similar to:

workstation$ $ ssh -V
OpenSSH_7.1p2, OpenSSL 1.0.2e 3 Dec 2015

If the version is below 7.1p2, the SSH client is affected.


  1. Update your OpenSSL client: Check for any updates to your SSH client and apply them immediately.
  2. Patch older clients: If an update is not yet available for your operating system, you may disable the roaming feature on affected clients by adding the line “UseRoaming no” to your ssh configuration file. You can do so directly or via one of the methods below:
    • On Linux, you can run the following command to add the necessary line:echo 'UseRoaming no' | sudo tee --append /etc/ssh/ssh_config

      And restart ssh.

    • On a Mac running OS X, you can run the command:echo "UseRoaming no" >> ~/.ssh/config

      You will need to close any active SSH sessions or log out and log back in to ensure the change has taken effect.

  3. Change existing SSH keys: If you’re using keys to authenticate SSH connections, you should generate new keys as soon as possible. You can find instructions for generating a key and uploading it to your server at: Using SSH Keys. Please note: If you currently are using the same key to connect to multiple servers, you may wish to consider using unique keys in the future in light of the potential scope of this vulnerability. You also should ensure you are using a strong passphrase for any key you generate.


Protecting Joomla Sites Against CVE-2015-8562


Joomla’s latest update addresses a critical remote command-execution vulnerability that has been actively exploited in the wild since at least Dec. 12, 2015.


The vulnerability affects every version of Joomla from 1.5 to 3.4.5, and Sucuri reported that nearly every site they checked had been targeted when Joomla 3.4.6 was released to address the issue.


  • CVE-2015-8562 was made public Dec. 12, 2015.
  • The vulnerability allows an attacker to remotely execute commands by exploiting Joomla’s method of writing session data to its database.
  • Every version of Joomla from 1.5 to 3.4.5 is vulnerable.
  • Joomla 3.4.6 has been released to address the vulnerability, and patches have been released for unsupported versions of the software.

As first reported by Sucuri, the vulnerability allows an attacker to exploit the way session data is processed before it’s stored in the database. In several reported cases, a php shell installed via the exploit has been used to modify core files, with one result being unwanted email (spam) being sent from the server.

In line with Sucuri’s findings, we also noticed these attacks shortly after the updates were announced by the Joomla team. On a sample set of servers, we noted about 10 attack attempts per server by Dec 15. As of 2 p.m. on Dec. 16, that number was more than 50 attempts per server, and likely to keep increasing as attackers continue their efforts.

Liquid Web’s Fully Managed cPanel servers include our ServerSecure package by default, and were protected against various versions of this exploit by our ModSecurity rules. While this certainly is good news, it is not a reason to put off updating your software to the latest version.

Has Your Joomla Site Been Targeted?

To check whether your site was targeted by this attack, you can search for a specific string in your domain access logs.

  • On a cPanel server, the access logs for each domain are stored in /home/accountname/logs and /home/accountname/access-logs.
  • Alternately, the most recent logs for all domains on the server should be in the directory /usr/local/apache/domlogs/.

Once you have located the relevant log files, you can use the grep command to check them. For example, this command checks for attempts to exploit the Joomla vulnerability on sites under the cPanel account joe over the last day:

egrep -H '}__|JDatabaseDriverMysql' /home/joe/access-logs/*

And this command checks for exploit attempts on any of joe’s site logs older than 24 hours, if available:

zgrep -E -H '}__|JDatabaseDriverMysql' /home/joe/logs/*

If any log entries are returned, then you’ll know your site has been targeted. Assuming that Joomla actually is installed on the targeted site, you should check for any recently updated files in the installation or scan it with a tool such as ClamAV or Linux Malware Detect (maldet).

Was Your Joomla Site Protected?

If your site was targeted and you are a Liquid Web customer, you can take the IP address(es) from the log output you found above and check them against Apache’s error_log to see whether the requests were blocked by ModSecurity. In this sample command, we’re checking the IP address

grep /usr/local/apache/logs/error_log

If the requests from that IP address were blocked, you will see a log entry containing something like:

[Tue Dec 15 23:20:25 2015] [error] [client] ModSecurity: Access denied ...

If the log does show that ModSecurity blocked the requests, it is likely your site was not able to be breached. However, regardless of the result, you should proceed with updating your site as soon as possible.

Resolution: Update or Patch Your Joomla Site

The process for protecting your Joomla site against the remote command-execution vulnerability depends on your Joomla version. You can check the current version by logging into your Administration panel. If the version number is not displayed at the bottom of the page in the footer, select Joomla! Update from the Components menu to see your current version.

Joomla 3 Sites Require an Update

If you have not done so already, back up your site and the site database now before proceeding, or check your automated backup solution to ensure that you have a recent backup from which you would be comfortable restoring the site if necessary.

  1. Log into your Administration panel.
  2. You should see a banner indicating that version 3.4.6 is available. If so, and if you have backed up your site and the site database, click the Update Now button to update to the latest version.Joomla Update Available
  3. On the Update page, you are reminded to ensure that your installed extensions are available for the version you’re updating to. Once you have verified that, and have confirmed that you have a backup of the working site, click Install the Update to update Joomla.Install Joomla Update
  4. Once complete, you will see a success page.
  5. Now select Joomla! Update from the Components menu to confirm that you are on version 3.4.6 (occasionally, the update can sometimes fail to reflect the new version in the Update Success confirmation message).

Joomla 1.5 and 2.5 Sites Require a Patch

Users on unsupported versions are encouraged to consult with their developers about migrating to Joomla 3 so that they can receive all security updates.

However, due to the nature of this exploit, Joomla has chosen to make patches available for Joomla versions 1.5 and 2.5 to address this specific issue. The patches can be downloaded directly from Joomla at https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions. Applying the patch is as simple as replacing the existing session.php file which is included in the download.

It’s important to note that Joomla’s decision to release patches for unsupported versions of its software in this specific case is due only to the scope and impact of the current vulnerability, and does not mean that any future patches also will be released for legacy versions. Joomla continues to encourage users to migrate to the current version as soon as possible.

  1. Download the appropriate zip file for your Joomla version from https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions and unzip it. The extracted archive will contain three nested folders leading to a single file, session.php.
  2. Connect to your site via FTP, SFTP as the cPanel user, or SSH as the cPanel user and navigate to libraries/joomla/session inside your site’s document root to locate the existing session.php file.
    • On a cPanel server where www.yourdomainname.com loads the main Joomla site, the file would be located in the directory /home/accountusername/public_html/libraries/joomla/session.
    • On a cPanel server where www.yourdomainname.com/blog loads the main Joomla site, the file would be located in the directory /home/accountusername/public_html/blog/libraries/joomla/session.
  3. Now back up the existing session.php file on your server so that it can be restored if necessary. You can do that by simply renaming the existing session.php file on your server to something you’ll be able to remember later (you also could give the file a “.old” extension or add a period to the beginning of the file name.)
  4. To finish, upload the session.php file you downloaded from Joomla to replace the one you renamed, and check that it has the same ownership and permissions.FTP upload of new session.php file

    Note: If you uploaded the file while connected to the server as root, the file itself will be owned by root. You may need to change its ownership and group to match the other files in the directory.