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.
I remember you explaining the problem @ ITForum last year. Your session certainly provoked much debate. Unfortunately sooooo many people seem to view 802.1X authn as a silver bullet ;-(
I trust that you will be delving into more detail @ ITForum in Barcelona this November.
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.
Great article, Steve. What is your opinion on Cisco NAC as an alternative til IPsec?
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.
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.
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?
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.
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?
NetNerd -- no, the "victim" can be disconnected and reconnected as I described. Of course the hub never makes a connection, because it can't, and nowhere do I discuss having a hub without a supplicant. The "victim" will reconnect (most likely the next morning when the user returns to work) through the hub. The presence or absence of a hub between the victim computer and the switch doesn't change the 802.1X authentication sequence at all.
Most host firewalls already drop unsolicited ACK-SYNs.
Ordinary users will probably ignore the dialog box warning of a duplicate IP address. The dialog box speaks in a language users don't know ("IP address? What's that?") and so people will simply click OK to make the dialog go away.
Edward Ray -- the point of my article is to raise awareness that 802.1X, by itself, is ineffective at stopping the very attack many people deploy it for: thwarting rogue machines. OTOH, domain isolation with IPsec, by itself, *does* address the threat. You will, however, have to allow the bad guy on the network -- but at least he can't do anything other than flood it with traffic, but of course you'd recognize such a DoS attempt and shut down his switch port. Do IPsec and 802.1X make sense when combined? Sure, if you want to control both access and entry. This is oftentimes not possible, though.
J Record -- EAP-MD5 is specifically disallowed for wireless 802.1X. Honestly, I don't remember if it's also disallowed for wireless. I'll have to check again.
You're right about the location of the certificate. Oops! I'll have to reword that.
See reply to NetNerd about users and dialogs. Regarding port security for duplicate MACs, remember we've got two machines, with the same MAC and IP, connected to a *single* switch port. As far as the switch is concerned, there's only one machine.
See http://www.microsoft.com/windowsserver2003/technologies/networking/nap/default.mspx for more information on NAP. It's a Longhorn feature, not Windows Server 2003, so um ignore the fact that it's in the 2003 URL tree :)
" 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!
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.
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 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.
Your comments on wired 802.1x and the flaws are accurate, but you fail to identify what you're typically trying to mitigate in these scenarios - raising the bar on security, not a security silver bullet.
I've had this conversation with several people at MS and was in Redmond for discussions on this topic about 3 weeks before this whitepaper was posted.
SECURITY IS ABOUT ADDING LAYERS OF PROTECTION, not about expecting absolute solutions. If someone can bring their own workstation, wireless hub, and have access to one of my workstations all without being harrassed, I'm pretty well fubar anyway - assuming I only ever put ANY single layer of protection in place.
Instead, 802.1x wired is a very nice complimentary solution to Layer 2 NAC/NAP (depending on which solution you're interested in), along with IPSec (where feasible), network segregation, network based security vulnerability assessment, log reviews, Personal Firewalls, and Hardware firewalls to protect the crown jewels.
Your article should state that 802.1x is not a silver bullet in the wired OR WIRELESS space. It's not that 1x is unsuitable to the task - it just mitigates different risks (or the same risk, to a lesser degree).
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?