DHCP is Your Friend!
by di0nysus
Did you ever wonder when you turn on your computer to surf the web how the heck your computer knows what IP to use?
If you are reading this article, chances are you already know. For those who don't know, I will give you a little background before revealing how this magic can be used for good... err... evil... well... you can choose exactly how you use your newfound knowledge.
This magical union between your computer and your ISP's server is known as Dynamic Host Configuration Protocol (DHCP). When you turn on your computer, or anytime you request it to, it sends a request via UDP on port 67 or 68 asking for information on how it should configure the network interface.
Information like what DNS server to use, what IP and netmask to use. DHCP was created by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (wow, that was a mouthful).
In this article I will concentrate more on how it works than where it came from. We will leave its origins for a more boring article another time. I will also explain how to bend it to your will...
Why Should I Care About DHCP?
One of the first lessons every aspiring script kiddy learns is the importance of his IP.
Your IP is what identifies you to the rest of the Internet. When you spew packets from your computer, this magic number is recorded all over the place, like footprints in the snow saying "I was here." The only people who can quickly trace this number to your actual computer are your service providers.
Coincidentally they are also the ones handing out the IPs (insert sarcasm here). So what if you could have 30 different IPs in an hour? That would sure make tracing you a lot harder. Easy, right? Just request a new IP from the magical DHCP server and rejoice.
I wish it were that simple. When you get an IP from the DHCP server it assigns you a lease. This lease is the amount of time that it will give you the same IP. Also, some ISPs, like my local ISP, require you to register your MAC address with them or their DHCP server will never give you an IP in the first place.
The Media Access Control (MAC) address is the unique hardware address given to your network card by its manufacturer. This gives them an extra level of "security." Security is in quotes because I will demonstrate how to fool the DHCP server into thinking you are someone else.
Lastly, you have a cache on your end that also says what IP you had last time you hooked up with the DHCP server. If your lease is still good the server will try to give you the same address again. This is nice if you have a domain name registered to a home account, but not so nice if you want to do some port scanning. You would never do anything like that, right?
Get To The Good Stuff Already!
So now we know a little about how DHCP works. Let's get into how it can be useful.
This article assumes that you are using a Linux box as a firewall/router for internal Windows boxes, I will also assume that you have installed the Cygwin package from Red Hat on your Windows box. If you have not installed Cygwin you should really check it out. It gives you much UNIX-like functionality on your Windows box, not the least of which is Perl, which we will be using later. Cygwin is free at: sources.redhat.com/cygwin
The Non-Authenticating DHCP Server
This could also be called the "easy to fool DHCP server," simply because it will hand out an IP to any old MAC address. As mentioned, your MAC address is what the DHCP server uses to keep track of who's who. Unlike the authenticating DHCP server, we will not need to perform any real magic to get a new IP.
For the rest of the article, I will assume that we are using eth0 for our external interface on our Linux box. So... let's do some initial checking.
To find our MAC address we can simply do an:
$ ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.115 netmask 255.255.255.0 broadcast 192.168.1.255 ether ec:1a:b3:7d:49:a3 txqueuelen 1000 (Ethernet) RX packets 118865822 bytes 116650628526 (108.6 GiB) RX errors 0 dropped 706 overruns 0 frame 0 TX packets 163616191 bytes 188303589898 (175.3 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0xf3100000-f3120000Or, if we really want to feel like UNIX geeks we can use:
$ ifconfig -a eth0 | head -1 | cut -f 11 -d "" $ ip -brief link|grep eth0|awk '{print $3}' ec:1a:b3:7d:49:a3This command will become useful later when you write a script to automate the new IP process, right?
We also need to take a look at our DHCP cache.
Lets do an:
$ ls /etc/dhcpcYou will likely see the following files: dhcpcd-eth0.cache, dhcpcdeth0.info, and dhcpcd-eth0.info.old
We can safely remove these files with an:
# rm -f /etc/dhcpc/dhcpc*eth0*Because we don't want the DHCP server to know that we ever had an IP.
The next thing we need to do is "change" the MAC address that will be sent to the server.
First, make a note of your MAC address. It will be something like 00:50:DA:0A:24:26. Let's change it to 00:50:DA:0A:24:27 and try to get a new IP.
First we need to take down the interface with an:
# ifconfig eth0 downThen we can change the MAC address with an:
# ifconfig eth0 hw ether 00:50:DA:0A:24:27Now we bring the interface back up with:
# ifconfig eth0 upAnd last but not least, we request our new IP with:
# /sbin/ifup eth0and voilà! You have a new IP.
If you got the same IP you had before, you probably forgot to delete the cache in /etc/dhcpc.
At this point it should be painfully clear how these concepts could be incorporated into a script for things like port scanning or whatever your devious mind desires.
The Authenticating DHCP Server
This is where it gets a little tricky.
Some ISPs (like my ISP) require you to register your MAC address so they can control which computers have access to their network. So, what's a boy to do?
Grab a list of IPs and MAC addresses, wait for an IP-MAC address to go down, and use that you are someone else. Easy, right?
The hard part is how we get the MAC addresses. Luckily, Microsoft has provided us with an easy way to query MAC addresses from remote computers.
NetBIOS strikes again!
First we need to generate a list of IPs of computers that are on our subnet. If our IP is 24.64.220.20 then we can be pretty sure that all of the people on 24.64.220.* have registered MAC addresses.
First we will do an Nmap scan on port 139 (NetBIOS port) on our subnet and generate a list of IPs to query for MAC addresses:
# nmap -sS -p139 -oM '-' 24.64.231."*" | grep open | cut -d "" -f 2 > ip_listThis will generate our list. This should work on Linux and Windows (if you have installed Cygwin and Nmap).
Then we need to get MAC addresses for all of the IPs. This can get a little ugly when you have to do it manually.
On our Windows box, the command nbtstat -A [IP Address] will give us the MAC address of the remote host as well as some other useless info.
Here is a little script to generate an IP-MAC table. We will need to do a cat ip_list | perl this_script on our Windoze box:
# this_script while ([]) { chomp; $ip = $_; chomp($mac_raw = `nbtstat -A $_ | grep MAC`); (undef, undef, undef, $mac) = split('', $mac_raw); print "$ip $mac\n"; }Redirect the output to a file and wait a few minutes.
Then run the script again and see which IPs don't return a MAC address. These computers are no longer accessible meaning that their MAC can be used to authenticate against the DHCP server.
Follow the steps outlined above using your newfound MAC address and you are on your way.
Final Thoughts
While using multiple IPs is a good way to cover your tracks, it is in no way a magic ring that makes you invisible on the Internet.
Think of it more as an added layer of confusion when trying to follow your tracks. At the very least I hope that you learned about Cygwin and how it can add a whole new dimension to your Windows world
I have written several scripts around these concepts. Feel free to email me for copies.
Happy hax0ring!