Page 1 of 7 123 ... LastLast
Results 1 to 10 of 68

Thread: DHCP and the Resulting Theoretical Attacks

  1. #1
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915

    DHCP and the Resulting Theoretical Attacks

    DHCP and Resulting Theoretical Attacks

    Hey Hey,

    I'm sure that you all can add to this, but I'll lay out the basics for you and a few theoretical ways to disrupt DHCP.

    You all know how DHCP works right? You plug into a port that's linked somewhere to a DHCP Server and you are assigned an IP Address and other vital information. Now... do you understand the down and dirty of it? For those of you that want a more technical explanation. I'll refer you to RFC 2131: DHCP. In all it's might and glory, DHCP is nothing more than an extension to BOOTP if you really want to simplify things, however I'm not going to get into an explanation of BOOTP.

    I'm extremely lazy and don't feel like typing out what a DHCP Message looks like, so I'm stealing the outline from the RFC listed above. Remember that this message is transported using UDP and is encapsulated in a frame.
    Code:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Operation    | Hardware Type | Hardware Len  |   Hop Count   |
       +---------------+---------------+---------------+---------------+
       |                         Transaction ID                        |
       +-------------------------------+-------------------------------+
       |Seconds Since Process Start    |           Flags               |
       +-------------------------------+-------------------------------+
       |           Client IP Address (Used During Renewal)             |
       +---------------------------------------------------------------+
       |                   Your (Client) IP Address                    |
       +---------------------------------------------------------------+
       |                      Server IP Address                        |
       +---------------------------------------------------------------+
       |                     Gateway IP Address                        |
       +---------------------------------------------------------------+
       |                                                               |
       |                   Client Hardware Address                     |
       |                                                               |
       |                                                               |
       +---------------------------------------------------------------+
       |                                                               |
       |                       Server Hostname                         |
       +---------------------------------------------------------------+
       |                                                               |
       |                            Filename                           |
       +---------------------------------------------------------------+
       |                                                               |
       |               DHCP Options (Including Messages)               |
       +---------------------------------------------------------------+
    One day, I'll make my own pretty tables like that. In the mean time, those of you that browse to the RFC will notice they actually have shorter versions in their table fields. That's because I've expanded upon them to give you a better idea of what I'm talking about.I'm not going into detail on all the fields. I'll mention two things though.The first is that there are two used values for the Operation Field... 1 and 2. 1 is BOOTREQUEST and this is used when the client sends a message to the server. 2 is BOOTREPLY and this is used when the server sends a message to the client.The second is that the Gateway IP Address is used when you are doing DHCP Relay (DHCP Server is located on another subnet... which would otherwise cause problems since routers don't forward broadcasts). If you want more information on the packet itself, I suggest you read the RFC.

    Now back to where we started. So you've plugged into your network and your DHCP Server gave you an IP Address... but exactly what went on during that process? Obtaining an IP Address and the related information is actually a 5-Step process (Assuming all goes well). There are actually 8 DHCP Messages... which are located in the DHCP Options field of the packet. There are a few common points for these steps, which I would prefer to mention here, rather than continuously repeat. The DHCP Options field ALWAYS begins with the same byte sequence. This sequence is 4 octets containing the following decimal values - 99 130 83 99. Another thing to remember is the ports used for communication. The client (your computer) always sends packets to Destination Port 67/UDP. The server will respond to the client using Destination Port 68/UDP The 5-Step process is as follows:

    Step 1. DHCPDISCOVER. You have plugged in your computer and the settings tell it to ask a server for an IP Address. This results in a DHCP packet with the DHCP Options field set to DHCPDISCOVER. During a DHCPDISCOVER a broadcast is sent out. Basically your computer says "I need an IP Address, who can give me one." There are two other times a DHCPDISCOVER will take place. If a computer wants to renew it's lease (Windows computers do this when the DHCP Lease has reached 50% (unicast to the current DHCP Server) of it's time and then again at 87.5% (broadcast to any listening DHCP Server). The other time it will do this is if the 5-step process fails during one of the other steps.

    Step 2. DHCPOFFER. The various DHCP Servers on your network have heard your request and they reply with a set of configuration data that you can use. (Standard Information includes IP Address, Subnet Mask, Gateway and DNS Servers). This is a unicast as opposed to your clients broadcast.

    Step 3. DHCPREQUEST. Your computer accepts an offer (traditionally the first offer it receives) and sends out a broadcast, telling the server it has accepted the offer. The reason for the broadcast at this point, is so that other DHCP Servers will see it and they will drop the addresses they have offered back into the DHCP Pool (You have declined their offers).

    Step 4. DHCPACK. Just like any other Acknowledgement with computers. The Server says "Yes, you understood the information I gave you.. go ahead and start using it." Your computer uses the information that was supplied in the DHCPOFFER.

    Step 5. DHCPRELEASE. When you are done using the IP Address, you tell the server and release your DHCP Lease. This let's the server put the address back into the DHCP Pool. You may notice that when you simply power off your computer, and don't first release the IP Address manually, that you tend to get your same IP Address when you plug back in if it's in the near future. The reason for this is that Windows (and at least some Linux flavours) don't send a DHCPRELEASE before they power down, they just shut down the connection. The DHCP Server still thinks the lease is active. So when you reconnect, it already has you matched in the Pool.

    Those are the steps, however there are other DHCP Messages available from the Options field. They are:

    DHCPNAK. Say your computer misunderstands the Address in DHCPOFFER or your lease has expired. The DHCP Server will send you a DHCP Not Acknowledge packet.

    DHCPDECLINE. A DHCP Server is supposed to test the address availability before issuing it to you. However if the packet is lost on transit, it's possible for the Server to issue an address that is already in use. When the Client receives an offer, it will also test the address. If it finds the address is in use. It will send back a DHCPDECLINE instead of a DHCPREQUEST.

    DHCPINFORM. Occasionally you'll have a PC with a static IP address, however you may want it to receive other information (Gateway, DNS Servers) from the DHCP Server. The DHCPINFORM message asks the server for Local Configuration Information only, stating that the client already has an IP Address.

    That, in a nutshell, is DHCP. I realize it is much more indepth and that I could go on for ages just describing the basics, however my purpose is to make this tutorial security oriented. I just wanted to cover the basics first.


    DHCP and Security

    First, let's look at a security benefit of DHCP (I'm not the greatest at thinking up scenerios so give me a break, but you'll at least get the idea). You're company wants static IP Addresses on all the machines that were previously Dynamic. There's been some fishy business and they want to know the where and when of it. You could go from machine to machine and set static IPs, however if you have multiple buildings, and the PCs are spread out through-out buildings... this would take a lot of time and effort. The easiest thing to do would be to limit your DHCP Scope. You, being the good little admin that you are, have documented all the PCs distributed throughout the firm, and have a nice list of MAC Addresses. Instead of running from PC to PC, you simply enter in specific DHCP Reservations. This MAC Address always get's this IP Address. You've got Addresses in your DHCP pool leftover? That's easy to deal with... Add those IPs to your DHCP Exclude list. Your entire firm is now essentially using static IP Addresses and you never had to leave your cozy little office. This is a great benefit, you see fishy activity from an IP. You pull out your diagram and you know exactly who that IP belongs to, and in this scenerio... it makes management happy.

    However, DHCP also has several security flaws. The biggest and most easily exploited is a rogue DHCP Server. Walk into an office and plug in a PC running a DHCP Server. This has happened several times at our college. The IT people can never seem to figure out how to solve this problem. You'll end up with many users assigned IP Addresses that are completely useless and because of this, they lack network connectivity to the extent that they should have it. There are two quick fixes for this. Client-side firewalls that filter port 68/UDP, only allowing DHCP Messages from known DHCP servers. The other solution is a little more pricey, however better than having firewalls on all your client PCs inside a large corporation. This solution is layer-3 switches. These switches provide for access lists, which would allow you to setup ACLs on ports 67/udp and 68/udp so that clients/server communication on those ports would be only with legitimate servers.

    You could also perform in a sense, a man in the middle attack using DHCP. A software application could be generated that listened for DHCP messages. A spoofed message could then be injected into the "conversation" sending a DHCPNAK to the client or a DHCPDECLINE to the server. You could effectively stop the client from ever receiving an IP Address. The software could also listen specifically for DHCPOFFERs. As soon as it hears one (you'd have to be using hubs or have the ability to sniff through the switch). However, the attackers PC could change it's IP address to match the IP that is offered. When the client tests the availablility of the address, it will find it in use and send back a DHCPDECLINE, again this process could be repeated forever preventing the client from receiving the information it requires.

    A third way to exploit a network relying on DHCP is to claim all the addresses in the pool. If you are on a smaller network that only has a single Class C range as its pool (254 usable addresses), it would be very easy to claim all those addresses from the DHCP Server. The next person who sends out a DHCPDISCOVER is going to find out that there are no addresses available for them to use. This attack could be easily initiated using pre-existing software. Even honeyd will emulate real machines and claim real addresses from the network. A method of protection against an attack like this would be to create a list of allowed MAC Addresses, if that's a feasible design for your network.

    I had hoped to present you with further security related DHCP tasks (from attacking or securing points of view)... however at 3AM... I'm starting to run out of wind and coffee. I wrote this because on Tuesday I have a test on DHCP and I find the best way to reinforce information is to explain it to someone else.

    I'm curious to see solutions to some of the possible attacks I have listed... I'd be very interested in seeing how people deal with this, or if people even bother to deal with this. It's my theory that most people don't consider attacks using DHCP and tend to ignore it and leave it with a fairly basic default setup. Even setting up the ACLs to ensure only legit DHCP servers are used, could be a big step towards protecting yourself and your company. Anyways, that's about it for now... Take it easy and as always dump a bunch of feedback on me... Let me know what you think.

    Peace,
    HT

    [Edit]
    I thought of a little addition that I'd like to add. Very Handy software, that every admin should implement on their network is NetReg. This requires users to authenticate and provide you with their hardware information (MAC Address) before they'll recieve a valid DHCP Address. You only have to register your hardware the first time and the database will remember you. For the most part this will keep would-be attackers at bay.
    [/Edit]

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    How about this attack:

    - Create a rogue DHCP server
    - Allocate a block of normal IP addresses which are within the pool of the real DHCP server but not in use
    - Send all the right info to the clients, except for the default gateway, which the attacker changes to their own IP
    - The attacker's machine performs routing and forwards packets to the genuine real gateway
    - Attacker can now sniff outgoing packets from clients, even on a switched network

    Slarty

  3. #3
    Senior Member
    Join Date
    Mar 2004
    Posts
    139

    A timely contribution. I have just been reading up on DHCP, and its nice to get different point of views and interpretations.

    Here's a link that might be of interest:

    http://www.networkpenetration.com/dhcp_flaws.html

    Its short and sweet.

  4. #4
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    Several of those attacks can be defeated, but I am wondering how exactly this qualifies as a tutorial at all, let alone a security tutorial. It doesn't cover securing the system, it doesn't really cover how to break the system, and it doesn't cover how to implement DHCP pretty well at all. Your "tutorial" gives a brief "how dhcp works" bit and then goes on to talk about potential flaws -- the majority of which are preventable with switches you seem to believe are expensive.
    Check out Cisco's Cayalyst 2950, or the low-end Baystacks. The features to limit certain types of traffic (DHCP) on the switch have been there for a while, and has become mainstream, so most admins should be able to secure DHCP on their networks from these sorts of attacks.
    At any rate, Thumbs Down, this isn't a tutorial, doesn't belong here, and none of the information is explored sufficiently. Why is it a cursory mention of "this can be done" is acceptable around here anymore?
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  5. #5
    chsh - I think most people would call it a proof of concept, and putting ideas out here never hurt anyone. So maybe it's not a tutorial.

  6. #6
    Senior Member
    Join Date
    Jun 2003
    Posts
    772
    It is a good article, the thing you expect from the stuff posted here is called a paper.
    The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me

    www.elhalf.com

  7. #7
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    Might I sugget that if I asked any of you to describe how to properly secure a Harrier "Jump Jet's" primary and secondary flying sites and their associated logistics sites and the supply routes between them there would be none of you who could.

    Why? Simple.... You don't know how they work.... Without that knowledge they are wide open. Exactly the same applies to computer security. You need to know how the computer and the OS work in order to be able to see the potential holes and mitigate them.

    Thus HT's article/paper/tutorial is quite valid here. There are plenty of visitors here who don't know this information and we do them a disservice by not providing it. Just the same as there is no point me explaining IRF deployment and use until you know the basics of securing that flying site in the first place.

    Good job HT.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  8. #8
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    IMO More disservice is done by the large number of half-efforts presented as tutorials. This is supposed to be a security site. This is not a tutorial. This is the Security Tutorials section. Do the math.

    Just my (obviously unwelcome) $0.02.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  9. #9
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    No less valid than this I would suggest.

    It doesn't cover securing the system, it doesn't really cover how to break the system
    At any rate, Thumbs Down, this isn't a tutorial, doesn't belong here, and none of the information is explored sufficiently. Why is it a cursory mention of "this can be done" is acceptable around here anymore?
    "Why is it a cursory mention of "this can be done" is acceptable around here anymore".... Hmmm.... That "tutorial" was from nearly three years ago..... Oh well..... Things don't change I guess......
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  10. #10
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    Originally posted here by Tiger Shark
    No less valid than this I would suggest.
    You are quite correct Tiger Shark, however, as that was well before your time, you may not know that there was *NO* Security Tutorials section back then. When I posted that, it was to the "Tutorials" section, as there was no separation between the two. While you may not see it as a security tutorial (I certainly don't), evidently whomever created the two forums mistook it as such.

    "Why is it a cursory mention of "this can be done" is acceptable around here anymore".... Hmmm.... That "tutorial" was from nearly three years ago..... Oh well..... Things don't change I guess......
    My tutorial then was not posted here, and it was indeed more than "this can be done" as I illustrated how to go about enumerating the information. Things do change, which is precisely what I was saying. Thank you for further illustrating my point.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •