Monday, July 30, 2007

Cisco Multiple Products Wireless ARP Requests Denial of Service

Secunia Advisory: SA26161
Release Date: 2007-07-25
Last Update: 2007-07-27


Critical: Moderately critical
Impact: DoS
Where: From local network
Solution Status: Partial Fix


OS: Cisco 4400 Series Wireless LAN Controller
Cisco Catalyst 3750 Series Integrated Wireless LAN Controllers


Software: Cisco Catalyst 6500 Series Wireless Service Module (WiSM)


CVE reference: CVE-2007-4011
CVE-2007-4012

Description:
Some vulnerabilities have been reported in multiple Cisco products, which can be exploited by malicious people to cause a DoS (Denial of Service).

1) Certain Cisco Wireless Lan Controllers (WLCs) do not correctly handle unicast ARP requests from MAC addresses that are unknown to the Layer-2 infrastructure, causing a second WLC to incorrectly re-forward the ARP request back into the network.

Successful exploitation allows to cause a DoS due to heavy network traffic, but requires that two WLCs are attached to the same set of Layer-2 VLANs and each have a context for the wireless client, e.g. if a guest WLAN (auto-anchor) is used or after a Layer-3 (cross-subnet) roam.

2) Broadcast ARP packets for the IP address of a known client context are not correctly handled and re-forwarded into the network.

Successful exploitation allows to cause a DoS due to heavy network traffic, but requires that more than 1 WLC is installed for the corresponding network and that the arpunicast feature is enabled.

Note: This affects version 4.1 only.

3) In certain Layer-3 (L3) roaming scenarios (e.g. when wireless clients move from one controller to another and the wireless LAN interfaces are configured on different controllers which are on different IP subnets), a foreign controller may send a unicast ARP request out to a local VLAN.

The vulnerabilities are reported in software versions 4.1, 4.0, 3.2, and prior in for the following products:
* Cisco 4100 Series Wireless LAN Controllers
* Cisco 4400 Series Wireless LAN Controllers
* Cisco Airespace 4000 Series Wireless LAN Controller
* Cisco Catalyst 6500 Series Wireless Services Module (WiSM)
* Cisco Catalyst 3750 Series Integrated Wireless LAN Controllers

Solution:
Version 3.2:
Reportedly, an update will be available 27-July-2007.

Version 4.0:
Reportedly, an update will be available 27-July-2007.

Version 4.1:
Update to version 4.1.181.0.

Provided and/or discovered by:
Reported to the vendor by customers.

Changelog:
2007-07-27: Added CVE reference.

Original Advisory:
http://www.cisco.com/warp/public/707/cisco-sa-20070724-arp.shtml

Labels: ,

Friday, May 4, 2007

RFID Firewall

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 tags

By 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 bolts

The 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 attacks

The 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 future

Version 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: , ,