The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Poisoning Cached HTTPS Documents in Internet Explorer
------------------------------------------------------------------------
SUMMARY
Under specific circumstances, Internet Explorer does not warn the user
about an invalid server SSL certificate. This allows an attacker to
"poison" a user's browser cache with a malicious document that will later
be used from cache when the user visits the legitimate site. Furthermore,
once the user is on the legitimate site and the malicious document is used
from browser's cache, even manual inspection of the document's certificate
will not reveal anything suspicious - in contrast to most other SSL
content-faking vulnerabilities, where manual certificate inspection alerts
the user about the
attack.
The attacker can exploit this vulnerability for "replacing" HTML
documents, images, script files (.js), cascading style sheet files (.css)
and other static documents on a legitimate secured web server, thereby
possibly completely compromising the component of its security provided by
the SSL protocol.
DETAILS
Vulnerable Systems:
* All patches applied, up to and excluding Cumulative Security Update for
Internet Explorer (834707).
Immune Systems:
* Windows XP Service Pack 2 resolves the issue on Windows XP.
For more vulnerable systems see Microsoft's advisory at:
<http://www.securiteam.com/windowsntfocus/6X00G0UBGY.html> Cumulative
Security Update for Internet Explorer (MS04-038)
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0845>
CAN-2004-0845
In 1999, ACROS company has informed Microsoft about a
<http://www.acrossecurity.com/aspr/ASPR-1999-12-15-1-PUB.txt>
vulnerability in Internet Explorer that allowed the attacker to force IE
to communicate with a malicious web server over HTTPS without the browser
issuing a warning about an
invalid SSL certificate used by that server. To summarize, IE did not
check the validity of SSL certificates for:
(1) connections with web servers with which a successful SSL connection
has previously been established
(2) connections established via images or (i)frames. Microsoft has
subsequently fixed both aspects of this vulnerability.
Recently, ACROS discovered a somewhat similar security problem in Internet
Explorer, although one which does not pose such an obvious threat. Under
certain circumstances, Internet Explorer again doesn't perform all three
of the required SSL certificate validations. The threat is not obvious
since it is very unlikely that a secure production site would provide such
circumstances. However, we have found an attack vector that allows the
attacker to "replace" arbitrary static documents on a secured web server
using only DNS spoofing and little or no social engineering. Furthermore,
the attack can take place any time before the user actually visits the
"attacked" web server (note: actually, the browser is attacked, not the
server), and the user may even restart his computer in between.
The key to the attack is browser's cache (Temporary Internet Files). IE by
default caches all documents except those which web servers instruct it
not to cache. While there is a "Do not save encrypted pages to disk"
option in IE, it is turned off by default, which means that HTTPS
documents are cached by default.
When a web server includes a "Last-Modified" header in its response
containing a document, IE remembers its value and when it subsequently
needs the same document again, includes an "If-Modified-Since" header in
its request for the document. The web server, receiving an
"If-Modified-Since" header, checks whether the document it hosts is newer
than the one browser claims it has cached, and sends the document to
browser only if it is newer - otherwise, it returns a "304" (meaning "Not
Modified") response, instructing the browser to use the locally cached
copy.
Using the discovered vulnerability in IE, the attacker can covertly
"poison" browser's cache with a fake document that seemingly comes from a
legitimate secured web server while the user opens a page on a malicious
web server. This fake document can be used to effectively replace an image
or HTML (e.g., a login form) on the legitimate server, or even to
introduce a malicious script
that will, for example, steal visitors' credentials and send them to the
attacker.
What the attacker needs to do in order to execute the attack is this:
1. Temporarily poison the user's DNS server or send a fake DNS response to
the user's browser ("man in the middle") to redirect requests for the
legitimate secured web server to a malicious web server.
2. Set up a malicious web server hosting a fake document that will poison
the user's browser cache.
3. Make the user's browser visit the malicious web server, either using
social engineering or by modifying the HTTP traffic from/to the browser
("man in the middle").
4. Wait for the user to visit the legitimate secured web site where the
fake document will be used instead of the real one, possibly introducing
malicious scripts, fake images or fake text.
Two important facts distinguish this attack from many other attacks on
SSL-protected sites:
A. The active component of the attack takes place before the user actually
visits the targeted web site (e.g., a web-banking site). No attacker's
activity is required during the user's visit of the legitimate ("spoofed")
web site. Furthermore, there can be a long pause between steps 3 and 4
above, during which the user can restart his computer any number of times.
The only serious limitation is that the user must not manually delete the
browser's cache (and hence the fake document) during this period.
B. Once on the legitimate secured site, the user has no way to determine
that a fake document (be it an image or an HTML document) is not
legitimate - even a manual SSL certificate inspection will show that the
document has come from the legitimate server. This is, by the way, not the
case in most "URL obfuscation" attacks that only modify the apparent URL
for web sites or documents and try to trick the user into believing that
he is actually visiting some other site - these attacks can generally be
detected at least by manual certificate inspection.
Some additional notes regarding this vulnerability:
* While it may be tempting to think that the described attack requires
quite a resourceful attacker (poisoning DNS response, getting the user to
visit a malicious web server), we should remember that SSL (and HTTPS)
protocol is being used for defending against this exact type of attacker -
the attacker being able to monitor and possibly modify network traffic
between browser and server.
* The attacker can use any web server certificate issued by any one of
the IE's trusted issuers (currently 109 of them!), which can be long
expired and issued for any host name. A usable certificate can also be
bought by any commercial trusted CA like Verisign or Thawte.
* It seems that IE will always send en explicit GET for the first request
in an HTTPS connection - for example, in case of index.html with three
inline images, index.html will be, as the first request, requested
unconditionally (i.e., without "If-Modified-Since" header), while the
images will be requested with "If-Modified-Since" header. Consequently, it
is easier to successfully poison documents that are loaded from another
document, e.g., images, script files or style sheet files. However, HTML
documents can also be successfully poisoned as long as they're not the
first to be requested over an HTTPS connection.
* Malicious scripts can also be introduced via fake cascading style
sheets.
* The attacker can only poison sites that respect "If-Modified-Since"
headers. Furthermore, the attacker can only poison documents (HTML
documents, images, .JS files etc.) that the web server considers static
and therefore subject to "If-Modified-Since" logic.
* It makes no difference if the targeted web server tries to make sure
its pages aren't written to browser's cache (using cache-related HTTP
response headers). The attacker's malicious server will always be able to
demand its fake page to be cached and there's nothing the legitimate web
server can do to prevent it.
* Caching HTTP proxy servers in general have no effect on this
vulnerability as HTTPS sessions run through them encrypted. Proxy servers
that actually decrypt and re-encrypt the traffic can either mitigate, or
even escalate the issue, depending on their logic.
Mitigating Factors:
* Browsers with the "Do not save encrypted pages to disk" option enabled
are not affected by this issue as the fake document(s) can't be written to
browser's cache.
* Web servers that ignore browser's "If-Modified-Since" header and always
send the requested document are not "spoofable" using this vulnerability.
Solution:
Microsoft released
<http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx>
Cumulative Security Update for Internet Explorer (834707) which addresses
this issue.
Note that Windows XP Service Pack 2 also fix this issue on Windows XP.
Workarounds:
Browsers - Turning the option "Do not save encrypted pages to disk" on
will disable the cache poisoning attack. Deleting the browser's temporary
files is advised afterwards to remove any malicious documents.
Servers - If you're running a critical web site and don't want to rely on
your visitors to install the patch, implement a workaround or even know
about this issue, there are steps you can take to protect them. As the
described attack relies on the fact that the browser will (re)use a cached
page when the web server responds with "304 - Not Modified" response,
preventing the server from ever sending such a response will thwart it.
Following, we provide specific solutions for IIS and Apache web servers.
All solutions are aimed at removing "If-Modified-Since" headers from
browsers' requests, effectively bypassing server's "Not Modified"
functionality.
Internet Information Services - ACROS wrote a simple, minimum overhead
ISAPI filter (24 lines of code) that intercepts browsers' requests and
removes any "If-Modified-Since" headers from it. The filter is available:
<http://www.acrossecurity.com/aspr/misc/if-modified-since-eliminator.zip>
here
Apache 1.3 - Edi Weitz from Germany wrote a simple Apache module called
mod_header_modify, specifically intended for changing incoming HTTP
headers. This module can be used for eliminating "If-Modified-Since"
headers from incoming requests using the following directives in
httpd.conf:
HeaderModify on
HeaderModifyRemove If-Modified-Since
mod_header_modify module can be downloaded from:
<http://weitz.de/mod_header_modify.html>
http://weitz.de/mod_header_modify.html
Note: Apache must be built with DSO support.
Apache 2.0 - Apache 2.0 already comes with mod_headers module. Rebuild
Apache with this module included and use the following directive in
httpd.conf: RequestHeader unset If-Modified-Since
ADDITIONAL INFORMATION
The information has been provided by <mailto:lists@acros.si> ACROS
Security.
The original article can be found at:
<http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt>
http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
