CYBE231 Lab 5 - Auditing and Remediation of Vulnerable Systems
Most systems out of the box have a large amount of logging going on to help keep the system secure, and to help find issues with the system. In this lab we were given console access to the machines we were exploiting in the past weeks to take some time to investigate logs, and upgrade the security policy on some systems.
The first system we took a look at was the Windows 10 box that we passed hashes to get into. We logged into the machines with the cracked password for Administrator. After we logged into the system, we opened Event Viewer and started looking for logs with the event ID of 4624 which is the ID for a successful login. Moving back some time, we were able to find when we logged into this machine by passing the NTLM hash from the Kali machine.
While this ability to login with hashes can be useful for older Active Directory setups, and using a computer remotely without sending passwords across the network. With a just a single machine or two, this is a security flaw though. Unfortunately, in Windows this ability to use hashes is enabled by default, and must be disabled with the Windows policy editor. In the Windows policy, after stepping through multiple levels of menus, we got the “Security Options” tab of the “Local Policies” section. We set it up to restrict incoming NTLM connections, to prevent others from connecting into the machine, but did not prevent outgoing connection if they were needed. We then attempted to pass the hash from the Kali box again, with it failing and showing up in the logs. This was not the only policy we changed though, we set up stricter password policy requirements, as the default Windows policy has no requirements for passwords.
The next step that we took was hardening the firewall on the router. It is forwarding telnet requests from the internet, which is rather dangerous since telnet is an insecure, and outdated protocol. We disabled this forwarding from the WAN, and made it only available on the LAN. We then logged into an Ubuntu 12.10 box that was behind the firewall, and saw it was hosting a database for its web server available to everyone on the local network. So we set host based firewall rules to deny traffic on that port and prevent unauthorized access to the database. This was not all we did on that system though. Since the system was on a rather old version of Ubuntu 12.10, so we are going to update it to Ubuntu 13.10. Since this is a long outdated version the official update tool no longer works, instead we had to update the sources list with a downloaded version ourselves, alongside downloading and installing a few packages that were needed to update properly. This took a while, as it involved installing quite a large number of packages, but after some time it was done. After a reboot, we could see that sysetm had updated, and the DirtyCow exploit that had worked prior no longer works.