ACROS Security
14/10/04, 00:05
Below please find our public report for the HTTPS cache poisoning issue =
in
Internet Explorer. It includes workarounds for server operators, =
allowing
them to protect their web services without having to rely on users to =
patch
their browsers.
Regards,
ACROS Security
http://www.acrossecurity.com
=3D=3D=3D=3D=3D[BEGIN-ACROS-REPORT]=3D=3D=3D=3D=3D
PUBLIC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D
ACROS Security Problem Report #2004-10-13-1
-------------------------------------------------------------------------=
ASPR #2004-10-13-1: Poisoning Cached HTTPS Documents in Internet =
Explorer=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D
Document ID: ASPR #2004-10-13-1-PUB
Vendor: Microsoft (http://www.microsoft.com)
Target: Internet Explorer
Impact: Arbitrarily modifying the content of HTTPS pages shown
in Internet Explorer
Severity: High
Status: Official patch available, workarounds available
Discovered by: Mitja Kolsek of ACROS Security
Current version=20
http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt
Summary
=3D=3D=3D=3D=3D=3D=3D
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=20
cache when the user visits the legitimate site. Furthermore, once the =
user
is=20
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=20
anything suspicious - in contrast to most other SSL content-faking=20
vulnerabilities, where manual certificate inspection alerts the user =
about
the=20
attack.
The attacker can exploit this vulnerability for "replacing" HTML =
documents,=20
images, script files (.js), cascading style sheet files (.css) and other =
static documents on a legitimate secured web server, thereby possibly=20
completely compromising the component of its security provided by the =
SSL=20
protocol.
Product Coverage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Internet Explorer 6 - affected
All patches applied, up to and excluding Cumulative Security Update for=20
Internet Explorer (834707).
Note: Windows XP Service Pack 2 resolves the issue on Windows XP.
Other versions may also be affected.
Analysis
=3D=3D=3D=3D=3D=3D=3D=3D
In 1999, our company has informed Microsoft about a vulnerability [1] in =
Internet Explorer that allowed the attacker to force IE to communicate =
with
a=20
malicious web server over HTTPS without the browser issuing a warning =
about
an=20
invalid SSL certificate used by that server. To summarize, IE did not =
check=20
the validity of SSL certificates for (1) connections with web servers =
with=20
which a successful SSL connection has previously been established, and =
for
(2)=20
connections established via images or (i)frames. Microsoft has =
subsequently=20
fixed both aspects of this vulnerability.
Recently, we've discovered a somewhat similar security problem in =
Internet=20
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=20
that allows the attacker to "replace" arbitrary static documents on a
secured=20
web server using only DNS spoofing and little or no social engineering.=20
Furthermore, the attack can take place any time before the user actually =
visits the "attacked" web server (note: actually, the browser is =
attacked,
not=20
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=20
default caches all documents except those which web servers instruct it =
not
to=20
cache. While there is a "Do not save encrypted pages to disk" option in =
IE,
it=20
is turned off by default, which means that HTTPS documents are cached by
default.=20
When a web server includes a "Last-Modified" header in its response
containing=20
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=20
the document. The web server, receiving an "If-Modified-Since" header,
checks=20
whether the document it hosts is newer than the one browser claims it =
has=20
cached, and sends the document to browser only if it is newer - =
otherwise,
it=20
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=20
secured web server while the user opens a page on a malicious web =
server.
This=20
fake document can be used to effectively replace an image or HTML (e.g., =
a=20
login form) on the legitimate server, or even to introduce a malicious
script=20
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=20
user's browser ("man in the middle") to redirect requests for the =
legitimate
secured web server to a malicious web server.=20
2. Set up a malicious web server hosting a fake document that will =
poison
the=20
user's browser cache.=20
3. Make the user's browser visit the malicious web server, either using
social=20
engineering or by modifying the HTTP traffic from/to the browser ("man =
in
the=20
middle").=20
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=20
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=20
visits the targeted web site (e.g., a web-banking site). No attacker's=20
activity is required during the user's visit of the legitimate =
("spoofed")
web=20
site. Furthermore, there can be a long pause between steps 3 and 4 =
above,=20
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=20
cache (and hence the fake document) during this period.=20
B. Once on the legitimate secured site, the user has no way to determine
that=20
a fake document (be it an image or an HTML document) is not legitimate -
even=20
a manual SSL certificate inspection will show that the document has come
from=20
the legitimate server. This is, by the way, not the case in most "URL=20
obfuscation" attacks that only modify the apparent URL for web sites or=20
documents and try to trick the user into believing that he is actually=20
visiting some other site - these attacks can generally be detected at =
least
by=20
manual certificate inspection.
Some additional notes regarding this vulnerability:
- While it may be tempting to think that the described attack requires =
quite
a=20
resourceful attacker (poisoning DNS response, getting the user to visit =
a=20
malicious web server), we should remember that SSL (and HTTPS) protocol =
is=20
being used for defending against this exact type of attacker - the =
attacker=20
being able to monitor and possibly modify network traffic between =
browser
and=20
server.=20
- The attacker can use any web server certificate issued by any one of =
the=20
IE's trusted issuers (currently 109 of them!), which can be long expired =
and
issued for any host name. A useable certificate can also be bought by =
any=20
commercial trusted CA like Verisign or Thawte.=20
- 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=20
images, index.html will be, as the first request, requested =
unconditionally=20
(i.e., without "If-Modified-Since" header), while the images will be
requested=20
with "If-Modified-Since" header. Consequently, it is easier to =
successfully=20
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=20
connection.=20
- Malicious scripts can also be introduced via fake cascading style =
sheets.
- The attacker can only poison sites that respect "If-Modified-Since"
headers.=20
Furthermore, the attacker can only poison documents (HTML documents, =
images,
..JS files etc.) that the web server considers static and therefore =
subject
to=20
"If-Modified-Since" logic.=20
- It makes no difference if the targeted web server tries to make sure =
its=20
pages aren't written to browser's cache (using cache-related HTTP =
response=20
headers). The attacker's malicious server will always be able to demand =
its=20
fake page to be cached and there's nothing the legitimate web server can =
do
to
prevent it.=20
- 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D
1) Browsers with the "Do not save encrypted pages to disk" option =
enabled
are=20
not affected by this issue as the fake document(s) can't be written to=20
browser's cache.=20
2) Web servers that ignore browser's "If-Modified-Since" header and =
always=20
send the requested document are not "spoofable" using this =
vulnerability.
Solution
=3D=3D=3D=3D=3D=3D=3D=3D
Cumulative Security Update for Internet Explorer (834707) was released,
which=20
fixes this issue. Affected users can install it via Windows Update or by =
downloading it from
http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx
Note that Windows XP Service Pack also fixes this issue on Windows XP.
Workarounds
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Browser
-------
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=20
afterwards to remove any malicious documents.
Servers
-------
If you're running a critical web site and don't want to rely on your
visitors=20
to install the patch, implement a workaround or even know about this =
issue,=20
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=20
responds with "304 - Not Modified" response, preventing the server from =
ever
sending such a response will thwart it. Following, we provide specific=20
solutions for IIS and Apache web servers. All solutions are aimed at
removing=20
"If-Modified-Since" headers from browsers' requests, effectively =
bypassing=20
server's "Not Modified" functionality.
Internet Information Services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We wrote a simple, minimum overhead ISAPI filter (24 lines of code) that =
intercepts browsers' requests and removes any "If-Modified-Since" =
headers
from=20
it. The filter is available on our web site at=20
http://www.acrossecurity.com/aspr/misc/if-modified-since-eliminator.zip=20
(Visual C++ project)
[Remember to always review the source code before using it!]
Apache 1.3
~~~~~~~~~~
Edi Weitz from Germany wrote a simple Apache module called
mod_header_modify,=20
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=20
http://weitz.de/mod_header_modify.html
Note: Apache must be built with DSO support.
[Remember to always review the source code before using it!]
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
Acknowledgments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We would like to acknowledge Microsoft Security Response Center for =
prompt
and professional response to our notification of the identified
vulnerability.
References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[1] ACROS Security, "Bypassing Warnings For Invalid SSL Certificates In=20
Internet Explorer"
http://www.acrossecurity.com/aspr/ASPR-1999-12-15-1-PUB.txt
Company Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D
ACROS d.o.o.
Makedonska ulica 113
SI - 2000 Maribor
e-mail: security@acrossecurity.com
web: http://www.acrossecurity.com
phone: +386 2 3000 280
fax: +386 2 3000 282
ACROS Security PGP Key
http://www.acrossecurity.com/pgpkey.asc
[Fingerprint: FE9E 0CFB CE41 36B0 4720 C4F1 38A3 F7DD]
ACROS Security Advisories
http://www.acrossecurity.com/advisories.htm
ACROS Security Papers
http://www.acrossecurity.com/papers.htm
ASPR Notification and Publishing Policy
http://www.acrossecurity.com/asprNotificationAndPublishingPolicy.htm
Disclaimer
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The content of this report is purely informational and meant only for =
the
purpose of education and protection. ACROS d.o.o. shall in no event be
liable for any damage whatsoever, direct or implied, arising from use or
spread of this information. All identifiers (hostnames, IP addresses,
company names, individual names etc.) used in examples and =
demonstrations
are used only for explanatory purposes and have no connection with any
real host, company or individual. In no event should it be assumed that
use of these names means specific hosts, companies or individuals are
vulnerable to any attacks nor does it mean that they consent to being =
used
in any vulnerability tests. The use of information in this report is
entirely at user's risk.
Revision History
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
October 13, 2004: Initial release
Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D
(c) 2004 ACROS d.o.o. Forwarding and publishing of this document is
permitted providing the content between "[BEGIN-ACROS-REPORT]" and
"[END-ACROS-REPORT]" marks remains unchanged.
=3D=3D=3D=3D=3D[END-ACROS-REPORT]=3D=3D=3D=3D=3D
in
Internet Explorer. It includes workarounds for server operators, =
allowing
them to protect their web services without having to rely on users to =
patch
their browsers.
Regards,
ACROS Security
http://www.acrossecurity.com
=3D=3D=3D=3D=3D[BEGIN-ACROS-REPORT]=3D=3D=3D=3D=3D
PUBLIC
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D
ACROS Security Problem Report #2004-10-13-1
-------------------------------------------------------------------------=
ASPR #2004-10-13-1: Poisoning Cached HTTPS Documents in Internet =
Explorer=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D
Document ID: ASPR #2004-10-13-1-PUB
Vendor: Microsoft (http://www.microsoft.com)
Target: Internet Explorer
Impact: Arbitrarily modifying the content of HTTPS pages shown
in Internet Explorer
Severity: High
Status: Official patch available, workarounds available
Discovered by: Mitja Kolsek of ACROS Security
Current version=20
http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt
Summary
=3D=3D=3D=3D=3D=3D=3D
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=20
cache when the user visits the legitimate site. Furthermore, once the =
user
is=20
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=20
anything suspicious - in contrast to most other SSL content-faking=20
vulnerabilities, where manual certificate inspection alerts the user =
about
the=20
attack.
The attacker can exploit this vulnerability for "replacing" HTML =
documents,=20
images, script files (.js), cascading style sheet files (.css) and other =
static documents on a legitimate secured web server, thereby possibly=20
completely compromising the component of its security provided by the =
SSL=20
protocol.
Product Coverage
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Internet Explorer 6 - affected
All patches applied, up to and excluding Cumulative Security Update for=20
Internet Explorer (834707).
Note: Windows XP Service Pack 2 resolves the issue on Windows XP.
Other versions may also be affected.
Analysis
=3D=3D=3D=3D=3D=3D=3D=3D
In 1999, our company has informed Microsoft about a vulnerability [1] in =
Internet Explorer that allowed the attacker to force IE to communicate =
with
a=20
malicious web server over HTTPS without the browser issuing a warning =
about
an=20
invalid SSL certificate used by that server. To summarize, IE did not =
check=20
the validity of SSL certificates for (1) connections with web servers =
with=20
which a successful SSL connection has previously been established, and =
for
(2)=20
connections established via images or (i)frames. Microsoft has =
subsequently=20
fixed both aspects of this vulnerability.
Recently, we've discovered a somewhat similar security problem in =
Internet=20
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=20
that allows the attacker to "replace" arbitrary static documents on a
secured=20
web server using only DNS spoofing and little or no social engineering.=20
Furthermore, the attack can take place any time before the user actually =
visits the "attacked" web server (note: actually, the browser is =
attacked,
not=20
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=20
default caches all documents except those which web servers instruct it =
not
to=20
cache. While there is a "Do not save encrypted pages to disk" option in =
IE,
it=20
is turned off by default, which means that HTTPS documents are cached by
default.=20
When a web server includes a "Last-Modified" header in its response
containing=20
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=20
the document. The web server, receiving an "If-Modified-Since" header,
checks=20
whether the document it hosts is newer than the one browser claims it =
has=20
cached, and sends the document to browser only if it is newer - =
otherwise,
it=20
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=20
secured web server while the user opens a page on a malicious web =
server.
This=20
fake document can be used to effectively replace an image or HTML (e.g., =
a=20
login form) on the legitimate server, or even to introduce a malicious
script=20
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=20
user's browser ("man in the middle") to redirect requests for the =
legitimate
secured web server to a malicious web server.=20
2. Set up a malicious web server hosting a fake document that will =
poison
the=20
user's browser cache.=20
3. Make the user's browser visit the malicious web server, either using
social=20
engineering or by modifying the HTTP traffic from/to the browser ("man =
in
the=20
middle").=20
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=20
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=20
visits the targeted web site (e.g., a web-banking site). No attacker's=20
activity is required during the user's visit of the legitimate =
("spoofed")
web=20
site. Furthermore, there can be a long pause between steps 3 and 4 =
above,=20
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=20
cache (and hence the fake document) during this period.=20
B. Once on the legitimate secured site, the user has no way to determine
that=20
a fake document (be it an image or an HTML document) is not legitimate -
even=20
a manual SSL certificate inspection will show that the document has come
from=20
the legitimate server. This is, by the way, not the case in most "URL=20
obfuscation" attacks that only modify the apparent URL for web sites or=20
documents and try to trick the user into believing that he is actually=20
visiting some other site - these attacks can generally be detected at =
least
by=20
manual certificate inspection.
Some additional notes regarding this vulnerability:
- While it may be tempting to think that the described attack requires =
quite
a=20
resourceful attacker (poisoning DNS response, getting the user to visit =
a=20
malicious web server), we should remember that SSL (and HTTPS) protocol =
is=20
being used for defending against this exact type of attacker - the =
attacker=20
being able to monitor and possibly modify network traffic between =
browser
and=20
server.=20
- The attacker can use any web server certificate issued by any one of =
the=20
IE's trusted issuers (currently 109 of them!), which can be long expired =
and
issued for any host name. A useable certificate can also be bought by =
any=20
commercial trusted CA like Verisign or Thawte.=20
- 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=20
images, index.html will be, as the first request, requested =
unconditionally=20
(i.e., without "If-Modified-Since" header), while the images will be
requested=20
with "If-Modified-Since" header. Consequently, it is easier to =
successfully=20
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=20
connection.=20
- Malicious scripts can also be introduced via fake cascading style =
sheets.
- The attacker can only poison sites that respect "If-Modified-Since"
headers.=20
Furthermore, the attacker can only poison documents (HTML documents, =
images,
..JS files etc.) that the web server considers static and therefore =
subject
to=20
"If-Modified-Since" logic.=20
- It makes no difference if the targeted web server tries to make sure =
its=20
pages aren't written to browser's cache (using cache-related HTTP =
response=20
headers). The attacker's malicious server will always be able to demand =
its=20
fake page to be cached and there's nothing the legitimate web server can =
do
to
prevent it.=20
- 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D
1) Browsers with the "Do not save encrypted pages to disk" option =
enabled
are=20
not affected by this issue as the fake document(s) can't be written to=20
browser's cache.=20
2) Web servers that ignore browser's "If-Modified-Since" header and =
always=20
send the requested document are not "spoofable" using this =
vulnerability.
Solution
=3D=3D=3D=3D=3D=3D=3D=3D
Cumulative Security Update for Internet Explorer (834707) was released,
which=20
fixes this issue. Affected users can install it via Windows Update or by =
downloading it from
http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx
Note that Windows XP Service Pack also fixes this issue on Windows XP.
Workarounds
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Browser
-------
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=20
afterwards to remove any malicious documents.
Servers
-------
If you're running a critical web site and don't want to rely on your
visitors=20
to install the patch, implement a workaround or even know about this =
issue,=20
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=20
responds with "304 - Not Modified" response, preventing the server from =
ever
sending such a response will thwart it. Following, we provide specific=20
solutions for IIS and Apache web servers. All solutions are aimed at
removing=20
"If-Modified-Since" headers from browsers' requests, effectively =
bypassing=20
server's "Not Modified" functionality.
Internet Information Services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We wrote a simple, minimum overhead ISAPI filter (24 lines of code) that =
intercepts browsers' requests and removes any "If-Modified-Since" =
headers
from=20
it. The filter is available on our web site at=20
http://www.acrossecurity.com/aspr/misc/if-modified-since-eliminator.zip=20
(Visual C++ project)
[Remember to always review the source code before using it!]
Apache 1.3
~~~~~~~~~~
Edi Weitz from Germany wrote a simple Apache module called
mod_header_modify,=20
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=20
http://weitz.de/mod_header_modify.html
Note: Apache must be built with DSO support.
[Remember to always review the source code before using it!]
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
Acknowledgments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We would like to acknowledge Microsoft Security Response Center for =
prompt
and professional response to our notification of the identified
vulnerability.
References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[1] ACROS Security, "Bypassing Warnings For Invalid SSL Certificates In=20
Internet Explorer"
http://www.acrossecurity.com/aspr/ASPR-1999-12-15-1-PUB.txt
Company Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D
ACROS d.o.o.
Makedonska ulica 113
SI - 2000 Maribor
e-mail: security@acrossecurity.com
web: http://www.acrossecurity.com
phone: +386 2 3000 280
fax: +386 2 3000 282
ACROS Security PGP Key
http://www.acrossecurity.com/pgpkey.asc
[Fingerprint: FE9E 0CFB CE41 36B0 4720 C4F1 38A3 F7DD]
ACROS Security Advisories
http://www.acrossecurity.com/advisories.htm
ACROS Security Papers
http://www.acrossecurity.com/papers.htm
ASPR Notification and Publishing Policy
http://www.acrossecurity.com/asprNotificationAndPublishingPolicy.htm
Disclaimer
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The content of this report is purely informational and meant only for =
the
purpose of education and protection. ACROS d.o.o. shall in no event be
liable for any damage whatsoever, direct or implied, arising from use or
spread of this information. All identifiers (hostnames, IP addresses,
company names, individual names etc.) used in examples and =
demonstrations
are used only for explanatory purposes and have no connection with any
real host, company or individual. In no event should it be assumed that
use of these names means specific hosts, companies or individuals are
vulnerable to any attacks nor does it mean that they consent to being =
used
in any vulnerability tests. The use of information in this report is
entirely at user's risk.
Revision History
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
October 13, 2004: Initial release
Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D
(c) 2004 ACROS d.o.o. Forwarding and publishing of this document is
permitted providing the content between "[BEGIN-ACROS-REPORT]" and
"[END-ACROS-REPORT]" marks remains unchanged.
=3D=3D=3D=3D=3D[END-ACROS-REPORT]=3D=3D=3D=3D=3D