August article: 802.1X on wired networks considered harmful

Several months ago I learned from Svyatoslav Pidgorny, Microsoft MVP for security, about a problem in 802.1X that makes it essentially useless for protecting wired networks from rogue machines. Initially I was a bit skeptical, but the attack he described is in fact true -- I've seen it myself now. So I've been explaining the attack at conferences lately and have also included information about it in the book. However, I don't believe the danger presented by wired 802.1X is getting enough reach, so I've written about it in the August security management column.

As you read the article, remember that the vulnerability enabling the attack is a fundamental weakness in the protocol -- it authenticates only upon connection establishment and assumes all traffic after authentication is legitimate. The vulnerabiliy exists in wired networks because there's no follow-on packet authentication. You really should be using domain isloation with IPsec to thwart rogue machines, and at the article's end are links to information about that. Also, understand this particular vulnerability isn't present in 802.1X-protected wireless networks, because the authenticators and supplicants have established authentication and encryption keys that protect individual 802.11 frames.

Comments

• Anonymous
  August 11, 2005
  The comment has been removed
• Anonymous
  August 11, 2005
  Yeah, the network hardware vendors see 802.1X as something that can require wholesale hardware replacements, so it looks very good to them.
  
  I'm delivering Steve Clark's domain isolation presentation at TechEds Asia, New Zealand, and Australia (and perhaps other TechEds, too). I've added a series of slides showing how the attack works and why 802.1X is inferior to IPsec.
• Anonymous
  August 12, 2005
  Great article, Steve. What is your opinion on Cisco NAC as an alternative til IPsec?
• Anonymous
  August 12, 2005
  I haven't spent any time with Cisco's NAC, so I can't comment on it specifically. Not sure I understand what you mean by "alternative til IPsec," though. You don't need to wait for IPsec -- it's in the products now. You can begin deploying domain isolation today, which will solve most of the rogue machine problems you're having now. Then you'll be ready for NAP when Longhorn ships.
• Anonymous
  August 13, 2005
  In order for the scheme as proposed in Pidgorny's paper to work the "victim" PC would have to be attached to a hub in advance on connecting to a 1X enabled switch port. This really isn't a victim as much as a confederate. If the hub attaches to a 1X enabled switch port by itself it creates link; which starts the 1X auth process. Hubs wouldn't respond to an auth challenge when attached to a 1X enabled port by itself(no supplicant). A device on a port that doesn't respond to that 1X auth challenge usually moves that port to a blocking state.
  
  And then there is the little factoid that got overlooked. The "victim" PC has to have a personal firewall and that firewall has to be configured not to respond to unsolicited SYN-ACKs.
  
  Has anyone else tested this? When I ran this using an XP PC as the "victim" I noticed that XP regularly popped up a window telling me that another host on the network was using the same IP address.
  
• Anonymous
  August 13, 2005
  Hmm. About that "known problem" you said:
  
  "On both Windows XP and Windows 2000, a known problem might surface. If you’ve configured 802.1X only for machine (not machine and user) authentication and you’re using PEAP (not EAP-TLS), and your computer’s machine account password has expired, the computer won’t be able to log onto the domain. Two DLLs involved in client authentication don’t exchange messages properly—mainly because they were written long before 802.1X was part of the design. It’s pretty much impossible to change these DLLs; it would require completely redesigning them and there is too much other dependency risk. You must be configured with PEAP and machine-only authentication."
  
  Given that IEEE 802.1X was first released in 1998 and revised in 2001 you'd think that Microsoft might be able to get an implementation that worked for Windows XP? It's even more amazing when you consider that Microsoft helped write the PEAP draft! Is there some 1995 era code in Windows XP?
  
  
• Anonymous
  August 14, 2005
  802.1X by itself is a poor solution, just like IPSec on its own is a flawed security strategy.
  
  The layered approach to security is best IMHO. Like I told Jesper J. when he said that I could not implement IPSec encryption of ALL SMB/port 445 traffic on my LAN due to bootstrapping issues (hint: use of certificates instead of Kerberos for authetications mitigates this issue) the MS viewpoint on security is very one-dimensional. There are two types of computer networks; one that has been compromised and one that will be. It is the degree of compromise one seeks to control. 802.1x for wired auth is just one of many one can and should use.
• Anonymous
  August 15, 2005
  Good article Steve.
  
  A few comments:
  "Windows supports two different EAP methods:"
  I believe EAP-MD5 is also supported (Although I would not recommend it's use.
  
  "Each switch requires a digital certificate which it presents when authenticating to clients. "
  A digital certificate is not required on the Authenticator (Switch or Access Point). Certs are only required on the the Authentication Server (RADIUS) for EAP-TLS & PEAP and on the client supplicant for EAP-TLS.
  
  "Next the attacker configures the shadow computer’s MAC and IP addresses to be the same as those on the victim computer."
  Won't this cause an IP address conflict?
  Port security measures should be put in place to detect duplicate MACs.
  
  I agree that IPSEC for domain isolation is a good solution.
  Where can I find more info on NAP?
  Thanks.
• Anonymous
  August 16, 2005
  The comment has been removed
• Anonymous
  August 17, 2005
  @stile
  
  " Is there some 1995 era code in Windows XP? "
  
  LOL! The hosts/lmhosts files still live in system32/drivers/etc even in the Longhorn beta... that's gotta be some ancient code required that!
• Anonymous
  August 23, 2005
  The insertion of a hub will trigger a port down/up signal on the authenticator. IMO, the authenticator may in this case go ahead an send a "EAPOL-Request Identity" message to the potential supplicant (in this case the hub), even before the supplicant starts the process with a EAPOL-Start message.
  
  I don't know what happens in the standard if an authenticator does not get an answer to a "EAPOL-Request Identity" message. Simply ignoring all EAPOL-Start requests until the port changes state again would thwart all such hub insertion attacks.
  
  Thoughts?
• Anonymous
  August 23, 2005
  Follow-up:
  
  Inserting a Hub will change the controlled Port state to unauthorized. If
  the "EAPOL-Request Identity" is not answered by the supplicant, the port
  will stay unauthorized. The supplicant can request authorization (and
  will likely do so, having figured out that something is wrong) using the
  "EAPOL-Start" packet. Ignoring all EAPOL-Start requests until the port
  changes state again would make the attack only slightly more difficult
  (connecting the supplicant to the hub before connecting the hub back to
  the authenticator).
  
  The approved standard does not seem to make authentication depending
  on individual supplicant's MAC addresses a requirement. IP/MAC address
  takeover would not even be necessary if this is true.
  
• Anonymous
  August 26, 2005
  The comment has been removed
• Anonymous
  August 31, 2005
  Lost in the body of the article is this statement:
  
  "Note that requiring 802.1X will eliminate your ability to use PXE boot in your network."
  
  Is this, in fact, true? I've been searching the web for definitive answers. Cisco has a different take. Any experts that can clarfiy under what conditions PXE and 802.1x are incompatible?
• Anonymous
  September 06, 2005
  The comment has been removed