full-disclosure - Zero-Day Magento EE Cache Poisoning Attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <74E87EDA-35A0-45EB-98AE-670DE35B8CDA@mrjoy.com>
Date: Mon, 7 Feb 2011 11:48:39 -0800
From: Jon Frisby <jfrisby@...oy.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Zero-Day Magento EE Cache Poisoning Attack

Summary:

Magento Enterprise Edition is vulnerable to poisoning of its page cache
under some configurations due to inappropriate trust of HTTP Host header
values.

Impact:

Users shopping at online stores driven by Magento EE can be redirected
to arbitrary third party sites, allowing malicious entities to entice
users to hand over their credit card information inappropriately.

Severity:

Major -- Exploit allows for content injection, and hijacking of users.
Exploits have been observed in the wild.

Fix/Workaround Status:

At this time, the vendor (Magento Inc) has only stated an intent to fix
the problem (as a "product enhancement") but has not provided any patch
despite being given considerable lead time by us and being first made
aware of the problem in 2008 (see note below for more details).

The issue can be worked around using one of several configuration-
related changes, including one which the vendor introduced in 2008.

Affected Versions:

All versions of Magento EE, up to and including 1.9.1.1 (the latest as
of this writing) when page caching is enabled.  It is unclear if the
block-level caching in Magento Community/Professional Edition is
similarly impacted, however both are likely vulnerable to the
misinterpretation of data.

Details:

Magento uses a hierarchical configuration mechanism, allowing values
such as site URLs to be set at a global level and at a more specific
per-storefront level.  Magento EE adds a mechanism for caching whole
pages.

With default URL values, Magento EE can be tricked into generating page
cache entries with arbitrary URL values by simply sending an artificial
HTTP Host header.  Unfortunately, setting the URL value at the
*storefront* level is insufficient to prevent this behavior.

In order to prevent this issue, one of the following must be true:

The key is to have the web server send only trustworthy/cleansed values
to PHP.

The following are example approaches for Apache:

* Your web server is configured in a way that results in untrusted Host
values never being sent to PHP.  An example of this would be the use of
name-based vhosts that do not point the "_default_" vhost to a Magento
instance.

* Using one or more ServerAlias masks with IP-based vhosting to
constrain the range of valid host values.

Magento level:

* Provide Base Unsecure URL and Base Secure URL values in the "Default
Config" (top-level) configuration.  The precise values do not appear to
matter, just so long as some value is present.

Reproducing the problem simply requires requesting any URL with a forged
Host header at a time when the page cache is considered invalid.

Nota Bene:

The vendor's solution to the problem when confronted with it in 2008[1]
was to introduce a vaguely worded warning[2] in the admin UI when the
base URL value is not defined at the top level of the configuration
hierarchy.

Given that:

1) It is not made clear that the configuration status presents a severe
security hole.

2) A non-default base URL value in the top-level configuration level is
never actually *used* in page-cache generation.  Its presence apparently
serves only to trigger use of the per-storefront configuration value.

We therefore hold that the provided warning does not suffice as a 'fix'.
The vendor has indicated that they believe otherwise both through their
actions and their communications with us.

References:

[1] http://www.magentocommerce.com/boards/viewthread/8220/

[2] The exact wording of the message is:  "{{base_url}} is not
recommended to use in a production environment to declare the Base
Unsecure URL / Base Secure URL. It is highly recommended to change this
value in your Magento configuration."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/