CompTIA Pentest+ PT0-002 – Section 7: Nmap Part 2

58. Nmap Fingerprinting (OBJ 2.3 and 2.4)

In this lesson, we are going to talk a little bit more in depth about fingerprinting scans. So we’ve talked about ports and we’ve talked about port states. But there’s more information that you can get by doing your fingerprinting. When you do fingerprinting, this is a technique that gets a list of all the resources on the network, the host or the system, as a whole to identify potential targets for future attack. Now, this is the idea here with fingerprinting. As an attacker, I’m trying to find out all about your system, so I can figure out a way to penetrate it and a way to exploit it. You as a defender want to know that same information so you can put defenses in place to stop me from doing that. Now once you start identifying the open ports and you’ve discovered those, we’re then going to use Nmap to probe them intensely. Now, what do I mean by intensely? Well, there are two way of doing this. You can use the command, nmap-sV or nmap-A. Both of these will do an intensive port scan. Now, these scans do differ just a little bit. When you’re using sV, you’re going to be able to get some basic versioning information.

But -A is going to do it more intensely and discover even more data. This intensive fingerprint scan can provide you with a lot of detailed information. Things like the protocols in use, the application name and version, the operating system type and version, the host name and the device type. All of this is great information. So once your scan is complete, you’re going to see something that looks like this. You’re going to receive a list of the ports and their states. Notice, there are different states that a port can be in. We talked about those. We had open and closed and filtered, right? And so here, I see the first port, is port 53. Its a TCP port and its open. Now what service does it run? It runs domain service domain name service. Now I also see the fingerprinting strings here.

And it shows me what version of the bind request TCP was being used. In this case, it couldn’t identify the exact version, but it does know its using bind. Then, I see the next port, port 80. This again is TCP and it was open. This is running, our web service HTTP. What version is being run here? Microsoft Internet Information Services. That’s running the HTP daemon which is running on version 10.0. Now as I look into that, it gives me even more information. Gives me some basic methods of how it’s done that and the information it knows about it. And as you go through this you’re getting more and more details. As you go further, you can see the Mac address, you can see what operating system it’s using in this case, Windows Server 2016. And all those types of details are things you can find out by doing this type of in depth, intensive probing of those different ports and seeing what the responses are. So you may be wondering, how does Nmap fingerprint, what services and versions are running on this server? How does it know all this information? Well, it does it using what’s known as a CPE which is the Common Platform Enumeration.

This is a scheme for identifying hardware devices, operating systems and applications developed by the MITRE Corporation. Essentially, this CPE is a database of different fingerprint signatures. And what Nmap does is it compares the response it’s getting from these ports when it sends that send packet. What it gets back as the synack, it looks at that packet and determines which operating systems it is and which versions because each one answers just a little bit differently. That’s the idea of using the CPE. Now Nmap is also a really powerful tool and it’s even more powerful when you can use scripting with it. Nmap even comes with its own scripting engine. It’s known as the Nmap Scripting Engine or NSE. This allows scripts that are written in the Lua scripting language to be used to carry out detailed probes. This includes things like, OS detection and platform enumeration.

Windows user account discovery. Identifying the logged-on windows users against the system. Performing some basic vulnerability detection to figure out what software is in use and what might be vulnerable. It can also be used to probe web servers to gather HTTP data and identify web applications in use. And, you can even add geolocation to your different traceroute probes. All of this and more can be done using the Nmap Scripting Engine. If you go to nmap.org, you also find there are lots of pre-made scripts out there that have already been created for you. You can simply plug them into your Nmap client and that way, you don’t even have to write these scripts yourself. We’re going to explore the Nmap Scripting Engine more in a separate video.

59. Using Nmap (OBJ 2.3 and 2.4)

In this lesson, I want to show you hands on how we use Nmap by combining some of those commands we learned about into a real scan and real information gathering techniques. Now this is really important come test day, because I guarantee you’re going to get some Nmap question. I want you to play with Nmap before the exam. I want you to be comfortable with it, because these are going to going to be easy points for you if you’ve gotten used to doing these scans. Now for this demonstration, I’ve put together this lab. On the left side, this is where I’m going to be attacking from, which is going to be simulating the internet. I’m coming in from outside the network, and the router has certain things in place to try to keep me out.

I’m going to attack from my Kali Linux command line environment which you can see highlighted with the red dash lines. Going to come in through the router, which is separating the internet, the outside, versus the target network, which is the inside. And so with our scans, we’re going to try to discover those three servers on the right, the LAMP-server, the Metasploitable 2 and the Damn Vulnerable Web App or DVWA. Now those all reside inside the 10.10.10.0/24 network. So now that we are in the command line environment, what are we going to do? Well, we first are going to want to find out which things on the 10.10.10.0 network are up and which ones are down. So we want to use that ping scan.

Now, do you remember what the command is for ping scan? That’s right. It’s nmap dash sn and then the IP address. So for us, that’s 10.10.10.0/24. It’s going to go through and scan all 254 possible IPs, and find which ones are up and which ones are down. Now it came back with four hosts. What are those four hosts? Well, the dot one is the router itself. It’s the internal interface of the router. There is the dot 10, which is one of our servers, the dot 11 and the dot 12, which is the other two servers. So the dot 10 is going to represent the LAMP-server. The dot 11 is our Metasploitable 2 server. And the dot 12 is going to be our DVWA or Damn Vulnerable Web App. Now all we have at this point is knowing that those three servers are up and responding to pings. We have no other information, so we’re going to want to take it a step further. Let’s go ahead and do a SYN scan, which if you remember the command is nmap dash sS and then the IP address that we want to look at. But I’m going to combine that with port 80. So I want to figure out what web servers are being run out of this network. And then we’re going to use the 10.10.10.0/24. Now, as I scan away, it’s going to check all of the 254 IPs again, and in this case we found there are four web servers responding. There is port 80 responding up as close on the router. It is open on the LAMP-server, the dot 10. It is open on the dot 11, which is Metasploitable 2. And it is open on dot 12, which is the Damn Vulnerable Web App. So all three of my servers are running at least port 80.

Now let’s dig in deeper on one of those servers as we go further in our information gathering. Let’s go ahead and do a SYN scan against the lamp server, which is the dot 10. So we’re going to do nmap -sS and then 10.10.10.10, and we’ll go ahead and search that. And you can see now that there are more than just the web server running, right? There are three services running on this server. There’s an SSH server on port 22. There is the web server on port 80 and the web proxy on port 8080. Now that we found those, what about the versions? What if I wanted to figure out what version of web server it was running on port 80? Well, how would we do that? Well, we’re going to use nmap dash sV and then the 10.10.10.10. And now if we run it, you’re going to see a little bit of a difference here. So you’re going to see it takes a little bit longer to run this, but instead of half a second, it’s taking almost seven seconds. The difference here is that I get the versioning associated with each of those services.

So the same three services are up, but I found out that it’s running some form of Linux, and it’s running Apache 2.4.18, which tells me that I could start associating vulnerabilities associated with that, and attack this machine. Now it tells me it’s Ubuntu Linux, but it doesn’t tell me what version. What if I wanted to go deeper and figure out the version of this operating system? How would I do that? Well, it’s not sV, because that’s the version for the service, instead, it’s dash O because it’s for the operating system. So it’s nmap dash O and then 10.10.10.10. And then we’ll go ahead hit Enter and away it goes, and it comes back in less than two seconds and tells me that it is Linux somewhere between version 3.2 and 4.6. So let’s go ahead and take it a step further. Let’s combine some commands. Let’s go ahead and do an nmap scan for dash sS. We’re also going to do dash sV for the versioning. And we’re going to go ahead and add the dash O to get the operating system. I’m going to do that against 10.10.10.10 through 10.10.10.12, those three machines, and see what comes back. Now you may have noticed that it keeps saying, it’s unable to determine any DNS servers. That’s an error because I don’t have this lab environment connected to the internet. So there’s no DNS being resolved. It’s not an issue because we’re using IP addresses.

But if I tried to do something like scanning google.com right now, it wouldn’t be able to give me that answer back because it doesn’t know what the IP address is for Google. Now this scan is going to take a little bit longer, so I’m going to fast forward to when the scan comes back with the results. Now the results have come back, it took 140 seconds. So this has come back with a ton of information. So much so, it actually scrolled off my screen. So we’re going to scroll back up to where I put in the command. So there we go. There is the command we put in, nmap dash sS, a SYN scan, dash sV, versioning for the services, dash capital O for operating system versioning, and then 10.10.10.10 through 10.10.10.12.

Now the first one it comes back with is the results for 10.10.10.10, which shows that there are 997 close ports, ’cause by default, nmap is going to scan the top 1000 commonly open ports. You’ll notice here there was those same three ports that we found earlier, port 22, port 80 and port 8080. And you’ll notice it tells us what version of SSH, and what version of Apache is being run. And again, the versioning of Linux was somewhere between 3.2 and 4.6. Not very accurate. Now if we look at the bottom of the screen, I’m going to scroll it up to the top here. This is the scan report for 10.10.10.11. Notice this one has a ton of open stuff. It only has 979 closed ports, which means that there are 21 open ports, and you’ll see them all shown on the screen there. Things like FTP and SSH, and Telenet, and HTTP, and rpcbind, and port 139 and 445 for netbios-ssn, which is Samba for windows file sharing between a Linux machine and a windows machine. All of these different things with all of these different versions.

Now this is a great machine that we can target because we have a lot of vulnerable apps on it. Things like Apache 2.2.8, there’s exploits that exist for that. There is vsftpd 2.3.4 for the FTP service. That’s a vulnerable version we can attack. There’s proftpd 1.3.1. There’s MySQL version 5.0.51, right? Lots of different pieces of information that we can use to then later exploit it. Now it does say that one service was unrecognized even though it gave back data, and they weren’t really sure what it was because there wasn’t a valid fingerprint, and you can submit it to Nmap for them to try to figure it out better. If you know what the service is, you could tell it, and then they can add that to the next version of Nmap. Now as we scroll down a little bit further, we’ll go through that signature that they gave us, and you can see that the version of Linux here was again, version 3.2 to version 4.6. And so that again, wasn’t real helpful.

And the reason why we’re gaining that wide range of operating systems is because this is all actually being run in a Docker environment, so they’re all sharing this same operating system. This is a container based virtualization. Now, as I scroll on down, we’re going to see the results for 10.10.10.12. And this one only has one port that’s open, and it’s running Apache version 2.4.10. So again, we can go and look for something that would be able to be exploited and go after that server using that. So that’s the idea here, as we start scanning and figuring out all this information. Now all that was a lot of information to put on the screen.

Wouldn’t it have been helpful if I output that into a grepable file? Well, certainly it would. For any of these commands, we could have output this to a file and that way we’d have it for our reference later on. Because when you go back a couple days from now, you’re not going to remember what ports were open on any of these machines, right? That’s why having these files will be helpful. So instead I’m going to use nmap dash sS dash p port 80, and I want to get the versioning of that, and I’m going to look at that on 10.10.10.10 through 10.10.10.12. And I want to output that to grepable format, and I’ll just call that outputnmap.txt. We’ll go and hit Enter. It will run that scan. And in addition to putting it to the screen that I can see it, it will also save it into that grepable file.

Now, how do I find that grepable file? Well, let me go ahead and clear my screen here. And if we do ls in Linux, that will list our directory. And you’ll see here, outputnmap is listed right there. And so I can just use a pico which is an editor, and just type in outputnmap.txt and hit enter, and there it is to the screen. Notice it looks different here because it’s grepable. They removed a lot of those new lines. They removed a lot of the special formatting. And they made it really easy for us to find the information we want. For example, we have the hosts on the left the very clean, status was up or status was down. And then we have the ports that were open, right port 80, it’s open, it’s TCP, and it was an HTP service running this version of Apache. As you can see why this grepable format is very, very useful. Now from here, I want you to download nmap.

Take some time and play with it. Scan things inside your home network, scan authorized websites like scanme.nmap.org, and get used to using Nmap because it’s going to be essential to your success on the exam. I promise you, you’re going to get some questions about Nmap, including which syntax options you need to use to create certain types of output, or they may even ask you to read the output of an Nmap scan and determine what’s services are most vulnerable to an attack. Nmap is a huge part of conducting information gathering and performing basic vulnerability scanning of operating systems, servers, and network devices. So make sure you’re comfortable with using it before you take the exam.

60. Nmap Scripting Engine (OBJ 2.3 and 2.4)

In this lesson, we’re going to explore using the Nmap Scripting Engine just a little bit more. Now we’ve covered the basics of it when we talked about how it’s used and why it’s used. But in this lesson, I’m going to actually show you how to do it in your lab environment, so you can practice using it. Now, the first thing we want to do is open up VirtualBox. When we open up VirtualBox, there’s a couple of settings that we’re going to make to make sure that we can effectively do these scans, and put both our Kali Linux machine and our vulnerable machine, that we downloaded from VulnHub, into the same network. Now, when you get to the VirtualBox screen, the first thing you want to do is go into the VirtualBox host manager. This is underneath the File menu, under Host Network Manager. Once you’re there, you’re going to click the Create button. And this is going to create a virtual network that we can then connect these two machines to. Right now, the way we have our virtual machines installed, they’re able to connect directly to the internet. So now that we’ve done that, I’m going to go ahead and hit Properties. Now, from here, you can see the IP address scope that’s being used. Right now, this individual adapter is being used with 192.168.56.1. But if we want to be able to enable DHCP on this particular network, we can simply click DHCP Server, and then hit Enable Server. From here, you can select what IP address ranges you want to use.

They have to be on the same network as that vboxnet0 that we just created. And so, here, we can use the default settings we have. There is a virtual DHCP server being configured that’s going to be using the IP address of 192.168.56.2. It’s going to have a subnet mask of 255.255.255.0, which tells me it is a default Class C network which will have up to 256 total IPs. One was used for the router, one was used for the DHCP server, one will be used for the network name, and one will be used for the broadcast. This leaves us with 192.168.56.3, all the way up to 192.168.56.254, for a total of 252 IP addresses that we can use for our virtual machines. Now, in my case, I only have two virtual machines, so this is more than enough. Once you have that set, go ahead and hit Apply, and then hit Close. Now, on your Kali machine, you want to select your Kali machine and then go to Settings. Under Settings, click on Network, and under Network, switch it from a NAT to a Host Adapter. From here, you’ll see it already selects vboxnet0. If you click the Advanced settings, you’ll have the ability to enable or disable the Promiscuous Mode. You can allow it for VMs or allow it for every device on this network.

Now the nice thing is, you can actually connect real-world machines to this vboxnet0 as well, if you’d like to. For our purposes, though, I’m going to leave the VMs having the ability to use Promiscuous Mode, because that is something that’s helpful when we’re doing some of our network attacks later on. Then go ahead and hit OK. The second thing we need to do is select our vulnerable machine. In my case, jangow 01. Click on Settings. Click on Network. And the same thing needs to be done, where we’re going to click on it and tell it to go to a Host-only Adapter, which selects vboxnet0. If you click on Advanced, you’ll see this one is in Deny mode, and that’s going to work just fine for us. Go ahead and hit OK. At this point, we want to turn on both of our virtual machines. So I’m just going to go ahead and click Start. And then I’m going to click on the Kali machine as well. And I’ll hit Start on that. And I can then minimize my VirtualBox manager. Now you’ll notice how small these are again. If you want to make these larger, there’s a couple of ways to do it. But the easiest way is to simply click on them, go to Machine, and then go to Settings. From here, you can click on Display, and underneath Scale Factor, change that to 200 or 300%. Whatever is comfortable on your monitor. That’s a good size for me. On the other one, I’m going to go ahead and do the same thing. 200% should be fine for my vulnerable machine, because it’s going to be in the background most of the time. And right now, I’m going to minimize it, ’cause there’s really nothing I can do with it, ’cause I don’t know the login yet. Going back to my Kali machine, I am going to go ahead and make that just a little bit bigger by going full screen.

And then, from our full screen, I am going to go ahead and make this up to 250, to make it a little bit easier for you to see as you’re following along. All right, once you’re at the screen, you’re going to log in using kali, and the password of kali. Okay. Now that we’re in our Kali machine, we’re going to go ahead and get into our terminal and start using Nmap. Now the first thing I want to do is I want to bring up a Root Terminal Emulator, which is, if you click on your terminal, and a little down arrow, you’ll see it come up with red Root Terminal Emulator. Your password for this is going to be kali, just like your regular password. Now, the reason I’m using the root user here instead of the regular user is because, as I start doing packet crafting and manipulation using Kali Linux, such as doing a SYN scan instead of a three-way handshake, that is going to require root access. So instead of having to be asked every time to log in as the root user, or to do sudo, we’re just going to use a root terminal. Once you have your terminal set up, you can make it full screen. And then, from here, we’re going to start doing an Nmap scan. Now the first thing we need to do is figure out what is that victim machine that we’re trying to gather information on, that vulnerable machine, what is its IP?

And to figure this out, we’re going to do an Nmap scan. So I’m going to do nmap -sS 192.168.56.1/24. And that’s going to say to do a SYN scan across the entire subnet of 256 hosts, because I know it’s someplace in there. Now, is this pretty noisy? Yes. But for our purposes right now, it’s totally fine, because I’m just trying to figure out what is up and online in this particular subnet. Now, if I wanted to make it a little bit less noisy, instead of scanning the default top 1000 ports, I could just put –top-ports and the number that I want to do. In my case, I’m going to do the top 10 ports. So just put space 10, and then hit Enter. When you do this, it’s going to scan the top 10 ports across the entire range, and display to the screen what it finds. Now, what I expect is to find two machines, a Kali machine and a vulnerable machine. Now the Kali machine should have no ports open, because by default, Kali has all ports completely closed, because this way you can be very quiet and you can listen to things without people coming into your machine. Now, on the other hand, the vulnerable machine should have some ports open, because we have to have a way to get into that machine. Okay, here’s our results. Now the first thing we have is the .1. The .1 is the router, or the simulated router, inside a VirtualBox. Notice here, we have a bunch of ports. Because I said to show me the top 10 ports for each of these machines that it finds, it’s going to list out the top 10 ports and whether they’re open, closed, or filtered. If they’re filtered, that means there’s a firewall in place that is making sure that you cannot connect to that machine. Now, in the case of the first machine, the .1, that is our simulated router. And yes, there are 10 ports, but they’re all filtered and blocked by the firewall. The next one we have is .2. And you can see the same thing. They’re all filtered and blocked by the firewall. If you remember when we set things up, the .2 was our DHCP server.

Next, we have .4. And under .4, we can see that there are those 10 ports. Eight of them are filtered by the firewall, but two of them are open. We have an FTP server and a web server that are open on port 21 and port 80. And then we have .3, which is actually our Kali machine. And you can notice that those are all closed, not filtered. That means they’re not even being protected by a firewall. They are all answering back as closed because there is no service there at all, and there’s no firewall in place to have to block them because they are fully closed. So this tells me that my vulnerable machine is 192.168.56.4.

Now when I ran the scan, I did it with the top ports option, but I did not do it with the -sV option. So I didn’t get the versioning information. If I want to learn a little bit more about this particular machine, I can look it up by using -sV with my Nmap command. So let’s go ahead and try that out, nmap -sV 192.168.56.4. And then we’re going to do -p21,80. Now why did I do -p21,80? Well, I know there’s only two ports that are open. So why would I go and scan 10 ports when I only need to scan two? This will make it less noisy, and less likely that I’ll be detected by a cybersecurity analyst or a network defender. As I go out and do that, it’s going to start scanning those ports, and it’s going to try to fingerprint and enumerate what versions of software are running for FTP and HTTP. So now we can see we got our results back.

They’re running vsftdp 3.0.3 and Apache httpd 2.4.18. I would make a note of that in my log, and that way I know what versions of software I’m likely to encounter on this machine, and I could then try to manually figure out what vulnerabilities might exist against those. Or I can use the Nmap Scripting Engine to try to figure that out for me. Now to do this, you’re just going to use the tool nmap –script=vuln, for vulnerability, and the IP address that you want to search. In this case, 192.168.56.4. And then you’ll hit Enter. Now, notice the category I’m using here, that I’m scanning with, is vuln. What I just told it was, take every vulnerability script you know about inside of Nmap and run it against this target, and then come back and give me a full report on anything you’ve been able to find. Now, keep in mind, when you do this, you’re going to be running multiple scans against this target. And that is something that can be very detectable by a cybersecurity analyst or a network defender. If I wanted to be more sneaky about it, I could actually pick individual scripts and individual vulnerabilities that I want to look at. In addition to this, there are different categories of scripts that Nmap can use. If you go to nmap.org, you’ll be able to see the different scripts they have. Nmap has scripts in lots of different categories, including auth, for authentication credential scripts, broadcast, brute, for brute-force attacks, default, discovery scripts, denial of service scripts, exploit scripts, lots and lots of different ones. In total, if you go to the Nmap website, you can see that there are currently over 600 different scripts that they have that have been created in this Lua programming language, so you can run these against different victims and targets.

But the one I was really focused on here is vuln, which is any script that’s in this category is going to be going against a specific and known vulnerability and then only report results if they’re found. Now, you’ll notice this is taking a while for this to do it. This is because it has to go through all of the scripts, because I wasn’t very specific in what I wanted it to do. Once we get the results back, we’re going to talk about them, and then I’m going to show you how you can be quieter by actually using the information we gathered in the -sV command, knowing that it was vsftp, or there was Apache httpd, that we can then check for vulnerabilities just against those things, instead of doing this throwing the kitchen sink mentality that we did by using the basic –script=vuln that we used in this case. The reason I showed you this first is because the exam objectives only cover this level of depth in the Nmap Scripting Engine, that you can go ahead and throw the entire category of scripts at something. But we do want to be a little bit quieter and avoid detection, so I’m going to show you how to do that in a moment. All right. Our results are back. We are done scanning the one IP address, and it took 330 seconds. As you can see, if you start going after large number of systems with these vulnerability scripts, it can take a long time. And again, it’s pretty darn noisy.

Let’s go ahead and scroll back up, and see what we found. All right. As we went through and started doing our scanning, we did find that port 21 and 80 were open. We already knew that. As it checked for any cross-site request forgeries, we didn’t find any vulnerabilities there. Now it did find possible SQL vulnerabilities for SQL injections when running the http-sql-injection vulnerability script. You’ll notice on the left side, the name of the script is included, and then the results. As we move down the list, we see a lot of those underneath that SQL injection one. The next thing we have is http-stored-xss. This means it couldn’t find any stored cross-site scripting vulnerabilities. After that, it looked at http-enum to try to do an enumeration of your web server. It found there was a root directory with the listing of apache/2.4.18. Basically, it did a banner grab for us. And then it checked and found that there was a /site/ that was a directory that was possibly interesting, and we may want to go look at that. There was another vulnerability script that was run that was checking for DOM-based cross-site scripting attacks. And again, nothing was found for that one. After that, they checked for a fileupload-exploiter inside of the HTTP daemon, and they couldn’t find a file-type field there, so that wasn’t valid either. And so, that was all the things that it found as it went through and did its scripts. Now it didn’t really find anything for our FTP server though, and I think that’s a little unusual. So I’m going to go ahead and run some other scripts that contain FTP-specific vulnerabilities, enumeration, and other techniques. To do this, we can go ahead and use the command nmap -p 21, which is port one for FTP, –script. And in this case, instead of saying I want to use the entire category of vulnerabilities, I want to search for anything that has the word FTP in it, dash something else. So I’m going to put a wild card, and then end my quote, and then put the IP address, which is 192.168.56.4. Now what I’m doing here is I’m looking across all of the categories that Nmap has, not just the vulnerabilities. Because, maybe our FTP server wasn’t vulnerable to a specific exploit that Nmap already knew about. But I can still do enumeration. I can still do fingerprinting. I can still do other things to find information about that FTP server.

And that’s what we’re going to do right now by using this command. Now, again, this will probably take a couple of minutes for it to run through all of those scripts that contain FTP in it. So I’m going to pause the video and come back with the results. Okay. Our results are back. Now, it took a while. It took over 600 seconds, which is over 10 minutes, for this scan to finish. Now, the reason it took so long is because I ran seven different scripts by using ftp-*. Anything related directly to FTP was going to be run. This includes the ftp-anon script, which checks if an FTP server allows for anonymous logins. In our case, we did not find an anonymous login on this particular FTP server. It also checked ftp-bounce. This checks to see if an FTP server allows port scanning using the FTP bounce method. And again, we didn’t see that. It also checked ftp-brute, and you can see a couple of error messages on the screen from this. Now, ftp-brute conducts a brute-force password audit against the FTP server. In this case, we exceeded the time limit, which was 10 minutes. So we tried for 10 minutes to guess the usernames and the passwords, and we failed. And so it quit, and then continued with the rest of its scans. As you can see, during that 10 minutes, no valid accounts were found. But we did try 3,442 guesses in that 602 seconds, with an average of 5.7 guesses every single second. The next thing we did was we tried to do ftp-libopie.

This checks if the FTP service was prone to the CVE-2010-1938. Now, this is a really old CVE, so I wouldn’t expect us to be vulnerable to it. And as you saw, we weren’t. Additionally, if this one had shown, it would’ve shown inside the first scan we did using the vuln scripts because it is a vulnerability script. Another thing that we checked was ftp-proftp-backdoor. This is a script checking for another vulnerability that allows a backdoor to be able to get access inside a ProFTPD 1.3.3 FTP server. Now, we’re not running that version of the FTP server, as we know from our reconnaissance earlier on. And so, that also came back as negative, and didn’t allow us in. We also tried running ftp-vsftp-backdoor, which is another vulnerability, this is CVE-2011-2523, that tried to find out is there a backdoor in vsFTP 2.3.4? We’re not running that version of vsFTP, so we’re not vulnerable to it. And then we also checked the last one, ftp-vuln-cve2010-4221. This checks for a stack-based buffer overflow in a ProFTPD server if it’s running version 1.3.2 to 1.3.3. Now, we’re not running that version of the server, as we saw earlier, so again, we weren’t vulnerable to that. Now what this tells me is that based on these seven scripts, Nmap doesn’t know any known vulnerabilities against this particular FTP server. Now, it doesn’t mean it’s not vulnerable. It just means that it doesn’t have any scripts that Nmap can check against to find those vulnerabilities. Remember, Nmap is a very basic vulnerability scanner. It can check for some obvious things, but it doesn’t have a complete list of every FTP vulnerability that ever existed. For that, you’d want to use something like Nessus or OpenVAS against a server to identify those particular vulnerabilities.

All right. The last thing I’m going to show you is how you can actually have Nmap set up on a network segment. For example, maybe you connected to the local area network of your target. Or you were able to get on their wifi, in which case, you can actually start sniffing the area and be able to see who was on that network, instead of having to actually go out and scan the network the way we did at the beginning. To do this, I’m first going to clear my screen. And the command you want to use is nmap –script=targets-sniffer. This tells it to run Nmap and use the script, targets-sniffer. Then, I need to pass some arguments into that script. So we’re going to use –script-args=newtargets .targets-sniffer, which says, any new targets are going to be passed as an argument into targets-sniffer. Then we’re going to do targets-sniffer.timeout=60s, which says my timeout is going to be 60 seconds. That’s how long I want to conduct my network sniffing for. Then I’m going to use targets-sniffer.iface=eth0. And this says, I want to use the Ethernet adapter known as eth0 to do my sniffing. So if I go ahead and hit Enter, it’s going to start sniffing for 60 seconds.

Now, what we found was three different addresses. We found the .1, which was our router, .2, which was our DHTP server, and .4, which was our vulnerable machine. Now, why is this, if nobody’s actually using any of those devices right now? Well, most computers actually have some background communications that happen even when you’re not sitting at them and using them. So even though I’m not actively doing anything on that vulnerable machine, it still goes out, usually, every 10 to 15 seconds, to be able to say, “Hey, I’m here on the network. If you need to talk to me, this is where I am.” And it does that to the rest of the devices on the network. This happens at layer 2, inside of ARP traffic. And that is what we are listening to here, to collect and see who is on this network, and then resolve those ARP traffic messages into an IP address. So we now know there are three devices on this network. This would’ve been a really good, quiet way to figure out who is on this network, and who we want to look into further. Now that we have these three targets, we can then see what ports are open, what services are running, what versions are running, and possibly, what vulnerabilities they have.

• Category: Uncategorized