WordPress XSS2Shell Vulnerability Transforms Login Bug into Total Server Control
XSS2Shell flaw allows for administrative seizure and remote code execution. Users are urged to upgrade to secure versions.
Experts at Pwn have unveiled a detailed report concerning a vulnerability chain dubbed XSS2Shell. The initial entry point is strikingly straightforward: submit an unregistered username, prompting WordPress to respond with an error message containing a subtle formatting lapse inherent in the operation of two distinct sanitizers processing the same string.
This defect resides within the login page’s error feedback. Upon entering an unregistered username, WordPress generates an error message that incorporates the submitted text, employing a function designed to eliminate any HTML tags.
Intriguingly, this stripping mechanism hinges on PHP’s native strip_tags(), which identifies a tag solely if its opening bracket is immediately succeeded by a letter, thus ignoring any intervening spaces.
This subtle imperfection constitutes the fundamental vulnerability. A payload such as< area id=ajaxurl>, which features a space following the bracket, passes through strip_tags() unscathed, since PHP’s parser fails to recognize it as an HTML tag.
However, as this string is processed by WordPress’s alternate sanitizer,wp_kses_post(), an entirely different parser that accommodates that whitespace, it is interpreted as a bona fide element, subsequently rendered as dynamic HTML.
When JavaScript evaluates an identifier lacking binding in the current scope chain, the runtime eventually reaches the window object.
Per the HTML specification (section 7.3.3), the window object exposes ‘named properties’: every HTML element possessing an id attribute becomes accessible as window. The report elaborates. The inserted is now the value returned for window.ajaxurl.”
The researchers unearthed an existing script on the login page that interacts with the injected elements seamlessly, requiring no user interaction.
WordPress loads a profile-related script,user-profile.js, on the login screen due to its handling of password resets.
This script autonomously monitors for a password-reset command and auto-clicks it; thanks to the injected DOM components, it identifies one that shouldn’t exist.
This click event initiates a sequence that ultimately resolves an undefined JavaScript variable, ajaxurl, exploiting a browser nuance: any HTML element with a matching id becomes directly accessible as a property on the window object.
Thus, the injected element effectively becomes the value assigned towindow.ajaxurl, granting the attacker dominion over the handling of the script’s request.
This phenomenon, known as DOM clobbering, serves as the fulcrum that transforms a mere rendering peculiarity into a tangible network request issued by WordPress’s own script.
The resultant request directs to WordPress’s REST API, furnished with parameters that deceitfully induce a JSONP response, enclosing the reply within a callback function governed by the attacker.
Given that this callback field accommodates both dots and letters, the attacker is not confined to a single global function; rather, it can traverse a comprehensive property chain across different browser windows.
The researchers adeptly repurposed a technique originally disclosed in 2022 to facilitate a cross-window click that occurs within the legitimate session of an authenticated administrator, rather than the attacker’s own.
Transitioning from this scenario to a complete server compromise necessitates a meticulously orchestrated sequence: opening a covert window, maneuvering the admin’s browser to WordPress’s application-password approval interface, and subsequently triggering the cross-window click on the approval button employing the admin’s authentic session cookies and nonces.
This grants the attacker a valid Application Password for the administrative account, which the REST API readily accepts via HTTP Basic auth from any origin.
“Application Passwords authenticate REST API requests through HTTP Basic auth. WordPress’s REST CORS framework reflects the requesting origin, permitting Authorization and Content-Type headers. Thus, the attacker’s page can now execute authenticated cross-origin API calls.”
“Single-site WordPress administrators have the unfiltered_html capability by default. The script elements persist in the published page precisely as submitted.”
From this juncture, it is a mere step to publish a page embedding the attacker’s JavaScript code, leveraging the unrestrained HTML permissions typical for single-site administrators, subsequently utilizing that script to upload and execute a plugin containing arbitrary PHP code.
The researchers demonstrated a proof of concept culminating in a plugin file yielding a JSON response that confirmed execution of code as the web server user, followed by a clean-up of all traces: revoking the application password, deleting the published page, and eradicating the plugin directory.
Nothing lingered; however, the critical message had been conveyed. This vulnerability operates pre-authentication, requires no user engagement beyond simply visiting a link, and consistently culminates in remote code execution on a standard WordPress installation.
“Our proof employed a minimal PHP file that issued a JSON marker while returning a custom header,” the report concludes.
“After verification, the PoC ensured WordPress cleaned up thoroughly: the Application Password was revoked, the published page was deleted, and the plugin directory was removed. Nothing persisted.”
In swift response to the alert, WordPress acted expeditiously. The researchers reported the vulnerability chain on July 27, and WordPress released version 7.0.3 on August 6, backporting the remedy to version 4.7 to cover all actively maintained branches.
For those operating WordPress, an update is not simply a suggestion; it is imperative to implement before concluding this reading. The simplicity with which an assailant can exploit the vulnerability is alarming.
Source link: Securityaffairs.com.
