Five hours! Five hours! That’s how long it took for hackers to exploit Drupal vulnerability (CVE-2018-7602) after the patches were released. This time, instead of releasing the patches straight away, Drupal dropped a PSA(Public Service Announcement) approximately two days before releasing the updates to get the website owners and developers ready to patch out the vulnerability. Unlike Drupalgeddon 2 which took almost two weeks to be exploited in the wild, this started right away. The “critical” remote code execution vulnerability on Drupal’s own severity scale went on to become “highly critical” meaning, it can give attackers complete control over an attacked website.
DrupalKernel.php class located on path a/core/lib/Drupal/Core/ is vulnerable. The flaw here again is related to the way Drupal handles ‘#’ character and the lack of input sanitization applied to parameters supplied via the ‘#’ character. As the “destination” GET query parameter accepts a URL (with GET parameters) which ain’t sanitized with the function stripDangerousValues() (Responsible to filter ‘#’ character), Drupal becomes vulnerable. Injecting a renderable array into an appropriate input field can exploit the vulnerability. For the vulnerability to be exploited one must have authentication and power of deleting a node. Attackers are using malformed request using GET or POST functions to inject and execute a piece of code.
The vulnerable php class lacking the input sanitation located at core/lib/Drupal/Core/DrupalKernel.php. It also now includes a class RequestSanitizer on path Drupal/Core/Security which will be used to sanitize the input.
A function preHandle is now coded into the DrupalKernel class to accept public requests and pass it on to the RequestSanitizer class which strips the dangerous keys from the input and user input including the request body(GET, POST), Cookie parameters and saves the sanitized output in the whitelist array using the functions sanitize and stripDangerousValues.
Just after the first seven hours of patch release and two hours after the first in-the-wild attacks were reported, a user named Blacklis(Pastebin) published proof-of-concept code making it easier to weaponize for attackers.
You must be authenticated and with the power of deleting a node. Some other forms may be vulnerable: at least, all of the forms that are in 2-step (form then confirm). POST /?q=node/99/delete&destination=node?q[%2523]=passthru%26q[%2523type]=markup%26q[%2523markup]=whoami HTTP/1.1 [...] form_id=node_delete_confirm&_triggering_element_name=form_id&form_token=[CSRF-TOKEN] Retrieve the form_build_id from the response, and then triggering the exploit with : POST /drupal/?q=file/ajax/actions/cancel/%23options/path/[FORM_BUILD_ID] HTTP/1.1 [...] form_build_id=[FORM_BUILD_ID] This will display the result of the whoami command.
Successful exploitation will allow attackers to conduct remote code execution and gain complete control of the website. The compromised website can then be injected with crypto miners, ransomware, and other nasty malwares.
For websites running v7.x update to v7.59, running v7.x update to v8.4.8, and running v7.x update to v8.5.3. This patch can only be applied if Drupalgeddon 2 is already patched. It’s advised to install updates immediately. For more info click here.