 So, once again, thank you everyone for attending this presentation. We will be talking about bypassing advanced device profiling with DHCP. My name is Iwitsa Stipo, which I work as an information security consultant for Word Solutions in Dublin, Ireland. And before we jump into the matter, let me give you just a brief outline of the presentation. First, I'll give you a quick intro to the network access control mechanism, what that is, and then the two layers of defense that comprise the network access control, which are .1x and MAC authentication bypass. Then we'll take a look at what device profiling is and how it works, what attributes DHCP packets carry that are relevant to us. Then we'll briefly look at the common algorithms that DHCP profiling uses, following with the steps how to bypass device profiling. And then I will give you three cases and each of them describing the various techniques and approach of bypassing either DHCP profiling or MAC filtering. And I will conclude the presentation with the risk proposal for this weakness and some potential measures how we can protect ourselves from the given vulnerability. So, first, what is a network access control? Network access control is simply a mechanism that controls whether the connecting device complies with set of security requirements. These requirements can be anything from a patch level, antivirus version, specific hardware type, operating system type and so on. Why do we need that stuff? It's simply to prevent rogue devices and attackers from connecting unauthorized devices. So, where is NAC implemented? It's implemented within the access layer of the network. Now, in the given diagram, you will see that shaded rectangle and it shows the network layer where this is implemented. In other words, this means the point where your end device touches the network. So, let's just briefly summarize the two layers of defense that comprise network access control. One is .1x commonly known as IEEE 802.1x. It's simply a device authentication mechanism. It can be implemented as a mechanism that provides a username and password or what is much more common these days is the device presenting its digital certificate that was issued by your corporate CA or PKI infrastructure. However, not all devices support .1x. This is where MAC authentication bypass comes to the rescue because this is the mechanism used exactly for those clients that have no .1x capability. In the early days, MAC was around inspecting the MAC address and that was about it. These days, MAC authentication bypass has advanced quite significantly and is much more capable of collecting and inspecting much more information than just MAC address itself. How these two mechanisms complement each other? It's pretty simple. Basically, you take your corporate switch and define the authentication order that will simply tell the switch what mechanism to try first and if that fails, it will fall back to the second mechanism. That's just an example of a Cisco switch, but the philosophy is the same for any other vendor. So, what is device profiling and how it works? Think of device profiling as fingerprinting the device and we do that by inspecting the traffic of various protocols that the device may use. That can be DNS, DHCP, it can be layer two protocols such as Cisco discovery protocol, HTTP and so on and so forth. Also, the device profiler can choose to use Nmap scan, which will actually try to determine the services that your device is exposing. What methods are used to do the job? Methods will simply inspect the above protocol packets and in a form of a regular expression. Think of it as multiple conditions that are connected with logical operators. In other words, think of it as an if-then-else statement of a programming language. Where do we implement those checks? Obviously, within the device profiler, the focus of this presentation will be two products. One is Cisco identity services engine, to which I will refer as Cisco ICE, which is a fully featured device profiler. The other one is Windows DHCP server. DHCP server was not designed to be a device profiler. However, it contains some interesting features that we will exploit and investigate. Let's take a deeper look into the mechanics of DHCP profiling. On the left-hand side, we have a DHCP client that starts the whole conversation by broadcasting the DHCP discover packet. That packet is aimed for DHCP server, and if it's there, the server will reply with DHCP offer. This is a packet that will contain a proposal for the client containing the IP address, the subnet mask, default gateway, DNS server, whatever you define. At that stage, client will usually respond with, okay, I'm fine with the proposal. I'm taking these, and the DHCP server simply acknowledges the transaction and terminates the DHCP session. Now, in the middle of the whole process, we have a device profiler that does the deep packet inspection of those packets. The end result will be the certainty about the device categorization. In other words, upon the inspection, we will be able to tell whether this end device was a Linux client, or Windows client, or Cisco access point, or HP laser jet, or whatever you have. Let's have a look at the intelligence used to make this decision. I'm giving you here an example of a DHCP discover packet. That is the packet that client initially sends to the DHCP server. Among other things, note in the red rectangle attributes that are all labeled with option and with some numbers in the brackets. Now, these are important because they define very specific attributes that will help us determine what that device is. If you further expand one of these attributes, which is parameter request list, we will have another list with a number of elements. Now, you can spot here things like NetBios over TCP name server, NetBios TCP node type, and so on. For those less familiar, NetBios is a protocol that is extensively used by Microsoft clients. This is one of our indicators of the nature of the device. But the story doesn't end here. We have some other attributes such as vendor class identifier. If this attribute exists, it will usually declare the manufacturer details, such as device type, manufacturer name, etc. Hostname is self-explanatory. And one more thing I want to emphasize about the parameter request list is that sequence of attributes. You can see in the brackets numbers 1, 3, 6, 15. So each one of these numbers have specific meaning and signifies specific attribute. Now, that list alone is sometimes enough to determine the device family at least. One other thing is that some vendors may decide to inject their own specific values in the DHCP payload. And if they do that, we will have even more information. It's quite a big topic, so I'm just giving you the link to the RFC so you can look at the details. So what are the common algorithms for DHCP profiling? This example shows the profiler policy of Cisco ICE, which is responsible for detecting the Cisco access points. So let's have a look at how it's composed. It's made of three conditions. Each condition, if true, will raise our certainty factor by configurable value in our example 10. So if we have all the three conditions true, we will be, let's say, 30% sure that we have profiled device correctly and that we know what it is. If two are true, then the certainty will be less, 20 and so on. We'll have a look at specifics of only one condition because the second two are not DHCP related. So an example of rule here is, looks for a specific attribute called DHCP class identifier. And if that particular field exists, the profiler will scan its content. In other words, the string it contains. And then if it finds Cisco AP, then it will trigger true. So as I said, it is only one condition that we are discussing here and this one is DHCP related. The other two are not. However, bear in mind this policy is flexible. So you can add conditions, remove them. You can change the values of certainty factors and so on. So how do we then bypass device profiling? There are two main options. First is we reverse engineered the profiling policy. Now, that's not really feasible to the attacker because the attacker would have no knowledge of what's running on the other side of the connection. Therefore, they don't know what the policy, what the profiler policy is, or if there is one at all. However, option B is we can capture and modify the initial DHCP payload. So the attack design looks like this. First, we captured the P-cap or any other format of network traffic between the device you wish to mimic and profiler. Now, there are a couple of ways how you can do that. You can connect your hub, which will allow you a sniffing of the local network segment. You can connect the cable directly between your laptop and victim device. We go there to see what happens. Or you can simply look at the P-caps for specific devices on the internet. The second step is constructing the DHCP discoverer and DHCP request packets as proof of concept code that I give you. You then fire up the proof of concept and the packet tracer in parallel. Now, the reason why you should have packet tracer in parallel is so that you can capture as many details coming from DHCP server as possible. These details will further allow you to configure your IP stack with all the attributes required, such as IP address, network mask, default gateway, DNS server, whatever, and then hack away. So let's look at the case study A which describes a single bypass of MAC filtering on Windows DHCP server. I have a Windows DHCP server with one single filter that specifies that specific MAC IP address is denied access. Now, that MAC address happens to be the MAC address of my Linux attacking client. So if I try to obtain the IP address from the DHCP server, it fails. However, if I change the MAC address and reissue the request, I get the IP address and whatever the DHCP server is doing. But there is really nothing spectacular here. It's just a simple MAC inspection bypass. Now, case study B is really of importance to us because it shows the bypassing of DHCP profiling. So what happens here? We have our proof of concept and we decide that we want to impersonate Cisco access point. So we simply define the attribute that will inject this value, meaning Cisco AP 1500 into our DHCP packets, then we fire up the request and then look at what Cisco profiler does. Cisco ICE will trigger an event that tells us, okay, I see you, so you must be Cisco access point because you triggered my policy for Cisco access point. In other words, I found that you were using DHCP class identifier specific to Cisco AP that your DHCP parameter request list is 13615 that your name is bad hacker and that your MAC address is the MAC address that I have. So what happened here is that we masqueraded our attacking Linux client to appear as Cisco access point and that actually tricked the Cisco ICE profiler because we spoofed the fingerprint of the DHCP packet. Case study B will show us bypassing of DHCP profiling on Windows DHCP server. The logic is very much, well, not maybe the same but very similar. So the server will inspect the vendor class, so specific DHCP attribute and then if that attribute contains, sorry, does not contain values that are defined for one of the three Microsoft Windows options that it will declare the client as non-Microsoft client. Quite the opposite if the value of this parameter equals any of these three categories, it will conclude we are dealing with Microsoft client. So let's see how we can bypass that. We take our proof of concept and this time instead of masquerading as Cisco AP, we masquerade our client as MSFT 5.0. So I caught that from the network capture. I simply implanted that stuff into my proof of concept. I fired it up and here's what happened. What happened is that I received the default gateway of 11111. So what does it mean? Let me help you interpret this result. DHCP server is configured with two policies. One policy says, if I detect you are the Microsoft client, you will get the default gateway of 11111. If you're not Microsoft client, you will get the default gateway of 2222. So we got the default gateway of 11111, meaning the policy triggered was the one for Microsoft client. However, we were attacking with our Linux client, but we successfully spoofed the signature of Windows client and that tricked the Windows DHCP into believing we were Windows. Case study C is actually a real life scenario of a relatively recent penetration test that I was assigned with. Let me just give you the context and the setup of the environment. So in this specific environment, there was no DHCP configured on the client side. In other words, all the client devices were configured with static IP addresses. On the profiler side, there was no NMAP or SNMP scan or anything else for that matter. It was only relying on DHCP policy. So what happened here is that Iced or the device profiler simply had no information that would allow him to decide whether my device was this or that. And as a result, immediate access to internal network was obtained. Now I need to say here, it is rare to see that you have advanced device profiler deployed with, for example, DHCP profiling and then having your clients configured with statically configured IPs because it obviously negates the purpose of the device profiler. So static IPs simply don't give enough information to fingerprint the device. So here's how this attack happened. It happened as a two-stage process. The first step was I spoofed the MAC address of a legitimate device and I issued the DHCP request by a regular Windows DHCP client. And that attack failed. Now these screenshots show you why. I ended up essentially in quarantine VLAN with no access to the network because the profiler said, look, your DHCP class identifier is Microsoft. Your DHCP parameter request list matches Microsoft. Your host name was whatever it was. I think host name was not important here. But you will see in yellow the relevant stuff. So the profiler said, I found anomalous behavior and that is wired map spoofing detection. And the reason why I triggered the alarm is that I recognize you as a Microsoft workstation. By the way, the legitimate device was a printer. So the second stage of the attack or the second step was I spoofed not only MAC address, but I assigned the static IP address of a legitimate device. And when I fired that up, that attack succeeded. Of course, it succeeded because as I explained previously, having static IP leaves the device profiler without sufficient information to profile your device. So what about the risk mitigation and what can we conclude from the exhibits? First, how can we protect ourselves? I would say the most important step would be to fine tune the existing profiler policy. For example, add more criteria. Do not rely on a single policy or single criteria. In this case, if you already have DHCP profiling add-and-map scan, we don't need any other tool to help us do that. You can achieve that with the device profiler for sure. And with no additional cost. Again, if you have any decent device profiler and there are many of them available, you should be able to fine tune your policy and sharpen your edge of detection. So the recommendation goes two ways. First, do not select too many policies. So you may think of, okay, I'll select as many policies as I can in order to increase my certainty about device profiling. And sure enough, it would increase your certainty, however it comes with the cost. And that is that your network response may deteriorate. You may introduce unacceptable delays, frustrate customers because the connecting to the network will take too long. You may generate a lot of network noise and so on. On the other hand, if you select too few or too generic criteria, rogue devices will sneak in. So the suggested risk for this specific vulnerability is medium. And the reason why it's not high is because the attacker still needs physical access to your network. It's not low on the other hand, because physical access is essentially all the attacker needs. So you have two major options to protect yourselves. The first one is limit and control the physical access to your network, especially if we are talking about internal networks. And the option B is fine tune your network access policy. And primarily, I mean, use multiple detection criteria. However, bear in mind that whatever you do, you should achieve the balance between the security and performance. So two complex rules will come with the cost of performance. If the policy is too simple or too vague, you will simply decrease the security of the setup. So before we actually finish the presentation, I'm giving you the link to the proof of concept code. And blog, to be honest with you, I haven't made the blog about this particular topic, but I will, I promise. However, just one more word about the proof of concept. So it's a work in progress. But you have all the core functionalities there. The basic idea is I have several profiles predefined. Each profile will mimic specific family of devices. So I have Windows clients, Linux clients, Cisco APs, LaserJet printers. And I think the last profile is minimal. The idea being that you minimize your DHCP fingerprint. And essentially, you run the proof of concept and you simply specify what profile you want to use and see what happens. And that's it. Thank you for your attention. I hope you got some insight into this. Oh yeah, maybe just one more thing. I did not find anything similar in terms of manipulating DHCP packets. There are tools and techniques available for DHCP resource depletion. However, this one is, to the best of my knowledge, the only one that allows you to manipulate the DHCP application payload actually. So yeah, as I said, thank you for your time. That would be all from me.