The 802.1x (or 1x, for short) port-based network access control is thought to be a solution to the problem of rogue systems connecting to the corporate networks:
IEEE 802 Local Area Networks ? are often deployed in environments that permit unauthorized devices to be physically attached to the LAN infrastructure, or permit unauthorized users to attempt to access the LAN through equipment already attached. Examples of such environments include corporate LANs that provide LAN connectivity in areas of a building that are accessible to the general public, and LANs that are deployed by one organization in order to offer connectivity services to other organizations (for example, as may occur in a business park or a serviced office building). In such environments, it is desirable to restrict access to the services offered by the LAN to those users and devices that are permitted to make use of those services. ? IEEE 802.1x Standard
The expectation is that networks using a 1x scheme will block access to the segment on which 802.1x is deployed, as well as access to the whole network, since hubs, bridges and routers will reject packets from unauthorized systems. ? Robert Moskowitz, TruSecure Corporation
We believe 802.1x will be key to all scan and block and Microsoft needs to get on board. We'd also like to see Microsoft and Cisco make their 802.1x supplicants be compatible. ? John Pescatore, Gartner Group
In this whitepaper I introduce the concept of shadow host and discuss the conditions when a 1x-enabled network allows unauthorised connections.
The proof of concept network is shown on the figure:
The lab network has:
· Windows 2000 Active Directory domain
· Microsoft IAS running on Windows 2000 SP4, configured to authenticate 802.1x clients against Active Directory using PEAP-MSCHAPv2
· Cisco 2950XL switch, configured as a RADIUS client, with 802.1x port authentication enabled
· Victim host: a Windows XP computer, which is a member of the domain. RADIUS policy allows the computer and a group of test users to connect to the 1x-enabled ports
· Attack host: a Linux computer with Netfilter
· A hub connected to the 1x-enabled switch port. The victim host is re-connected through the hub, together with the attack host
The attack host is configured as a shadow to the victim host. Shadow host has the same MAC address and IP address as the victim host, is connected to the same managed switch port and has a firewall configured to drop all inbound connections that are not responses to communication initiated by the shadow host. No prior knowledge of the victim host configuration is required: all necessary information can be obtained by sniffing network traffic comping through the hub.
With the above configuration, the shadow host can connect to the lab network after the victim host authenticates against the RADIUS server and 1x activates the Cisco switch port, and use all stateless IP protocols like ICMP and UDP. That is, the shadow host could ping any host on the lab network, receive DHCP lease (naturally, it gets the same IP address as the victim host), but cannot use TCP.
TCP doesn?t work because the victim hosts resets TCP connection initiated by the shadow host after the second stage of the TCP three-way handshake:
· Shadow sends TCP SYN to a Lab host
· The Lab host sends SYN-ACK
· Victim receives unexpected SYN-ACK and sends RST to the Lab host
· Lab hosts acknowledges the reset, Shadow receives unexpected RST-ACK and TCP connection dies.
(Thanks to Cookie who explained why that wouldn?t work before we?ve built the PoC and started capturing traffic).
However, there is one exception to the rule: if the victim host is running a firewall that drops unsolicited SYN-ACKs, the shadow host has full connectivity to the lab network. Windows Firewall, configured through AD GPO to deny all, can be such firewall. That is, full locking down of the Windows client allows full connectivity from the shadow host to the lab network.
Potentially there is a way to avoid the TCP problem by removing hub and configuring shadow host as a bridge, then getting it to suppress resets from the victim host.
I don?t have working wireless shadow host yet: even though wireless networks are using shared media, shadow host with unmodified 802.1b client won?t associate to the access point where the victim host is already connected. I think rewriting BSSID association request code will allow us make some progress. Rudimentary authentication schemes like NoCatAuth will probably allow shadow hosts to the network, and there might be further implications.
In our scenario, the only requirement for connectivity to the 1x-protected network was access to the physical port in order to insert a hub between the victim host and the network switch. The victim host itself is not compromised or tampered with: it?s fully operational and is the only host that is connected to the network from network management point of view. Authentication credentials are not readily available to the shadow host, either. The shadow is completely invisible until it starts to generate network traffic.
The approach used for compromising the network connection is vendor- and platform-independent. Shadow host will run equally well on the common switched networks, 802.1x-enabled switched networks, and networks utilising proprietary authorisation schemes like Cisco Network Admission Control. It would not help in cases of full end-to-end mutual authentication of network communication ? IPsec and SSL. Until such protocols are implemented, physical security of the corporate cabling infrastructure is as important as the information transmitted over the cables and computer systems that are connected to it. With WPA in wide use, I would consider wireless networks more secure for the time being.
 802.1x - Port Based Network Access Control (http://www.ieee802.org/1/pages/802.1x.html)
 Cisco Announces Availability of Network Admission Control Solutions (http://newsroom.cisco.com/dlls/2004/prod_062104b.html)
 Microsoft Network Access Protection (http://www.microsoft.com/nap)