This week the Australian government released an advisory focused on a Chinese hacking campaign, which includes a couple of case studies looking in to successful hacks. The information in the advisory provides some valuable insights for those looking to better protect WordPress websites even if they are not facing threats from a nation state.

The hacking campaign involves a group the advisory states “conduct malicious cyber operations for the [People’s Republic of China] Ministry of State Security (MSS)”, which they refer to as “APT40” and those in the security industry refer to as “Kryptonite Panda, GINGHAM TYPHOON, Leviathan and Bronze Mohawk.” (Some of those names by the security industry don’t make the industry seem all that credible.) While the average WordPress website is highly unlikely to be targeted by a group like this, elements of the hacks happen to average WordPress websites on a daily basis. One element highlighted a significant limitation of a security solution sometimes implemented on WordPress websites.

There are four areas that stood out to us as being useful to highlight for those securing WordPress websites.

Logging

Anyone that properly deals with hacked websites (which isn’t true of many security providers, unfortunately) has run into an issue that was noted in the advisory, limits on what information you can gather about a successful hack due to incomplete logging:

During ASD’s ACSC investigations, a common issue that reduces the effectiveness and speed of investigative efforts is a lack of comprehensive and historical logging information across a number of areas including web server request logs, Windows event logs and internet proxy logs.

For those looking to improve the security of WordPress websites, there are a couple of logs that you should have access to months of data. The first is one mentioned in the quote, web server request logs, which show requests to the website. The other is logging for remote file access, usually FTP or SFTP. You may want to move to a new web host if they don’t provide those, especially the web server request logs, as without those, you have very little to go on in the case of a hack.

Other server logging could be useful as well. For example, having logging of all access to cPanel or a similar control panel.

To have wider insight in to what is going on, you can look into using a plugin that logs activity being made by those logged in to WordPress. Though, you want to make sure that the plugin is not introducing any security issues of its own (that isn’t a theoretical issue).

While it is possible that an attacker can edit logs if they are stored in a way that is accessible to the hacker, that doesn’t seem to be something that the types of attackers of WordPress websites are bothering to do. But having logging store to a separate location can help if that were to happen.

Arbitrary File Upload Vulnerabilities

With the first case study, the advisory suggests the start of the hack came through a common source of hacking of WordPress websites, an arbitrary file upload vulnerability:

Much of the compromise was facilitated by the group’s establishment of multiple access vectors into the network, the network having a flat structure, and the use of insecure internally developed software that could be manipulated to perform arbitrary file upload.

The best solution to avoid that type of vulnerability is making sure that file upload functionality is properly secured. If you are using WordPress plugins that have file upload capability, those should be checked for that.

Another approach that can stop a lot of those is a well-developed firewall plugin that can limit what types of files can be sent with a request to the website, while not limiting things it shouldn’t. With our own Plugin Vulnerabilities Firewall, by default it restricts the types of files that can be sent to those normally allowed by WordPress unless the request is coming from an Administrator. A more restrictive option to limit any files from those that are not logged in to WordPress with the upload_files capability is available for websites that don’t intend for others to be able to upload files.

The advisory suggests using “well-tuned Web application firewalls (WAFs) to protect web servers and applications,” but because WAFs operate separately from software on a website, they are not able to provide fine grade control on file uploads as a firewall plugin can.

IP Address Based Blocking

One method to try to protect WordPress websites is by blocking IP addresses. One approach to do that is through country blocking. That approach falls flat when hackers launch attacks from infrastructure in the same country, as has with the group focused on :

Although APT40 has previously used compromised Australian websites as command and control (C2) hosts for its operations, the group have evolved this tradecraft (T1594).

Another approach is by trying to block individual IP addresses for known malicious activity. The problem with that is the breadth of IP addressees the attacker could be coming from because of the types of devices they can be sending requests from:

APT40 has embraced the global trend of using compromised devices, including small-office/home-office (SOHO) devices, as operational infrastructure and last-hop redirectors (T1584.008) for its operations in Australia.

Another problem with that approach is that you have to already be able to detect that there are malicious request coming from the IP, so you likely would be able to block the attacker directly that way.

With any IP blocking approach, the provider offering it should be able to provide evidence that it is an effective method of protection. That is something we have yet to see from any provider in the WordPress space. As should always be the case, security providers should be providing you with evidence of the effectiveness of their solution before you even consider using it.

Addressing Publicly Known Vulnerabilities

With the second case study, the advisory states the likely start of intrusion was due to publicly known vulnerabilities:

The group likely exploited RCE, privilege escalation, and authentication bypass vulnerabilities in the remote access login and identity management product to gain initial access to the network.

This initial access method is considered the most likely due to the following:

• The server was vulnerable to these CVEs at the time;
• Attempts to exploit these vulnerabilities from known actor; and
• The first known internal malicious activity occurred shortly after attempted exploitation attempts were made.

The report doesn’t provide more detail on what those vulnerabilities were, but in most cases, there should already be a fix available before vulnerabilities are exploited. So, as has long been suggested, it is important to keep software up to date.

While there usually should be a fix available, that doesn’t mean the fix works. We often find that vulnerabilities in WordPress plugins haven’t actually been fully fixed and in some cases the “fix” doesn’t fix anything. That is where getting properly vetted information on vulnerabilities in WordPress plugins can help to improve security.

Unfortunately, based on extensive reviewing of claims from other providers that vulnerabilities have been fixed and finding them to be wrong, we are currently the only ones doing that. Other original sources that are not reliable include Patchstack, Wordfence, and WPScan. Many other sources rely on their data, sometimes without disclosing that is the source, and certainly not warning about the unreliability of the data. Our new Plugin Security Scorecard warns about security plugins that are known to be using unreliable sources of data on plugin vulnerabilities.