WordPress is the most popular and easiest way to create your website or blog. WordPress is likely to power more than one-fourth of the websites you visit.
WordPress is an open-source content management system released under the GPLv2 license, which means that anybody can use or change the WordPress software for free. As a result, WordPress is much more prone to attacks and vulnerabilities.
In this blog, we’ll be looking at one of the recent supply chain attacks that hit WordPress.
What is the actual vulnerability?
AccessPress, a popular WordPress plugin, and theme author was recently compromised, and their software was replaced with backdoored versions, according to security researchers at Automattic. In other words, rather than physically compromising systems by exploiting vulnerable software components, attackers gained access to the very source that websites and network administrators use. By doing so the attackers gained access to almost all the systems that use the said plugins and themes.
How did this happen?
To better understand the vulnerability and how it is working, let's go ahead and replicate it in a controlled environment.
We will create a new Kubernetes cluster with default values.
Once the cluster is ready we’ll deploy the WordPress application with a vulnerable plugin to simulate the attack.
For this, we have created a complete YAML for WordPress installation on Kubernetes. You can use this predefined deployment file to quickly deploy WordPress to your Kubernetes environment.
With this, the initial setup is completed. It's time to upload the vulnerable plugin and dissect the attack pattern.
The Supply Chain Attack Tree
To explain the vulnerability, let's take a look at the root cause of this issue, the supply chain attack.
After gaining access to the AccessPress website, the attackers installed PHP backdoors in many of the group's free software components. There were 40 themes and 53 plugins that were known to be impacted.
The backdoor was simple, yet it gave the attackers complete access to the victim's web pages. The first thing they did was create a new file called initial.php in the main plugin directory, which they then included in the main function code.
We’ll use a slightly modified version of the exploit code to show the workflow.
Since this is etched into the source code of the plugin’s source code itself, it’ll execute the moment you download and activate the plugin.
This simple code created a new file in the plugin or theme folder respectively and started its execution by adding values to the
The malicious extensions featured a web shell dropper, giving the attackers complete access to the affected sites. The dropper can be found in the inital.php file in the plugin or theme's main directory. It creates a cookie-based web shell in wp-includes/vars.php when it is activated. The shell is installed as a function named
wp_is_mobile_fix() immediately before the
wp_is_mobile() function to avoid arousing suspicion even if someone casually browses the
The file also connects to a malicious URL to further receive queries and remove the dropper file once execution is completed to avoid traces.
Once the execution is completed you will notice that the
vars.php file now has an extra function
wp_is_mobile_fix() created by the dropper file.
Let's see this in action.
To replicate the issue, we will upload
You can download the vulnerable version from samples/WordPress-demo at main · accuknox/samples
Once uploaded and activated we will execute inside the WordPress pod to confirm the changes.
Alright! Now we will check for
vars.php. (Since the exploit deletes the initial.php once execution is completed it is highly unlikely to see the
initial.php file. But the file will be downloaded to
wordpress-root-folder/wp-content/themes/ accordingly.). It also downloads a PHP payload
acc.php which can cause RCE.
The exploit does its magic and installed a shell inside the
vars.php file. if the request's user agent string is
wp_is_mobile and contains eight specified cookies It assembles and runs a payload from the cookies provided.
An attacker can craft make use of this and send in crafted commands to get information or even escalate it into an RCE.
To see it in action let us get the IP of our WordPress pod
script.sh file has a bash reverse shellcode embedded in it. So once we go to this URL we’ll get a reverse shell connection established.
You can download the
script.sh file samples/wordpress-demo at main · accuknox/samples
Providing Run-time protection and defending against the vulnerability with AccuKnox Open-source tools
Accuknox enables the ability to protect your workloads at run-time. Accuknox enables this by allowing you to configure policies (or auto-discover them) for application and network behavior using KubeArmor, Cilium, and Auto Policy Discovery tools
KubeArmor, is open-source software that enables you to protect your cloud workload at run-time.
The problem that KubeArmor solves is that it can prevent cloud workloads from executing malicious activity at runtime. Malicious activity can be any activity that the workload was not designed for or is not supposed to do.
Given a policy, KubeArmor can restrict the following types of behavior on your cloud workloads:
- File access - allow/deny specific paths
- Allow / deny Process execution / forking
- Allow / Deny Establish network connections
- Allow / Deny workloads to request other capabilities with the host os. Such capabilities can enable additional types of malicious behavior.
Cilium, is an open-source project to provide eBPF-based networking, security, and observability for cloud-native environments such as Kubernetes clusters and other container orchestration platforms.
We will be able to block this attack by enforcing a simple system policy via KubeArmor; the policy is as follows:
The Policy: In-action
After applying the policy let's go ahead and upload the plugin again to see what happens. The policy blocks the creation of
initial.phpfile and denies RCE via the
Checking the policy logs on KubeArmor
There are two ways we can check policy logs on KubeArmor.
The traditional way is all about finding the KubeArmor pod running on the same node as the application pod and executing inside it to find logs.
- Get the node name which your application pod is running
2. We will take the node name
gke-wordpress-demo-default-pool-1cc20b06-7nfl and check for the KubeArmor pod running on it.
3. We got to know that
kubearmor-xh4zb the pod is running on node
4. Let us execute into the pod and watch the logs (you watch the entire logs or grep it with keywords like policy name)
5. Blocked Log Created by KubeArmor
kArmor is a CLI client to help manage KubeArmor. With kArmoryou can get the logs in 2 steps
- Download and Install kArmor CLI (if not present)
curl -sfL https://raw.githubusercontent.com/kubearmor/kubearmor-client/main/install.sh | sudo sh -s -- -b /usr/local/bin
2. Enable port-forwarding for KubeArmor relay
kubectl port-forward -n kube-system svc/kubearmor 32767:32767&
3. Observing logs using kArmor cli
4. Blocked Log Created by kArmor
Auto Policy Discovery for your WordPress Application
Even though writing KubeArmor and CIlium (System and Network) policies are not a big challenge AccuKnox opensource has it simplified one step further by introducing a new CLI tool for Auto Discovered Policies. The Auto-Discovery module helps users by identifying the flow and generating policies based on it.
Discovering policies has never been better with Auto Discovery. In two simple commands, you can set up and generate policies without having any trouble.
To auto-discover policies, execute the following command
curl -s https://raw.githubusercontent.com/accuknox/tools/main/get_discovered_yamls.sh | bash
You should be able to see the following output.
In mere seconds after installing executing auto policy discovery tool, it generated 10 Cilium policies and 3 KubeArmor policies.
Auto Discovery was able to discover network-level policies that allow communication from WordPress frontend pod to MySQL pod only via port 3306 thereby eliminating the possibility of any attacks on MySQL pod from external or internal rogue pods.
These features by AccuKnox open-source make sure that all the necessary policies to secure your workload are generated and ready to be used in a single click.
Accuknox's policy templates repository
Accuknox's policy templates is an open-source repo that contains a wide range of attack prevention techniques, including MITRE and hardening techniques for your workloads. Please visit GitHub - kubearmor/policy-templates: Community curated list of System and Network policy templates for the KubeArmor and Cilium to download and apply policy templates.
Even though supply-chain attacks are more brutal to avoid and protect from, with AccuKnox opensource tools, you can prevent your workloads from possible threats and vulnerabilities.
Using AccuKnox open-source tools, an organization can effectively protect against all sorts of accidental developer-introduced vulnerabilities and/or known/unknown vulnerabilities.
Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.
Let us know if you are seeking additional guidance in planning your cloud security program.
Read more blogs from Cloud Security Category here.