WordPress and Trojan Source

WordPress Trojan Source

TL;DR: We have found no evidence that the new Trojan Source method has been used to sneak in backdoors in any of the WordPress plugins listed on WordPress.org (CVE-2021-42694 and CVE-2021-42574)

A new vulnerability affecting the supply chain of Source Code for projects like Go, PHP, Python, JavaScript and many more programming languages. The vulnerability makes it possible for an adversary to hide characters in plain sight that makes it possible to alter the logic in the code, or as the authors explains the new attack Trojan Source:

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards such as Unicode to produce source code whose tokens are logically encoded in a different order from the one in which they are displayed, leading to vulnerabilities that cannot be perceived directly by human code reviewers.

The authors Nicholas Boucher and Ross Anderson from University of Cambridge received CVE-2021-42694 and CVE-2021-42574.

This type of attack also affects WordPress and the Plugin ecosystem, and since WordPress Security is our highest priority here at WPSec we immediately started to investigate if WordPress or any of the +90k plugins are vulnerable. First we need to find a method that would work and tested it against the Trojan Source Github repository. We also found some additional control unicode characters that was not present in the Trojan Source paper:

And when looking in the Unicode standard and the PropList.txt we found the following:

So in total we are searching for 12 unicode characters: \u200E \u200F \u202A \u202B \u202C \u202D \u202E \u2066 \u2067 \u2068 \u2069 \u202C

First we searched for this characters in the WordPress Core but found no occurrences and then we searched in all WordPress plugins. The code we used to find these control characters was the following (gist)

find . -type f -name ".php" -exec grep -H $'\u200E' {} \;;find . -type f -name ".php" -exec grep -H $'\u200F' {} \;;find . -type f -name ".php" -exec grep -H $'\u202A' {} \;;find . -type f -name ".php" -exec grep -H $'\u202B' {} \;;find . -type f -name ".php" -exec grep -H $'\u202C' {} \;;find . -type f -name ".php" -exec grep -H $'\u202D' {} \;;find . -type f -name ".php" -exec grep -H $'\u202E' {} \;;find . -type f -name ".php" -exec grep -H $'\u2066' {} \;;find . -type f -name ".php" -exec grep -H $'\u2067' {} \;;find . -type f -name ".php" -exec grep -H $'\u2068' {} \;;find . -type f -name ".php" -exec grep -H $'\u2069' {} \;;find . -type f -name ".php" -exec grep -H $'\u202C' {} \;

We searched throught all published plugins and found over 10000 matches of the unicode characters. We manually reviewed all the findings and found no evidence that the logic of the plugin has been altered with. Almost all of the occurrences looked something like this:

In conclusion: We have found no evidence that the new Trojan Source method has been used to sneak in backdoors in any of the WordPress plugins listed on WordPress.org

Update: We also recommend to read this blog post by Russ Cox.

Leave a Comment

Your email address will not be published.