Part 4: Intelligence gap

This content is based on the H4 tasks of Data Security by Mr. Karvinen.

The Art of Hacking

In this section we will have a closer look at Passive Reconnaissance and Active Reconnaissance from The Art of Hacking. Reconnaissance itself is an essential base which helps with the gathering of intelligence and mapping of a target environment. With it we can cut down on the time effort for an engagement significantly, especially in larger target systems.

Passive Reconnaissance (3.0 - 3.4)

Passive Reconnaissance (recon) is one of the most important elements when it comes to engagement. It refers to the research or reconnaissance that is done without directly engaging with the target itself (no scanning, phishing etc.), which would potentially make them aware that someone is actively looking for something.

Instead passive recon relies on things like researching publicly available information, etc. This can reveal extremely useful information which is commonly overlooked. As example you might find employee names, password dumps from previous breeches, test systems open to the internet, and a variety of other gems.

Skipping out on recon is will potentially cause you to overlook crucial information on the target system, such as vulnerabilities which might be of importance for any successful engagement. It is in general an invaluable source of intel that might provide you with information that you simply could not obtain in other ways without extensive effort.

In terms of methodologies we can utilize multiple techniques in the spirit of passive recon. For host and port discovery this can include things like:

  • Search engines (including some techniques like Google dorking, etc.)
  • Certificate Transparency (Find issued certificates)
  • Guessing Hostnames (and check with nslookup if target exists)
  • Regional Internet Registries
  • Netcraft searches (to get some intel on the technologies used)
  • Shodan.io and Censys.io searches (to see/search scan results of systems that are reachable online)

Another crucial source for recon are files that belong to a target. These can often be acquired through simple Web searches. With the right search parameter we can for example execute a targeted search for PDF, XLSX or password files. The Metadata in files can provide useful intel such as usernames, org info etc. Something like ExifTool can help with the extraction of such metadata.

Last but not least we shall not forget about the value of names, passwords, and other sensitive information that belong to a target organization. A valuable source of such information are public breaches (as example Adobe, Dropbox, etc.), some of which contain a significant amount of data that could be of interest, since many users reuse their passwords and usernames. Pastebin is another interesting source that can contain valuable information. Here we can also again use search engines for our advantage, by utilizing modified search queries to specifically search for sensitive information. Very useful for this specific purpose is the Google Hacking Database

Active Reconnaissance (4.0 - 4.3)

Active reconnaissance/recon differentiates itself from the passive form by the nature of active engagement with the target network. This could be port scanning, vulnerability scans, and other techniques which come at the risk of triggering some alarms or cause awareness on the targets side, assuming they monitor for such things.

In general active recon builds up on the passive recon and most often boils down to the following order of techniques:

  1. Port Scanning, to find additional an verify existing open ports
  2. Web Service review, to prioritize our targeting for an attack
  3. Vulnerability scanning

Port scanning can be done with a tool like Nmap, which is one of the most established and popular port scanners. The functionality is not simply limited to port scanning but also provides service detection, OS detection, and certain aspects of vulnerability scanning. There are also various other port scanning tools out there, such as Udpprotoscanner for UDP port scanning. For things like web service review there are tools such as EyeWitness, which can analyze a large amount of websites and providing a detailed report containing information about the header, screenshots, etc. to assist in the prioritization and identification of an ideal attack vector. This could as example be a web service page with an administrator login field.

Nmap Network Scanning

Lets have a quick look at the basics of port scanning with Nmap. As mentioned earlier Nmap delivers a vast array of functionality, but before we go any further we should understand the essentials. With nmap target we start scanning the ports on the target host. The results will then be categorized into one of six port states:

  1. open An application accepts TCP connections, UDP datagrams, or SCTP associations.
  2. closed Accessible but no application is listening to it.
  3. filtered Undetermined state due to package filtering, which obscures the results.
  4. unfiltered Accessible but undetermined if it is closed or open.
  5. open|filtered Undetermined whether the port is open or filtered.
  6. closed|filtered Undetermined wether the port is closed or filtered.
For more detailed information on these states and Nmap please follow the link below.

Virtual Network

In an earlier step we setup a Debian VM (Virtual Machine). But now would like to add an internal network to Virtualbox. We can do this through the following steps:

Step 1 - Create the network

In VirtualBox we choose the menu function Network --> Properties. We should see now our host-only network. If not then we should create one.

We use the manual adapter configurations as seen in the screenshot above. Diving into the DHCP Server tab we need to ensure that we enabled the DHCP server

Step 2 - Adding a VM to the virtual network

Before we add our VM to the host-only network we need to power it off. Once that is done we can select our VM and click the settings button, where we will navigate to the Network category. There we click on Adapter 2 and enable it. We configure it as a Host-only Adapter and choose the earlier configured network. It will look something like this:

Step 3

Lets boot now our VM and check out the situation. First of all lets make sure that we have the right network connection active. Since we configured a second one, we might have to switch over to the new one first (this was the case for me). After that lets run $ip addr to verify our IP address.

It looks like our IP is now 192.168.56.101 which matches the host-only adapter parameters we configured earlier. Now we can start adding other virtual machines to this virtual network or even connect to it from the host. I verified this quickly through PowerShell on my Windows Host, this way I can now utilize SSH directly to my VM.

Punchbag: Metasploitable 2

In this section we focus on the installation of a Metasploitable 2 practice target on VirtualBox. We will take advantage of our new virtual network and connect it to it. Now lets have a look at the step by step process.

Installation

First of all we will have to download the VMX. I did so from rapid7. Once that is done we can unzip the file and mount the VM in VirtualBox. To do in VirtualBox we click on New, give it a name, set the type to linux and version to debian 64bit, set our desired memory size, and last but not least we use the downloaded Metasploitable 2 file as our existing virtual hard disk file.

Configuration

We should then see the VM in our VirtualBox interface. So lets use our knowledge from step 2 from the Virtual Network chapter and change the Virtual Network Adapter to the same host-only adapter as our Debian VM. This time lets directly modify adapter 1 so that we do not have to mess around with 2 connections.

Now lets verify the IP from inside the VM as well as if it is reachable from the outside. The login info is msfadmin:msfadmin

and it appears that we can also reach it through our virtual network

Hello sploitable!

After the previous setup process, lets see if we can reach now the web interface of Metasploitable 2 from within our initial Debian VM which is part of the same virtual network. It should look like this:

Scanalyses

Now that we know that everything is up and running, lets try to run a port scan on Metasploitable 2 with the help of Nmap. Our first command will be $ nmap 192.168.56.102

Looks we have pretty much every port open that can be open. Not something we would like to see if we are in charge of IT security. An open port doesn't necessarily mean that we should immediately pull the ethernet cable from the server, but in some cases it might be just like that. Nevertheless, each open port means more attack surface, so we should keep them to the necessary minimum. Lets have a closer look the individual ports/services that we found with Nmap and the potential implications. I only list some of the potential attack vectors, there are a variety of other techniques and tools for each item listed.

  • Port 21 / FTP - Used for file transfers, if the FTP server has a vulnerability, this might be problematic. The protocol itself is rather outdated and insecure with no encryption. Rather risky. We could try if anonymous logins are permitted or brute force the password.
  • Port 22 / SSH - Used for the secure shell, this could lead to unauthorized login attempts. Could be dangerous if we aren't using key management. We could read out the encryption algorithm, read the host key, brute force the password, etc.
  • Port 23 / Telnet - This is an insecure and outdated relative of SSH. This is bad. We could run a brute force attack.
  • Port 25 / SMTP - Simple mail transfer protocol. In case this isn't secured properly we might have a compromised mail server soon. We can run a brute force attack, try to enumerate the users with VRFY, EXPN or RCPT TO commands, or use open relay to check if theres a vulnerability for mail relaying.
  • Port 53 / DNS - Nameserver port, this should only be open if we are running a DNS server with ingoing DNS queries. We can use this port to discover host services, cache snooping, checking the DNS zone config, etc.
  • Port 80 / HTTP - Commonly used by web servers for HTTP based requests for Web Pages. Theres no direct risk as long as the webserver is secured properly, which is often not the case. There are nearly endless potential attacks depending on the services running on the webserver.
  • Port 111 / RPCBIND - A port mapper. This should never be open to the internet since it delivers a rpc port map and has low security and a variety of other security issues. Very risky since we can potentially check the NFS mounts, get a port map, etc.
  • Port 139 / NETBIOS-SSN - Used for NetBIOS communication between Windows 2000 Hosts. It is an outdated protocol for printer sharing as well as file sharing. It is risky to have that open and we can discover the master browser and the managed domains.
  • Port 445 / MICROSOFT-DS - This port is associated with SMB (Samba) or more generic speaking file-sharing. This should not be open to the internet and is very risky since we can detect the OS version and target specific vulnerabilities.
  • Port 512 / EXEC - Used for remote execution. This should not be open to the internet. We can use it to find an open shell or brute force it.
  • Port 513 / LOGIN - Used for remote login. It is similar to Telnet, very risky and should not be open to the internet. We could use something like the rlogin authentication scanner or other vulnerabilities.
  • Port 514 / SHELL - Used for remote shell to send single commands to the remote server. Very risky and should not be open to the internet, we can use similar attacks like for port 513.
  • Port 1099 / RMIREGISTRY - Used for the Java Remote Object Registry. Very risky and we can potentially load remote Java classes from a remote URL and therefore execute remote code.
  • Port 1524 / INGRESLOCK - Very risky to be open. This is part of Ingres Database and can be used to lock parts of the Database or even gain access to the system.
  • Port 2049 / NFS - NFS stands for Network File System. A protocol that is used to in Linux systems for the sharing of files and directories. This is very dangerous and should not be open to the internet. There are a variety of vulnerabilities and we scan the port for exports, extract data, etc.
  • Port 2121 / CCPROXY-FTP This is a proxy server which can act as HTTP, mail, FTP and other servers. In this case we detected an open FTP proxy. This very risky since there are a variety of vulnerabilities available for the many outdated versions that can be found in the wild.
  • Port 3306 / MYSQL - This port belongs to MySQL and if it is completely open to the internet that is rarely a good idea. We can run brute force attacks, potentially extract hashdumps, etc.
  • Port 5432 / POSTGRESQL - This port belongs to PostgreSQL and when open to the internet we can try to brute force our way in, run DB name command line flag injections, etc.
  • Port 5900 / VNC - This port is for secure remote desktop access with VNC. This is rather risky if there are no authentication methods defined. We can also run an authentication scanner, and look for the VNC password in the default location.
  • Port 6000 / X11 - This is a communication protocol used by the X window system. This can be very risky, especially without authentication. We can use vulnerabilities like keyboard command injections, key sniffing, steal screenshots or video recordings of the target system, view it live, etc.
  • Port 6667 / IRC - IRC stands for internet relay chat. This can be very risky since there are multiple available exploits and vulnerabilities known which can deliver reverse shell payloads to the target.
  • Port 8009 / AJP13 - This is the Apache JServ Protocol which builds on top of HTTP. There are multiple known vulnerabilities available for outdated versions. As example we could extract files from the server with CVE-2020-1938 / Ghostcat.
  • Port 8180 / UNKNOWN - In this case the service is unknown.

As we can see in the list above, while some of the ports are justified depending on the functionality of the system, there a lot of things that should not be open to the internet. Among them Telnet, RMIREGISTRY, EXEC, SHELL, LOGIN, RMIREGISTRY, NFS, RPCBIND, IRC etc. These would be especially good targets for an initial path of attack, since they are either outdated, or should not be open to the outside world. Nevertheless, as with all of those ports it always comes down how well everything is configured, updated, and secured in an overall matter.

It's raining shells

Now after all the recon we are ready to get our hands dirty. Let us try to break into Metasploitable 2 and use the intel from our port scan as a base for further attack. Lets start testing if FTP allows anonymous logins with the following command nmap -sV --script ftp-anon -p 21 192.168.56.102. Bingo seems we already found the first huge problem.

Lets see what else we can do. How about giving RMIREGISTRY a try. We will use the following command nmap --script=rmi-vuln-classloader -p 1099 192.168.56.102. Ups that doesn't look very good.

What about EXEC on Port 512? That must be secure right? Lets try a simple brute force attack with nmap -p 512 --script rexec-brute 192.168.56.102. Oh no what is this?

As we can see there are plenty of ways to attack such unsecure targets.