Security researcher Simon Scannell from RIPS Technologies, has discovered a new CSRF vulnerability in WordPress, that could potentially lead to remote code execution attacks.
The flaw is a cross-site request forgery (CSRF) that resides in the comment section of WordPress that is enabled by default, the issue affects all WordPress versions prior to version 5.1.1.
An attacker can hack a website running a vulnerable version of WordPress that has comments enabled by tricking an administrator of a target site into visiting a website set up by the attacker.
“As soon as the victim administrator visits the malicious website, a cross-site request forgery (CSRF) exploit is run against the target WordPress blog in the background, without the victim noticing.” reads the analysis published by RIPS Technologies.
“The CSRF
WordPress is used by over 33% of all websites online and considering that comments are a feature of blogs that is enabled by default, the vulnerability potentially affected millions of sites.
The exploitation of the flaw allows even an unauthenticated, remote attacker to compromise a website and remotely execute code on it.
Scannell demonstrated the attack that relies on multiple flaws, including:
- WordPress doesn’t implement CSRF validation when a user posts a new comment. “This is because some WordPress features such as trackbacks and pingbacks would break if there was any validation. This means an attacker can create comments in the name of administrative users of a WordPress blog via CSRF attacks.”
- The above issue can become a security issue since administrators of a WordPress blog are allowed to use arbitrary HTML tags in comments,
even <script>tags . - The frontend is not protected by the X-Frame-Options header by WordPress itself. For this reason, the comment can be displayed in a hidden way on the website of the attacker. Since the injected attribute is an
onmouseover event handler, the attacker can make the iframe follow the mouse of the victim to instantly trigger the XSS payload. In this way, the attacker could execute arbitrary JavaScript code with the session of the administrator who triggered the CSRF vulnerability on the target website. JavaScript is executed in the background without the victim administrator noticing.
The researcher demonstrated that chaining these issues, an attacker can silently inject a stored XSS payload into the target website just by tricking a logged on administrator into visiting a malicious website containing the exploit code.
Scannell initially reported this flaw to the WordPress development team in October. The WordPress team attempted to mitigate the issue but did not enable CSRF protection, so Scannell was also able to bypass the solution.
WordPress development
If for some reason you have disabled the automatic updating of WordPress, you have to install the version 5.1.1 or temporarily disable comments and log out of your administrator session until the security patch is installed.
Below the timeline shared by the expert:
| Date | What |
|---|---|
| 2018/10/24 | Reported that it is possible to inject more HTML tags than should be allowed via CSRF to WordPress. |
| 2018/10/25 | WordPress triages the report on Hackerone. |
| 2019/02/05 | WordPress proposes a patch, we provide feedback. |
| 2019/03/01 | Informed WordPress that we managed to escalate the additional HTML injection to a Stored XSS vulnerability. |
| 2019/03/01 | WordPress informs us that a member of the WordPress security team already found the issue and a patch is ready. |
| 2019/03/13 | WordPress 5.1.1 Security and Maintenance Release |
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
