Posts Tagged ‘Cisco’

Cisco IP Phones – The next easiest venue into your NACed network?

May 8, 2007

VoIP, IP Phones, and the gear from Cisco always fascinated me. In the past I have published several advisories and papers regarding vulnerabilities and security issues I have found with the Cisco IP Phone gear.

Looking into how Cisco handles IP Phones with their NAC solutions caused me to raise some interesting questions regarding it.

The IP phones identify/authenticate to Cisco NAC solutions using CDP packets. These packets can be easily spoofed. Usually a computer will be hooked to the IP Phone. The IP phone would assign a different VLAN tag for traffic from the IP phone, and a different VLAN tag for the computer date. What if a hub is connected to the wall, the computer is disconnected from the IP phone and now is connected to the hub and uses the VLAN tag of the Voice VLAN? What if the computer spoof an “authenticating” CDP packet?

Not even mentioning the fact the IP phone can be disconnected and the computer may completely abused its MAC address and the special authentication way of it.

You get the picture.

Advertisements

Suspended for hacking Cisco Clean Access NAC

April 27, 2007

Tim Green over at NetworkWorld has interviewed me for an article with an interesting story. A sophomore student over at the University of Portland was recently suspended for a year since he managed to find a way to circumvent Cisco’s Clean Access NAC. The student managed to find several vulnerabilities with Cisco’s CCA circumventing it to believe its operating system and A/V adhere to the network access policy, where in truth they were not.

Some more information can be read at The Beacon, the students paper over at the University of Portland.

This story, and others, that were published recently, demonstrates how a questionable device, that is not trusted as is, may falsify information part of a posture validation check. This proves one of the points I have raised during my summer BlackHat 2006 presentation were I have raised these same issues.

The first lesson you learn with information security is that there is no such thing as client-based security.

What lessons should we learn from the latest Cisco NAC Framework Vulnerabilities?

April 6, 2007

At the recent BlackHat Europe 2007 two researchers, Dror-John Roecher and Michael Thumann, presented on attacking Cisco NAC framework.

They discussed two main issues with the Cisco NAC framework.

The first relates to the fact that a NAC solution cannot trust the information coming back from an element. It is since this information is provided by the element, the same one the NAC solution does not trust in the first place.

This point is valid for all NAC solutions and was raised by me in my Bypassing NAC presentation at BlackHat 2006 in the summer (my recent version of the presentation can be downloaded from here).

The second issue is that for two variants of Cisco NAC framework (NAC-L3-IP, and NAC-L2-IP) there is no form of user authentication mechanism other then verifying the posture of the client machine (i.e. A/V, FW, patches, SP, etc.).

The German researchers managed to spoof the posture validation between a Cisco Trust Agent to the Cisco ACS (Access Control Server), and to gain access to the network even if the element is not compliant with the posture validation checks. Their attack would work when either using NAC-L3-IP and NAC-L2-IP. If NAC-L2-802.1x will be used, then user authentication will be mandatory (actually this is the response Cisco had issued to this manner).

The conclusion here is simple, posture validation cannot replace user authentication. It should be part of the overall NAC process, but only after the element and the user are authenticated.