>home_lab_mk3

A Home Lab is Where the Heart Is

A home lab can be many things. At its core, it is a made up of the device or devices that you use practice and hone your IT skills. The important part is that you use it to learn. You can get an old laptop, install a Linux distro of your choice and just learn; learn Linux; install Wireshark and packet tracer to learn networking; install DVWA and learn penetration testing. This is one of the laptops I still use to practice with. The screen and keyboard were broken and it cost $20. With the addition of a $30 SSD, a keyboard and old monitor I had sitting in a closet, it works fine for running Kali or being the victim when I practice WIFI attacks.

Home Lab Mk3

This and many articles to follow will cover the third iteration of my cyber security home lab. For the hardware I am using some second-hand enterprise servers. I picked up a pair of HP DL380 Gen 8 Servers about two years ago for $600. I have used these to run services for my home as well as for my cybersecurity lab. I have also picked up a few different pieces of enterprise switches and routers for $40 to $120 each. Before you run out and buy enterprise gear, do some research, define your needs and your price range. I have seen plenty of posts for a whole pile of equipment in a rack for $1000 but with further research you find that it is worth the cost of scrap metal because it is so old. You could still probably learn a lot on it, but there are better options to be had.

For software, I am running VMWare ESXi on the servers and VMWare Workstation Pro on my laptop. There is a cost for this software, but there are other free options. Check the Tools & Resources section from some other virtualization ideas.

Lab Design

This lab will be run in a vlan and subnet that I have segregated from the rest of my home lab with my main router’s firewall rules. I am not going to get into the design of my overall network, but from the perspective of a machine in the lab, there is no other network. Traffic will make hops through a virtual switch, a virtual router, and a physical switch, before reaching the gateway router. This network segment will be broken into three subnets; a DMZ, a management network, and a client network. NOTE! “management network” is probably a bad name choice because that is used to refer to an out of band network that access the management interfaces of network equipment.

For now, the DMZ will host two servers, an instance of Metasploitable 2 and a WordPress site from TurnKey Linux. The management network will host a Windows Server 2019 Active Directory Domain Controller and an instance of Security Onion to act as a SIEM. Finally, the client network will include various Windows versions from XP to 10. I will most likely add a mail server as I continue to build this out. All of these networks will be defined by a PFsense machine that will act as the Firewall and router for this network.

This network diagram that shows the several subnets and their organization. A network tap or Span Port will be installed on the PFsense machine and connect to Security Onion to have access to all of the external network traffic. At some point in the future I would like to build something similar on a web hosted VPS and expose the DMZ directly to the internet but for now I am content to hide this behind two firewalls.

I will be using a Kali Linux VM as my attacking machine from an external network location. I have also installed a SIFT Workstation that comes loaded with a wide variety of forensic analysis tools. I don’t have any experience with SIFT yet so I am looking forward to learning more on that front.

>securing_metasploitable_1

Network File Share (NFS)

This is the second in a series of posts based on an assignment I had. Phase one is to exploit a vulnerability in Metasploitable 2. Phase two is to secure that same vulnerability.

Exploiting NFS

My next target was NFS hosted on port 2049. I installed rcpbind and ran the command rcpinfo -p 192.168.211.148 to show the running services and the command showmount -e 192.168.211.148 which identified that the entire file system was mounted as a file share.

With access to the root file system, the student’s objective was to put an ssh key into the authorized_keys file to ensure later access. The student first generated an ssh key with the ssh-keygen command. WARNING: If you post a private key out in public like I do below, make sure to delete it.

Next, I mounted the NFS to the attack system with the command mkdir /tmp/r00t to create a mount point and sudo mount -t nfs 192.168.211.148:/ /tmp/r00t to mount the share. Navigating to this folder and checking the directory contents showed it was successful.

Next, I attempted to append my newly minted SSH key to the authorized_key file with the command sudo cat /tmp/r00t/tmp/metassh_key.pub >> /tmp/r00t/root/.ssh/authorized_keys. This action was not allowed, so I copied the key and pasted it directly into the file with the nano file editor using the command sudo nano authorized_keys.

Finally, I was able to gain remote root access using the command ssh -I metassh_key root@192.168.211.148. Figure 15 shows the command and root access.

Securing NFS

The next vulnerability I set out to secure was the NFS root mount. My primary objective was to change the shared directory in NFS. First, I created a new directory to share with the command sudo mkdir /mnt/nfs_share. I then made these files accessible to any connected users with the commands sudo chown nobody:nogroup /mnt/nfs_share and sudo chmod 777 /mnt/nfs_share. WARNING: This is not a best practice: chmod 777 gives read write and execute permissions to all users and groups. Read and write should have been used 666, 664, or 644. For more on Linux permissions check out this post on https://linuxize.com/  

Next, I modified the /etc/exports file with the command sudo vim exports. This file showed one share for the root file system. I commented out this line by adding a “#” character and added a new line /mnt/nfs_share *(rw,sync,root_squash,subtree_check,secure). Compared to the previous entry the new line included three additional options. The “root_squash” option stops an external root from having root privilege in the share. The “subtree_check” option helps ensure that a user cannot break out of the shared folder. Finally, the “secure” option forces a connection on a port of 1024 or lower where it is harder to spoof root privilege.

Next, I stopped and restarted the export using the commands sudo exportfs -ua and exportfs -a.

The fix was validated on the attacking Kali machine with the command showmount -e 192.168.211.128 and mounted using the command sudo mount -t nfs 192.168.211.128:/mnt/nfs_share /tmp/test. I validated that the new share only had access to the identified directory, not the entire root directory.

>securing_metasploitable_0

>setup && Rlogin

This series write-ups follows two assignments I completed as part of a class I was taking last year. It covers several good lessons related cybersecurity. The first assignment involved exploiting vulnerabilities found in Metasploitable 2, a purposefully vulnerable VM. The second assignment involved securing those same vulnerabilities. This is an important aspect of cybersecurity that can be ignored by those just beginning their study by the more interesting world red team tactics. Learning how to harden operating systems and minimize vulnerable services while still maintaining the operational objective of the machine is an important skill.

Lab Setup

For these attacks I used a Kali Linux VM against a Metasploitable 2 VM both running on VMware Workstation. After installing or booting both systems, the first step was to validate that they could communicate. In Metasploitable, the Command ifconfig will display information on the network interface. Below we can see information on the interface eth0 and the IP address under inet addr: 192.168.1.57.

On the Kali VM, I use the more current command ip addr. Again, we look for eth0 and see the IP under inet 192.168.1.56. Without going into a full article on networking, it is common in a home network that if the first three numbers of the IP address are the same, the machines are in the same network.

We can test that they can communicate with a ping test. Ping sends ICMP message to a target IP address and expects a response. If the other machine is on a network that can be reached and is not blocking ping requests, it will respond. On the Kali Machine, the command ping -c4 192.168.1.57 is used to send four packets. The four responses return very quickly.

The next step is to enumerate the vulnerabilities on the target machine. For this case, I used a basic nmap scan. Nmap is very powerful and can collect a lot of information on the target machine. They are many different scan types and it is a critical tool for a variety of hacking and networking tasks. This scan shows many open ports on the target machine.

The basic nmap command scans the 1000 most common ports. Conducting a second scan and specifying to scan all possible ports with the -p operator found five additional ports.

Enumeration can be a very involved task. This shows only the most basic example. Learning how to use nmap, wireshark, burpsuite, your web browsers developers’ tools and google will help you better enumerate a target machine’s vulnerabilities.

Exploiting Rlogin

Note: I switched around some configurations in the network so the IP addresses have changed from the first section.

For the first attack, I chose rlogin on ports 512, 513, and 514. Rlogin has been replaced by SSH. Rlogin suffers from a variety of vulnerabilities and should simply not be used. It sends authentication information in the clear and uses IP based authentication based on the .rhosts file. I attempted to connect to all three rlogin ports on the older Kali build but successfully connected only to port 513 with the command rlogin -p 513 -l root 192.168.211.148. I immediately gained root access to the target machine with this command.

With root access, I copied the contents of /etc/passwd and /etc/shadow. These were both printed to the screen using the commands cat /etc/passwd and cat /etc/shadow. The contents were copied into passwd.txt and shadow.txt files with the right-click copy and paste commands. Additionally, I extracted the password hashes from the shadow.txt file into a hashes.txt file using copy and paste. These password hashes will come in handy later for getting into the system another way.

“Securing” Rlogin

The only real answer to securing Rlogin is to remove it and use SSH. However, my goal was to secure the specific vulnerability I had exploited. Because I got root access without having to sniff a password or spoof an IP address, I assumed that there was a problem with the hosts.equiv or .rhost files used to identify authorized IP addresses.

I navigated to the /etc directory used the command cat hosts.equiv to review the contents of hosts.equiv. I found the string “+ +” which allows trusted authentication to any user attempting to connect through the Rlogin service.  The student created a file backup using the command cp hosts.equiv hosts.equiv.bak before editing the file with the command sudo vim hosts.equiv and removing the string from the file. I attempted to log in as root again and was successful.  Next I searched for any .rhosts files with the command sudo find ./* -name .rhosts. This command found two versions of the file in the /root and ~/msfadmin user folders. The cat command on each file revealed that they contained the “+ +” string. I modified one file with the command sudo vim .rhosts and removed the string. Next, I used the commands rm /root/.rhosts and sudo cp .rhosts /root/.rhosts to delete the second copy and replace it with the newly modified file. I was no longer able to simply login with no authentication.

Again, while I closed one vulnerability, many remain and this program should simply be removed. One thing that should be considered when securing vulnerabilities is what other impacts with this create. Some services have other dependencies. Securing a vulnerability can impact these other systems. One benefit of virtualized environments is that changes can be tested before they are moved into production.

>touch home_lab

This post will be the first in a series where I discuss building a home lab to study offensive and defensive cybersecurity. Building a home lab has been the best decision I have made to help improve my technical skills. I have learned how to build and break Linux machines, become comfortable using the command line interface, and watched packets fly back and forth across my network.

When people begin researching a home lab, they may find sites like Reddit’s r/homelab. Some of the more impressive setups use enterprise servers and networking gear that could support a medium-sized office. A lab of that nature would undoubtedly be awesome to own and operate. However, all you need is a computer with some unused compute cycles as a beginner. For anyone reading this on a low-end laptop with no resources to get a better rig, there are a ton of free online resources as well. I will do another post on those resources soon. For now, check out the tools_resources page for some ideas.

The two primary types of home lab I will focus on are computer-based and networking-based. There are many other types of labs designed to support various other interests. Radio labs and hardware labs are common as well.

Computer labs support many objectives, such as testing new code or websites. They can be used as sandboxes to study malware. They can act as actual home servers to provide services such as email, media streaming, git repositories, data storage, or a myriad of other services. I currently run a few home services, but the primary focus of my home lab posts will be for offensive and defensive cybersecurity.