Announced yesterday, the newly discovered vulnerability (CVE-2018-7602) affects Drupal 7 and 8 core and allows remote attackers to achieve exactly same what previously discovered Drupalgeddon2 (CVE-2018-7600) flaw allowed—complete take over of affected websites.
Although Drupal team has not released any technical details of the vulnerability to prevent immediate exploitation, two individual hackers have revealed some details, along with a proof-of-concept exploit just a few hours after the patch release.
If you have been actively reading every latest story on The Hacker News, you must be aware of how the release of Drupalgeddon2 PoC exploit derived much attention, which eventually allowed attackers actively hijack websites and spread cryptocurrency miners, backdoors, and other malware.
As expected, the Drupal team has warned that the new remote code execution flaw, let's refer it Drupalgeddon3, is now actively being exploited in the wild, again leaving millions of websites vulnerable to hackers.
In this article, I have briefed what this new flaw is all about and how attackers have been exploiting it to hack websites running unpatched versions of Drupal.
The exploitation process of Drupalgeddon3 flaw is somewhat similar to Drupalgeddon2, except it requires a slightly different payload to trick vulnerable websites into executing the malicious payload on the victim's server.
Drupalgeddon3 resides due to the improper input validation in Form API, also known as "renderable arrays," which renders metadata to output the structure of most of the UI (user interface) elements in Drupal. These renderable arrays are a key-value structure in which the property keys start with a hash sign (#).
A Twitter user with handle @_dreadlocked explains that the flaw in Form API can be triggered through the "destination" GET parameter of a URL that loads when a registered user initiates a request to delete a node; where, a "node" is any piece of individual content, such as a page, article, forum topic, or a post.
Since this "destination" GET query parameter also accepts another URL (as a value) with its own GET parameters, whose values were not sanitized, it allowed an authenticated attacker to trick websites into executing the code.
What I have understood from the PoC exploit released by another Twitter user, using handle @Blaklis_, is that the unsanitized values pass though stripDangerousValues() function that filters "#" character and can be abused by encoding the "#" character in the form of "%2523".
The function decodes "%2523" into "%23," which is the Unicode version for "#" and will be processed to run arbitrary code on the system, such as a whoami utility.
At first, Drupal developers were skeptical about the possibility of real attacks using the Drupalgeddon3 vulnerability, but after the reports of in-the-wild attacks emerged, Drupal raised the level of danger of the problem to "Highly critical."
Therefore, all Drupal website administrators are highly recommended to update their websites to the latest versions of the software as soon as possible.
