How to Build an ARP Network Enumeration Tool Using Python
Welcome back my fellow hackers! We’ve covered host discovery tactics before; specifically, we’ve covered ping scans and ARP scans. But we didn’t go very in-depth when we covered ARP scans. Today we’re going to dive head first into this enumeration tactic by building our own ARP sniffer!
This tool will use ARP to find other hosts on the network, that way we know who our neighbors are. We’ll be writing this tool in Python, so brush on that if you haven’t already. We’ll also be using the Scapy library for manipulating the packets. We’ve already covered the basic usage of Scapy, so if you don’t know (or just need a refresher) you can find it here. First we’ll go through the script chunk by chunk and explain what everything does, then we’ll test our script to make sure it works. So, let’s get started!
Building the Script
Step 1: Path and Imports
Our fist step is very simple, we’re going to set the interpreter path, and import most of the libraries we’ll be using:
Now this actually looks way more complicated than it is. We start by setting our interpreter path (#! /usr/bin/python), and then we get to importing modules. First we take the entire sys module, then we take datetime out of datetime. Now here’s the weird part. Since Scapy is a third party library, not everyone will have it installed on their machine, so we need to take that into consideration when building our script.
Instead of import Scapy directly, we place it within a try/except block, so that if the import fails (since it isn’t installed) there aren’t errors spilled everywhere. This keeps everything nice and tidy. Within the try/except block we import getLogger and ERROR out of the logging module. We then run the getLogger function as seen above. This will stop Scapy from spilling out its own errors when we import it. We then import everything from Scapy, and set the conf.verb to zero. This will stop Scapy from throwing out messages that packets and been sent and received, which also helps keep things clean. Now that we have all our importing done, we can get to the fun stuff!
Step 2: Declaring the Class and Setting up
In order to make sure this script is as clean as possible, we’re going to keep all the functions for our sniffer inside a single class:
We’ve named our class ArpEnumerator. Next, we define our __init__ function. This function will automatically run when a new instance of this class is made. This is where we can set up variables that will be used throughout the entire class. We’ve taken quite a few arguments in our __init__ function, don’t worry about these for now, just note that the default value for all of them is False.
Now we can set up the variables for our class. We start by simply copying all our arguments into variables that share the same name. Now we can access these arguments across the whole class. Next, we declare a dictionary, but we leave it empty. We will use this to keep track of the hosts we find later. The filter variable is simply set to the string of “arp.” This is a good time to mention that this script will also have a passive mode, in which it doesn’t sent any packets, but still listens for them. This filter will change later to fit the needs of the user. Our final variable is simply the value of the datetime.now function. This will allow us to track when the enumeration starts and stops, so we can tell the user how long it took. Now that we have all our variables set up and ready to rock, let’s move on.
Step 3: Making the Functions
In this step we’re going to create all the functions that our class will use. They are relatively simple, so they should all fit nicely under one section. First, we’re going to make the functions to handle passive mode:
This function serves as a sort of packet handler for the sniffing we’ll be doing later. First, it checks to see if this host is already in our dictionary of discovered hosts, if it is, we move on, if it is not, we print the IP address and the MAC address of the newly discovered host, and place it in the dictionary. This function does nothing on it’s own, it is designed to be used in our next function:
The function seen above will actually perform the sniffing. We start by checking the range variable we set earlier to see if it contains anything. If it does contain something, we edit the filter variable and add the desired range of addresses to it. This way the attacker can sniff for a specific range of addresses, or all the addresses at once. Now that we have our filter ready to go, we call the sniff function inside of a try/except block. We set our filter, and our handler function. We also set store to zero, since we won’t be inspecting these packets any further.
The reason for try/except block is that sniffing in an indefinite process. Once it starts, it will not stop until the user forcibly interrupts it. Since we placed it inside our try/except block, we can handle keyboard interrupts, and properly stop the sniffing. Once our sniffing is complete, we report that sniffing has stopped followed by the duration of the sniffing. Now that we have our passive portion complete, we can move on to the active portion:
This functions gets a little more complicated than the others. First, we tell the user that we’re beginning the scan. Then, we use the srp function from Scapy to send out ARP requests for all the hosts in the range of addresses provided by the user. Once we’ve gathered all the response packets, we store them in the ans variable (note that we’ve also built a try/except block to handle any errors that occur). Now that we have all our response packets stored in a list, we iterate through them and store them in our dictionary of discovered hosts. We also print out the addresses of the host while we store them. Once this iteration is complete we tell the user the scan is done and stop the clock for the scan duration.
We’re almost done here so just stick with me! The final function of our class does not effect the sniffing in any way, but it’s a nice little added feature:
This function simply opens a new file (named by the user) and writes the contents of the discovered hosts dictionary to it. This way the user can output the results to file very easily! Now that we have our class and functions ready to go, let’s use them!
Step 4: Input and Execution
You may think it’s a little weird that we’re taking input so late in the script, but it’s actually not. We’re going to be using another module called argparse in order to take command line arguments in a very clean and easy manner:
If you feel intimidated by this large chunk of code, don’t. It’s just importing argparse and setting up all our arguments. I’m not going to go through and talk about every single argument, as they should be very self-explanatory since we just built the functions that use them. Let’s move on:
Now we just have to do a few checks before to execute our scan. Here, we check the arguments given to make sure everything lines up. We check for a specified network interface, and then we check to see if a range is given for the active scan (since the active scan is required to have a range). Now that we’ve made sure everything is in order, we can finally execute our scan:
We use some basic if statements to find what kind of scan our user wants, and then we create a new instance of our class under the enum variable. Once we’ve got the scan type figured and the class instance created, we execute our scan! Now that the scan is complete, we need to see if the user wants to output the results to a file:
That does it, our script is complete! Now that we’ve spent so long building it, we can finally test it!
Testing the Script
We’ll start by view the help page that argparse generates for us:
Looking good! Let’s go ahead and test the active scan, we’ll also output the results to a file named enum.txt:
We started a scan looking for all addresses within the 10.0.0.0/24 range, and it worked! We also successfully output our results to a text file, let’s check that file to make sure it went well:
Excellent. Our scan worked and our output file looks good. Now that we know the active scan works, let’s give the passive scan a try:
It works! It’s worth noting that passive sniffing will normally take a rather long time. I had mine running for a few minutes and only managed to catch two hosts. The perks of passive sniffing is that no packets are sent out, so the victim has no way to tell that they’re being watched! This helps us prevent tripping security devices such as an intrusion detection system, which can be set off by sending too many packets at once.
There we have it! Our script works like charm. Now that we’ve got our hands dirty and built our very own ARP enumerator, we should have a much deeper understanding about how ARP enumeration works. Remember: The best way to learn how something works, is to tear it apart and build it yourself!
How Hackers Redirect Web Traffic with DNS Spoofing
Welcome back my fellow hackers! There have been some articles I’ve been wanting to write regarding social engineering, more specifically, stealing passwords. But, in order to do that, there are some basic concepts and methods we needs to have a grasp of. The first of these concepts is Man in the Middle Attacks. Since we’ve already covered that, we’re going to cover the next concept, DNS spoofing. First, we’ll cover what DNS is exactly, then we’ll quickly discuss the anatomy of the DNS spoofing attack, and finally, we’ll perform the attack! So, let’s get started!
What is DNS?
This question is actually fairly simple. DNS stands for Domain Name System. You know when you go to a website using a browser, you type in a URL instead of the IP address of the server? That’s DNS working it’s magic! What DNS does is it keeps track of what IP addresses reside at what URLs, that way we don’t have to remember the addresses, just the URLs! Pretty neat, huh? Like I said, DNS is fairly simple, so let’s move on to the next part, the anatomy of a DNS spoofing attack.
Anatomy of a DNS Spoofing Attack
Since this can be a bit difficult to talk about without a reference, we’re going to be dissecting this attack based on this diagram:
As we can see here, the attacker starts by pretending to be the DNS server. Then, when the victim requests the address for the desired site, the fake server responds with whatever address the attacker wants, which in this case, directs the victim to a fake site. This attack is very simple, but can often play a part in a larger attack. Now that we know the ins and outs of DNS spoofing, let’s perform it ourselves!
Performing a DNS Spoofing Attack
Setting up the Attack
Before we really get started, there are a couple of things that we need to prepare. Namely, we need to prepare the fake website, and set up the configuration file for the DNS spoofing tool.
Let’s start by setting up the website. First, we’ll whip up some basic HTML code so we actually have a site. We’ll be using gedit. The proper file can be opened with the following command:
Now that we have our file open, just go ahead and erase everything in it. I’ll be replacing it with the following:
Feel free to replace the words with whatever you like, as long as you follow the HTML tags, everything should be fine.
Now that we have our website’s HTML code ready, we can go ahead and start the server that will serve the website. We’ll just be using the pre-installed Apache2 webserver, which can be started with the following command:
Now that we have the site up and running, we need to quickly edit the configuration file for the DNS spoofing tool. We’re just going to be modifying the /etc/hosts file and using it for our attack. We can open the file with the same command we used previously, but with the new file path. Once we have the file open, we can set up the file to tell the spoofing tool what sites we want to spoof. Before we do that, we need to know our local IP address, which we can find with the ifconfig command:
We can see that our local IP address is 10.0.0.16. Now that we know it, we can edit the file. We’re just going to be adding this line:
The line we added (the bottom one), will tell the spoofing tool that we want www.hackingloops.comto be redirected to our local IP address, which will then serve them our website instead of the real one! That’s it for the setting up, now it’s time to execute the attack!
Executing the Attack
Now, if we’re going to be redirecting traffic that isn’t ours, we need to be able to read it. This is where the Man in the Middle Attack comes into play. We’re going to place ourselves between the victim and the gateway, so that all of the victim’s DNS requests have to go through us. We can then sniff these requests and redirect them with our spoofed responses! To start, we need to know the gateway’s IP address, which we can find with the route command with the -n flag:
We can see by the above output that the address of the gateway is 10.0.0.1. For the sake of keeping this relatively short, we already have our victim’s address, which is 10.0.0.13. Note that all these addresses are on the same network. This form of DNS spoofing only works if the victim is on your LAN. Now that we have the addresses, we can start the Man in the Middle attack (finally)! We’re going to be using arpspoof for this attack, and we’ll be using the -i, -t, and -r flags to specify the interface to attack on and the addresses to attack:
Once we execute this, the MitM will start.
DO NOT FORGET: You must enable IP forwarding, so the data from the victim doesn’t get hung up on the attacking system. This can be done with this command: echo 1 > /proc/sys/net/ipv4/ip_forward
Now that we have our MitM running, we should have all the victim’s traffic flowing through the attacker system. Since we can see all this traffic, we can start the DNS spoofing tool (dnsspoof) to listen for DNS requests for www.hackingloops.com and respond to them with our IP address! Let’s go ahead and start dnsspoof now. We use the -i flag for giving an interface, and the -f flag for giving the path to the hosts file. The command to start the attack should look something like this:
We can see that dnsspoof is now listening for UDP traffic on port 53 (port 53 is the DNS port, and UDP is the transport protocol DNS uses) from all address but our own! Now that our attack is up and running, let’s move over to our victim PC and try and access www.hackingloops.com from a web browser:
Now, before we celebrate, let’s look back at dnsspoof to see the output:
There we have it! We were able to start a Man in the Middle attack, and use it to perform a DNS spoofing attack, which redirected a legitimate request for www.hackingloops.com to our fake website!
There are multiple reasons for this article. For one, we’ll be needing these attacks very soon in order to steal passwords from an unsuspecting user. Secondly, it’s a proof of concept of sorts. It shows that these smaller attacks (MitM, DNS spoofing, etc.) aren’t just one trick ponies. We can combine these attacks to achieve even greater things. Many times, when performing an actual hack, you will need to combine many different kinds of attacks at once to achieve a goal, this just proves that. I’ll see you next time!
How to Steal Cookies the Easy Way
Cookies still remain one of the largest areas of computing that the average user just doesn’t understand, and there are a myriad of different ways that a hacker can take advantage of cookies to steal a user’s personal information. Cookie stealing, which is synonymous with session hijacking, allows an attacker to log into a website that is protected with a user’s username and password by stealing session data in real-time. But before we delve into the different ways of stealing cookies, we first need to understand what a session is and how cookies work.
What is a Session?
“Session” is a term in computing – more specifically, networking – that gets thrown around a lot, but it can seem like jargon to the aspiring hacker. Most concepts in computer networking are in some way related to the OSI model, which is comprised of seven different layers that map different stages and processes of data exchange between two remote computing systems. More importantly, the fifth layer is called the Session layer, and this is where the term “session” gets it’s name.
Within the Session layer of the OSI model, you’ll find common protocols such as SOCKS (a common type of proxy server connection), PPTP (Point to Point Tunneling Protocol), RTP (Real-time Transport Protocol), and others that aren’t as well known. However, when someone talks about session hijacking, they’re most often referring to a session between a client computer and a web server. In this context, “session” basically means a semi-constant exchange of information between two hosts. In contrast, consider constant exchanges through other protocols such as VPN tunnels, whereby the connection is permanent (barring technical difficulties, of course).
In a session, two computers exchange information and authentication credentials to lay the groundwork for future communications. Take Facebook, for example. After you have logged into the Facebook service, you can browse through your feed, chat with friends, and play games until you intentionally choose to log out. If a session hadn’t been built between your computer and the Facebook servers, you would need to continually login again and again every time you wanted a new piece of data. Fortunately, you don’t have to, because all of your connection information is stored within a cookie.
What is a Cookie?
Cookies are small repositories of data that are stored within your web browser by a web server. They are rife with security concerns, and some of them can even track your online activity. Whenever you visit a web site, the cookie stored in your browser serves as a type of ID card. Each additional time you login or request resources from the same web server, the cookie saved in your browser sends its stored data to the web server. This allows web site administrators, and even Internet marketers, to see which of their pages are getting the most hits, how long users stay on each page, which links they click on, and a wealth of other information.
And believe it or not, cookies are extremely prevalent these days. Have you ever purchased something from Amazon.com? If so, then you’ve used cookies before, whether you knew it or not. It’s quite common for online ecommerce sites to use cookies to record and store personal information you’ve entered, which products you’ve searched for, which items are in your online shopping cart, and other information so it doesn’t need to be tediously reentered each time you want to make a purchase.
Furthermore, cookies are used to make a website more personal. Many sites offer preference options to let you customize the look, feel, and experience of any given web service. Once you revisit the site or resource, you’ll find that all your preferences were preserved. Though cookies make browsing the web a lot more convenient, they do have a lot of security drawbacks, as we’ll discuss next.
Types of Cookies and Security Problems
In theory, the only other online entity that can read cookies stored in your browser is the website that stored it there originally. However, it’s surprisingly easy for scripts to mine data from cookies, and there are some exceptionally dangerous types of cookies that are rife with security threats. Mainly, the types of cookies that are the most fearsome are named Flash cookies, zombie cookies, and super cookies.
Even though your browser has ways to manage cookies, some are nearly impossible to delete. The problem is that special types of cookies aren’t stored within your browser, so even if you opt for a different web browser (Firefox, Chrome, etc.), the cookie will still be active. And many of these types of cookies are much larger than the average 4KB HTTP cookies – some of them ranging to 100KB or even 1MB. If you attempt to delete the cookie but notice that it keeps coming back every time you restart your browser, you’ve discovered a zombie cookie and may need special security software to remove it.
Viewing Your Cookies and Managing Them
You might now be wondering just how many cookies you have stored in your browser, and what you can do to pro-actively manage them and avoid the disaster of having an attacker hijack your session. Just about every browser has useful extensions that allow users to manage, backup, delete, secure, and view their cookies. All it takes is a simple search through your browser’s add-ons menu, though for Firefox users, I highly recommend the View Cookies add-on.
Though you can navigate through the file system and see the cookies individually (which stored in different places by different browsers), I think the add-ons are the best way to go. Furthermore, just about every browser has code that allows users to completely disable cookies or set limitations, such as disallowing any cookies that are greater than X number of kilobytes or megabytes in size. Lastly, many browsers even have a setting that specifically disables flash cookies.
The Easiest Way to Steal Cookies
There are a number of ways that someone can steal another user’s cookies. From cross site scripting attacks to viruses embedded in seemingly harmless software, modern hackers have a lot of tools in their tool belt to hijack an unsuspecting user’s session. Many of these advanced attacks require a lot of background knowledge and expertise in networking protocols, software development, and web technologies to carry out the attack.
Unfortunately for average users, there is one place way that is easier to steal cookies than any other attack method, and that’s by using simple tools over a local LAN. But getting access to a local LAN isn’t as challenging as it may seem. You can view any of our other posts on just how easy it is to crack wireless encryption protocols, but try to imagine where the easiest place is for hackers to connect with other users over a local LAN. Can you guess where it is?
That’s right, on public Wi-Fi networks such as those found at airports and your local Internet café – heck, even a Starbucks. You don’t even need any fancy command line tools or advanced packet sniffing knowledge to steal cookies. Nope, all you need is a Firefox extension called Firesheep. Though it isn’t currently supported on Linux, it is available on Mac OS X and Windows (XP and later versions, dependent on the Winpcap package).
Firesheep
Firesheep is a simple to use Firefox extension that leverages underlying packet sniffing technology to detect and copy cookies that are sent in an unencrypted format. If the cookie is sent across the network in an encrypted format, there’s not much this tool can do, however. But Firesheep makes it ludicrously simple to hijack a user’s session. As the extension sniffs out cookies, it populates a list of them on the sidebar of your browser in real-time. Once an unencrypted cookie has been discovered, the user (it’s so simple I doubt it’s fair to use the term hacker) simply needs to double-click on the cookie and they’ll automatically hijack the session and log in as the unsuspecting user.
Given that Mozilla is a legitimate and trustworthy organization, it’s a little odd that they wouldn’t blacklist the extension. However, Mozilla had stated that they only use their blacklist to mark code and add-ons that contain spyware and other such security threats. Since this tool doesn’t harm the user’s browser, it seems that it’s still available. But even if they did disable, attackers would still be able to use the tool since Firefox contains a feature that effectively disables the blacklist.
Packet Sniffer’s and Man-in-the-Middle Attacks
Firesheep is essentially a packet sniffing add-on that is ridiculously user-friendly. However, advanced users can take advantage of other packets sniffers, such as Wireshark, to steal cookies. However, this method is a lot harder an takes some preexisting knowledge of how to work in Firefox. We won’t detail the process of starting a Wireshark packet capture here, but we do want you to understand how they work.
Man-in-the-Middle attacks and DNS based attacks are very common, and they both work to redirect a user’s traffic to a computer system that the hacker controls – such as their personal computer, a server, or a networking device (router, firewall, proxy server, etc.). Once the hacker has hoodwinked the end user’s computer and/or the default gateway into sending their data to the hacker’s networking interface, the attacker can see everything that isn’t encrypted. Naturally, this includes cookies, so all a hacker would have to do is run a capture, analyze collected traffic, and pluck the cookie data out of their results before the user disconnects or logs out.
Cross-Site Scripting (XSS)
Last but not least, cross-site scripting is another popular way to steal cookies from a user. If you remember, most often only the website that stored a cookie can access it, but this isn’t always the case. Cross-site scripting works by embedding PHP (among other types) of scripts into web pages, web pages that may or may not be owned by the hacker (though often they are not).
Though security controls are always increasing, there are still a vast amount of websites vulnerable to XSS attacks. It can even be a simple website like a forum. For example, consider a forum that allows image tags. They code post a link in the image tag with code such as the following: <img src=MyBadScript.html/>
Other times, they may simply link to a web resource that contains their script. Once the script executes in the users web browser, the attacker’s code will execute and send copies of any active cookies to another location, such as their web browser or another resource.
Final Thoughts
Remember that the idea here is to learn how to protect yourself, and others, from becoming the victim of a cookie stealing attack. Though it would be simple to run Firesheep, I’d highly advise against doing anything illegal. Also remember to respect other user’s privacy.
How Hackers Spy on People with a Man in the Middle Attack
Welcome back everyone! Recently, we’ve been discussing ARP quite a bit, so I figured I’d take this opportunity to cover a fundamental ARP based attack, the Man in the Middle. We’re going to cover how this attack works and then we’re going to launch this attack on our test network. So, let’s discuss how this attack works.
The Anatomy of a Man in the Middle Attack
A Man in the Middle is just what is sounds like. We’re going to insert ourselves into the middle of a connection. Let’s take a look at a diagram of a MitM attack, then we’ll dissect it further:
We can see in the diagram above that the attacker has killed the victim’s original connection to the server. The victim and server now think they are connected to each other, when they’re actually both connected to the attacking machine. Neither ends of the connection know that anything is wrong, and the attacker can see all unencrypted traffic that flows between them. This attack can be used to do a whole slue of attacks. The attacker and spy on the victim (which is what we’re going to do here), they can send fake information to the victim as the server, and they can catch any passwords that the victim uses to log into the server.
Side Note: Since ARP is a layer 2 protocol, it can only be used in LANs. Therefore, ARP based MitM attacks can only be performed on a LAN
Now that we know the end result of a MitM, let’s discuss the technology behind it. When hosts use ARP, they are trying to resolve IP addresses to MAC addresses. When a host has the MAC address of another host, it will use that address to send data across a LAN. These associations of IP to MAC addresses are stored in the MAC address table of the host. If we can manage to replace the MAC address associated with a certain IP address with our own, that host will send all data meant for that IP to us instead. Now image if we do this for two hosts and replace the MAC address associated with the other host with ours. All data that goes between those two hosts would then be sent to us instead.
Now that we know the ins and outs of MitM attacks, let’s move on to launching the attack!
Step 1: Find Your Victim and the Gateway
If we’re going to be launching an attack, we’ll need to find a victim. You could find victim on your LAN via a ping scan or an ARP scan (just to name a few). We also need to default gateway. Since we’re on a LAN, we’re going to spy on our victims activity on the Internet. This means that we’ll need to launch our MitM between them and the default gateway of the network, that way all data from the victim intended for the Internet must go through us first. I’ve already selected my victim (10.0.0.15), and we can find our default gateway by using the route command:
We can see by the highlighted output of the route command that our default gateway is 10.0.0.1. Now that we have our victims IP addresses, we’re almost ready to launch our attack.Step 2: Enable IP Forwarding
Now one of the main issues with ARP based MitM attacks is that since all the data is being sent to the attacker, it won’t get to it’s destination. This will effectively kill the victim’s Internet access and will generate quite a bit of suspicion! We need to make it so that the data can pass through the attacking system instead of bouncing off of it. Doing this will allow our attack to seamlessly come together with minimal suspicion from the victims.
In order to enable IP forwarding, we need to write a “1” to a file under the /proc directory. Let’s take a look at the command that will enable IP forwarding for us:
If you think about it, this actually makes sense. In binary, a one stands for on. If we put a one in the ip_forward file, we effectively turn IP forwarding on. Now that we’ve enabled IP forwarding, we can establish our MitM.Step 3: Launch the MitM
We’re going to be using a tool by the name of arpspoof in order to launch our attack. First things first, let’s take a look at the help page for this tool:
Alright, it looks like we need to use -t and -r in order to specify our victims. We also need to use -i to specify the network interface we want to send our attack out of (in our case, wlan0). Now that we know what flags we need to give, let’s take a look at the command to launch our attack, and some of the output that it will give:
Here we can see that we’re sending ARP replies that say our MAC address is tied to both the victim’s IP addresses. We’ve successfully launched a Man in the Middle attack! Now that we have this attack going, let’s use it spy on their web surfing.Step 4: Sniff the Victim’s Activity
We’re going to be using a tool named urlsnarf in order to sniff the victims web activity. Let’s take a look at the command we’ll need to use to start this sniffing:
Now, when we execute this command, we’re going to get LOTS of output, so I’m just going to filter through it and highlight what we’re looking for. Let’s take a look at our sniffing results:
We can see in the highlighted output above that our victim at 10.0.0.15 is browsing on none other than howtohackin.com/blog! Let’s give a brief wrap-up and end this lesson.
Today, we not only learned the anatomy of a MitM attack, we learned how to perform one and how to utilize it to spy on a victim’s web activity. This attack is very common on LANs and, given the proper circumstances, can be very effective in successfully hacking a target. I’ll see you all in the next article!
No comments:
Post a Comment