Friday, May 30, 2008

Flash Vulnerability Info

On 5-27-2008 Symantec issued a 0-day vulnerability alert pertaining to malicious flash (SWF) files circulating in the wild. The initial Symantec report stated that this issue was unknown and that it affected the latest version 9.0.124.0 of flash player and several other Adobe products that processed SWF files. Further analysis of the exploit files determined that the initial categorization of this as 0-day was incorrect and that this was actually a working implementation of the vulnerability described by Mark Dowd of the IBM X-Force team.

For more details on this flash vulnerability (CVE-2007-0071) then take a look at our analysis here:

http://www.snort.org/vrt/docs/analysis/flash-cve-2007-0071.html

Enjoy.

How to annoy co-workers taking a break

We have a Foozball table here at SF World Domination HQ. It sees a lot of action from various people in the company during lunchtimes. Unfortunately, it is located close to the VRT lair. So close in fact, that we are able to run wire to a speaker strategically placed in the ceiling above the table. Once the speaker had been placed into position and the wires run back to the lair, the other ends of the wire were attached to a pair of desktop speakers connected to a laptop containing mp3s of some of the most hideous music known to man.

All we had to do was wait for the first set of victims. Sure enough, right on time, luncheon arrived and so did the unsuspecting groovers. A dose of Abba's "Dancing Queen" was enough to send them scurrying out and back to their part of the building.

The results so far: VRT 3 - IT Staff 1.

UPDATE: VRT 1 - Martin Roesch, Sourcefire CTO 0

The next victims can expect to be "Rick-Rolled", yes, we are that evil. (we will get some pictures of the debacle soon, hopefully we can catch some folks dancing too)

Power over Ethernet and Snort

Lurene correctly points out that vulnerability research is often a series of failures, but that what you learn as you work through the failures will often come in useful in the future. Recently we had a strong desire to put a snort sensor in-line with a wireless access point. While in the end we were unable to achieve the desired result, we had to go through a series of iterations in order to get the snort sensor to be able to see the traffic and still have the access point working, and we picked up some useful information about power over Ethernet.

Power over Ethernet (PoE or Data Terminal Equipment (DTE) Power via Media Dependent Interface (MDI), as our IEEE overlords put it) can be provided in two different pinouts. Alternative A passes power over conductors 1, 2, 3 and 6. This means that power is passing over the same wires as the data is. This can also be called ‘phantom power’ and appears to be the standard way that Cisco chooses to supply power. Alternative B passes power over conductors 4, 5, 7 and 8, which are not used in 100Base-TX cabling, but are in Gigabit Ethernet and 100Base-T4 networks. As it turns out, certain devices only work with Alternative B power, and this comes in handy later.
The target wireless access point receives its power via PoE. We knew this would be an issue because the Snort sensor we were using did not have the means to supply power over Ethernet. Also, because the power was being sent across data line, not the free pairs, we couldn’t use any wiring tricks to route the current around the sensor. In a somewhat insane moment, we considered pulling the power off of the data lines and reintroducing it to the alternative B wires. This also wouldn’t have worked, because the 802.3af protocol requires a powered device check, in which the switch looks for 25K ohm resistance while passing DC over the powered pairs. The sensor would not pass this check, so no power would be placed on the data wire.

Now, skipping past some recon, luck and a small bit of social engineering, we find out that our VOIP phones don’t support phantom power and require that power be passed over the free pairs. In order to support this, each phone has a dongle that acts as an intermediary to the Cisco switches and moves the power from the data lines to the free pairs. Also, the dongle passes the 25k ohm test, so we don’t have to worry about that either. So now we can ensure that power is supplied, and that the power runs on non-data lines. All that is left is to route the power around the sensor.

We find an unused patch panel in the data center and Patrick runs out to get a seven dollar punch down tool. The idea is straightforward. We use four ports on the patch panel: Port one is in from the dongle, port two is out to the sensor, port three is in from the sensor’s second bridge port and port four is out to the access point. From port one we grab the free pairs that have the power on them, 4,5,7 and 8 or brown, brown/white, blue and blue/white and run them to port 4, bypassing the sensor. The data wires, 1, 2, 3 and 6 or green, green/white, orange and orange/white, are wired straight to port two. Port three patches the data lines straight to port four. See the diagram below:

PoE Bypass Diagram

Once the panel was ready, we could begin testing. The last remaining hurdle was to remember that the patched connection from the sensor’s second port to the access port requires a cross over cable (future implementations will take care of that in the punch-down). Once that was done we were where we wanted to be: The wireless access point was powered, the Ethernet cable from the wireless access point ran into an inline snort sensor where we could see all of the traffic.

There were several other solutions we looked at. One that would have worked would have been to use an inline PoE device that supplies 802.3af compliant power to an unpowered Ethernet line. We would have placed this between the sensor and the wireless access point. Another idea is drawn out on Patrick’s white board as a series of calculations that were being made in an attempt to supply power directly to the line, again on the access point side of the sensor. I’m not sure whether it would have worked, or how many Ethernet cards we would have ended before we got it right, but the whiteboard sure looks impressive.

We did some other interesting things, including NOPing out some checks in Snort to let us do an overly long content replace. More on that, and maybe some information on how the Muppets relate to the Rick Roll craze a bit later her on the VRT blog.

References:
Catayst 6500 Series Switch Installation Guide – Transceivers, Module Connectors, and Cables Specifications, url: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Chassis_Installation/Cat6500/0bcabcon.html

PoE IEE 802.3af White Paper, url: http://www.cisco.com/en/US/netsol/ns340/ns394/ns147/ns412/networking_solutions_white_paper09186a008026641c.shtml

Tech Info – LAN Wiring and Pinouts, url: http://www.zytrax.com/tech/layer_1/cables/tech_lan.htm

Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications, url: http://standards.ieee.org/getieee802/802.3.html

AUTHOR: Matthew Olney, Research Engineer, Sourcefire Vulnerability Research Team