(Analysis by Lena Frid, Bar Menachem and Victor Hora)
Shortly after the recent Drupalgeddon vulnerabilities hit the popular content management system, new vulnerabilities were discovered.
As reported by PortSwigger Web Security, Drupal versions 8.x are vulnerable to cache poisoning, by abusing X-Original-URL and X-Rewrite-URL headers to override the requested path. In addition, an unsecure implementation of the URL-override code exposes the system to an Open Redirect vulnerability, abusing the "destination" parameter. In case the vulnerable website is using an external cache, a combination of those two vulnerabilities can be exploited and lead to Nested cache poisoning. For detailed explanation please refer to the source blogpost.
According to Drupal, the cache poisoning vulnerabilities were found in Symphony HttpFoundation component. Symphony is a third-party library which is integrated in Drupal Core. All users that are using version 8.x are urged to upgrade to 8.5.6, as versions prior to 8.5.x series will not receive security coverage. Drupal published its own security advisory named SA-CORE-2018-005 while Symphony coordinated the disclosure with CVE-2018-14773).
Cache poisoning vulnerability:
A website is vulnerable to cache poisoning, if it allows an attacker to send malicious request, resulting with corrupted response. The harmful response is then cached and served to other users.
A user can set the X-Original-URL/ X-Rewrite-URL headers to bypass restricted access or serve unintended pages. For example:
GET /admin HTTP/1.1
HTTP/1.1 403 Forbidden
Access is denied
GET /anything HTTP/1.1
HTTP/1.1 200 OK
Please log in
Open redirect vulnerability:
A website is vulnerable to Open Redirect when parameter values in an HTTP GET request allows redirection to a new website without any validation of the target of redirect. For more details please refer to SpiderLabs blogpost.
Authenticated user can send an HTTP GET request abusing the "destination" parameter as open redirect to the attacker's website.
GET //?destination=https://attacker.com\@origin.com/ HTTP/1.1
HTTP/1.1 302 Found
The SpiderLabs WAF Research team released a set of rules to address the described vulnerabilities as part of the Commercial Rules package: