 Okay, welcome to 3 o'clock talk at, this is my accent, talk, at DEF CON. This is going to be Gabriel, Ryan talking about owning lettuce, give him a big DEF CON, welcome, come on. I can't hear you. Thanks. You guys awake yet? Fair enough. All right. Got 45 minutes, so like the first like 10 minutes of this is going to be really fast. Where if I can back up from this thing? Can you guys still hear me if I do this? All right, so I work for a company called Digital Silence or a pen testing firm in Denver. I talk more, but I'm going to skip that. So my name is Gabriel Ryan, also known as some circles as Solstice. I'm a co-founder of Senior Security Assessment Manager at Digital Silence. Used to work for a company called Gotham Digital Science. Before that I worked for a DOD contractor in Virginia called OG Systems. Between the two of those companies it's pretty much the best two names in security ever, like OG Systems, that's fucking awesome. Also about me, I'm a red teamer, researcher, new dad, interestingly enough. Hence the dark circles in my eyes. My LinkedIn handle is kind of interesting, it's MS08067. So this is a talk about bypassing particular port security technology. So before we get started we kind of have to go over some introductory information about 802.1x. 802.1x is an authentication protocol. It's designed to provide rudimentary authentication to local area networks and also wireless local area networks. The protocol defines an exchange between three parties, the sublucan, which is the client device that you're going to try to connect to the network, the authenticator, which is the network device that the sublucan is connecting to and providing access to the LAN, and the authentication server, which is a host running deeper inside the network and it's usually running some kind of triple-A software like Radius that actually performs the actual validation. So you can think of the authenticator, you know, the authenticator is going to be like your switch that the device is connecting to, and you can think of it as a gatekeeper, like a security guard. The sublucan is going to connect to it and provide the authenticator with some credentials. And the authenticator doesn't really know what to do with these credentials, so it just forwards them off to the authentication server, which then validates the credentials and then either sends a message back to the authenticator and tells it to either allow the device to access the network or not to. 802.1x is typically a four-step process beginning with initialization, initiation, then we go to EAP negotiation and authentication. We'll talk more about that in a second. So when we connect to a switch port that is protected by 802.1x, it's going to be one of two states. It's going to be authorized, and when it's in the authorized state, traffic is going to be completely unrestricted, at least by 802.1x, and when it's in the unauthorized state, traffic is restricted to only 802.1x traffic. You mentioned the first step of the 802.1x authentication process is on initialization, and what this means is that the switch port is going to connect to the switch port and it's going to start out disabled. The authenticator is going to detect this new connection and enable the switch port, but the switch port is going to start out in an unauthorized state, because we haven't authenticated yet. Then we move to step two, which is initiation, which we're initiating the authentication process. The first step of initiation is actually optional, and this has security implications that we're going to talk about later. The supplicant is going to begin with the supplicant sending an E-Pool start frame to the authenticator. The authenticator is going to receive this and respond to the EAP request identity frame, which gets sent back to the supplicant. At that point, that EAP request identity frame is basically asking who are you, and the supplicant is going to respond with an EAP response identity frame, which contains the username, or an identifier such as username. The authenticator is going to encapsulate that EAP response identity in a radius access request frame, because it can't actually validate the stuff itself, and it's going to forward it off to the authentication server, and then we're going to move from step two to step three, which is EAP negotiation. So, it'll do that when it actually implements authentication using EAP, and EAP, you can think of it as like an API or black box for performing authentication. There's many ways to implement it, but the important part is that there's going to be a set of inputs, you know, kind of like a generic set of acceptable inputs that you can put into it, and you're going to get a consistent output from it, which is either an EAP success or EAP failure or authentication success or authentication failure. So in step three, what's going to happen is that the authentication server and the supplicant are going to haggle for a bit, until they decide on the EAP method they're both comfortable with. When they do, we move to step four, which is authentication. So, this is where we actually perform the EAP authentication. The specific details, as we mentioned, of how this should work are dependent on the EAP method. EAP method is just a fancy way of saying, you know, however you're choosing to implement EAP. But it's dependent on the EAP method chosen between the authentication server and the supplicant. So, this will always result in an EAP success or EAP failure message. That's the important part to remember about this. And if we get an EAP success, the port is going to be set to an authorized state and communication is going to be allowed through that port. Otherwise, it's going to either remain on authorized, or in a lot of cases, they're actually just going to shut down the port entirely and go alert someone, which is bad, if you're an attacker, that is. So, we've been talking a lot about EAP. EAP is short for extensible authentication protocol. Really, like calling it a protocol is like not, or authentication protocol is kind of misleading. It's more of an authentication framework because it's only defining message formats. The actual implementation is wrapped up in what's called an EAP method. And as we mentioned earlier, it's pretty much more like a black box for performing authentication. Just going to briefly mention some notable EAP methods. We're going to talk about them in more detail later, but that's a really hit point on that. The first of which is EAPMD5. Spoiler, it's kind of bad. There are a lot of security issues with it. EAPP. Another EAP method. It also sucks. I know it's so, but it looks delicious, so I just wanted to include it in this presentation. There's also EAPTLS. And the traditional school thought has been that EAPTLS is a lot better than the other two I just mentioned, but more on that later too. Without the way, let's do a brief history of wired port security also just to kind of get ourselves up to speed with what we're going to talk about today. In 2001, you know, I triply released 802.1X2001. And this standard was created to provide a rudimentary authentication mechanism for local area networks. The standard was revised in 2004 with 802.1X2004. And this extension basically was designed to facilitate the use of 802.1X in wireless environments. A year after that happened a researcher named Steve Riley figured out that you could actually bypass 802.1X2004 and 2001 as well by inserting a hub between the subbook and the authenticator. And basically doing this lets you just passively sniff traffic between those two entities. You could also interact with the network to limit a degree by injecting UDP traffic. Injecting TCP packets would cause a race condition, so that wasn't really feasible. But this was like the first, you know, kind of documented mention of such a bypass. Fast forward six years to 2011, Abbott Grammel security created a tool called Marvin. Marvin was able to bypass 802.1X by introducing the road device directly between the subbook and the switch. So before we were using a hub, which by 2011 those were starting to become harder and harder to find. But Abbott's tool was actually able to, it had two network interfaces. You know, you have this road device that's inserted between the switch and like this authorized workstation. And this road device has two network interfaces. One of them is connected to the workstation, one of them is connected to the switch. And it actually is able to use a Linux bridge, just kind of forward these packets transparently back and forth and bypass port security without using a hub. And also you're able to get full interaction with the network using packet injection. Later that year, and this is actually probably the most widely used, you know, 1X 2004 bypass out there, Alva Duckwall introduced a similar bypass technique. It's a little simpler, which is a really good thing. So Alva Duckwall's implementation also uses a transparent bridge to introduce the road device between the subbook and the switch. But unlike Abbott's technique, it doesn't rely on packet injection. Instead, you interact with the network by creating a source net using IP tables. And this lets you basically push packets onto the network and make it look as if it's coming from the subbooking device, the authorized workstation, that you're kind of like middling doing this process. And actually very recently, 2017, we have Valerian Legrand, he created a tool called Fenrir. And it works very similar to Duckwall's tool, but it's all implemented in Python at a very high level. So you don't run into some of the kernel patching issues that Duckwall's tool is kind of affected by. And it's pretty cool. It has a modular design, support for responder, all that good stuff. So I guess when I started working on this project, it made sense that the first thing to do should be to kind of try to recreate the classic, Duckwall's classic 802.1x 2004 bypass and also see if there's any ways that it can be improved upon. So looking at Duckwall's 802.1x bypass more closely, we mentioned using a transparent bridge to silently introduce the road device between the sub-leg and authenticator. And you achieve network interaction using SourceNet. Another interesting feature of Duckwall's device, remember that when we're performing this style of attack, presumably we're not able, this is going to be performed on network in a physical environment, like a building or something like that, that we do not own and we're not supposed to be getting into in the first place. So it's not like you're on a red team or physical security assessment where you can go walk in, set up this device, install a monitor and just sit there on the computer interacting with this thing. You have to kind of like get in there, hook this thing up and get out. So it's important when you're doing this kind of thing that whatever, however you implement these kinds of attacks, you provide yourself with a mechanism of reconnecting with this road device remotely once you perform the bypass and once you've actually made your egress from the building. So the way Duckwall's implementation does this, well it actually uses two methods. The first is a hidden SSH service that's created using destination adding and also it has support for like an outbound SSH channel that goes through the target network and lets you connect that way. So I wasn't able to improve upon Duckwall's implementation a couple of ways. You know, back when Duckwall's implementation was first created, the Linux kernel was not forwarding Apple packets over a bridge. It was completely disabled as a security feature. So actually, you know, traditionally if you look at most tools that deal with 802.1x2004 or bypassing SSH, they deal with this problem in the same way that Duckwall had to, which is essentially patching the Linux kernel. The exception to this is Fenrir by Valerian Legrand and he just does this completely at a high level using escapee so it doesn't really matter. You don't have to rely on the kernel patching. So this made sense at the time but there are some problems with both of these approaches and one is that relying on kernel patches can become unwieldy. At this time, there are no longer any publicly available kernel patches for modern kernel versions that will perform this ePoll bridging. The reason for that, if you think about what it takes to maintain a tool of any kind, you know, you constantly have to maintain this kernel patch because if you don't, you know, you can bet that the kernel development team is going to keep working on, you know, pushing updates to the kernel and kind of if you think of your, like, here's your patch and here's like the direction that the kernel is going and eventually that patch is no longer going to work after, you know, subsequent iterations of updates to the kernel. And that's kind of the state we're in now. And then if you deal with high level tools such as escapee, they work really well because you don't have to rely on kernel patches but also it can slow down your bridge under heavy loads because it just isn't able to handle it in the same way that the lower level plantation can. So fortunately, the situation has dramatically improved since Duckwell's contribution. In 2012, ePoll bridging actually was added to the kernel but kind of as an optional feature that you had to enable using the PROS file system. The PROS file system is pretty cool. It's actually like an API to the Linux kernel that you can, that you can let you reconfigure stuff on the fly and you can just interact with it by setting values and files and stuff like that. So basically you just, you change the value of this file within the PROS file system and you can forward ePoll packets. So we added that in there. And the other proven that we added was support for side channel interaction. When Duckwell created his original 802.1x bypass, you know, this was 2011. You know, cellular modems were pretty unsophisticated. They were slow. They were very expensive. You couldn't just go down to Best Buy or whatever and buy yourself like a $15 LT modem with a prepaid plan that you could plug into your rogue device. So this is why he kind of had to rely on the hidden SSH service and the outbound SSH channels. This is not a perfect solution though because it relies on the assumption that egress filtering can be bypassed. So if we improve upon it, that'll be great. Also relies on pushing traffic through the target network, creating an opportunity for detection. So, you know, kind of, now that we have the opportunity, you know, it's several years later at this point, so, you know, we have the opportunity to leverage a lot of this newer cellular technology to kind of establish a side channel to our lead behind device. That also lets us deal with, you know, air gap networks and stuff like that. So, you know, the updated implementation actually relies on a side channel interface to provide the attacker connectivity rather than the hidden SSH service or the outbound SSH channel. Had to modify some firewall rules to get this to work, but it's totally worth it because now you can just connect over LTE. So, here's the demo of our improved implementation here to figure out how to get this to play. Oh, cool. Okay. Can I fast forward? Interesting. All right, the video is running. I just don't know how to, oh, geez. All right, that seems to be working, so I'm not going to touch it. Okay, so, um, no, it's paused. Okay, so it's happening here, right? And it's in the left-hand side, we have the attacker's device on the top right here. If you can see my mouse, can you guys see my mouse? Okay. Well, pretend there's a mouse pointing at the top right of the screen. That's, that's the sublicant. Let's play pretend. In the, in the bottom right, that's the switch we're connecting to. Uh, you notice that we've disconnected the device here and we're running this software on the left, which is setting up the transparent bridge we were talking about. And up, it's turning yellow in the bottom right. Uh, so that means it's re-authenticating and we're just kind of forwarding that authentication. And, oh, magically the sublicant that's in the top right is able to communicate with, it's going to go back to pinging 8.8.8.8, which apparently this is just what this workstation is used for. Um, yeah, so now we're going to add network interaction by running this other command. Um, basically I, I, you can see all these other flags and other information that we're passing to it. When we set up the, the initial transparent bypass, we're, you know, pushing the position where you can sniff all of that, which is pretty neat. Um, still running? Well, long story short, you can, you can scan things with NMAP, but, um, just, I'll, I'll post the videos on, on, on the accompanying blog post after this so you can go check them out there. Anyways, so, all traditional ATO2.1x bypasses either hub based, injection or bridge based, take advantage of the same fundamental security issues that affect ATO2.1x 2004. Uh, the protocol does not provide encryption and the, the protocol does not support authentication on a packet by packet basis. And that's why this bridge based bypass works. Um, so to kind of mitigate this problem, uh, you know, another revision to the protocol is introduced called ATO2.1x 2010. And ATO2.1x 2010, uh, uses MACSEC, which provides later two encryption performed on a hop by hop basis and packet by packet and integrity checks. So this kind of throws a wrench in the whole bridge based attack scenario that we just talked about. Um, interestingly enough, it also allows network administrators with the means to inspect data in transit. So because the encryption is only performed, you know, on a hop by hop basis, you can still inspect traffic, uh, which is actually a pretty big deal. So ATO2.1x 2010 works in three stages. Uh, the first stage is authentication and master key distribution. The second stage is session key agreement. And the third stage, stage is the session secure stage. So stage one, we mentioned authentication. I mean, that's pretty much just the ATO2.1x authentication process that we talked about before. Um, you're going to perform those four steps that we talked about and then you're going to perform EAP authentication, um, using some EAP method that is going to be selected between the supplicant and the authentication server. And if that succeeds, we'll move to stage two, which is the session key agreement. Uh, the, the basically the, the, what's happening in the session key agreement is that the, um, the authenticator is going to establish that the supplicant is actually capable of supporting MACSEC. And if it is, uh, you're going to install the SAC on the supplicant and we're going to move to step three. And step three is session secure. So in session secure, um, basically at this point everything is encrypted, um, at layer two, uh, your, your MACSEC is fully enabled and this is kind of where we are trying to get to. So, I guess like, uh, with this in mind, right? You know, whenever you're trying to come up with like a way of bypassing or attacking some kind of new technology, I think it's useful to, uh, to kind of look at parallels, you know, between whatever you're currently working with and similar technologies that have been compromised in the past or even recently. And with that in mind, this particular section, section 6.6 in the 802.1x 2010 standard kind of stuck out of me. And basically it's, it's comparing, it's basically stating that conceptually the cryptographic capabilities provided by 802.1x 2010 kind of play the same role as similar, you know, cryptographic capabilities provided for wireless networks in 802.11, right? So I think what they're alluding to here are parallels between MaxSec and WPA. And actually if you look at, you know, why WPA1 was released back in 2003, um, well when it was released, what it was introducing was layer 2 encryption between the access point to the station. And this, you know, authentication that provided access to this encryption was provided by EAP or using pre-shared key as a fallback or alternative. Um, when WPA was released, there was a major paradigm shift that had to happen, you know, from an attacker's perspective because, you know, prior to WPA, injection-based attacks for all the rage, you know, you could use them, they're very effective against web, they're very effective against open networks. Um, but now because of WPA, they're no longer possible due to that layer 2 encryption. So what you saw was a major shift in focus from attacking, um, the encryption itself to actually attacking the authentication mechanism and not even dealing with the encryption. So that's where you start to see the WPA handshake, captures and dictionary attacks against PSK networks and that's when you start to see, uh, rogue AP attacks against weak EAP methods on wireless networks emerge as well. So we fast forward to 2010, right? 802.1x 2010 has been released and, you know, very similarly, we're providing hop-by-hop layer 2 encryption using MaxSec and, you know, this is being, this, this encryption is either occurring between the device and the switch or from multiple, two switches to kind of encrypt the traffic between the two of them. Once again, authentication is being provided by EAP or PSK as a fallback. Kind of see where I'm going with this. So, I mean, the obvious hypothesis here is that it makes sense to start with a hypothesis that you could also perform a similar shift of focus and start looking at attacking the authentication mechanism rather than trying to attack MaxSec itself because why do things that are hard? Um, with PSK, um, I would venture to speculate that some kind of dictionary attack may be possible, although I haven't really worked on that so I don't know. Um, but in this talk we're talking about attacks against weak EAP implementations. So, spoiler alert there. To kind of more understand this, this, this, these kind of parallels, uh, let's talk, you know, very briefly about attacks against WPA2 EAP, right? And, um, so the most commonly, like, widely known, um, weak EAP method is, uh, EAP peep and it's very similar to EAP TTLS. Um, so you can kind of talk about them, you know, in the same way. Uh, the way EAP peep works is that the sublucent, and remember we're talking a wireless context now, the sublucent is going to make an authentication request to the authentication server, which is going to respond with an X599 certificate. At this point, um, basically the role of the certificate is, is for the authentication server to prove to the sublucent, uh, that it is who it says it is, that it can be trusted. The sublucent is either going to accept or deny, it's either going to accept or reject that certificate. If it accepts that certificate, it means the trust has been established between the sublucent and authentication server, which moves us from the outer authentication process to the inner authentication process of EAP peep. And, you know, the inner authentication process happens when the, the secure tunnels established between the sublucent and the authentication server and basically transmit your, your identity, your username, um, uh, password in the form of hashes, uh, what have you through the secure tunnel and the secure tunnel is there to prevent you from sniffing this process passively. So, this process does have security issues. Remember we're operating wirelessly. Two researchers, researchers named Brad and Tanoas and Josh Wright, uh, back in 2008, they were able to discover that you could use a rogue, um, access point attack to force the sublucent to authenticate with a rogue authentication server. Um, what do we mean by rogue access point attack? Well, basically, um, you have all these, these, these wireless devices here and you force them to connect to your own access point, establishing a man in the middle. Uh, there are many ways to implement this, uh, but that is the general concept that remains the same. You know, so pretty much you force them to connect to you and then you force it to authenticate with your rogue authentication server. And to do this you have to send the, um, you do have to send the target device, you know, one of these X5-9 certificates. It's probably going to have to be self-signed or at least generated by rogue CA, but you know, in a lot of cases the sublucent will either just automatically accept it or it's going to be left up to the user to accept the certificate, in which case, you know, you'll always find someone within an organization who's going to accept that thing. So, it's kind of okay. Um, making this worse, right? Uh, when we talked about inter-authentication, um, it's, it's being the part that's happening through that secure tunnel. Well, the strongest form of EAP, um, authentication available for EPP and E P T T L S is MS Chappie 2, at least, you know, the ones that are widely used. So, MS Chappie 2 is interesting because although it provides mutual authentication, um, it actually is vulnerable to a cryptographic weakness that was discovered by Maximum hours, Marlon's Blake and David Holton back in 2012. Um, essentially once you capture the, um, MS Chappie 2 challenge and response that is sent through the secure tunnel, um, using the rogue AP attack that we just described, uh, you can reduce it to 56 bits of DES encryption, um, using a divide and conquer attack. Which, you know, at that point, uh, uh, Marlon's Blake and Holton were able to, uh, demonstrate that with, with a 100% success rate, regardless of the length of the, of the password, they were able to convert it into an NT password hash, which is password equivalent, within 24 hours with a 100% success rate. Now remember, this is back in 2012. Although they were using $100,000 cracking rig to do this, if you look at what their cracking rig would cost now, it's somewhere between like 10 and $20,000, which is roughly within the, it's actually pretty much within the range of most kind of like mid-level, I guess like the startups of the criminal world, if, if you will, um, let alone in like a nation state or like an APT. So let's go back to Etude ONX 2010. Um, with all this in mind, the most important takeaway about Etude ONX 2010 from an attacker's perspective is that it still uses EAP to authenticate devices to the network. And EAP as we just talked about is only as secure as the EAP used. So, you know, the Etude ONX, the Etude ONX 2010 standard allows any EAP method so long as it supports mutual authentication, supports derivation of keys that are at least 128 bits in length, and generates an MSK of at least 64 octets. And there are plenty of commonly seen weak EAP methods that meet these requirements, including EAPP, EPTLS, et cetera. I think you see where we're going with this. So this is where we kind of go into the, our, our new contribution where, I'm going to introduce something called a rogue gateway attack that can be used to defeat Etude ONX 2010. This slide is kind of misleading because it's saying defeating MaxSec with using rogue gateway attacks. It really we're just avoiding having to deal with MaxSec by kind of cutting it off at the authentication process. So the goal of a rogue gateway attack is to force the supplicant to authenticate with the attacker's device. Remember, we're on the wired network, we're on a wired network, not a wireless network, so we're going to have to get creative in terms of figuring out a way that we can do this. Once, once you get this device to authenticate with you, you're able to capture hashes which you crack and then you get credentials and just you can authenticate directly with the network at that point. So when we talked about bypassing Etude ONX 2004, we used a man the middle style bypass. So here you see we have this rogue device that's directly between the authenticator and the authorized work station, which is the supplicant. We're going to have to do something a bit different with the Etude ONX 2010. We're going to have to go for direct access because this isn't going to work due to that layer 2 encryption. So let's talk about how we can build a device that can do this. The first step of actually setting up our bypass is actually just to set up our device. We see this, this is our rogue device here, kind of our design for it. We have three network interfaces, the side channel interface and that's going to provide us remote access to this device via LTE or what have you, right? We're also going to have an upstream interface that's going to be connected or eventually be connected, should I say, to the switchboard. And we have our fee interface here, which is going to be, I don't actually know how to say that, I just see it in documents all the time. Fi, okay, cool, cool. Our new thing every day. So we have our Fi interface and that's connected to the supplicant. And the device itself, you just use a mini computer, we use an Intel Nuke, or Nuke, running Fedora 28. So we're going to need a way of diverting traffic to the rogue device. So I'm going to take a look at this picture, right? This is a set of train tracks. And in the end of the train tracks here we have this little train station here and then we have a switch here and depending on which way the switch is configured, if the switch is configured in mode A, the train is going to go directly into the train station, if the switch is configured in mode B, or mode, I just spoiled it, in mode B, the train is just going to bypass the station entirely. It would be cool if we could do something like that with Ethernet, right? So you actually can. You can buy these little devices off of Amazon for like ten bucks and it's a mechanical A-B splitter. You press the A button and you're either in a traffic, it's diverting mechanically through rogue A, or through port A, press the B button and it's diverting mechanically through port B. This would be cool but if it senses a lead behind device, if we're going to actually use this, we need a way of manipulating that push switch. There are a couple ways you could do this. Theoretically, you could use a relay to do this, which essentially you either use higher or low current to kind of like effect where the Ethernet traffic is going to go. Unless you're an electrical engineer and that's definitely not me, building something like this is going to lead to impedance issues, which is why a better option is to use solenoids. A solenoid is basically a linear motor. You have a rod with a coil wrapped around it. You run the electricity through the coil and depending on the configuration of push solenoid or pulse solenoid, it's going to result in that rod being kind of like slammed outward or pulled back in. So you can use that to create a pushing motion, which you can use to manipulate those buttons we saw there. So our completed rogue device design is going to look like that. We have a rogue device as set up as we saw before. We're also going to have these physical A-B splitters on either side, our upstream splitter and our downstream splitter. And we're going to have this wired link between the two of them. We'll also have a passive tap that is going between these two splitters when it's in bypass mode that will allow us to inspect traffic. We used Michael Osman's throwing star land tap. You build something that's basically similar to that and use it to inspect traffic when you're in bypass mode. So in the switches are in mode A, traffic is completely bypassing the rogue device and going directly between the authenticator and the rogue. When you use the solenoids to flip the switches into mode B, now traffic is diverted to the rogue device. So to actually implement the attack, we flip the switches, you know, after we find the device, we remotely flip the switches to mode B and we shut down the upstream interface, which essentially blocks any traffic from being sent to or from the authenticator. And then we set up our rogue authentication server to listen on our FI interface. And essentially what this does is it forces the supplicant to authenticate with us. And you'll have to inject an EPOL start frame to yourself to get this to work and we'll talk about what that is later. But this actually will actually force the device to authenticate with you. And then once you are able to capture those hashes provided, they're using a weak AAP method. You can crack them and then you bring down your FI interface, bring up your upstream interface and authenticate directly with the network. And you just kind of very lazily avoided having to deal with 8 or 2.1X entirely. So here's our updated demo. There's going to be some lag because I don't really know how to fast forward through it. But okay, so in the bottom right, yeah, so those are the solenoids actually flipping the AB switch. I made them really big so you could see them, although obviously you'd want to use a smaller implementation. Actually the first time I got this to work, I freaked the hell out of my wife because she's like, what is that? You want to execute yourself? Which I was actually pretty concerned about myself because I don't really do this very often. But yeah, so essentially we set it up. This is paused. Yes, it is. Okay. So yeah, we diverted the traffic to us. It's playing again. I don't know how to control this device. I'm sorry. But what you will see soon is that basically, yeah, so we've cut off connectivity from there and we have our hashes that we've captured. And from there we go ahead and crack them. So I honestly don't know why you're clapping. That is like the laziest attack that like, whatever, they wanted me to come talk about it. So let's take a quick detour really fast. Now we've gone over that. Kind of some other stuff that I looked into while working on this project was kind of the current state of Mac filtering and Mac authentication bypass because it's something that's been affecting me directly a lot lately. So fun fact, not all devices support A to 2.1X. Who'd have thought, right? But not all devices support A to 2.1X. But enterprise organizations that need to use these devices, they still need to be able to deploy them anyways. So when this happens, when you're an enterprise organization that uses A to 2.1X but you have to deploy a device that supports it, traditionally what you've had to do is create what's known as a port security exception. An port security exception essentially you just disable A to 2.1X on the port used by that device. When you do this, you usually replace A to 2.1X with Mac filtering or some other weak form of access control, not always but usually. And historically these have been pretty prevalent because of the widespread lack of A to 2.1X support by peripheral devices such as printers, IP cameras, all those essentials that just don't have the sophistication of a full work station or something like that. So port security exceptions have traditionally been very low hanging fruit for attackers. It's much easier to try to find a port security exception than to try to actually bypass A to 2.1X at 2,000 whatever using a bridge or a hub. The problem is, and I kind of had to go try to verify this myself just by looking into things because anybody do like any red teamers here, people who have done physical security assessments, haven't you gotten the impression that these are just becoming much less prevalent? It's just slowly kind of, yeah. Well, I mean, when you think about it, it actually makes sense. Basically support for A to 2.1X for A to 2.1X by peripheral device manufacturers, it actually has increased dramatically in recent years. A good example of this, if you go on New Egg or whatever and just look up multi-function printers and try to find ones that support A to 2.1X, pretty much every major manufacturer of a multi-function printer has at least one model that's affordable by an enterprise budget, but I don't mean like a $5,000 printer, I mean like a couple hundred dollars, that supports A to 2.1X. So the result of this is that as legacy hardware is phased out, either breaks or just gets cycled out on a however, whatever basis, it gets replaced with A to 2.1X capable models. So what this means is that port security exceptions are becoming much less prevalent than they used to be. And although they're still there, they're not quite the low hanging fruit that they once were, which seems like a good thing, except for the fact that we have to remember improved adoption of A to 2.1X does not necessarily imply strong port security for peripheral devices for the following reasons. To begin with, A to 2.1X 2010 support is really only just starting to become a reality for really, really expensive enterprise networking hardware, let alone peripheral devices. Additionally, we mentioned that A to 2.1X 2004 can be bypassed using bridges, injections, et cetera. And we're releasing a tool that makes it really easy to do that as well, so that's going to become a little easier to do. With that said, adoption for secure AAP methods can be expected to be lower on these peripheral devices than domain join devices. So it kind of begs the question, can we just attack AAP as a means of kind of compensating for the diminishing returns that we're getting from port security exceptions? And doing this actually makes sense when you consider that the adoption of secure AAP methods is already low across the board, let alone peripheral devices which often can't be configured centrally in the same way that a domain join workstation can be. So I guess your first option for doing this, if the peripheral device is using something like EAPP or EAPTTLS, you could use a similar row gateway attack like what we talked about before. You don't actually need the mechanical splitters to do this this time though. You just set up your transparent bridge like we talked about and then just disable your upstream interface, disable your bridge, and launch your rogue authentication server on your fire interface. And then from there you're able to capture hashes, crack them, and authenticate directly with the network. Interestingly enough though, honestly like one of the most widely used EAP methods that you see using peripheral devices such as multi-function printers is EAPMD5, which is really, really old and kind of crappy but when you think about it, it's also really, really, really easy to set up and configure and it's still better than Mac filtering. So you can honestly if you're deploying EAPMD5 and protecting all your printers with it, you can say yes, all of our devices support 802.1x. We're not going to tell you how we implemented that but they support 802.1x. So the way EAPMD5 works, once again, it's a really old EAP implementation. The first step of the EAPMD5 authentication process is that the authentication server is going to send an EAP request identity frame to the supplicant. And the supplicant is going to respond with an EAP response identity frame, which is providing a username. The authentication server is then going to create a randomly generated string of characters. Awesome. Very good. It's going to create a randomly generated string of characters in the form of an EAP challenge and it's going to send that off to the supplicant as an EAP challenge request. The supplicant is then going to take that randomly generated string of characters, concatenate it with its username, concatenate that with its password and then dump that through the EAPMD5 hash function. And what comes out of the EAPMD5 hash function is the EAP challenge response which is sent back to the authentication server. The authentication server is then going to have the exact same hashing operation that the supplicant did generate its own response and then compare it to the one it received from the supplicant. If they match, then authentication succeeds. If they fail, then authentication fails. So kind of the thing to remember about this authentication process is the entire process is occurring over plain text. Which, you know, if you think about it, you know, we don't have the benefit of that tunnel that we had with EAP or EAPTTLS. And what that means is that an attacker can be able to use the EAPTLS to passively capture the username, capture the EAPMD5 challenge request and the EAPMD5 challenge response and then basically perform a dictionary attack to obtain the password. And actually a couple of researchers from China in 2012 they were able to recover EAPMD5 credentials even faster using a length recovery attack. So I mean this is essentially a really, really broken protocol. So with this in mind and leveraging what we know not only about how to attack EAPMD5 but how to attack 821X2004 as well you know it follows that we can start out by using a bridge-based approach, a bridge-based bypass to place a road device between the supplicant and the authenticator. We then start sniffing traffic being sent back and forth between these devices. You know, we then wait for the supplicant to authenticate, sniff the EAPMD5 challenge, sniff the EAPMD5 response when it does crack the credentials and just then we're done with the network. There is one major drawback to this approach and that's that we have to wait for the supplicant to re-authenticate with the switch which actually that's not going to happen unless we disable a virtual network interface or I'm sorry disabling a virtual network interface isn't enough to make that happen and it's realistically not going to happen unless we actually unplug the supplicant from the switch itself. We could use the mechanical splitters that we talked about with 821X2010 for simpler. So basically another thing that the third contribution that we have here is the EAPMD5 forestry authentication attack against 821X2004. We mentioned the first two steps of the initialization process, right, which realistically are the first two steps of the EAP authentication process. That's pretty much the whole thing combined. Are that the supplicant is going to send the authenticator an equal start frame that it should send the supplicant EAP request identity frame because we're beginning the authentication process. We also mentioned that this first step the EAPL start frame is optional. The reason why the first step is optional is that the authenticator needs a means of forcing the supplicant to re-authenticate in the event of a problem, in the event that it needs to reconfigure something, etc. So that's left as an optional step. The problem with this is the supplicant has no way of verifying if the incoming EAP request identity frame has been sent before. Essentially like we could force re-authentication by sending an EAPL start frame to the authenticator as if it came from the supplicant using max-moving. The result will be that the authenticator is going to send an EAP request on any frame to the actual supplicant and kick-start the re-authentication process. When this happens, both the authenticator and the supplicant are going to believe that the other party has initiated the re-authentication attempt. As you can see here in this little video, EAPL start frames using escapee in the bottom left and that forces re-authentication. It's very easy to do and very fast. So if we take this information and add it to our first attack, our passive attack against EAP MD5, we come out with, you know, I guess what we call the EAP MD5 force re-authentication attack, which we start out by introducing this rogue device to the network directly between the authenticator and the supplicant, set up our bridge as before, start passively and force re-authentication by sending a spoofed EAPL start frame to the authenticator. And then from there, that allows us to immediately capture the EAP MD5 challenge response and the EAP MD5 challenge, crack those, and then we can authenticate the network that way. And this is pretty fast. You just run this, yeah, it's, we literally just by running the thing, now we have the request ID, the challenge, the response, and also the identity. And that's it. I guess like the first proposal mitigation of this, that comes to mind, although, you know, honestly this is probably not bulletproof either, is to put a safety bit in the EAP request identity frame, you can set it to one if the frame was sent in response to the EAPL start frame, and check it when the supplicant receives an EAP request identity frame. And, you know, essentially if the safety bits set to one and the supplicant did not recently issue an EAPL start frame, you abort the authentication process. So we summarized our contributions, what we kind of went over today. We've introduced the road gateway and Baton switch, which in conjunction with one another can be used to bypass 802.1x 2010 by attacking its authentication mechanism. We've also introduced an updated and improved existing 802.1x 2004 bypass techniques, emphasizing on the techniques introduced by Alva Duckwall back in 2011. And we've also introduced the EAP MD5 forestry authentication attack, which improves attack against EAP MD5 on wired networks. Some key takeaways before we wrap this up. Port security is still a very, very positive thing, please keep using it. But it's not a substitute for a later approach to network security. You know, deploying port security does not absolve you from very basic responsibilities like patch management, you know, kind of keeping tabs of, yeah, it's part of, it needs to be part of a larger system that is designed to keep your network secure. And additionally, the benefits provided by 802.1x can be undermined due to the continued use of EAP as an authentication mechanism. And finally, improved 802.1x support by peripheral devices, or should I say peripheral device manufacturers, is largely undermined by lack of support for 802.1x 2010 and low adoption support rates for strong EAP methods. If you want to look over this information in detail, there's going to be a blog post. I tried putting in the entire URL of the blog post, but it just kind of took up the entire slide, so it's just the first results on digitalsilence.com. And finally, we have the, if you actually want to try performing these, the tool and the associated documentation is available on github.com. Thank you very much.