Vista Windows Firewall Incorrectly Applies Fltering to Teredo InterfaceAuthor: Jim Hoagland / Ollie Whitehouse
Release Date: 10-07-2007
Application: Windows Firewall (Vista version)
Platform: Windows Vista (RTM and RC2 builds known affected; XP, 2003 would not be affected)
Severity: Unintended remote exposure to services
Vendor status: Resolved in MS07-038
CVE Number: CVE-2007-3038
Reference: http://www.securityfocus.com/bid/24779
Overview: 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
Labels: Bug, Firewall, Microsoft
Feeling insecure about who might be trying to access your RFIDs? Here is a portable firewall from Melanie Rieback to provide a modicum of protection. The project web site is
rfidguardian and the below article is from Ars Technica.
=====================================================================
The RFID Guardian: a firewall for your tagsBy Nate Anderson | Published: May 01, 2007 - 11:53PM CT
Here, there, and everywhere
Don't carry RFID? You might be surprised; the short-range ID technology is currently found in everything from US passports to swipeless credit cards to public transit passes to World Cup tickets to car keys to the building access pass for your office building. A few of the digerati even elect to have RFID implants from VeriChip slipped beneath their skin in order to use them as cashless payment systems.
Much of the information on these chips can be read without exotic equipment, assuming an attacker can get within several feet with a concealed RFID reader. Unfortunately, most tags give users no control over when they respond to queries, and they offer no notification, which means that sensitive data could be at risk in public places.
The solution, for those concerned about such things, has so far been low-tech: smashing the chip with a hammer appears to be the preferred method for passports, but it is technically illegal and could lead to unpleasantness at customs.
A new tool from a graduate student at the Vrije Universiteit in Amsterdam offers the first real-time cloak of protection to users concerned about security, and no hammer blows are required. The RFID Guardian is essentially a firewall that can prevent or allow RFID queries, and can do so on a per-tag basis. Melanie Rieback, the Guardian's designer, describes it as a portable, battery-powered device for personal RFID privacy—but even if you aren't concerned about men in dark sunglasses snatching your passport data, the selective jamming tech in this diminutive device is fascinating stuff.
I had a chance to sit down with Rieback during her recent trip to the United States, and she explained how the device works, what's coming in version 3.0, and why she has no plans to profit from the technology.
"I'm definitely not anti-RFID," she explains. "I think there's a lot of great things you can do with it, but I just think that like any other technology, they need to take security and privacy into consideration."
Here's how the RFID Guardian gives that power to the people.
And I need this... why?
RFID got its start as an antitheft tool that soon became important for inventory management. Using RFID chips, it was suddenly simple for shippers to know how many pallets were in a trailer, and retailers could see how many razors were on a store shelf without keeping employees all night to do inventory. RFID received a massive boost when Wal-Mart required RFID tags to be used by all of its suppliers.
Because such commercial deployments emphasize cost over security, most tags still have no access controls, so grabbing a tag's information is relatively simple. Some specialized tags do employ basic cryptography, but this is not always robust. When researchers looked into the encryption found in the ExxonMobil SpeedPass, for instance, the algorithm turned out to use a 40-bit key and was cracked easily by a brute force attack. Tags with stronger cryptography tend to be prohibitively expensive, and thus are not often used.
As the tags showed up in increasingly sensitive applications, security became more of a concern—at least to researchers and privacy advocates. Rieback was one of those people. As a graduate student searching for a Ph.D. dissertation topic, she spent eight months reading computer science research papers and discovered that the number of published works on RFID security could be counted on both hands. "It became painfully obvious that there was a deficiency in the area of RFID, and there is so much work to be done," she says.
So Rieback turned herself into one of the foremost academic authorities on RFID security and went on to develop the first RFID virus as a proof of concept. That got the industry's attention. As Rieback tactfully puts it, there was a "mixed reaction" that even included some personal attacks. But other companies approached her team for consulting assistance within days of publishing the paper.
After doing her part to publicize these security shortcomings of many RFID implementations, Rieback moved on to the RFID Guardian project, which would give people a measure of control over their tags. It became her Ph.D. project, and when she finalizes the next version in the next eight months or so, she should earn her doctorate. Even when that happens, though, she has no plans to drop the project. "I think this is important enough that we should finish it," she says. "We should get it out there."
Eventual plans call for the Guardian to be incorporated into cell phones and PDAs, but the current model is a pocket-sized device that runs on its own battery and provides a circular 1m field of control over RFID tags, jamming any tags that the user does not want read. It sounds simple, but the technology behind it is surprisingly complex—complex enough that the current model uses what Rieback refers to as a "beast" of a CPU, an Intel XScale PXA270. Here's what all that power is for.
Guts and boltsThe Guardian has four basic components: an RFID reader, a radio transceiver, an XScale processor with flash memory, and a power source. Rieback has implemented two common RFID protocols in software (ISO 15693 and 14443), both of which operate at 13.56MHz. Passive tags using these protocols can be read from up to one meter away; higher-frequency tags and those with an active power source extend much further.
The Guardian polls all the tags in its vicinity, along with all queries that might come from other RFID readers. Whenever the Guardian detects a query, it looks up the requested tag's ID number in its internal Access Control List (ACL). The Guardian currently has no external interface for adjusting the ACL in the field, but it does have an RS-232 port for a connection to a PC, which can then be used to update the ACL.
Entries in the ACL can tell the Guardian to prohibit access to a specific tag, or to allow it, or to allow it only to specific readers. The Guardian needs to do this lookup quickly, since it must make a decision about whether or not to jam the tag's response within 320.9µs—the amount of time between the RFID reader's request and the beginning of the tag's transmission back to the reader.
Actually, the Guardian has even less time than this, since 23µs are needed to wake up the software thread that monitors the receiver and another 5µs are needed to to fire up the transmitter before sending a jamming signal. That leaves only 292.9µs for the Guardian to decide about jamming.
This is where the "beast" of a processor comes in handy. In tests, the 520MHz XScale processor looked up a tag's ID number in the ACL in far less time than this, even when the ACL contained hundreds of entries and the sort algorithm was unoptimized.
If the tag in question in supposed to be blocked, the Guardian then jams the tag's response. RFID tags use an anti-collision protocol (called "Slotted Aloha" in this case) so that their responses do not overlap with those from other tags in the area. The system recognized by the Guardian uses 16 timing slots to transmit responses; the tag chooses a slot after running a XOR function on the reader's anticollision mask and the tag's own ID number. The Guardian does the same calculation in order to know which time slot needs to be jammed.
When the time slot comes up, the Guardian generates a relatively massive burst of noise in the two sideband channels used by each tag for data transfer. This is easy to do, since most tags are inductively-powered and are therefore weak; the battery-powered Guardian simply swamps their response with noise. The anticollision system goes on to vary the time slot over the next few query rounds, hoping to find a clear channel to the tag—but the Guardian blocks them each time until the reader simply gives up.
Blocking only the time slots belonging to a specific tag can reveal the presence of that tag to a canny attacker, though, so the Guardian also creates a few collisions when the requested tag isn't actually firing. As Rieback puts it, this "throws in some chaff with the wheat."
Because all of this activity must take place in real-time, the Guardian uses the open-source e-Cos Real-Time Operating System to handle low-level tasks for the Guardian. The software that runs on top of the OS consists of device drivers for the RFID hardware, protocol stacks for various RFID flavors, and data storage libraries. The complete code is 12,694 lines long; for those who want to see it in operation, the project
web site contains high- and low-resolution videos that illustrate how the jamming system works .
Of "kill queries" and DOS attacksThe Guardian provides real-time protection of RFID tags, limiting access only to trusted readers; it can also keep all tags blocked until the user switches it off. But there are a few things it can't do.
One of the most important limitations of the Guardian stems from the way it works. The device can't block queries, only responses. This normally is no big deal, but some RFID tags can respond to special "kill queries" that can permanently disable a tag. The Guardian cannot jam these queries.
The most likely active attack against a device like the Guardian would be a denial-of-service attack that attempts to overload some part of the device—likely its limited radio bandwidth or flash memory capacity. Simple tweaks to the code prevent the Guardian from locking up in most of these situations, though, and attacks against the radio bandwidth would also confuse the tags, which depend on precisely-timed signals.
So despite its limitations, the device looks like a powerful new privacy tool. But will the technology be used by black-hat hackers, especially since the libraries and protocol stacks will be open-sourced? "Of course," says Rieback, but notes that if she doesn't build such a device, others will. The hardware in question isn't even particularly complicated; she just happens to have put it together first.
"There aren't that many privacy-enhancing technologies out there for RFID right now," she says. The Guardian provides one of the first, but it also sends an important message to industry: these tags are not as secure as you think. Tag jamming and spoofing, both of which the Guardian does, are possible with off-the-shelf components. Security needs to be taken more seriously.
Guardians of the futureVersion 3.0 of the device is already being drawn up in Rieback's Amsterdam lab. High on the list of priorities for the new design is a more modular design where the analog electronics would be contained on plug-in baby boards that could be easily removed and altered. That's because the v2.0 Guardian had everything soldered to a single board; when Rieback had a problem with impedance matching, "it was a pain in the butt to try and fix it."
The new version also features an upgraded interface that allows that Guardian to be controlled using Bluetooth and a custom Java applet designed to run on cell phones and PDAs.
Once the design is complete, the board will be professionally produced and then offered—at cost—to the public.
Getting the tech incorporated into cell phones and PDAs would be the next step, though Rieback notes that this would require the design and production of a custom chip, and that she has neither the time or facilities to do that at the moment. "We're taking it one step at a time," she says.
But for a grad student, she's already taken quite a few important steps and produced the only functioning RFID tag protection system. The project has now swollen to include 15 people, three of them full-time employees. Future versions of the Guardian will include more protocols and different frequency ranges, but the basic tech is already in place and working—putting it ahead of most similar projects.
So put away the hammers; if you're worried about the privacy implications of insecure RFID implementations, you'll soon be able to take back a measure of control.
Labels: Firewall, News Article, Wireless
OSVDB ID: 31592
Disclosure Date: Jan 1, 2006
Description: Check Point Firewall-1 contains a flaw that may lead to an unauthorized information disclosure. The issue is triggered when an attacker connects to port 18264 and accesses the internal certificate for the server, revealing the presence of the firewall. This may also disclose certificate revocation lists and other information resulting in a loss of confidentiality.
Vulnerability Classification: Remote/Network Access Required
Information Disclosure Attack
Loss Of Confidentiality
Exploit Available
Verified
Concern
Web Related
Products: Check Point Software Technologies, Inc. FireWall-1 Unknown or Unspecified
Solution: Currently, there are no known upgrades or patches to correct this issue. It is possible to correct the flaw by implementing the following workaround: Restrict access to the Internal Certificate Authority interface to internal hosts.
Manual Testing Notes: http://[target]:18264/
External References:Nessus Script ID:
22094 Vendor URL: http://www.checkpoint.com/products/firewall-1/index.html
Credit:OSVDB does not have information on who discovered this vulnerability. If you have credit information please send it to OSVDB Moderators
Vulnerability Status:
This entry was last updated on Feb 14, 2007. If you have additional information or corrections for this vulnerability please submit them to OSVDB Moderators.
Labels: Advisory, Firewall, Vulnerability
mullware at gmail.com
Date: Sun Jul 16 2006 - 08:23:16 CDT
Vulnerable Products:
Outpost Firewall Pro ver. 3.51.759.6511 (462) And Lavasoft Personal Firewall ver. 1.0.543.5722 (433)
Summary of problem: The firewall runs its windows under a SYSTEM context.
A user with lower privileges than SYSTEM could locate the (open folder) control on some of these windows, terminate the explorer.exe process and then click on the (open folder) control to open a SYSTEM owned explorer shell logging in right over the top of the previous user!
for details see:
http://www.ben.goulding.com.au/secad.html
Labels: Firewall, Microsoft, Vulnerability
Check Point Firewall rules may improperly handle network trafficOverviewCheck Point Firewall CIFS service group may allow unintended traffic to pass through the firewall.
I. Description
Check Point Firewall contains a set of predefined service groups designed to handle different types of traffic associated with a service or collection of protocols. For instance, Check Point firewalls contain a predefined collection of rules to handle traffic associated with the Common Internet File System (CIFS), known as the CIFS service group.
A flaw in CIFS service group implementation may cause traffic not designated as part of the CIFS service group to be handled in an unintended manner. Depending on the configuration of the rules in place, the firewall may allow unintended traffic to pass through the firewall or drop legitimate traffic at the firewall.
II. Impact
Under certain configurations, arbitrary packets may pass through the firewall. This may allow access to hosts that would normally be protected behind the firewall boundary. Additionally, in other configurations, this issue may cause the firewall to deny all traffic.
III. Solution
Check Point suggests changing the name of the CIFS service group to mitigate this issue. For more detailed information on this workaround, please refer to Check Point SecureKnowledge database article SK31196.
Systems AffectedVendor Status Date Updated
Check Point Software Technologies Vulnerable 19-Sep-2005
References
http://www.securityfocus.com/bid/14781
http://www.securityfocus.com/archive/1/409877
http://secunia.com/advisories/16770
http://secureknowledge.us.checkpoint.com/SecureKnowledge/viewSolutionDocument.do?id=sk31196
http://marc.theaimsgroup.com/?l=bugtraq&m=112611529724821&w=2
Credit :This vulnerability was publicly reported by fitz.
This document was written by Jeff Gennari.
Other InformationDate Public 09/07/2005
Date First Published 09/16/2005 04:03:13 PM
Date Last Updated 09/27/2005
CERT Advisory
CVE Name CAN-2005-2889
Metric 4.39
Document Revision 68
Labels: Advisory, Firewall, Vulnerability
------------------------------------------------------------------------
Inside Security GmbH Vulnerability Notification
Revision 1.6 2001-07-14
------------------------------------------------------------------------
The latest version of this document is available at
http://www.inside-security.de/fw1_rdp.html
The proof of concept code is available at
http://www.inside-security.de/fw1_rdp_poc.html
-----------------------------------------------
Check Point FireWall-1 RDP Bypass Vulnerability
-----------------------------------------------
Summary:
It is possible to bypass FireWall-1 with faked RDP packets if the default implied rules are being used.
RDP (Reliable Data Protocol, but not the one specified in RFCs 908/1151, a Check Point proprietary one) is used by FireWall-1 on top of the User Datagram Protocol (UDP) to establish encrypted sessions.
FireWall-1 management rules allow arbitrary eitherbound RDP connections to traverse the firewall. Only the destination port (259) and the RDP command are verified by FireWall-1. By adding a faked RDP header to normal
UDP traffic any content can be passed to port 259 on any remote host on either side of the firewall.
Implied rules can't be easily modified or removed (except all together) with the FireWall-1 policy editor.
Impact:
Given access to hosts on both sides of a firewall a tunnel to bypass the firewall could be built using this vulnerability. Such access could be gained with a trojan horse that uses this vulnerability to connect from the inside back to the machine of the attacker. But also arbitrary connections from the outside to machines behind the firewall (even if they are supposedly totally blocked from the in- and outside by the firewall) can be established, for example to communicate with infiltrated programs like viruses.
Affected systems:
Check Point VPN-1(TM) & FireWall-1(R) Version 4.1
Releases tested:
Build 41439 [VPN + DES]
Build 41439 [VPN + DES + STRONG]
Build 41716 [VPN + DES + STRONG] (SP2)
Vendor status:
The vulnerability has been reported to Check Point and a fix is scheduled for today [2001-07-09]. We want to thank Check Point Software Technologies for their quick reaction.
Detailed description:
As FireWall-1 rulesets are created they are translated into the INSPECT language (similar to C) and by default include the file $FWDIR/lib/base.def which itself includes $FWDIR/lib/crypt.def in line 259. Together they define
protocol names and the so called implied rules (for FireWall-1 management). In line 62 the macro accept_fw1_rdp is defined to accept any eitherbound connection that matches the following characteristics:
- Protocol UDP
- Destination port 259 (RDP)
- RDP Command RDPCRYPTCMD (100), RDPCRYPT_RESTARTCMD (101),
RDPUSERCMD (150) or RDPSTATUSCMD (128).
The RDP command types RDPCRYPT = {RDPCRYPTCMD,RDPUSERCMD,RDPSTATUSCMD} and RDPCRYPT_RESTART = {RDPCRYPT_RESTARTCMD} will permit traversal of faked RDP packets (regardless of the value of NO_ENCRYPTION_FEATURES, undefined by default).
Proof of concept code:
Proof of concept code has been submitted to Check Point. We are planning to make this code publicly available within a few days.
[ Updated 2001-07-13: Proof of concept code was released:
http://www.inside-security.de/fw1_rdp_poc.html ]
Suggested workarounds:
- Comment line 2646 of base.def ( accept_fw1_rdp; )
- Deactivate implied rules in the Check Point policy editor (and build
your own rules for management connections).
- Block UDP traffic to port 259 on your perimeter router.
Solution:
Apply the fix available from Check Point:
http://www.checkpoint.com/techsupport/alerts/rdp.html
Credits:
This vulnerability was found and documented by Jochen Thomas Bauer
and Boris Wesslowski
of Inside Security GmbH, Stuttgart, Germany.
------------------------------------------------------------------------
(C) 2001 Inside Security GmbH
This notice may be redistributed freely provided that redistributed copies
are complete and unmodified, and include all date and version information.
ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY WARRANTY OF NON-INFRINGEMENT OR IMPLIED WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ARE HEREBY DISCLAIMED
AND EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW.
IN NO EVENT WILL INSIDE SECURITY GMBH BE LIABLE FOR ANY LOST REVENUE,
PROFIT OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL
OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF ANY THEORY OF
LIABILITY ARISING OUT OF THE USE OF OR INABILITY TO USE THE INFORMATION
CONTAINED IN THIS SECURITY BULLETIN, EVEN IF INSIDE SECURITY GMBH HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
If any of the above provisions are held to be in violation of applicable
law, void, or unenforceable in any jurisdiction, then such provisions are
waived to the extent necessary for this disclaimer to be otherwise
enforceable in such jurisdiction.
------------------------------------------------------------------------Labels: Advisory, Appliance, Firewall, Vulnerability