Chapter 4: Scanning Networks
As an ethical hacker, or possibly the attacker ourselves, we've gone through and completed some of the first steps of attacking networks and systems. The first step we did was our reconnaissance in the previous chapter. If you're not familiar with that phrase, or what those steps involve, you need to go back to that chapter. Reconnaissance gave us a perfect view of the network. Now, it's time to get specific. In this chapter, we're going to get a little more active and involved.
In the initial stages of looking at our target, we did our footprinting and reconnaissance. Now, it's time to scan. This chapter will ensure you understand what you're doing and what scanning is.
You may be thinking, Wait, I thought we achieved everything we needed to achieve during the reconnaissance stage! Well, we didn't get as much information as we needed. And that's the whole goal here. Again, if the attacker can find out as much information as they can before they go after the system, it makes their time getting into the system a breeze, and there's a good chance they won't get caught.
In this chapter, we'll discuss the different techniques for scanning. We'll also look at some common scanning tools. However, we don't necessarily focus on the tools since there's going to be even more tools out there in no time. The goal here is to understand the concepts of what these tools can do. So, let's jump in.
We will cover the following topics in this chapter:
- Grasping scanning
- Understanding the three-way handshake
- Checking for live systems and their ports
- Scanning by thinking outside the box
- Banner grabbing and OS fingerprinting
- Vulnerability scanning and drawing out the network
- Preparing proxies and other anonymizing techniques
Grasping scanning
In this section, we will discuss the various types of scanning techniques and the goals, techniques, and tools that are used for scanning.
Types of scanning
So, what are the different types of scans an attacker can use? To start, let's categorize these into three different sections. We'll discuss network scans, port scans, and vulnerability scans.
Network scans
During a network scan, the attacker simply puts a packet out onto the network to look at every device on the network and goes through them, trying to identify them. During this process, it provides us with information to help us to see which hosts are currently live. This can be done with something as simple as a ping. Unfortunately, using a ping won't give us much besides revealing if the system is up or not. We'll also be able to see what type of operating system is running on those devices. This is not just about revealing what's on the operating system for a desktop or a server, but what operating systems are currently running on the router, on a switch, or a printer.
We'll also want to go through and be sure we pick up all the IP addresses. We know we have a range from the reconnaissance side, but we want to make sure we go through and look at individual IP addresses and see if we can group them in a specific order.
Now, what I mean by this is that, as an attacker, I might be able to go through and see you're using an IP address of 192.168, the first 10 IP addresses for servers, and maybe 250 through 255 for printers, or network services. This information will help me when I see a node. I can go through and say, Oh wow, that particular server happens to have this IP address. I wonder if the server sitting next to it has the next IP. So, this helps me go through and figure out more. If you want to think of it as adding more to your reconnaissance steps, then do.
Port scans
Now, as we hit those machines, what we want to do is discover what a port is. Typically, a port is an IP address with an attached protocol. Let's take an IP address of, for example, 192. 168. 0. 15. We know that this is the IP address or target address, but when we add to it a protocol, such as HTTP, it becomes a port. If you want to look at it differently, here's what it would look like from a port perspective: you have the IP address followed by 80. Port 80 is a very typical port that's associated with an IP address that displays web pages. Sometimes, you might see 443. That's a secure port on that device.
There are more than 65,535 ports out there that we can run on each machine. As we do the port scan, we want to see which ones are open and which ones are closed. We normally focus on the first 1,023 ports. We must go through and see which ones are responding and correlate that with what services use those ports, which will give us an exact footprint (an exact representation of that machine). No, you don't need to go through and memorize all 1,023 ports. Just know that there are some very common ones. We already mentioned port 80 and port 443. We also have port 25 for email, port 53 for DNS, ports 20 and 21 for FTP, and so on. We want to scan and see which of those ports are open. In some cases, ports are specific to certain services.
Vulnerability scans
As IT professionals, we do this to identify what possible threats there are to operating systems and/or applications that have been installed in the environment. You'll also want to make sure you can identify the vulnerabilities of the OSes and their applications. In some cases, we can install a Service Pack or do an update of some sort, and this will create new vulnerabilities. This should be something every IT person does almost monthly, or at least any time there's any type of update. Why? Because an attacker will do this same type of vulnerability scan – we'll look at some vulnerability scanning software later.
As we mentioned earlier, most of the software we see and think, Oh, it's designed for good! is anything but. Think of what an attacker can do with a particular piece of software. If an attacker can make it into your network, they'll want to do a vulnerability scan to see which systems can be compromised.
What's the goal?
Scanning can have a couple of different objectives. We've talked about some of these already, but I want to make sure you grasp this, especially for your immediate future – that is, if you plan on taking the Ethical Hacking exam!
The first objective is to identify live hosts. More importantly, I want to know when a host comes online. Again, if you're going to introduce a new idea system, I want to be aware, so I know I've got to be a little trickier and sneakier with you. I also want to go through and make sure I gather all the IP addresses. If an IP address changes, I want to be notified. Networks are consistently evolving and we're always changing up our IP addresses. Now, we may not be changing them from the server's perspective, but trust me – desktops are always changing IP addresses. If I've compromised a particular box and its IP addresses change, I want to be able to track that somehow. Scanning is going to help me with that.
Again, once I've got the IP address, the next thing I want to do is ensure I know which ports are still open and which ones are closed. This can expose information such as the operating system or even the architecture. Again, I'm going to make a notation of the results I get from my scans.
As I've mentioned previously, certain Windows boxes respond in a specific way to an open or closed port that's different than a Linux box or a UNIX box. So, looking at how it responds to us can help us identify our architecture as well. Most of those functions are built into the scanning software you'll see demonstrated later. I'll also go through and check for vulnerabilities and threats. Again, if I can identify the target, its OS, and the services that are running on it – Hey, it's an Apache server! What version of Apache? Version 2. 6 – I want to go off and find out what vulnerabilities existed for that version of Apache.
I'm typically talking about web servers because they get attacked quite a bit, but there are vulnerabilities for specific machines – one that's running Adobe Acrobat Reader, another for iTunes, and so on. I'm going to try to compromise a box, if not multiple boxes, within your environment. It doesn't have to be a server – again, my main target may not be the server, it could just be your desktop systems. I'm also going to go through and look at the security risks and services running on those machines.
From the attacker's perspective, the security risk is going to involve thinking, What is my risk of exposure when I attack this machine? It's easy to think it's just the Windows boxes that always get attacked because they're easy to attack, but guess what? I can attack a Mac or even a Linux box – nothing is foolproof. Of course, some may be more difficult than others to go after, and some will end up exposing me.
Scanning can be extremely noisy or chatty on the network, depending on the type of scanning you're doing. So, I'm going to make sure my security risks are low. I'm going to do some scans that could be very stealthy.
I'll also go through and look at the services that are running – all kinds of services. Is SNMP running? Is NNTP for time running on that box? Are the file and print services running on a particular box? Again, what applications (server-based applications)? Is it an exchange box? Is it a SharePoint box? Is it a SQL box? What services are running that could give me some type of access to this system as a whole?
What techniques are used?
There are different techniques for scanning different technologies. Some of the different techniques we use will include techniques for either internal or external networks. Typically, these are almost the same type of technique. Because of those pieces of software or scans that we do, they don't care if they're internal or external; it's just a different way of looking at it – if I'm attacking a public IP address range versus an internal IP address range.
We'll also have a different technique for not just looking at computers – I want to be looking for printers, switches, routers, and any other devices on your network. I mean, nothing is more fun than compromising one of the network devices you have no idea someone is monitoring – your printer's OS, the OS on the switch, or the OS on the router. If I can compromise and issue my commands to my zombies on your network via one of these devices, it will be extremely hard to track because nobody ever suspects them.
Another technique is Wi-Fi, which is such an open book force. As we take more and more advantage of wireless technology, I can just jump into the network. If I am visiting a location and I can hit the Wi-Fi, I'm good to go. Well, guess what? There are some specific techniques I can use on a Wi-Fi network that are different than what I would use on an internal or external network to do my scans.
If I'm able to hit a server, one of the first things I'm going to do is banner grabbing. This is a very interesting technique known as operating system fingerprinting, or OS fingerprinting. Banner grabbing will help me take advantage of the way servers respond to identify themselves – a Windows box, a Linux box, and so on.
What you saw in our previous course on reconnaissance was that when we used Netcraft, this entailed using banner grabbing techniques to identify those public-facing servers. We can do that internally to identify the different targets on the network.
Tools used for scanning
So, what tools are used for scanning? Well, where do you want to start? I could use a standard command line to do a ping to see if there is an active or a live host or node on the network. I can also go through and use Nmap, which is probably one of the more popular scanning tools out there. It's more than just a scanning tool. We can also use an angry IP scanner, a nifty little tool that I used when I had my wireless ISP service. We assigned IP addresses to each of the antennas we'd put on our customers' homes.
Initially, we went through and had them all organized, saying, Here is this antenna and it has an IP address of 1, and here's the next one, which has an IP address of 2. This works perfectly until you have an antenna go out. In that situation, you'd have to go through and change the IP address. We would quickly jump onto the wireless network, do a quick angry IP scan, and see which IP address we could utilize next because a host or IP address wasn't live, meaning it was usable. Interestingly, most antivirus products pick up angry IP scanners as malicious software, yet they're just ping sweepers.
Luckily, SolarWinds have a plethora of utilities, especially the engineering set, which you can utilize. Some of the things it scans include Ethernet and Bluetooth. They've got all kinds of tools –and not just scanning tools – their solution is amazing. We also have Colasoft ping, Ping Scanner Pro, and Visual Ping Tester, which, after it pings, helps map out the network. There are a ton out there. You may have a favorite, but there are a couple of them you may want to pay attention to. I will not tell you which ones they are, because I shouldn't as an ethical hacker, but some are going to be focused on your immediate future if you plan on taking the Ethical Hacking exam.
Understanding the three-way handshake
Let's talk about how polite computers are when it comes to communicating with each other, shall we? So, part of the scanning concept is understanding what they refer to as the three-way handshake. Again, it's very polite.
Mike O'Cain, who is an American football coach and former player, once said I don't remember who came up with the handshake idea, but it was a great one.
This is true because there are some advantages when it comes to the three-way handshake and computers.
To understand the three-way handshake, you must get your geek on. You need to understand what's going on in the background. To cover this in a way that makes sense, we'll look at TCP and UDP communications. We'll also look at the different flags that a TCP header has. After that, we'll look at the extremely normal three-way handshake and ensure you understand the communication that goes on between computers as they're about to talk to each other. I'll whip out some Wireshark for you, and we'll discuss how it takes place.
We'll start by looking at some what-ifs… what if something else happens differently than what the computer is expecting? Get your pocket protector ready, whip out your pin, and let's get learning.
TCP and UDP communications
When computers want to talk to each other, they need to set up ways of communicating. There are two different ways computers can do this to make the initial connection: TCP and UDP.
TCP communications
TCP has a huge advantage over UDP because when one computer talks to another via TCP, it tries to negotiate a connection between the two computers. Again, this is very polite – Hello, I would like to communicate with you, is that all right? – as they communicate with each other and send data back and forth. Another advantage of TCP is that it has what's referred to as delivery acknowledgments. Thank you, sir! I did receive that packet, you may continue. It's very similar to when UPS delivers a package to you – you sign for it. Again, you're acknowledging you received that packet or package. It also has a little fault tolerance built into it because of error detection, which means it can retransmit packets it sees did not get delivered. Oh, I see you didn't get that! Well, let me send it to you again. Once you get it, please send me back a delivery acknowledgment.
As the packets get delivered to the destination, it does what's referred to as in-order delivery. If we need to send over five boxes via UPS, we can mark them as boxes 1 of 5, 2 of 5, 3 of 5, 4 of 5, and 5 of 5 for easy identification. The same helps a computer reassemble data as it's received. TCP also goes through and does congestion control. If it sees that too many packets are coming to it, it'll try to slow things down.
If there is a downside to TCP, it's that TCP is slower than UDP because of all this retransmission, in-order delivery, congestion control, and delivery acknowledgments going back and forth all the time.
The other reason it's a little slower is because of the header size. It's about 20 bytes. In UDP, it's around 8 bytes; a little smaller. Besides having bigger headers, it also has a bigger overhead. Some of the fields that are required by TCP when it's communicated are sequence number fields in the packet. There's also an acknowledgment number, data offset, a reserved field, a checksum field, a source port, a destination port, and about 12 different fields compared to UDP, which only has four.
TCP is also stream-oriented, which means data is read as a byte stream, whereas in UDP, the packets are just sent individually and are only checked for integrity if they arrive. Part of that is handled by data flow control. So, TCP does flow control, which, again – remember our three-way handshake – requires three packets to set up a socket connection before the user data can be sent, so TCP handles reliable transmissions.
Again, as we mentioned previously, it has all these features. Some of the applications we see use TCP include Simple Message Transfer Protocol, File Transfer Protocol, Telnet, Hypertext Transfer Protocol, and even HTTPS.
UDP communications
The evil twin of TCP is called UDP. Now, it's not that we hate it, UDP just has some differences. For example, UDP is connectionless-based, which means that when two computers want to send data and they're going to do it via UDP, I'm just going to send you the data, I don't care if you get it or not, is how they communicate.
A great example of seeing this is if you like streaming music. Sometimes, while streaming music, suddenly, the music will stop and then kick up again. That's because it's UDP and unlike TCP, there's no guaranteed delivery. Another analogy you could use is TCP is FedEx, where they guarantee overnight delivery, and UDP is the ordinary US mail system, not priority mail – you just put the letter in there and hope for the best.
It also uses smaller packets. At just 8 bytes, it's extremely small.
Again, part of this is because the header itself only has a source port, a destination port, and a checksum value associated with it. When data is transmitted, only one packet goes across at a time, and with UDP, there is no guarantee that the packet is going to hit the destination. It's extremely fast, though, and because of that, there is no error checking involved. With TCP, we were very polite; Did you get it? Was it correct?
With UDP, packets are also delivered out of sequence. When the packets are sent, they're sent individually. They're only checked for integrity if they arrive because we don't have that in-order delivery mechanism that TCP has. Again, the packets arrive out of order. Packet 5 may arrive before packet 4. So, there's no form of ordering messages or tracking connections.
One of UDP's biggest advantages over TCP is that UDP is extremely fast. There's no congestion control either, which is a possible advantage. I only look at it as a disadvantage because if the network gets saturated, there's no way of stopping the packet from going across or the network adjusting on the fly, yet with TCP, we have flow control. Technically, UDP is message-oriented, meaning it's a protocol we use in message transport or transfers. However, because it's not connection-based, this means that one program can send a ton of packets to another and that it would be the end of the relationship.
Some of the applications that are used by UDP include DNS, DHCP, TFTP, and SNMP. VoIP utilizes it too. All types of video conferencing tools, such as Skype, use UDP. I'm sure you've been in a video conference where, suddenly, the video stream locked up and looked as if the participants were in an old 1930s movie that was choppy. This happens because some of the packets are missing or there was no guaranteed delivery, but it eventually catches up.
Now that I have described and explained how computers talk to each other and love each other, we will discuss how TCP sets up that three-way handshake.
TCP header flags
TCP uses what we refer to as flags to represent different types of communications and connections we'd like to establish. For example, one of the flags you might see is SYN, which is short for synchronization. The synchronization flag includes a sequence number. Now, sequence numbers themselves don't increase sequentially; they are linked to the source machine and the destination machine.
Technically, the numbers are randomized when they're created, and they're based on the payload. That number can be anywhere from zero to over four billion. Most sniffing products out there, such as Wireshark, will display the relative sequence and acknowledgment numbers in place of the actual numbers, which makes it a little easier for us to see.
Another type of flag we might see is ACK, short for acknowledgment, which simply means that I got your request, where you stated that you'd like to do something. We also have FIN, short for finish, meaning jobs done.
The other flags we might see are PSH, which means I need to push data to you. There's also URG – short for urgent – Excuse me, I need to send this packet to you immediately, please. Finally, there's RST, which is just saying: I need to reset the connection (Figures 4.1 and 4.2).
Now that we know about the different flags TCP uses to create, establish, and leave connections with other computers, let's look at them in a normal three-way handshake:
Figure 4.1 – Two-way handshake diagram
Let's say we've got two computers (Figure 4.1). The source computer on the left needs to set up a connection with the destination computer on the right. It does this by sending a SYN with a sequence number. My sequence number is 101. The destination computer sends back and responds to a SYN, with a SYN/ACK. I got your acknowledgment and your sequence, so your next sequence number will be 102, and here is my SYN or my sequence, which is 508. The source computer responds with an ACK saying, You're right, my sequence number was 102 and your next sequence number will be 509. See how the sequence numbers synced? This is done to help you identify that we have established a communication channel between the two systems:
Figure 4.2 – Three-way handshake after transfer
Now, when the source computer has finished transferring the information (Figure 4.2), it starts with a FIN – I'm finished. I'd like to stop now. This relationship just isn't working out. The source computer responds with Okay, I acknowledge that; I'm going to tell the application to stop SYN information, and when it's done, I'm done. In response, the source computer sends, Oh, hey, it was nice talking to you. I'll call you sometime. Maybe we could do this again!
Checking for live systems and their ports
Scanning for live systems can be very loud or noisy on the network, but if you can do it strategically, the target might never see we're going through their network looking for targets.
Now, let's look at different ways to check for live systems.
ICMP sweep/ping sweep
This is the most common way to check for live systems. Like a sonar ping in a submarine, we ping and hope we get a return, which tells us how far away the target is or where the target is located. A standard ping uses the ICMP protocol, which is not only well known but also very noisy on the network – so much so that most IT professionals will block ICMP traffic as a deterrent.
Port scanning
Just because a machine does not respond to a ping sweep or an ICMP sweep doesn't mean it's not there. So, we can perform port scans in various ways and specify IP addresses. We can still try to check if it responds. We'll show you how to do that next. So, let's get pinging!
Nmap
Now, in your immediate future (my way of saying in the exam), you will need to know the syntax for some Nmap commands. There are many, but I'll highlight the most important ones as we move along. When we get into some of the additional scans that we can accomplish with Nmap, I'll ensure that you see all the different options:
Next, let's look at the hping tool.
hping3
I know what you're thinking: That's cool, but what happens if a machine doesn't respond to an ICMP request or a ping sweep? Oh, young Padawan, follow me now.
First, you need to understand that tools such as hping3 can craft packets to work around security measures.
Packet crafting is the process of adding customized data payloads to application layer protocol packets. A customized data payload refers to any arbitrary content that cannot be identified as part of the protocol.
Installed by default on Kali Linux is a nifty tool that's called hping3. Using hping3, I can utilize TCP, UDP, ICMP, and even RAW protocols. The hping3 utility is a network packet generator and analyzer that can be run from the command line. hping3 can be used for TCP/IP and security testing, such as port scanning, firewall rule testing, and network performance testing, thanks to its ability to create bespoke network packets.
hping3 switches can cause the tool to scan in the following ways:
- -0 (Raw IP mode)
- -1 (ICMP mode)
- -2 (UDP mode)
- -8 (Scan mode)
- -9 (Listen mode)
What's firewalking?
The concept behind firewalking is that we can try to determine what layer 4 protocols an IP address, such as a router, will pass by. Even though we can't ping it, it may allow port 80 through.
Firewalking is designed to help us get around IDS systems, firewalls, and routers. It's very similar to traceroute, but instead, it tries to determine if a particular packet via a port can pass from the attacker's system to your target through the packet filtering device.
We use firewalking to help define the firewall's access control list or determine what's allowed to pass through. The firewall may not be allowing other ports to pass through, but maybe it allows port 80 to pass through – which it does by using time to live (TTL). Now, what I mean by that is that traceroute – a networking utility that allows you to see the routers a packet passes through to get to its destination – gets a list of the IP addresses of each of the routers along the way. To determine this information, traceroute uses a TTL.
A TTL is implemented with an IP to prevent packets from looping indefinitely on your network. Now, as each device receives a packet, the TTL counter decreases by one. If the counter is less than or equal to 0, then the packet is dropped, and you get an ICMP error message that says that the TTL exceeded in transit. Now, this error message will typically hold the IP address of the router that dropped the packet as the originator. So, what happens to the packet when you're firewalking? It gets forwarded if the port is open and gets dropped off if the port is closed.
Let's say that we have two systems, and as we do a simple ping, our packets get passed from one router to the next and then to their eventual destination. We may not see all the different routers or hops that it passes through on a ping command, but if I do a traceroute, I'll go through and start to see the IP addresses, but then I'll start seeing packets being dropped off.
Mobile apps that help
We often talk about tools we can use on our laptops, but because mobile devices are becoming so influential in our lives, there's a ton of apps out there that can help us as far as network discovery is concerned. If you open your app store and type in network scanning, scanner, or network scan, you will see a plethora of different utilities.
One I use quite a bit is Fing. Fing is designed to keep track of all the different devices that are currently on your network. It provides cool tools, including showing the current location. It has vulnerability tests built into it and Wi-Fi intrusion protection. You can also check your internet speed and look at your Wi-Fi's performance. Additionally, you can go through and set up different people and assign devices to them.
It's also great at finding devices. It found my TP-Link switch (Figure 4.3), it can get my MAC address, it shows me my vendor, and I can also go through and have it notify me when it changes status, which is kind of interesting:
Figure 4.3 – Finding devices using Fing
You can also go through and block a device. I have most of mine set up so that if a device hits my network by default, it gets blocked.
There are other products out there as well – both on Android devices and iOS devices.
Scanning by thinking outside the box
So, when we scan a network, we have some tricks that can be used to get a system to respond without being detected. Now, the normal three-way handshake we know about involves a SYN followed by a SYN/ACK and then an ACK. What if we change up the order of the handshake and craft packets so that we send a SYN/ACK first? Or a FIN? Using these types of methods, we can pick up targets on the network that normally wouldn't respond to an ICMP scan. Let's talk about some of these scans.
Full scans
A full scan is simply the same process that we talked about previously – the three-way handshake. It's just that here, while a computer is talking to another, an attacker is going after a target. What they'll do is send a standard SYN. Attached to that SYN, we'll have a port number.
As you may remember from the three-way handshake, it'll simply respond with a SYN/ACK. And now that we've seen the acknowledgment, we can finish that off by just doing an ACK and then a reset, which means that, okay, I didn't want to talk to you. Now, if it responds this way again, using a full three-way handshake, we know that the port is, at that point, open. Contrary to that, if we have the same environment and we send a SYN and we get a reset option, then we know that the port is closed.
The disadvantage of a full scan is it's very noisy. Most IDS systems will pick this up and it'll be logged somewhere. But you can use it as a last resort, especially if you're a hacktivist and/or you're being hit by a hacktivist. They don't care if they're getting caught, or maybe they're just taking it on the assumption that you won't be looking heavily at your logs.
Half-open scan
A half-open scan is also known as a stealth scan. Now, remember how the three-way handshake worked? What if we modified this a bit? Let's say that we have the target and the attacker, and normally we send a SYN, right? Well, if we send a SYN, its normal response is to send a SYN/ACK. Remember what the third step of the three-way handshake was? It was to do an ACK that I got your acknowledgment and your SYNC? Well, what if I set an RST instead? By sending an RST, the scan partially opens a connection but stops halfway through. Now, because it stops without having done a full connection, it stops the service of ever notifying it of an incoming connection, so, it typically doesn't get recorded anywhere. Now, if I get the SYN/ACK from my target, I know that the port is open. If I do the same thing, where I send a SYN and it responds with an RST, well, guess what – the port's closed.
Xmas scans
A Xmas tree scan uses a technique that uses our ACK, RST, SYN, URG, PSH, and FIN flags to see if a particular port is open. Unfortunately, these flags only work against systems that are compliant with what is referred to as RFC 793, which means this does not work on Windows boxes because Microsoft followed their own RFC when it came to TCP/IP, so they left some of their stuff out.
So, how does a Xmas tree scan work? Well, we have our attacker and our target, and the first thing that we're going to send is a combination of a FIN, an URG, and a PUSH.
In response, the target machine is going to come back with nothing. If it comes back with nothing, that's because I said, I'm finished, and the computer goes, finished? We didn't even start talking, dude! So, if it comes back with nothing, then we know the port is open. Now, if I go through the same environment and I do the same FIN, URG, and PUSH and I get an RST, you guessed it – it means that the port is closed.
So, as far as your immediate future is concerned, remember that Xmas (or Christmas) tree scans don't work against Windows or Microsoft products.
FIN scans
Let's go back to our attacker and target again. Do you remember the three-way handshake? What do we start with? A SYN? No, let's hit them with a FIN, meaning, I'm done talking to you! The target machine will go, Well, I don't even know how to respond to that because we haven't even started talking yet. So, no response tells me that the port is open. Again, if I want to see if the port is closed, I send my FIN, and if I just get an RST/ACK, then the port is closed.
NULL scans
A NULL scan is kind of unique because it typically works on UNIX and Linux systems. Again, it does not work on the Microsoft platform.
Instead of sending anything, when we send the packet, it's going to go through TCP, but guess what? There's going to be no flag. It's not going to be a SYN, an ACK, or a FIN – it's just going to be nothing; the flag is empty. When the target receives that packet, it responds with nothing, which means that you're sending me information I have no idea how to handle. And because it doesn't respond, we know that the port is open.
The opposite of that is true, just like we saw with the Xmas tree scan. If I send a TCP packet with no flag implemented, the kernel will drop it if it's open, or it'll send an RST/ACK back to the attacker's machine, which tells me that the port is closed.
UDP scans
Do you remember the advantages and disadvantages of UDP? There's always a catch 22, right? The three-way handshake is caused by TCP and when it comes to UDP, there's no three-way handshake, there's no overhead of TCP, and that creates some advantages for us. One of the advantages is that it's a lot harder to monitor because there is no initial handshake. UDP itself is less informal as far as regarding it in an open port. The frames can be overloaded or be larger, so we can exceed the limitations of TCP frames. Again, Microsoft-based operating systems don't have any type of ICMP rate limiting built into them, so the scan is extremely efficient against Windows-based targets. The disadvantage of UDP is that we get port data only; we're unable to take advantage of some of the other options that are available to us, especially when it comes to Nmap, such as being able to identify the operating system. To see those things, we're going to have to include some additional parameters.
So, let's take our target and attacking machine. If the attacking machine sends a UDP packet that says, Hey, is port 31 open?, and the target machine says, Hi, I'm not going to talk to you, that's a no response and means the port is open.
The same concept applies if we go through and implement our attacking and target machine to do the same thing; is port 31 open? In this case, we will get an ICMP port unreachable error message. In that case, we know that the port is closed.
I know you're thinking, Let's take a look at this! Well, the big challenge with UDP scanning is doing it quickly. Both ports that are filtered and open rarely send any type of response, and this leaves Nmap to time out quite often. Closed ports are an even bigger problem. They usually send back an ICMP port unreachable error. Sometimes, you do get some false positives pop up. The cool thing is that Nmap will detect rate limiting and slow down to make sure the network doesn't get flooded with a ton of useless packets. Unfortunately, the Linux style limit of 1 packet per second makes scanning 65,000 ports take about 18 hours.
Now that we've gone through and looked at the different scanning techniques we can use, we'll move to those we can utilize to evade the Intrusion Detection Systems (IDSes) that are looking for the types of scans we have looked at.
Idle scans
An idle scan is where you're sitting in your car on Main Street on Friday night checking out the people next to you in the car while you're idling. Just kidding… This scan is tricky and very hard to detect because of how everything works inside of the three-way handshake and how computers are designed to respond.
We'll use the TCP port scanning mechanism and the regular three-way handshake, but instead, we're going to spoof the source address to the target. We're going to make the target think, it's not me scanning you, it's somebody else – Look over here! Now, there are some advantages to this because we get to blame somebody else. It wasn't me; it was this computer over here creating the problems for us. The disadvantage of this scanning mechanism is that it does require you to have a zombie – a system that I've already penetrated, compromised, or know about. I don't even need to own or pwn it. It's just going to be an IP address I know that's out there behind your existing firewall or your IDS system. It requires this because I'm going to use that zombie as the source address.
Listing scanning
A list scan is fast, and it goes through and enumerates every IP address range that you give in a specific target or a block on each. Then, it does a quick reverse DNS lookup on each of those IPs. One of the advantages of a list scan is that a lot of times, the name of the system could give you a hint about what it's doing.
SSDP scanning
Simple Service Discovery Protocol (SSDP) is an interesting and tricky scan. It's a network protocol that generally communicates with other machines. So, when a system comes up and says, Hey, I'm looking for printers or I have an available printer, this service goes through and helps with universal plug and play. It generally works when the machine is not firewalled. However, there can be times where we'll work through a firewall. So, an attacker could use SSDP scanning to detect universal plug-and-play vulnerabilities that could allow them to launch a buffer flow or even a denial-of-service attack against the target.
Countermeasures
So, how do we release countermeasures and what are the different countermeasures that we can implement? First, firewalls need to be configured to look for SYN scans. This is because most of the firewalls today – if they aren't updated – will have each manufacturer using different mechanisms or ways of scanning for SYN attacks.
Another thing you'll want is your IDS systems to be able to detect Snort or Nmap. Snort is a product that looks at traffic and helps evaluate and determine what's going on. It's almost like a silent sniffer, hence the name Snort. Again, you'll want to check with your IDS systems to make sure they support those features.
We'll also want to go through and only open the ports that are required to be open. So, if I'm doing a scan on a system and I see that no ports are open on the machine, that tells me something's up. Why is the machine on at all? It must be giving some type. I mean, a DNS server has a port open. A domain controller has certain ports open. So, you want to limit the number of ports that are opened. That's one of the things you should be doing. But going back and talking about those different scans, I would detect if I did a scan on an IP address and I had 0 ports open. At this point, I know that between me and the target, I've got some type of device that's blocking that. So, again, we only want to open the ports that are required for the services of that server.
We also want to go through and make sure that we filter ICMP messages, making sure that we don't allow ICMP traffic to pass through unnecessarily. I know that takes away the ability to do some pinging, but we want to filter and record that.
We'll also need to go through and test our network using the techniques I've just shown you. Again, part of our job as ethical hackers is going through and making sure we can withstand what can be discovered from the attacker using these same techniques and tools.
Finally, we're going to go through and keep our firewalls and IDS systems up to date and patched. Now, I know this doesn't look like a lot as far as some people go, but that's all I can do. Again, I will go back to the analogy I use all the time: that I know I have a higher risk of getting in a car accident driving on the freeway and getting injured or killed versus flying, but I'm still a little paranoid about flying. It may be a control issue for me, but I know those risks, and I'm willing to take them just to be able to drive and live in an area where I live – outside of the big city.
One of the most interesting conversations I've had was with a friend who is a white hat for Microsoft. When I was trying to open my ISP service out in my area, he said, Do you really want to do this? After asking what he meant by that, he said getting on the internet and becoming an ISP service will make me a target. I said, Dude, but I live in this little bitty town. I mean, a population of 2,000. He said, It doesn't matter because on the internet you're strictly a number. They don't care about where you're located. But I took that risk, and we have that risk today. We all know we can go shopping on the internet. It's convenient. However, we know that there is a chance that our identities can be stolen. Still, it's a chance we're willing to take.
More IDS evasion methods
There are other ways that we can get around IDS systems. One of them is to spoof your IP, but we're going to sniff the responses out there. We can also use a proxy or a pwned machine. So, a zombie is kind of a combination of the two.
Another way that we can do this is to fragment the IP packets, which I'll show you in a second. Then, if you're able to, you can use something called source routing – a method or a technique that you can use to specify the route a packet should take through the network. So, when you have a packet that has source routing specified on it, going through the network, the device that makes the routing decision, such as your router, will look at the path specified inside the network packet to determine where to forward the packet. So, we can force packets to bypass some of our IDS systems.
Now, as far as IP fragmentation is concerned, or IP fragments, the concept is to get past these IDS systems. Typically, they're looking for normal-sized packets going through, and they monitor them. Anything else that's small is typically ignored. So, when a big packet goes through, it gets blocked based on its packet size and its protocol. Maybe your IDS system is blocking FTP or a specific port. Well, instead, let's break that packet into smaller packets, which will pass right through and be reassembled at the target machine.
Banner grabbing and OS fingerprinting
We've gone through and found our live targets and we've scanned them to see which ports were open. Our next step is to try to identify the systems. How are we going to do that? When I say identify, I'm talking about finding what operating systems and what applications are possibly running on that machine. We're going to do that with banner grabbing and OS fingerprinting.
The best way to sum up what this module is about was best phrased by the famous scholar Joey Tribbiani, who said, How you doin? That's exactly what we're doing here! We're trying to get to know the system. We're trying to identify the target. So, we'll go through and look at OS fingerprinting, which is the process of going through and identifying the operating system by the way that it responds to certain types of packets we're going to send to it.
Now, there's something else we can do called banner grabbing. This is a very direct way of identifying the system, and it's something you can't stop as an IT professional. It's just the way operating systems are designed to work; they respond in a specific way to different requests. Eventually, we'll go through and look at our countermeasures. Again, there are some things you can't stop, but I can slow the attacker down. I can't stop them; you're going to give yourself a heart attack thinking that you can stop them, but you can't.
OS fingerprinting
The reason why we do this when we're doing pen tests today is because the tester usually starts by gathering as much information about the target as possible. One of the things we want to make sure we get hold of is the operating system or trying to identify the operating system itself. We typically do this by sending specific types of packets to the target machine. Now, if we can hide this information, then we are making it more difficult for the attacker to decide what type of attacks to throw. Often, you'll discourage the attacker; not that they can't get in, but they may want to try to find something else that's a little bit easier. Therefore, the focus on the initial information you're gathering is trying to discover what OS is being used. This makes us extremely, extremely active on the network.
There are several different approaches we can use to find the operating system of an unknown host without having an account or any other way of logging directly onto the machine.
There are two types of fingerprinting. The first is known as active fingerprinting. Now, in active fingerprinting, I'm going to use some packets that I'm going to go through and design to help me identify the operating system. Depending on the application you're using – and I'll be using Nmap since it's one of my favorite tools – as well as the responses or the way the target machine responds to my packets, I'm going to compare it to a database of known responses, and that's going to help me identify the operating systems. Unfortunately, there's a downside to this: because it's so active, there's a high probability I'm going to be detected on the network.
There's also passive fingerprinting, which involves sniffing the network and looking at the packets to see what the source IP is. You or your application will record over a certain period, and you'll gather enough information that will help you ID the target.
The upside, at least from the attacker's perspective, is that it's very, very quiet in that it's very hard to detect they're doing this on your network because they're just sniffing packets. Now, granted, it would take the attacker a while to do this, which is something you don't have – time.
Countermeasures
So, what are my countermeasures? How do you stop people from fingerprinting and possibly banner grabbing your servers? Well, there are a couple of things you can do. First, you can go through and misdirect by using fake banners. For example, in IIS, we can go through and change what the banner reports back as. There's a tool Microsoft has for this. It's called the IIS lockdown tool and it will help lock down an IIS box, especially the older versions of IIS.
I'm a big fan of misdirection. If I buy a Linksys wireless router, what would be its default wireless SSID? It's Linksys, right? An attacker driving by who sees my Wi-Fi will throw Linksys attacks at it. To avoid that, I will take my Linksys router and change its SSID to Belkin or Netgear, to have them throw the wrong attacks. The same concept applies here. Go and fake the banners.
There's also a nifty little tool out there, called ServerMask, that you can run to make the server look like it's something it's not, such as an older version of IIS, or an older version of Apache.
You can also turn off services that aren't needed because these services and ports can be used to identify the operating system. If you have some Linux boxes, you also need to go through and change the ServerSignature entry inside the httpd.conf file.
If you are dealing with Apache servers, you can go in and turn the ServerSignature line to ServerSignature off in the httpd. conf file.
You can also go into the same file (the httpd. conf file) and look for a section called mod headers. There, you can go through and change the server's name. So, I could type in IIS version 6.0 and leave the attacker scratching their head, wondering why their attacks aren't working.
Vulnerability scanning and drawing out the network
Now that we've gone out, found our live machines, footprinted the OS, or done a banner grab to identify the OS, our next step is to go through and look for vulnerabilities.
Remember, our goal is discovering those targets – hopefully to find out what type of operating system and possibly what applications were running. That's exactly what vulnerability scanning and drawing out the network does for us.
Some IT guys wonder if vulnerability scans are important and my answer – my favorite line from a famous character – is, A man's got to know his limitations.
You must understand what your limitations are, what your vulnerabilities are.
Now that we agree, we'll go ahead and look at some of our greatest weaknesses. We'll do that by understanding what vulnerability scanning is. After that, we'll look at how it works, the different mechanisms we can use, and how various software programs may look at your network infrastructure.
We'll also look at some vulnerability scanning tools and do a little vulnerability scanning.
We will then talk about drawing out the network, which we partly do to remember – as attackers – the network we were just on when we revisit it.
And, of course, we'll learn about some tools associated with how we draw out the networks.
As we get to this step, which is extremely active, we'll draw the line between being a black hat and a white hat because you will actively go out and try to find out what's wrong with the systems that you've identified. So, before you do this on a network, you better make sure you have permission. Okay? Now that you've gotten your permission slip signed by your parents or guardians, let's get going.
What is vulnerability scanning?
A vulnerability scanner is used to go through and look at a variety of vulnerabilities across a network, and we'll go through and use a piece of software that does that.
There are several vendors out there that create vulnerability scanners. Most of the tools we use are designed for good but are sometimes used for evil. So, this software is going to go through and look at information such as your network systems, switches, routers, and computers – which it'll try to identify based on the operating systems that are running and what vulnerabilities they are not patched for, including applications.
When we talk about applications, we're not necessarily talking about Word or Excel. It could be a server-based application, such as SQL, Exchange, or any other type of email server. These are applications that run on a server platform. However, this can include applications at the desktop level because, again, I'm going to try to break into any target I can find. So, if you have Adobe Acrobat and it hasn't been properly patched and it's on a desktop machine, I'm going to go after that machine because I can use its resources later to maybe attack or daisy chain into other systems in your network.
A commonly asked question is, How are these vulnerabilities created? Well, they're created as several different mechanisms and in several different ways. Some of them are done because of a user-initiated task. For example, a user goes through and shares directories to folks they shouldn't be sharing them to, fails to run an antivirus solution, or fails to keep up to date with that antivirus solution. In some cases, you may have a weekend geek, as I like to call people who brag I build computers, who know everything but deliberately load back doors on their systems while trying to hack into the system, only to open the systems for real attackers.
Vendor-created vulnerabilities can sometimes be caused by software bugs, operating system patches, and services that have been turned on without any notification – and some of those services might be unnecessary, insecure default configurations, web application vulnerabilities, and even system admins.
Some of these vulnerabilities are caused by lazy admins who go ahead and install an application that needs a service account. Lazily, they use the default built-in domain administrator account to run the service. Sometimes, they make configuration changes to solve a temporary situation and forget to switch it back. Some also lack password protection policies. This means they allow small password links to be used (seven or eight characters) instead of longer passwords.
Types of scanners
First, we have networked-based scanners. These are designed to go out and do things such as assess possible vulnerabilities on remote web servers or even perform port scans to determine which ports may be open.
You can't avoid having open ports if you're doing anything with that server to provide access to resources, but we need to make sure only the ports that are needed are open.
We'll look at web app scanners here. These will go through and assess the security aspects of a web application by looking at SQL injection. Web app scanners also look for things such as cross-site scripting.
Tech Tip
Web application scanners don't necessarily provide a comprehensive security check on every aspect of the target web application. There may be a need for doing additional manual checking, such as looking at a login account if it's locked out after so many invalid attempts. You may need to go through and look at those types of things when you're testing a web application.
We also have host-based scanners, which are installed on the host that's going to be scanned. It has direct access to what's referred to as low-level data, such as services or configuration details that may be on a host operating system. Because of this level of access, it provides better insight into user activities that could be considered risky, such as using easily guessed passwords or even no password at all.
It also detects signs that an attacker has already compromised the system, which would include going through and looking at suspicious filenames or unexpected system files that are showing up, or even device files. In some cases, we might see unexpected privileges being given to programs.
A host-based scanner can also perform baselines or filesystem checks. Typically, network-based scanners don't do this level of security check because they don't have direct access to the filesystem on the target. A great example of a host-based scanner would be a database scanner that goes through and performs detailed security analysis of authorization, which accounts have been given authorization, the authentication mechanisms being utilized, the integrity of the database, and possibly any security loopholes that may be in the database system (weak passwords, misconfigurations, and so on).
How does vulnerability scanning work?
What are the limitations? Because there are some definite drawbacks. The first is that human judgment is required. Vulnerability scanners can only report the vulnerabilities it finds according to the plugins that are installed inside the database. They are not designed to determine whether the result is a false negative or a false positive, so we always need someone to look at the data and analyze it after scanning.
You should also note that it's strictly a snapshot. A vulnerability scanner only looks at a specific system at a specific time. Therefore, you can't just do one vulnerability scan and assume you're safe. You must do this continually. As new vulnerabilities emerge, or if people are making changes to configuration settings, we might introduce new security holes.
Another limitation is that it only knows what it knows. A vulnerability scanner is designed to discover the specific vulnerabilities it's aware of. It's not designed to identify other security threats. So, you must keep this bad boy updated.
There's one more limitation. I call it parts as parts, or plugins. Most vulnerability scanners rely on these plugins to determine possible issues or possible vulnerabilities. Plugins become part of the scanning database, which expands the vulnerabilities that are known by the scanner. Now, some vulnerability scanning software programs may refer to them as scanning profiles, but the term plugin is normally what most all vendors refer to them as.
Again, the scanner only checks for those vulnerabilities it knows about. It can't identify what it doesn't know about. However, not all scanners need plugins. For example, a port scanner doesn't need a plugin; it'll hit a range of ports.
So, what are the benefits? Well, first, a vulnerability scanner allows you to detect and handle known security issues early. As a security expert, by doing ongoing security assessments all the time using these scanners, it would be very easy to identify vulnerabilities that may be present on your network. And these vulnerabilities could be either external or internal.
Another benefit is detecting new devices on the network, or rogue systems, that connect without any type of authorization or permission. This is typically what we find when we perform pen tests. I'll try to find a port that's not being utilized, and I've got a nifty little Raspberry Pi device – a tiny mini-computer that is about the size of a standard cell phone. I can hook that up to a port, walk away, and come back a couple of days later after it will be done sniffing your network. A vulnerability scanner will pick those things up.
A vulnerability scanner can also help you with inventory, verifying all the devices that are supposed to be on the network are on the network. It can also help with inventory things such as operating system versions, what OSes have been patched, what software has been patched, and what hardware configurations have been used. My favorite is: Hey, Billy, why does your machine only have 8 GB of RAM when we put 16 GB in it, and how's that machine running at home now? Again, this type of information is extremely useful when it comes to tracking and managing your environment. One of the things you'll hear me say over and over is that your first line of defense when it comes to securing your network is understanding what's on your systems, especially when it comes to software. Well, guess what? A vulnerability scanner can help you do this.
Vulnerability scanning tools
So, how do you choose a vulnerability scanner? Well, there are hundreds and hundreds out there. There are so many choices, so little time. Everyone has a preference, but if you're looking for your first vulnerability scanner, here are some things that you may want to take into consideration.
How often do they update their database and plugins? Again, we will go back to the statement that vulnerability scanners only know what they know. So, it can't identify a vulnerability if its plugin isn't available or hasn't been updated for a new vulnerability. So, a reputable vendor can produce updates and new plugins daily, weekly – you choose. How safe do you feel? I'd also be looking for scanners with an auto-update feature to ensure I don't have to worry about downloading them every day. It can be a scheduled task.
We'll also want to look at quality versus accuracy. If a vulnerability scanner finds a vulnerability, the question is, now that I have found 300 vulnerabilities, how many of those were accurate (were not false positives)? The accuracy that critical vulnerabilities are identified with is much more important than the number of vulnerabilities that have been checked. This is because the same vulnerability could be counted more than once by the same scanner.
We also need to look at the quality of the reporting options that are available to us. A good vulnerability scanner should have a reporting mechanism that gives very clear and concise information about how to fix some of the problems you've discovered. A scanner that has a great reporting option or feature with a nice backend database can make an administrator's life a lot easier when they need to perform follow-up scans after doing the initial scan, if there have been configuration changes, or they a need to make comparisons between the results of a previous scan and the current one.
Another thing to consider is the deployment process. Whether you put the scanner in front of the firewall or behind the firewall, it's going to influence the results you get. Scanning the internal network from outside the firewall is only going to detect the services that are available to the outside user or attacker. It will not look at the vulnerabilities from within the internal side of the network. That won't be visible to you because of the protection the firewall provides.
On the other hand, scanning the machines in your DMZ from inside may not provide a complete picture of your security. So, to get a complete picture of your security, make sure you do your scans externally and internally.
Now, what about port ranges? We already know that open ports could imply we have a security weakness somewhere, and port scanning is one of those we looked at earlier. Knowing that's what the attackers will use, part of your vulnerability scanning should include port scanning.
Some vulnerability scanners only check the first 15,000 ports, yet there are over 65,000, so make sure that you find out how many ports are scanned in the default settings. Oftentimes, you can override these settings by changing the configuration options of the vulnerability scanner.
After scanning
Now, let's talk about the post-scanning practices. What do we do afterward? When you get your reports, it's important to interpret the scanning results correctly to avoid identifying vulnerabilities that are not there.
It's also important to go through and set priorities on the different vulnerabilities you're discovering. A vulnerability on a server that's exposed to the internet would have a higher priority than, for example, Billy Bob's machine down in the mailroom.
Also, note that when you get service packs, or Patch Tuesday from Microsoft, or any other software vendors, any time you apply new patches, you should immediately run new scans. Make sure that your database has been updated but rescan once those patches have been applied.
Again, if you make any configuration changes, you need to run a vulnerability scan once you're done. You should also do this if you plan to deploy any new software, even if that includes your desktop platforms.
The cons of vulnerability scanners
Dun-dun-dun! Beware! Vulnerability scanners create some issues. You will need to be aware of some of those issues as, well, the most important ones will be potential threats. I know I just said it's a vulnerability scanner, but yes, it's a potential threat. You can end up crashing an already vulnerable server if all the plugins, such as one that tests for a denial-of-service scan, are enabled. So, when you go through and configure your scans, initially, you need to pinpoint which portions of the scans are necessary.
Normally, for preproduction systems, it's probably okay to enable all the plugins, including high-risk ones, but when it comes to the ongoing continual scans on a production system, you should be very wary. Alternatively, consider disabling certain high-risk plugins.
When you're handling the results, do yourself a favor – don't post them on a website in your organization, upload them to Dropbox, or put them somewhere a hacker could find them by doing a Google hack. If you do, you can name the document something like howtobreakintomynetwork.pdf. Otherwise, safeguard this information and keep it in a safe place. I would recommend encrypting it because the last thing you want to do is hand a treasure map over to an attacker.
We've talked about some of the cool things vulnerability scanners offer and we know that they were created for good. You also need to have some policies and actions in place in case somebody uses one of these tools against you, such as an employee, not necessarily somebody outside your company. You will find, especially in larger enterprise environments, weekend geeks who bring in a piece of software to scan because they saw something cool on YouTube.
You need to make sure you have policies and procedures to specify whom, how, and when vulnerability assessment tools can be used. These policies can include notifications of when the scan is going to be done, management approval, and possibly legal clearance. No one should be allowed to conduct a vulnerability scan without prior permission!
More tools for scanning
So, what are some of the tools out there? Oh, man. I'm only going to be able to give you some highlighted tools here because there are a plethora of these tools out there for us. These tools include looking at something called Nessus, which is among the more popular ones out there. We also have tools such as Core Impact Pro, which has some cool features built into it, including an Android agent and Windows domain information gathering modules. They also have support for WMI.
We also have Microsoft Baseline Security Analyzer, which goes through and provides baseline security for particular servers. Microsoft's built these features into a lot of and some of their newest server platforms where they have some best practice analyzer tools. So, if you've got some Windows servers out there, especially those that are running Server 2012, you may want to pop one of those bad boys off and see what it kicks out and says about the best practices for that server.
GFI LanGuard is another great product, and it has been out there for ages.
There's also Retina. I had an opportunity to play around with Retina when I had my ISP service. We used it to look at vulnerabilities. I had a friend who had an ISP service but didn't know much about the legality of security. He ran Retina on his network and would send out emails to his customers saying, Hi, your machine is missing these patches. At the time, his customers were grateful and would buy his service pack. That's kind of borderline because he never had any permission to hit their systems. Yes, they were on his network, and he had contracts that said he does scans on the network, but that was probably aggressive.
We also have Saint (https://www.carson-saint.com/). One of the things Saint likes to advertise is that their product helps you comply with government and industry regulations such as PCI, HIPAA, SOX, NERC, FISMA, and COPPA.
Why draw out the network?
Now that we've gone through and scanned for vulnerabilities, our next phase is to draw out the network. A lot of people wonder why they need to draw out the network. Well, take it from an attacker's perspective. First, you're not the only network he's tracking. He must have some way of visualizing your environment, so when he revisits it, he goes, I remember they have a server box here, a Linux box; they're running XP on this machine, they're still running server 2000.
He may also want to see if he can figure out the missing pieces because maybe he's not picking something up, such as a skip in an IP address range.
Now, these pieces of software are designed to help IT personnel go through and manage their networks. Some of them will give you a live map and start showing you important things such as when a node goes down.
It will also help show both the physical and logical paths.
So, let me ask you, what do you see on this map? (Figure 4.4)
Figure 4.4 – VCN network diagram
Can you see operating systems? What else? I can see the devices— a Dell station, a Brother printer, and available apps. I might be able to track architecture, too.
Some mapping programs will help you store additional information notes. So, here is my warning for you: you may be using something like this already in your environment, and typically, these programs save the layout as a file extension.
As an attacker, one of the things I'm going to be looking for are those extensions because if I can download a map, you've already created it for me, thank you! I will store those types of files somewhere secure and, preferably, encrypt them.
So, what are the tools that help us visualize? There are many of them, but one of the most used is WhatsUp Gold, which I liked using back in my old ISP days. It would tell us when an antenna went down so that we could notify the customer or dispatch somebody out to their house before they even knew that they were having an issue.
There's also The Dude, which got its name from the The Big Lebowski movie. The main character is The Dude. We also have NetworkView as another great little product, as well as OpManager. Microsoft also makes a great little product called System Center Operations Manager, but it does require us to load an agent, yet others can just be done via ping and port scans. We also have LANsurveyors and FriendlyPinger – which is quick and dirty.
Preparing proxies and other anonymizing techniques
Before we start attacking systems or launching our attack at a company, we need to prepare our proxies and discuss another technique called HTTP tunneling.
There are other ways that we can use different anonymizing techniques to hide who we are and where we're coming from. We want to create an environment where it's almost like a magician's misdirection – look over here while I attack you from here.
So, first, we'll go through and look at placing the blame on someone else. In this world, where we have hundreds of thousands of devices hooked up, why not utilize them (systems) to go through and create proxies? So, we'll look at what a proxy is, why we use a proxy, and how to use a proxy. Then, we will look at a scary technique that's being utilized today that should have you very concerned: HTTP tunneling. Wait a minute, my users can do what? will be your reaction when you see it. We will then close this chapter by looking at some other types of anonymizers that are out there. Let's go look at those droids, shall we?
What is a proxy?
A proxy can do several things. A lot of companies will use a proxy. They'll use it to hide the identities of their systems behind their firewall, although sometimes, the firewall is their only proxy.
A good example is the ISIS server by Microsoft, which acts as a proxy. It goes out and gathers the websites for you. People only see the IP address of the one machine; they don't have a clue that you have multiple machines behind it.
It can also be used to filter undesirable content. A lot of companies also use this feature to keep employees focused on what they're supposed to be working on.
Sometimes, it also provides anonymous IDs to websites because websites track all kinds of information. One of the things they track is what IP address you are coming from and in this case, it's going to see the IP address of your proxy. We can also utilize it to NAT the IP address from the outside world. Again, it's just acting as a frontend for us.
It provides us with a little bit of protection. It's not going to fool a good hacker, but for most uses, there's not a ton of IP addresses being registered from your business going to websites.
In fact, because of some of the IP addresses, and some of the ways web browsers are utilized today, some website owners can detect what operating system you're utilizing. This can be determined based on the web browser that you're using. The big thing here – for us too – is that it saves on bandwidth. Back in my day, when I had my ISP service, we implemented a proxy server to help reduce bandwidth because everyone's default page back then for Internet Explorer was to pull up msn.com.
Instead of me having 600 employees firing up msn.com, eschewing the same information over and over, why not have the first request go out and have the proxy cache up that web page? And so, the second request comes to hit the proxy server, and the proxy server just quickly checks with msn.com, sees that there are no changes, and immediately returns across the network. Instead of doing so across our internet bandwidth, it just transfers to the page. It was very fast. It saved us almost 40% of our bandwidth.
One of the biggest shockers for me was getting a list of the most popular websites that were being cached up. It was a big eye-opener for me. So, you can see there are some great benefits to using a proxy for a corporation. Now, the question is: Why do attackers use proxies? Well, they do it kind of for the same thing – to hide their IP address from you and place blame somewhere else. They get to mask the actual source if they want. You can even set up a proxy and still spoof the address beyond this proxy.
If I was an attacker, and I wanted to, I could access internal data that's behind a firewall. If I can get someone to load up a piece of malware I've distributed and they're behind a nice firewall they fired up, it reports back to me, sets up a proxy for me, and I will be inside your environment without lifting a finger to get past your firewall.
We also use them for misdirection. Look over here while I'm doing this over here. I can have you believe that the attack is coming from the mailroom server, or Dick Grayson's computer down in the Marketing Department, when it's actually coming from me.
We also use it to help create what we refer to as a proxy chain – where multiple proxies are involved.
How to use a proxy
So, how do we use a proxy? Well, as an attacker, there are several different ways I can make communications or connections to your servers and your machines. First, I can be very blunt and hit you directly. The downside of this is that any IT person worth their weight in salt would find it easy to backtrack and find out where the attack is coming from.
Some attackers will go through and compromise a machine or use a machine they've compromised and be able to issue the attack. Alternatively, they will spoof the address. Again, when we look at log files and see somebody's attacking our servers, we relate it to, in this case, the server in the middle, which the attacker has control of. Now, that's a decent attacker, and this is what common attackers do. The great attackers we see in movies are difficult to trace because a simple call to their cell phone goes through a bazillion links, making it impossible for detectives to get to them in time.
A proxy chain is where an attacker is going to pwn several machines to route their traffic through. You might be able to discover the first proxy IP address they are attacking you with, but just when you think you have figured out who it is, you realize that it's been hopped through from another IP address so that you can get to the second proxy server. And you could keep backtracking to the third and maybe to the fourth.
A good attacker might use multiple machines within your network, but that's easy for you to go and backtrack. For even better cover, some want to have the first two machines in your network, and then outside of that (a completely different network), and then have those machines attack you because you don't have the rights to go in and look at those machines' log files. It would make it harder and harder to figure out what's going on as you back up the chain.
Usually, by the time you find them, the next time they connect to you, they may take a completely different route. It is very easy to detect an attacker utilizing a proxy daisy chain because it's easy to see that source IP, but it's extremely hard to discover where the attack is coming from.
Proxy o'plenty
There are several tools out there that can help with proxying or making yourself somewhat anonymous. One of them is proxifier, which allows network applications that don't normally support working through proxy servers to operate through an HTTPS proxy or chain. This allows people to surf websites that are typically restricted, especially by government or corporate organizations. It gets you past their firewall and hides your IP address. It can even use different protocols through the chain as it makes its way through your proxy chain.
We also have SocksChain, a product that goes through and functions as a Sock server that transmits queries through a chain of proxies. Again, we can use this for client programs that don't support Socks but work with a TCP connection such as Telnet, HTTP, or IRC. It is designed to hide your IP address from being displayed on the targets' logs or even mail headers.
Fiddler, an HTTP debugging proxy server application, also operates as a proxy server. It captures HTTP and HTTPS traffic and logs it for the user to review that information. It's a way that we can implement a man-in-the-middle attack using signed certificates.
Fiddler can also be used to modify HTTP traffic for troubleshooting. Again, these tools are created for good, but they can end up in a user's hands to be used for evil.
We also have The Onion Router (TOR). TOR is a combination of software and an open network that stops websites from tracking you. Because we can utilize the TOR network, I could set up some proxies – there are some programs out there that'll set up proxies in the TOR network for me – so that I can connect to new sites and instant messaging services if my company blocks those. It also encrypts and decrypts packets using public key encryption.
We also have Proxy Switcher, which, as its name suggests, allows you to surf anonymously on the internet without showing your IP, allows you to go through several different proxies (you could get a list of available proxies) and IPs, and go through and select which ones you want to be routed through. So, it hides your IP, allowing you to access restricted sites.
The Proxy Workbench program is also a handy product. With it, you can go through and get a list of free proxy servers out there and create a proxy chain. Plus, it's very graphical and has a nice GUI.
So, again, I reiterate that this course, or all these courses, are not necessarily about learning about the different pieces of software. It's understanding what they can do because when you do your software inventory, your first line of defense is always knowing what's installed on people's machines. So, do a software inventory. Are they running TOR or are they running Proxy Workbench? Do they have Fiddler installed? Do they have Nmap installed? Those are going to be red flags for you.
HTTP tunneling
Now, let me tell you about something that kind of scares me today regarding people getting around the security environments we set up or even our security appliances. It's called HTTP tunneling.
HTTP tunneling is designed to create a tunnel with HTTP. This means that if a user can install this on their system, they fire up their system, and they normally go through our standard network. They hit our firewall, which then sends them out to the internet, and they're able to go out to the websites they want to go to. However, any type of restricted sites or services the security team has said we don't allow in our network infrastructure get blocked.
That's the way things are supposed to work. It's not your network – it is the company's network. As an employee, you are getting paid to do a job, not things they deem unacceptable during company time.
Well, we have all heard of a virtual private network (VPN) before, where we create a VPN between us and another machine. Some VPNs use certain ports, but the in-thing is creating a VPN tunnel using ports 80 and 443 and that's what scares me. Users fire up their machines, install a piece of software that does HTTP tunneling, and then make a connection to the firewall. The packets they pass to the internet that are trying to get to restricted websites go across via port 443 if they want to be secure while doing so. The problem is that your router will not block it because that's the port that we use to browse the internet. But as an attacker, I can encapsulate another protocol inside that HTTP packet because it's in a tunnel. I can submit that to an HTTP tunneling server, which then goes out as a proxy for me to that restricted site.
As far as the IDS system and router are concerned, it's just passing port 80 but encapsulating it in FTP, and maybe you're not allowing FTP. Or it looks like it is using port 80 to go to your HTTP tunnel server website, which could be Billy Bob's site, yet they are being redirected so that they can go to some hacker's site or some inappropriate website.
This is extremely hard to track. So, again, the best way you're going to detect these types of activities going on in your network is, I repeat, knowing what software is installed on each of your machines, and what it's designed to do. Why? Because for this to work, they must download some type of software that sets up this VPN solution for them.
Anonymizers
We also have anonymizers, which is a way of hiding ourselves. Instead of being identified as Bruce Wayne, we get identified as John Smith. There are several tools or mechanisms we can use as anonymizers. We can circumvent our IDS systems and firewall rules and use an anonymizer to get to restricted content that may be either on the network or outside of our network. We can also use an anonymizer for protection against online attacks. If attackers don't know who we are, aren't we just using the same tools against the attackers? Absolutely! And finally, we can use it to afford us a little bit of privacy.
One of the tools that we can use is Ultra Surf (U-Surf), which allows you to set up a proxy. It re-identifies you and allows you to route through a proxy to hide your identity.
We also have G-Zapper. If you are a little paranoid about Google and how they're tracking you, you can use G-Zapper. It goes through and zaps the Google cookie that's on your machine so that when you go to Google, it doesn't automatically log you in, and you're able to do your searches without logging in and therefore not be tracked by Google.
However, just because it's not tracking your search history doesn't mean you're completely anonymous. Other things are tracking your IP address unless you're using something such as a VPN.
There's also one named Hide My IP. Its name tells you what it's going to do.
Not to be outdone, another company came out with a similar tool. It's a Chrome extension you can install on your browser. I apologize for the name, but it's called Hide Your Ass. It's a plugin for your Chrome browser. You can go to a website but before you hit Enter, you can select the Hide Your Ass icon and it'll go through and make it look like your IP or request is coming from a different location, giving you some protection.
Summary
In this chapter, we talked about various methods of scanning a target network. We talked about using both passive and active techniques. We also took the time to look at various scan types. You will want to make sure you've reviewed these types while studying for your exam. Remember, some are not viable on Windows-based systems. We also looked at how systems can end up identifying the operating systems they are running on by implementing a Banner Grab. Using vulnerability scanners can also generate a ton of intel on target systems. Finally, we discussed why it's important to map the network and how to hide by using proxies and proxy chains.
In the next chapter, we'll focus on enumerating targets, which will expose things such as users, services, and other goodies.
Questions
As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:
- Which of the following is an example of banner grabbing?
- Application research
- Passive OS fingerprinting
- Footprinting
- Active OS fingerprinting
- What are the three types of scanning?
- Gray, black, and white
- Server, client, and network
- Active, passive, and hybrid
- Port, network, and vulnerability
- What is the primary goal of performing port scans?
- Checking to see whether any routers have been patched
- Finding system names
- To determine where a ship may dock
- Detecting services/applications that are listening
- Your system has been hacked. The IP address indicated in your logs is from France, yet the originating IP address is from Brazil. Which of the following options did the attacker use?
- Hide My IP
- TOR network
- Proxy chain
- WarpProxy