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
- - - - - - - - -
Vista Windows Firewall Incorrectly Applies Filtering to Teredo Interface
------------------------------------------------------------------------
SUMMARY
Windows Firewall for Windows Vista is "the Microsoft provided firewall
solution. It is installed and enabled out-of-the-box, with most ports
filtered".
Due to an implementation issue, the Windows Firewall does not apply
firewall rules correctly on the Teredo Interface. This allows a level of
remote access to TCP and UDP ports and services that exceeds what
Microsoft expected and what an administrator would expect.
DETAILS
Teredo is an IPv4 to IPv6 transition mechanism for IPv6-capable hosts that
are located behind an IPv4 NAT. It is installed and enabled out-of-the-box
on Windows Vista. It provides end-to-end automatic tunneling through a NAT
by tunneling IPv6 over IPv4 UDP packets. Once a Teredo interface becomes
set up (in Teredo terminology: qualified), anyone on the Internet that
knows the Teredo address can send it packets and possibly establish
sessions. This capability persists until the Teredo interface becomes
de-qualified for some reason; while in general Teredo works to keep an
Teredo interface qualified, under some circumstances, Vista will shut down
the interface after 60 minutes of inactivity.
By design, Windows Firewall is supposed to block all access to ports on
the Teredo interface, except for cases where access-though-Teredo is
specifically requested (through the "Edge Traversal" flag in the firewall
rule being set). However, due to a logic bug, it does not apply this
restriction. Instead, any port that is accessible on the local network is
also accessible from any host on the Internet over the Teredo interface,
even if the firewall rule specifies "remote address=local subnet".
The level of exposure depends on current firewall rule settings. An
out-of-the-box Vista installation with a network profile set to "private"
will expose the following port across the Teredo interface:
* TCP port 5357 (Web Services for Devices)
An exposed service may reveal sensitive or useful information to an
attacker. In combination with a vulnerability in the service it may also
provide an avenue of attack. In addition, a service that was designed to
only be accessible in trusted circumstances may simply not present an
adequate security posture for general Internet access.
It is not considered difficult for a remote user to cause the Teredo
interface to become qualified. Teredo can become qualified simply because
Vista or some application wants to use IPv6 for whatever reason. The
attacker would then just have to guess the Teredo address or learn it by
some means and they would be able to access any open ports.
Teredo will also become qualified if the address of a peer represents a
Teredo address (perhaps even if the peer has a native IPv6 Internet
access). Thus an attacker can send a URL of this form
"http://[2001:0:...]/..."; through e-mail, IM, HTTP, etc, and if the URL is
followed, the attacker will both know the Teredo address of the victim and
will have had the victim become qualified. A HTTP redirect to such a URL
would also work and may be more stealthy. Reportedly, Vista will not
return AAAA records corresponding to Teredo addresses, so attackers Teredo
address would have to be listed by address and not by hostname.
Vendor Response:
This has been patched in MS07-038.
Recommendation:
Apply the patch contained in MS07-038.
In addition you should consider whether Teredo poses an acceptable level
of exposure to your network. If it provides too much exposure (e.g., due
to bypassing network-based security controls), you should disable Teredo
and block it on your network
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3038>
CVE-2007-3038
ADDITIONAL INFORMATION
The information has been provided by Jim Hoagland / Ollie Whitehouse.
The original article can be found at:
<http://www.symantec.com/content/en/us/enterprise/research/SYMSA-2007-005.txt>
http://www.symantec.com/content/en/us/enterprise/research/SYMSA-2007-005.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.
