 All right, thank you so much. Thanks for coming out. Okay, so I'm worried that I'm really gonna have to book it through this talk because I've got a lot to go through, so hold on tight. Okay, so first off, I'm Headless Eek, Ricky Lauchay of Nasty. I'm a Principal Security Researcher at Keysight. I mainly focus on offensive IoT research. I've been doing this stuff since 09-ish and this is actually my fifth time speaking at DEF CON. For some reason they keep letting me come back. We'll see about after this one. Okay, so first off, a couple of ground rules about this talk. So yeah, we're gonna be diving into the wonderful world of layer two networking. You know, everybody always does like layer three and above, but all the cool kids hang out on layer two. So yeah, this is basically just gonna be like a survey of lots of different really weird ether types. They're not like specifically not common, not ubiquitous, and these are local network only. No internet-facing protocols. It's just layer two ethernet protocols that may or may not be a good idea to have on the network. Okay, so first off, what is an ether type? This is defined in IEEE 802.3. Basically, you've got a picture of an ethernet frame that I ripped straight off of Wikipedia right there. So you've got your preamble and then you've got your destination and source MAC addresses, and then the next two bytes after that are gonna be your ether type. And this is basically a way for switches to know what kind of payload is coming next. Some common examples are like, you know, 0800 for IPv4, etc. These ones are going to not be those. These are the uncommon types. So a fun fact about the ether type field, if the value of that field is less than 15, it's a length. And if it's more than 1563, it's an ether type. And between those two is undefined. I can imagine that there was a very heated discussion at IEEE about this. Does anyone know the significance of that 1500? MTU. MTU? That's right. Okay, so in order to get an ether type registered, you have to go through IEEE. It basically costs $3,810, which is not cheap. So these aren't just like, you know, throwaway things that you do just for fun. It's a one-time fee. I don't think the registration ever expires, although I have seen on their list of public ether types. Some of them are no longer in use, so maybe they do expire. There are several different listings where you can find all of the publicly registered ether types there. And there are a couple of special ether types. These ones are reserved for particular uses. That's 88B5 and B6 are for the Playpen ether types. These are what you can use when you're like prototyping your own Ethernet protocol. These cannot be used in actual production. These are just for prototyping so that you can figure things out before you actually register your ether type. And then 88B7 is the OUI extended ether type. This is to handle the case of, you know, it's just two bytes, so there are only so many ether types that can be registered. So this one exists to allow you to create a lot of ether types without having to register a specific ether type. So you use this one and then you've got your organizationally unique identifier and then your protocol identifier so that you can subtype multiple protocols within one organization. So yeah, that's that. Okay, everybody ready? Okay, we're going to start off easy and kind of ease our way into it. I've kind of broken this talk up into different verticals. This one is network management. So we're going to start off with everybody's dear old friend SNMP. SNMP actually exists on Ethernet as well. Ether type 81 4C. Basically the way this works is they just take SNMP packets, burn code them, burn code them, and then wrap them in an Ethernet frame. It supports all versions of SNMP mostly. So this, the uses and abuses, I do this on every one of the protocols. So this one is mainly used in these two port MAC relay bridges. They're kind of like Ethernet extender kind of things. But in the spec for this protocol, it actually talks about using them anywhere where you need to manage a device but you don't have IP access. Yeah, so abuses, basically everything that you can abuse SNMP for before, you can do that over Ethernet and you might actually get the added benefit of bypassing some firewall restrictions. Okay, this one is really cool. This is one of my favorites. All right, so 8899 is the real tech remote control protocol. This one is basically with certain real tech switches, real tech chipsets. It allows you to take an unmanaged switch and turn it into a managed switch. And the way this works is basically you give it an address like a like I squared C style like an e prom address and then what you want to like read or write data to that and you can actually like modify physical memory over the network. It's kind of cool. There's actually an open RCP project has tons of information on the protocol and they've got a list of all the supported hardware harder to find than you would think. I actually coincidentally ran across this protocol on a device that I'm not allowed to talk about because it was it was pre released at the time. Thank you. It was pre released at the time and I'm not sure if it's you know, public knowledge yet. But anyways, so this is kind of what the protocol looks like. You've got so speaking of sub typing, this actually works. This actually works for RCP and real tech echo protocol, you might actually see that that particular packet on your network, or actually sorry, no, the network loop detection is the one that you might actually see on your on your network. But that that is not actually remote control, the real tech remote control protocol that's a different sub sub type. Anyways, they they have an authentication key, but it's two bytes long. So you could easily brute force that. And also it defaults as 2379. And nobody even knows that this protocol exists. So nobody knows that they're supposed to change the authentication key. So yeah, it's just it's just that. So yeah, basically, at the end of the packet, you've got your register address and your data. So you just have straight up access to registers. Uses, I kind of already talked about that there's a limited amount of chipsets. Real techs, data sheets on this protocol are really, really awesome, like some of the best data sheets I've ever seen, they give you like full register maps and everything. But it's only certain certain chipsets that do this. Some cool abuses that you can do with this, you can actually change your own VLAN tags. So if you don't like the VLAN, you're on you feel lonely, you can change your VLAN tag beyond somebody else's VLAN. Or you can actually set yourself up as a trunk for it and just get all of the traffic going through you. Okay, this one is funny. So 6001 and 6002. Does anybody in the room remember DECnet? You should probably schedule a colonoscopy. So, so yeah, DECnet, they had a whole protocol stack in like the 1970s, 80s, you know, long, long dead. This DECnet maintenance operation protocol or MOP basically had two functions. One was to dump and load system memory. And the other was to have a remote control console on like vax systems and stuff like that. So basically whenever a system was malfunctioning to the point where you couldn't actually like create a session on it, you could use this protocol to still like remotely recover from it. So yeah, DECnet is gone, except that it's not because Cisco still includes the MOP protocol on all of its routers enabled by default to this very day. So yeah, and they actually still like this was from the Harden Cisco iOS devices PDF from September of 2020, when they actually talk about how you're supposed to go into the interface configuration mode and disable the maintenance operation service. But yeah, so the dumping memory side, you basically, you give it an address and account of bytes, and it will read that, you know, that many bytes from that address. I haven't actually gotten that side working yet, but, you know, in theory, that's how it works. And then the remote console side, the data field is it depends on what command you're, you're doing. But there is a full protocol spec out there and I've included a link to that in the slides. Oh, and there's also already a Linux tool called MOP RC that you can just use. Okay, so yeah, use uses and abuses. You can you can maintain old dex systems or a or you can maintain every Cisco router, apparently. But yeah, so like the dumping memory combined with the remote console could be pretty killer, especially when you consider that Cisco devices store their hashes in config files and then VRAM. So if I could actually get that that memory dumping side of things working, then I could dump the hashes and use those to log into the console. Okay, so that was network management. I'm really gonna have to pick up the pace here. So let's talk industrial electrical. So 88 b8 is the goose protocol. Some of you will probably be familiar with goose. It's pretty, pretty popular. goose stands for generic object oriented substation events. And is described in the IEC 61 850 standard. Basically, this is a protocol that's used in substations. So that smart devices within a power station can communicate with each other. And they can also send out events for like, you know, voltage measurement fault detection, etc. It's a pub sub model. And you can actually they apparently do like IO through this protocol also. But yeah, so they actually tried to add some security to this protocol with the IEC 62 351 standard. But the problem was that the latency requirements in these environments were so low, that they actually nobody uses the security because they can't. So yeah, still pretty widely unsecured. This is kind of what that protocol looks like on the wire. app ID byte length, or two byte length, a couple of reserved fields, and then as in one encoded payload, easy peasy used in smart grid and intelligent electronic devices and general IO devices within a power substation. Yeah, basically, I could see you being able to abuse this by like, you know, the those events are sent to multicast or broadcast on the ethernet. So you can just push out your own events and cause, you know, all kinds of havoc in a power substation. Also theoretically possible to control those IO devices to, you know, do whatever you want to do. Keppco. So 89 3d is Keppco PLC interoperability protocol. Keppco is a Korea Electric Power Corporation. And this protocol is basically so Korea started installing a bunch of smart meters on everybody's houses, but didn't have a way to talk to all of those smart meters in like, you know, specifically like rural areas and stuff like that. So they came up with this protocol in order to be able to communicate with the smart meters over the power lines like the electrical power lines. So I couldn't find any protocol specifics on this one. But I found a few papers that kind of, you know, danced around the topic a little bit. So like this one was about AMI protocols for two way communication and KMI. I don't think this is actually the protocol because like that end of field stuff makes me think it's actually a serial protocol. And then a couple other other papers. Again, like none of these like they all gave little clues about what AMI and PLC interoperability would look like. But none of them actually talked about this specific protocol itself. Some kind of still in the dark a little bit on that one. But yeah, so like I said, it's used for allowing AMI smart meters to talk back home over PLC infrastructure. But you could theoretically use this to cut off somebody's power, or possibly use it to get free electricity, depending on you know, what kind of things they're monitoring across the across the wire. And speaking of PLC 88 e one is the home plug AV protocol. So home plug is kind of a catch all protocol spec for power line communications. It's actually there are three different interoperable standards. There's home plug AV, which is mainly used for in home power line communications speeds up to 500 megabits. Home plug AV two is the same, but just with higher bandwidth. And then home plug green fi is actually kind of cool. That's used mainly at like electric vehicle charging stations. So you plug it in and it does like a little like authentication handshake thing over over this home plug green fi, and then it unlocks it and allows you to to charge your vehicle. Okay, so this is actually one of the best secured protocols that I'm going to be talking about. They do 128 bit AES encryption on the wire between between devices. They have a rotating network encryption key that rotates every hour or so. And then new stations can join a network, as long as they have a network membership key. And then you can also pull in new devices into your network. As long as you have that devices. It's called either a device access key or a device encryption key. So all of this is done so that you know, some random person can't just plug one of these adapters into an outlet on the outside of your house and get onto your network. And that's, that's what the protocol looks like this protocol is super annoying. But I put a bunch of specs again. So basically, yeah, just you read them. Okay, so yeah, this is basically like, with home plug AV, you've got these two devices that plug into wall outlets. And then you can connect them to your network on either end. And it'll send the send the network traffic over the power lines in your house. So it's basically used for whole home Ethernet. I actually back in the day, used one of these as a as a Wi Fi extender in my house because my house is basically a Faraday cage. And I could not get Wi Fi upstairs, no matter what I tried. So I used one of these. But yeah, if you can figure out those network management keys or the device encryption keys, you can build your own kind of malicious network. But you know, getting getting the keys is the hard part because you have to already be on the network in order to get the keys. But yeah, there's also cases where these things are used in like apartment complexes and stuff like that. So you could actually be on a power line network with your neighbors, and not even realize that you're on the same network as your neighbors. Okay, so transportation, this is where stuff starts getting really interesting. Okay, so 99 FE is tech CMP or tech MP, the technically enhanced capture module protocol. So this either type was registered by ASAM, but the actual protocol itself was developed by Technica Engineering. This is designed to work with a capture module inside of a vehicle. In order to pull out all of the the can and flex ray data, and you can actually like replay that back onto the bus, which is kind of cool. The protocol itself is like a lot of overhead for what the protocol is doing. So basically like the really light blue is all just like regular ethernet standard stuff. The medium blue is all of the overhead on on this protocol. It's basically just like a bunch of like identification things and like timestamps and stuff. And then the dark blue is the actual like can or flex ray payload. So as far as the tech MP protocol itself, it doesn't really do much. But still, you know, the replay stuff is is cool. So yeah, you know, allow remote diagnostics of in vehicle networks. You need to have a capture module inside the vehicle in order to access it. Possibly useful in replay attacks. Okay, so wave. This one, if you're, you know, following along with current events, you've probably heard of wave. 88 DC is the wave short message protocol. Wave is wireless access and vehicular environments. Basically, so so like imagine autonomous vehicles, they can communicate with each other. They can communicate with like, like stop lights and stuff like emergency vehicles can switch stop lights using this kind of protocol. And they can also communicate with like inverse structure like signs and stuff for doing location based advertisements because of course, that's what they want to do. So the the short message protocol. Again, as someone encoded, you've got a version PSID, then you've got several possible extensions, etc, etc. Yeah, I don't know. It's cool. So as far as uses go, I already talked about that again. Autonomous vehicles talking to each other talking to the environment. So it's designed to keep riders and pedestrians and emergency vehicles safe, because they can all talk to each other and, you know, work things out without having to rely on human intervention. But it also allows for remote control of cars. You can modify traffic lights. I don't know if you guys remember the old days of like having a strobe light on the dash of your car. Because that's the way emergency vehicles used to switch the lights to green as they were driving up it would be like a strobe light thing. So you don't have to do that anymore. You can use the this ethernet protocol. But yeah, I could I could also envision some abuses on the location based ads like seeing where somebody you're stalking is driving is kind of bad. Okay, so if cars aren't doing it for you. How about trains? So the either type 89 for C is for the train communication network protocol. This is basically two separate protocols. Ethernet train backbone ETB is a replacement for the older wire train bus standard. And then ether ethernet consists network consists is like another name for like a train car. Ethernet consists network replaces the multifunction vehicle bus standard. Basically, so the ethernet train backbone is basically the entire train communicating it will tell tell you how the cars are oriented how long the train is and all that. And then the ethernet consists network is within one train car, all of the systems there. Working together. The standards. So the the IEC standards there. They're available. But they they cost like 400 bucks each to get access to them. And I mean, I like you guys, but I'm not spending like a grand on a single defcon slide. So if you if you want, if you want access to those standards, they're out there. But yes, so if you've written on the monorail out there, you know, like whenever it pulls up to a stop, and the, you know, it lines up with the doors and then the doors automatically open, that's all handled by this, this kind of ethernet protocol. But because of that, you know, if you get access to that protocol, maybe you could open the doors while the train is in motion, or maybe you could tell the train that it's shorter or longer than it actually is kind of things. Okay, medical, this was a failure on my part. This was the only only section where I came up pretty dry for the entire thing. But I'm still going to talk about the ethernet protocols because, you know, they exist. I just couldn't find any specifics on like any of them. I'm not going to be writing any kind of like hospital ransomware anytime soon. Okay, so so 88 5b and 88 5c are for the Philips Clinical Network. I am pretty sure this is related to IntelliView. Everything that I've read indicates that this is related to IntelliView. So I went out and bought an MP 50 heart monitor, like one of those big, like by your hospital bed, heart monitor things. But I could only ever get it talking UDP. I can't get it to talk ethernet, no matter what I do. So I'm thinking now that maybe there's some other piece to this puzzle, like, fill this Philips Agilent carenet network switch is like a specifically designed network switch for these clinical network environments. So maybe I need to pick up one of those. There's also this Philips Information Center or pick pick IX, which is kind of like a database, like a server side of things. So maybe I need to get access to that, but I couldn't find it available anywhere without talking to a sales guy. It could be that I'm just wrong about all of this, that's entirely possible. But you know, hopefully someday I'll find out more about the Philips clinical network protocol. So these uses and abuses, I'm just making guesses based on the UDP traffic that I was able to get out of that heart monitor. So you can admit and discharge patients. It's constantly sending out vitals and patient condition type things. And of course, alarms and exporting data. So, you know, the abuses are pretty obvious. Like you can, you know, spoof cardiac arrest or something like that and cause cause interventions to happen or, you know, you could spoof normal activity when bad things are happening kind of thing. And then you know, personal identifying information disclosure, of course. And then either types 81 5f through 81 6 3 are all registered to the Massachusetts General Hospital. They've got they've got five ether types. And I can't find anything on any of them. It's so frustrating. So Massachusetts General Hospital is actually fed in by Harvard Medical. They've got their own computer science department. They've got lots of patents around transferring patient scans and imaging and stuff over a network. So maybe these protocols have to do with that. Oh, yeah, such a nice guy. So I don't know if any of you have heard of impact cyber trust. But it's like a website where researchers and professionals can come together and share like PCAPs and protocol data specs and stuff like that. Really great site. So I came across them when I was looking into Massachusetts General Hospital, because they had uploaded a bunch of PCAPs to this site. And I was like, Oh, my God, that's amazing. And then I looked at the descriptions of the PCAPs, and they were all taken from within Phillips Clinical Network environments. And I was like, That still works. It's still need that. But unfortunately, they've got like restrictions on sharing the information on some of these, they've got like different levels of sharing, like some of them are restricted some are quasi restricted, some are unrestricted. And the restriction placed on this would mean that I couldn't talk about it at DEF CON at all. So I didn't end up looking at those PCAPs. Anyways, because, you know, I wouldn't have been able to use the information. But you know, if you're if you're curious, go look at impact cyber trust, create an account and get access to those things. So yeah, they do things. Okay, and now this is one that didn't fit anywhere else, but was pretty cool. So I wanted to I wanted to include it. So ether type 88 9e is remote tech hazardous duty robot protocol. These are basically Northrop Grumman unmanned ground vehicles. So these are basically like the bomb diffusel robot type things. So I think, you know, obviously, I couldn't I couldn't find details on the protocol itself. But I think this one is related to their andros tight tightest line, specifically because they've got a press release where they're touting all of the new ethernet features of their their their tightest robots. So just because I couldn't get access to the network protocol doesn't mean we can't like make some guesses about how it would work. Because back in 2002, there was this guy that that his master thesis at the University of Tennessee was actually all about the serial control protocol for for the andros mark four hazardous duty robot. It was basically like he wanted to be able to control this robot from his computer. So he pulled apart the serial protocol. And the way that works is basically it's a 22 byte packet of command data, and then one byte checks on. And basically, each one of those bytes is dedicated to a particular part of the robot. So so like, you know, one byte will be like moving the treads and one one byte will be like raising the arm kind of thing, you know, and then there was this bite eight. That was the weapons bite. Basically, you know, you got weapon one weapon to weapon vehicle and weapon shotgun. Okay, so so yeah. Obviously, that was the serial protocol. The ethernet protocol is probably different. They're going to have, you know, function functionality for like upgrading firmware and stuff like that. But it does kind of give you an idea of what what like kind of things that you could do with with this kind of protocol. But yeah, and also I don't I don't know how much they would change the the protocol from version to version, you know, because you have to like retrain on these things. And they're really like, you know, they're delicate machinery doing delicate operations and stuff, you don't want to have to train somebody from scratch every single time. But anyways, yeah, they're used for bomb disposal, and to handle dangerous situations without putting actual people in danger. But of course, you know, if you get access to this protocol, you can do things like, you know, wait until they're about to do something. And then just like change the position of the arm on them. Or, you know, actually, like, legit control the weapons on the on the robot. Okay. Alright, so that's all the protocols that I was going to talk about today. So I've got a couple of demos that I've got worked out. The first one is using the mop protocol to get a to get access to the management console on a Cisco 1800 series router. Basically, I, you know, I wish I had gotten the mop dump side of things, working on this because that would have been the icing on the cake. But basically, this is my, my interface config. Notice there's no mention of mop whatsoever. Because, you know, if you don't mention mop, then it's enabled. And if you want it disabled, then you have to say like, no mop enable in your interface config. Okay, so that's tomorrow. Oh, no, what did I do? Okay. Let me open up. Okay, so yeah, basically, like, this couldn't be simpler. I'm just using the mop RC Linux utility. I give it the MAC address of the router I want to connect to. And it basically like drops me straight into a Cisco iOS shell. It's like a fully interactive shell to it's got like tab completion and everything. So yeah, basically, you don't have to be on the management interface in order to access the management console, you can just be on any interface. And as long as it as long as they haven't disabled mop, then you can get access to the management console. So that's that one. Okay, so that was that demo. Second demo is using the home plug AV protocol to actually pull device encryption key and a network management key from an adapter. This script uses some Qualcomm atheros specific functionality. But it should work on all Qualcomm atheros based home plug adapters. It uses it sends the get software request. And that basically I send that to broadcast. And all of the responses I get back, I make a note of their firmware version. And then I make a note of their MAC address to use for the next command I send, which is VS module operation, which gives me a lot of detail back from that MAC address, including those keys. So I ran this against the TP link TL WPA 8630, which is actually the device that I used to use in my house. I do not use it anymore. So but yeah, so so the the thing about this is you have to actually be on the network in order to get access to these these keys, you know, I mean, but you know, you could use this to like dump those keys so that you could bring back an adapter later on some some time or whatever. This, this is my really ugly escapee script that I wrote. Again, I included this on the media server stuff. So you don't have to worry about the fact that you can't read anything that's up on the screen right now. But yeah, so basically it just loops since the first packet to broadcast listens for any responses. And then since the second one to that specific MAC address, and parses out the key information. Alright, so now we'll look at that. So yeah, you just run the script. And then you'll see it comes back with a version. That's the version of the home plug adapter that it found. Oh, man. And then it spits out the the network keys, the network management key and the device encryption key. So then from there, you could either use that to join your own adapter to the network using the network management key, or you could force adapters on their network to join your own network using the device encryption key. So that is that. Okay, so hopefully, at the end of this talk, you've seen how many crazy things there are out there on the layer two of network. You know, they're local only, but still so much fun to be had, especially when you're in weird environments. And this isn't even close to what all is out there. There are like well over 3500 registered ether types on IEEE public listings. And I talked about like 12. So there's still lots of lots of stuff out there. So these are some some of the places I found the most helpful in my research efforts RFCs, of course, are the best. IEEE standards are also good. And if there's a wire shark detector, then you're absolutely golden because somebody else already did the work for you. IEC standards are a little less reliable and often cost a lot of money. But you know, if you can get access to them, then that's that's great. Research papers and patents again, you know, not as good, but but sometimes contain useful information. And then of course, lots of googling and patience. And that was just kind of a fun thing that I found while I was doing all of this work. Excuse me, is this guy who makes the ultimate PCAP, which is basically a single PCAP with every single protocol he could possibly cram into it, all in one PCAP. It's really awesome. But yeah, and then eBay is awesome for grabbing random devices that you can't find anywhere else. And, you know, sometimes you can find them for pretty cheap. But yeah, so that's, that's my talk. These are ways that you can reach out to me. I'm on infosec exchange and def con social. I'm also on Twitter, but not really anymore. There's my GitHub where I'll put some of this code that I wrote. I'll probably also throw an RCP script up on my GitHub. You should all come to the IoT Village because Keysight has a booth over there where we're doing some Bluetooth fuzzing and it's awesome. So come and see me over there and you can ask me questions or whatever. So yeah, that's any questions?