Pen testing #1: host detection & port scanning

File: pentesting/portscanning.pdf (or .txt)

Work with a partner or alone.

Goals

• Start learning some hacking techniques
• Learn a little bit about passive information gathering, host detection, and port scanning

Rubric

0. Background

This exercise is our first foray into the field known variously as penetration testing, pen testing, white-hat hacking, and ethical hacking. There are, as you might imagine, arguments about fine distinctions between these terms, but ultimately, they all concern the discovery, exploitation, and repair of vulnerabilities in computer systems.

Regardless of our goals, before performing ethical hacking we need permission of the owners of the target systems, as well as a clearly defined scope of action (e.g. what we're allowed to do, and when). In an educational context, our goals are to learn about the techniques of hacking and the corresponding techniques of securing systems. In a typical penetration testing context, a pen-tester will be hired by the system's owners to search for vulnerabilities and make recommendations for improving the system's security. In both situations, permission to hack is needed.

In our case, I have cleared our activities ahead of time with the ITS and Math/CS staff responsible for the security of the systems we'll be working with. For the most part, we'll be attacking the Metasploitable virtual machine (VM) from the Kali VM, in which context we can approach the task with no holds barred. But occasionally, we'll also reach out to external machines, in which case explicit and specific permission is essential. If you want to take your experiments significantly beyond these lab exercises, talk to me, and we'll figure out a way to get the right setups and permission.

Regardless of the context of our hacking, we will often talk about our work in terms that sound like we're sneaking around. For example, we'll talk about doing "stealth scans" to avoid having our actions show up in log files or get noticed by system administrators. That kind of language is natural and appropriate, but we can't forget that the reason we're trying to avoid detection is to demonstrate to sysadmins how their systems could be compromised, and to work with them to fix the vulnerabilities.

As you work on this stuff, you will have lots of questions. Write them down. Follow them up. Bring them up on Slack. Ask me when I ask "any questions?" during class. Be curious. Pay attention to details. And definitely, definitely don't expect to understand it all quickly. There's an enormous amount of detail in this material. I'll expect you to understand a layer or two, but there's always more to know.

In this assignment, we'll take a look at a few of the essential first steps in the search for vulnerabilities in a target computer system. To get started:

• Fire up and login to the Metasploitable VM.
• Fire up and login to the Kali VM.
• Open a terminal in Kali.
• Do a "mkdir yourname" to create a convenient place to save files on Kali. Remember that if you're working in the Olin labs, the files you save here will get trashed after you logout from the lab machine, so if you want to save any of them, you should copy them elsewhere (e.g. by emailing them to yourself, committing and pushing them to a GitHub repository, using sftp or scp to copy them somewhere like your account on mantis.mathcs.carleton.edu, etc.
• Launch Wireshark in Kali.

1. Passive information gathering

Suppose you already know the domain name or IP address of the host whose security you're trying to evaluate. There are many online data sources that can help you learn important information about your target. Using these sorts of tools is referred to as passive information gathering because it doesn't involve communicating with the target system itself. Active techniques run the risk of showing up on the target system's log files, alerting the system administrators, etc., so if you can learn something using passive techniques, it's best to do so.

• Pick a domain you're interested in. (You may want to try several domains before settling on one, especially since the Netcraft tool referenced in the last bullet point below won't always generate any data.)
• Execute:
  whois [domain-name]
  This consults an online DNS database and presents you with a summary. Read through the full output and write down things you don't understand.
• Do the same thing, but this time with
  nslookup [domain-name]
  You can also try getting more info with:
  nslookup -query=any [domain-name]
• Repeat the whois and nslookup commands, but use the IP address you discovered in the previous steps instead of a domain name. Do you get any new information, or is it the same as what you got from the domain names?
• There are many tools online for consolidating passive information gathering. Try this one from Netcraft, for example. It's a little inconsistent since, as it says, it only has information about "websites visited by users of the Netcraft extensions". So you may have to pick a domain that's pretty popular to get any information at all. But when it works, it generates interesting reports.
• Interested in more? You can look around for more passive information gathering tools. If you find something interesting, share it on Slack!

What to hand in

Include a section in your document entitled "1. Passive information gathering". In this section, answer the following.

• What domain did you investigate?
• What is its IP address?
• When does the domain's registration expire?
• What information, if any, did you learn about the people or corporation responsible for the domain in question? (Your answer could be less interesting than you had hoped due to the increasingly common use of domain privacy services. In that case, at least give me information about what you learned about the relevant domain privacy service.)

2. Host detection

Sometimes you know the network you're interested in targeting, but not the specific IP addresses. Host detection is the process of finding active hosts on the network.

• Scanning your local network
  • Get the IP address for your Kali instance's network interface. (Remember ifconfig?)
  • Fire up Wireshark and start capturing packets (no filter).
  • Using Kali's IP address, execute the command:
    nmap -sn [ip-address]/24
    (What does -sn do? What does the "/24" mean? (Maybe you can get me to talk about it so you don't have to try to find a sensible explanation online.))
  • Once nmap is done, stop the capture session in Wireshark.
  • Save this capture session in your directory, in case you want to look at it later.
  • Look at the nmap output in your terminal. How many hosts did you find? What are their IP addresses? What else, if anything, did nmap tell you about them?
  • Look at the captured packets in Wireshark. What steps did nmap go through to do its host discovery? What questions do you have about how the host discovery worked?
• Scanning a remote network (this is one of those spots where I needed to get permission). Go through the same steps as above, but this time, do it on the Math/CS network (137.22.4.0/24).
  • Start a new instance of Wireshark so you can compare the previous capture session with this new one. You can do this by executing "wireshark&" in a terminal.
  • nmap -sn 137.22.4.0/24
  • Wait until nmap is done, then stop capturing, save, and look at the nmap output.
  • Compare the two Wireshark sessions. How are they different? How are they the same?

If you're interested in learning more details about host discovery, here is a handy summary of host discovery techniques, all executable using nmap.

What to hand in

Include a section in your document entitled "2. Host detection". In this section, answer the following.

• List the IP addresses for all the active hosts you found on the local network (i.e. the hosts whose IP addresses have the same first 24 bits--i.e. the same W.X.Y of the IP address W.X.Y.Z--as Kali's IP address).
• What entities do those IP addresses represent?
• For each possible candidate IP address it was searching in the local network, what steps did nmap take? (You can answer this question by examining the Wireshark captured packets. If you want to make it easier to read the relevant packets, try doing "nmap -sn [just-one-ip-address]" instead of the /24 thing.)
• Repeat the previous three bullets, but for the 137.22.4.0/24 network. (Note that your results will be different if you execute nmap while connected to the Carleton network than if you're not connected. Either choice is fine with me.)

3. Port scanning

Once you know the IP address of the host you want to target, it's time to learn more about it. One of the most important things to learn is which ports on your target system have servers listening on them. For example, at this writing, mirage.mathcs.carleton.edu has exactly one port open: port 22, for SSH logins. (SSH access is the entire purpose of mirage in Mike Tie's world. Because Mike is cautious and smart, he has made sure there are no other ports open, so as to reduce the likelihood of anybody exploiting bugs associated with the services on other ports.)

Technically, any server process can listen on any port. That said, there are many ports that are conventionally associated with specific services. SSH is normally on port 22, HTTP is on 80, HTTPS on 443, etc. These port/service combos are called well-known ports. You can see a list of them at the Wikipedia link I just gave you, or by running "cat /etc/services" on a Unix system like Kali.

The process of learning about the available services on a host is called port scanning, so let's scan some ports!

(Want to know how nmap performs a port scan? Go ahead and capture the packets in Wireshark and see what you can learn. That's not mandatory in this part of our exercise, and it's rare that a hacker would worry about the specific packets contained in a port scan, but it's pretty illuminating when you're learning.)

• In your local network scan from section 2 above, you probably identified 3 or 4 active hosts. For each of those hosts, try this command:
  nmap [ip-address]
  (If you identified more than 4 hosts in section 2, just pick 4 of them to scan with nmap.) You should be able to tell which IP address is Metasploitable's just by the large number of ports left open. Unlike the ever-careful mtie, the fictional sysadmin in charge of Metasploitable is a bit on the sloppy side, security-wise.
• For the Metasploitable IP address, try
  nmap -A [ip-address]
  This gives you a lot more information about each of the open ports.
• Take a spin through the "nmap -A" output. Does the target host have a web server running? How about a web server listening for HTTPS queries? An SSH server? A mail server? A database server (and if so, which one)? etc.

What to hand in

Include a section in your document entitled "3. Port scanning". In this section, answer the following.

• Which ports does Metasploitable have open, and what services do they correspond to (e.g. port 22 / SSH or port 80 / HTTP)?
• What database server(s) is/are available on Metasploitable?
• What is the value of the RSA SSH host key? What is the host key for?
• Pick one of the open ports that has a service you have never heard of, and explain what the service does.