This documentation will summarize the actions performed within the entirety of this project and will elaborate on changes made to the original Project proposal. Each device will be walked through sequentially followed by the exploit steps and remediations.
Switch 0 was configured with default settings except for Switchport security. Switchport security was enabled for Interface F1/0/2. the maximum device count was set to one for this interface and the violation mode was set to shut down.
Router 0 was configured with two IP addresses. the first, 192.168.10.1/24 was set to the Ge0/0 interface and the second, 10.0.0.1/30 was set to the Ge0/1 interface. a DHCP helper address was defined as 10.0.0.2. RIP routing was configured on the Router with networks defined as 10.0.0.0 and 192.168.10.0. a username and password were also set on the router for local log in.
Router 1 was configured with two IP addresses. the first, 10.0.1.1/30 was set to the Ge0/0 interface and the second, 10.0.0.2/30 was set to the Ge0/1 interface. A DHCP server was also configured on R1. This server provided IP addresses to end devices connected to S0 and S1 on client sides of R0 and R2 respectively. Two DHCP pools were made on the router named R0 and R2. the IP pools were set up to exclude the first 10 addresses of each subnet respectively. RIP routing was configured on the Router with networks defined as 10.0.1.0 and 10.0.0.0. a username and password were also set on the router for local log in.
Router 2 was configured with two IP addresses. the first, 192.168.20.1/24 was set to the Ge0/0 interface and the second, 10.0.1.2/30 was set to the Ge0/1 interface. a DHCP helper address was defined as 10.0.1.1. RIP routing was configured on the Router with networks defined as 10.0.1.0 and 192.168.20.0. a username and password were also set on the router for local log in. SSHv2 was also configured on Router 2 with log in set to local.
Switch 1 was configured wit hall default settings and acted mainly as a “dumb” switch to connect multiple devices to the same network interface on Router 2. to verify the settings were at default, a reset was performed on the switch.
All end devices on the network were configured to use DHCP dynamically assign IP addresses to them as they were connected to the network. PC2 NIC 2 and PC3 are located on external networks and had prior static addresses assigned to them within the user’s home network.
Exploit 1, Cracking Cisco passwords from running configuration:
Exploit 1 was originally outlined to use John the Ripper to crack an MD5 hash of passwords located within the running configuration of a Cisco router. Upon implementing this exploit, it was discovered that the routers obtained for this project only supported Cisco 7 passwords. these passwords are fully reversible and therefore John the Ripper could not be used. upon some research, a Python script was discovered that could reverse Cisco 7 hashes and return plaintext passwords. This script was downloaded, and the instructions were followed within the script’s “readme” file. Using the script, the hashes were successfully cracked. When remediating the exploit, things went as planned and an FTP server was set up to back up the running configuration of R0.
Exploit 2, Using MacChanger to bypass switchport security:
Originally in the project proposal, a Kali Linux VM was slated to be used to bypass switchport security using MacChanger. After implementing the exploit, it was found that the Spoofing of the Mac address did not bypass switchport security. Upon further investigation, it was discovered that MacChanger will not spoof the mac address of the host machine when running in a VM. To fix this, a live boot of Kali Linux was installed on a Flash drive and PC1 was booted into a live version of Kali Linux. MacChanger worked successfully and Switchport security was successfully bypassed.
Exploit 3, Using Hydra to brute Force SSH credentials:
The SSH server on R2 was tested using putty from a Windows 10 machine. This SSH configuration worked as anticipated. However, upon attempting to SSH to the box from the Kali Linux VM located on PC2, it was discovered that the Key exchanges offered by R2 were out of date and antiquated to the point of not being accepted by Kali Linux. The machines could not talk to each other as they did not have any encryption methods in common. With some research, it was discovered that Key algorithms could be added to Kali Linux. The Diffie Hellman Sha1 Key exchange was added to Kali Linux and the issue was resolved. The Hydra attack worked as anticipated once this change was made. Once the Hydra attack was complete, a more complex SSH password was set on R2 and the Hydra attack was run again. This time Hydra failed to find a password and exploit 3 was considered remediated.