Scanning

Introduction to Packet Manipulation with Scapy

Welcome back everyone! In the last recon article, I stated that we’re going to be building our own ARP scanner for network enumeration and host discovery. We’re going to be building this ARP scanner in Python, with the use of the Scapy module. Scapy is a packet manipulation tool. For those of you that don’t know, a packet is a small unit of data that travels across a network (There are different names for different units, but we’ll use “packet” a general term).

Being able to build custom packets give us immense power. We can make whatever packets we want. Imagine the possibilities; we could launch a DoS attack, we could launch a port scan, or in our case we can build an ARP scanner!

This article is just going to be an introduction to Scapy so that we’ll know how to use it later. We’re going to build some custom packets and ping a host on our network. We’re going to do a normal ping first, then we’re going to spoof our address during a ping to prove that we can manipulate every aspect of a packet. So, let’s get started!

Step 1: Start the Python Interpreter and Import Scapy

Scapy is a module for Python, this means that in order to use the features of scapy to the best of our ability, we should import the module into Python. For our testing today we’re only going to be using an interpereter that is running live inside of a shell in our Linux distro. In order to fire up our interactive Python shell, we just need to enter “python” into the BASH shell. Let’s go ahead and open up our interpreter:

Now that we’re in our live interpreter, we need to import scapy. I suggest you read the Ruby crash course, as the information learned there will make this easier to comprehend. If you did read the Ruby articles, you’ll remember the concept of libraries and modules. Groups of code that are specialized for certain tasks. In Ruby, we ‘require’ these modules, but in Python, we ‘import’ them. Let’s import our scapy module now:

It’s worth noting that this error will be printed every time we import scapy unless we manually suppress it. Now that we have our interpreter up and running and we’ve imported scapy, we can go ahead and make our packets.

Understanding the OSI and TCP/IP Models

In order to understand how these packets work, we need to understand the OSI and TCP/IP models. These models represent how packets are encapsulated. When packets are send across the network, they are packed with information. This information is packed into layers, and only one layer is packed at a time. Let’s see a photo of the OSI model:

The OSI model is made of seven layers. Let’s imagine an HTTP packet coming from a website. At the application layer we’d have HTTP as it is an application layer protocol. The presentation and session layers are both associated with protocols resting above and below them. The transport layer is responsible for transporting our data (who would’ve guessed?), at this layer we have our trusting TCP and it’s not-so-caring counterpart UDP. Then we have the network layer. If you’ve ever heard someone refer to and IP address as a layer 3 address, this is because IP rests at layer 3 of the OSI model. Next up is the data link layer. This is where LAN restricted protocols like ARP reside. Finally we have the physical layer. This is the final layer before the packet is actually put on the network.

Packets are encapsulated (packed) going down the OSI model. The actual data being carried by a packet is stored under the application layer. If packets are built moving down, that means they are dissected at their destination by moving up the OSI model. We’ll learn more about this model later, but this will provide a basic understanding for now.

Side note: The TCP/IP model is a condensed version of the OSI model:

Step 2: Craft and Send the Packets

Now that we know how the OSI model works, we can build our packets. When we build our packets, we need to build then backwards. Let’s build our normal ping packet first. For those of you who don’t know, the protocol behind ping is ICMP (Internet Control Message Protocol). Ping rests at layer 3 of the OSI model, so we won’t need to put anything more than the IP and ICMP layers. These layers are more commonly known as headers, so I’ll be referring to them as such for the remainder of this article.

Let’s go ahead and assemble our normal ping packet:

We can see that we first packed our IP header with the destination address of 10.0.0.1, then we packed our ICMP header that signifies this packet as a ping packet. There is quite a bit that we didn’t configure here, that’s because scapy will auto-fill anything that we leave blank. This makes it easy to get just what we want without the hassle of configuring an entire packet.

Now that we have our normal ping, let’s send it and get our ping-back. We’re going to be using the sr1() function from scapy, this stands for send/receive 1. This function will send the specified packet and will receive one response packet. Let’s go ahead and send our packet:

There we go! Now, when we send a packet, scapy will listen to all incoming traffic until it times out or receives a response. Here we received a response packet and we’ve stored it under the name “res_pkt_1”. Let’s read this stored packet:

We can see that packet comes from 10.0.0.1, and that it is an echo-reply ping packet. This means that the host responded, we successfully made and sent a ping! Now that we get the gist of making and sending packets, let’s send another ping packet, but this one will be a bit more complicated.

Let’s see the construction of our packet:

Here we’ve defined our weird ping packet with the same destination, but this time we’re going to spoof the IP address as 1.3.3.7. We’ve got the same ICMP header, but now we have a whole new header. This is a raw data header. Whatever we set ‘load’ equal to will be packed in as raw data. We’re going to sniff this packet in wireshark so now is a good time to open that up. Let’s go ahead and send our packet:

You may notice that we used the send() function instead of a send/receive function. This is because the source address is 1.3.3.7. This address doesn’t exist on the network, so we won’t receive an echo reply. Let’s take a look in wireshark and see what happened:

At the top we can see that the source of this packet is the address we inserted into it, 1.3.3.7. We can see that it is in fact a ping packet, and if we look at the bottom, we can see a jumbled mess of letters and dots. At the end of this mess, we can clearly see the words “This ping isn’t real!”. This is the raw data that we inserted into our packet by force. We did it!

That concludes this article. We’re definitely going to be using scapy more, also, we’re going to learn the basics of Python to use in conjunction with scapy. We’ll eventually get around to networking and learning about the OSI/TCPIP models, but let’s take it one thing at a time. In the next article, we’re going to be starting to learn Python, I’ll see you there!

How to Build a Basic Port Scanner in Ruby

Welcome back everyone! In the past two articles, we taught the basics of Ruby in a sort of crash course. The reason behind this crash course was to prepare you for building our own port scanner. That’s what we’ll be doing here today. We have a few things we need to discuss first, so let’s knock those out. We need to discuss what sockets are and how to use them in Ruby, let’s discuss this now.

What are sockets?

Simply put, sockets allow us to make and manage connections over a network interface. This is what allows us to evaluate whether a port of open or closed. If we can successfully connect a socket to the target port, the port is open. Keep in mind that repeated and sequential connection such as this can and will be logged by both the victim and any IDS/IPS devices that may be listening.

Now that we know a little more about sockets, we can actually start making the port scanner. We’re going to be breaking the code down into sections and analyzing each section individually, so let’s get started!

Step 1: Setting Interpreter Path and Requiring Modules

When we make a Ruby script, it can be a real pain to have to type “ruby [SCRIPT NAME]” in order to execute it every time. So instead we can set the interpreter path. This will allow us to treat the file as a regular executable. We can mark the file as a ruby script from within the file by setting the interpreter path. This must be on the first line of the file, and is preceded by the shebang (#!). We also need to import the necessary modules for our port scanner. Modules are chunks of code that are logically grouped into files so we can pick and choose what we need. Now that we’ve discussed what this section of the script will do, let’s take a look at the code, it will seem fairly simple compared to what we just discussed:

The last bit of this snippet involves us calling multiple elements out of the “ARGV” array. This is an automatically generated array that contains command line arguments in the order they’re given. This means that when we run this script, we need to give the target, the starting port, and the ending port as command line arguments.

Now that we have the first snippet out of the way, we can work with some things we’ve already covered.

Step 2: Generate an Array of Ports to Scan

Now that we have a start and end port provided by the user, we need to generate an array of numbers to serve as port numbers. We already covered how to convert between different port numbers, and we briefly covered how to generate a range of numbers. We’re going to be chaining conversions together here, but don’t worry, it’ll all come out nice and clean. Let’s take a look at this snippet before we dissect any further:

Alright, we can see here that we’ve placed the whole array generation inside a begin/rescue statement. We start our conversion with an if statement, which tests to see if the start port number is less than or equal to the stop port number. This is to avoid generating an invalid range of ports. We’ve stored our range of ports in a new variable called $to_scan. The dollar sign in front of the variable name means this variable can be accessed from anywhere in the script. Now that we’ve got our range of ports, we can build the method to scan a given port.

Step 3: Build the Port Scanning Method

When we finally scan the ports of the victim, we’re going to need to perform the same action again and again, for every port in our array. In order to use this same piece of code over and over again, we’re going to make a method and call that method for every port. Our method will take one argument, a port number, and it will then proceed to connect to that port and return true or false based on the result. Let’s take a look at our method and then we’ll give a deeper look:

We start by creating a socket. We do this by calling .new on the Socket module we required earlier. Then we follow it with some attributes we want our socket to have. Next, we make a new variable named sockaddr, in this variable we store the result of calling pack_sockaddr_in out of the Socket module. In order to connect our socket to a remote host, we need to properly pack the addressing information into it. This is the proper way of doing so, we’ve placed this within a begin/rescue just in case the socket fails to resolve the target.

If you remember back to the very beginning, we imported a second module, timeout. We can make a timeout do loop to attempt a certain action for a certain amount of time. Once the timer runs out it will move on to the next section of code. This timeout is to prevent the script from hanging if a port is unresponsive. It will then assign the resulting value to the result variable. If the connection was successful, it will return 0. We can make a simple if statement to test for 0 result, and return true if it is. We will return false otherwise. Now that we’ve made a method to scan a given port, we can loop through our array and use it.

Step 4: Iterate Over the Array and Call the Method

Now that we have our method, we can use it on our array. We’re going to use a .each loop and give our temporary variable the name “port”. This loop is rather simple, so let’s take a look before we dissect any deeper:

First, we put that we’re beginning the scan, followed by some blank lines for neatness. Then we make a .each loop with our to_scan array. We then make an if statement using our method. Remember how our method returned true or false? Well this is where that comes in handy. Instead of manually evaluating it, we can just place it in an if statement and let it take care of everything. If the result from our method is true, we print that the scanned port is open, anything else we just ignore. Once our scan is complete, we put that the scan is complete. Now that we have our port scanner (available here), we can test it out!

Step 5: Test it Out

Since we have a new tool, we need to test it out. First we’re going to perform a basic nmap scan against our target and see what results to expect:

Alright, if we scan ports 1 through 100, we can expect that ports 80 and 53 will be open. Let’s go ahead and fire up our port scanner! First, we need to make the file executable using the chmod command. Once we’ve made it executable, we can fire it up and use it. Let’s do both now:

There we go! We were able to successfully build our own, functional port scanner! I hope now that we’ve built our own, we have a bit better understanding about how they work. In the next article, we’ll be covering the concept of discovery, and a few different tactics used by attackers. I’ll see you there!

Ruby Crash Course: Part 2, Finishing the Basics

Welcome back everyone! In the last article, we went over the first half of the Ruby basics to build our own port scanner. For those of you who didn’t read the last article, I highly suggest you do so. In this second (and most likely final) Ruby basics article, we’ll be covering some intermediate topics. Let’s go ahead and list what we’ll be covering here:

Loops
Methods
Begin/Rescue

The first two items on this list are relatively simple, but the third can get rather complicated. But don’t worry, we’ll do our best to make sense of it. So, let’s get to it!

Loops

Loops are just what they sound like, loops. Loops allow us to repeat a set of code over and over until the loop is finished or a certain result is achieved. For example; we may need to loop through an array and connect a port for each element in the array (That’s a port scanner).

There are quite a few ways to perform loops in Ruby, but the way that I use most often is the .each method. What this means is that we need to use an iterable object and we need call .each after it. Once we perform these calls, we follow it with the keyword do followed by our variable(s).

Before we explain any further, let’s take a look at a script that puts each element of an array individually. After we run it, we should be able to wrap our heads around it. Let’s take a look at the code:

loops.rb Alright, let’s give a quick rundown of this code and then we’ll execute it. We’ve made an array containing many strings, and we’ve made a .each loop. We can see the word “word” encased in pipes (This is a pipe: |). Think of this as a temporary variable name. Each element in the list will be housed under this temporary variable when it’s their turn to be put through the loops code. Now that we know the in’s and out’s of this loop, let’s execute this script:

running loops rb There we go, we were able to print out each element of our array individually. Now that we know how loops work, let’s move on to methods.

Methods

Repetition is very important in programming, no matter what language you use. Imagine if we needed to execute the same block of code multiple times in different place, it would be a huge pain to write the chunk of code multiple times, plus it would make the file size of the script rather large. If we want to execute a set of code multiple times in different places, we can use a method. Think of a method as a chunk of code that we’ve placed under a variable, we only need to call the variable name (and give the arguments) to call the chunk of code. We’ll be make two methods, both will perform the same actions, but one will take arguments. Our methods are simply going to say hello to us. Let’s write these methods now:

fix 1

Alright. Here we’ve made two methods, both functioning nearly the same, with the exception of the implementation of arguments in the second method. Then we’ve called our methods. Let’s see these methods in action and execute our script:

running methods.rb Alright, there we go! We were able to make and properly execute our methods! These will allow us to re-run a section of code whenever and wherever we need. Now that we’ve learned about methods, let’s move on to a very important concept, begin/rescue.

Begin/Rescue

In the span of these two article, I’m sure we’ve run into a few errors. When we make a script, we need to account for any possible errors that can occur. We need to account for these errors so that the error messages don’t end up spilling all over the screen. This jumbled output looks extremely unprofessional and can often times devastate the functionality of a script.

We can use begin/rescue to account for these errors. It’s fairly simple when you think about the words, begin this action, and rescue it from this error. There are many, many errors that can be generated by faulty code, and these errors are organized into a hierarchy. It would be very beneficial to become familiar with this hierarchy, this way you can distinguish between different errors and provide very specific feedback as to what went wrong.

We’re going to start this section by making a script that doesn’t work. We’re going to intentionally make a script that will return an error, and then we’re going to use begin and rescue to fix it. Let’s start by making our faulty script:

fix 2 This example script will simply ask the user for a number and tell them what their number plus one is. But as you may have guessed, the user can enter whatever they want, including things that aren’t numbers. Let’s go ahead and generate an error by entering a word instead of a number:

fail Here we can see that we’ve generated an error. By taking a deeper look at the error message we can see that it was a TypeError. Now that we know what kind of error is generated by this bug, we can account for it using begin and rescue. Let’s edit our code to account for this new error:

fix 4

We can see here that the syntax for utilizing begin and rescue is rather simple. We’ve merely placed the possibly volatile code under the begin, and we’ve place the rescue code beneath the rescue. Now that we’ve modified our code, let’s run it again and see what happens:

it works There we go! We were able to successfully diagnose and account for a possible error! When making real life tools, error detection is extremely important. We stand no chance of notifying the users of an error if we don’t even know what happened!

We covered some key topics today. After this article, we should all be on the same page for building our very own port scanner! We’re going to actually be building the port scanner in the next article, I’ll see you there!

Introduction to Reconnaissance: Part 2, A Deeper Look at Port Scanning

Welcome back everyone! In the last article we took a brief look at recon as a whole, but we didn’t really focus on any particular aspect of it. Today, we’re going to dive into the rabbit hole that is port scanning. We’re going to cover two different types of port scans, but this time we’re going to explain the process behind them. Before we do that, we’ll need to talk about the TCP three-way handshake, and it’s role in our scanning. So, without further adieu, let’s get started!

The TCP three-way Handshake

When making a connection to a port, there are multiple protocols that are used to handle and manage that connection. A protocol is simply a set of rules that both hosts use. This ensures that all hosts know how to properly send and receive data to and from each other. One of the two protocols responsible for transporting data is TCP. In order to initiate a connection, a three-way handshake is performed.

First, the host attempting the connection sends a packet with the SYN flag. SYN stands for synchronize, and means that one host is requesting to synchronize with another. After the SYN packet is sent, the second host must check that the proper authorizations are in place for this connection to be made. If all the requirements are met, then the second host sends a packet with the SYN and ACK flags. The SYN flag again stands for synchronize, while the ACK flag stands for acknowledge. This packet means that the second host acknowledges the original SYN flag, and sends it’s own SYN flag to confirm the connection. Finally, the first host sends a single ACK flag back to the second host, completing the handshake and establishing the connection.

Now that we know about the TCP three-way handshake, let’s move on to talking about our standard port scan. We’re going to be discussing the same form of basic scan we did in the previous article, so we can have a better understanding of it before moving on to a more complex scan.

Explaining the Basic Port Scan

In the last article, we used nmap to perform a very basic port scan. We didn’t really explain this port scan very deep, so we’re going to cover it today.. Remember that three-way handshake we just talked about? Well in order to understand port scanning, we need to know it very well. We’re not going to perform another basic port scan today, as we’ve already demonstrated it.

When we perform a basic port scan, or any port scan for that matter, we have to run through the TCP three-way handshake for every port we want to scan. The type of scan all depends on how we perform the handshake. A basic port scan runs through the entire handshake for every port. While this method does it’s job perfectly well, it makes quite a bit of noise. This means that every connection attempt will be logged by the victim, and this log can be tracked back to us. The basic port scan isn’t anything special, it’s more of an introduction to the next type of scan we’re going to discuss, the stealth scan.

Explaining the Stealth Scan

So far, we’ve explained the TCP three-way handshake, and it’s role in a basic port scan. There are many flags that can be used in a handshake, but we’ve only discussed SYN and ACK. In order to understand the stealth scan (otherwise known as the half-open scan) we need to know about a third flag, RST. RST stands for reset. This flag will terminate any handshake immediately. This can give us hackers an edge for evading those pesky logs!

During a SYN scan, the attacker performs the basic TCP three-way handshake as normal. The attacker starts with a SYN packet, and waits for the victims response. If the victim responds with a SYN-ACK, the port is open, and if they respond with an RST-ACK, the port is closed. After receiving the victims response, the attacker sends an RST packet instead of the regular ACK. By terminating the connection before it is complete, it is far less likely that it will be logged as an attempt to connect. This can help us fly under the radar during active recon.

Now that we understand the concept of stealth scanning, let’s perform one using nmap. Nmap supports many, many scan types, including stealth scans. If we want to utilize a stealth scan, we have to give the -sS flag before our target IP address. Let’s go ahead and perform our scan now, we’ll only be scanning ports 1-100:

There we go, our scan worked! But in order to better understand this concept, let’s open up wireshark and see our packets as they are transported:

We can see here that there are many packets going to and coming from our attackers IP (10.0.0.19). In this screen shot we can see that our attacker has sent SYN packets to many different ports on our victim. Now that we’ve seen the SYN packets being sent, let’s take a look at some of the victim’s response packets, as well as some of the attackers RST packets:

We can see here that the victim was responding with RST-ACK packets and some SYN-ACK packets. Upon closer inspection, we can see that this SYN-ACK packet comes form port 80 of our victim. This port was also reported as open during our scan! Immediately after the SYN-ACK from port 80, we see that the attacker sent an RST packet to terminate the connection before it was fully established, this let’s us slip by without being logged for attempting a connection. There we have it, we successfully performed and dissected a stealth port scan!

We covered quite a bit here, so I hope the concepts got across well. I know it may seem like this is moving a bit slow, but we really need to understand what is happening and learn the mechanics behind it. We’re here to become hackers, not script kiddies. The next two articles will be a Ruby crash course. It will prepare us with all the knowledge we need in order to build our own port scanner. I’ll see you there!