Five hours! Five hours! That’s how long it took for hackers to exploit Drupal vulnerability (CVE-2018-7602) after the patches came out. 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 exploit 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. A vulnerability management tool can fix this.
Technical Jargon:
DrupalKernel.php class located on path a/core/lib/Drupal/Core/ is vulnerable. Drupal vulnerability 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 exploit, one must have authentication and power of deleting a node. Attackers are using malformed requests using GET or POST functions to inject and execute a piece of code. Auto patching this vulnerability with a patch management software can be effective here.
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 codes 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.
Proof-of-concept:
However, Just after the first seven hours of patch release for Drupal vulnerability and two hours after the first in-the-wild attacks, 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.
Impact:
However, successful exploitation will allow attackers to conduct remote code execution and gain complete control of the website. The compromised website can inject with crypto miners, ransomware, and other nasty malware.
Solution:
However, 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 apply if Drupalgeddon 2 is patched. It’s advised to install updates immediately. For more info click here.