Every institution should have an internal penetration test performed annually. The goal of the penetration test is for the tester to try to gain administrative access to the network. In our experience, good testers can achieve this goal over half the time. In almost every case where testers gain access, they take advantage of vulnerabilities that institutions already knew about but put off remediating because they are rated only a moderate risk in the vulnerability assessment. By focusing on remediating these vulnerabilities, institutions will have a better chance of passing their next penetration test.
The first set of vulnerabilities have to do with something called “SMB”. SMB stands for “Server Message Block”, and it is the protocol used to manage file access on a network. SMB is what makes it possible for you to access files without having to enter your password for each file. The problem is that an unsecure implementation of SMB allows a penetration tester to impersonate you and access your files. If the tester can impersonate a network administrator, they can gain administrator-level access using these vulnerabilities. The most common SMB vulnerabilities are allowing old versions (SMBv1 is now 41 years old and is full of vulnerabilities) and not requiring SMB signing. Disabling older SMB versions and requiring signing greatly reduces the risk, but there is a slight chance remediation could also break something. In general, you should seriously consider replacing anything that breaks when trying to remediate SMB vulnerabilities.
The second set of vulnerabilities pertain to protocols called “Link-Local Multicast Name Resolution (LLMNR)” and “NetBIOS Name Service (NBT-NS)”. These are old services (dating again to 1983) that allow devices to find each other and communicate directly with one another on the network, and they were historically used to communicate with printers, scanners, and other network devices. The problem with these protocols is that they pass an encrypted version of the user’s password (known as a “hash”), and that it is easy for a tester to trick a user workstation into using the protocol to communicate with a machine the tester controls. This makes it possible for the tester to obtain the hash and decrypt it using high-powered computers. If the password belongs to an administrator, the. tester now has full administrative access. There are few systems today that require these protocols, so they can normally be turned off safely (but test to make sure!). Again, you should seriously consider replacing anything that breaks when trying to disable LLMNR or NBT-NS.
The third set of vulnerabilities relate to the “NT Lan Manager (NTLM)” protocol. First created in 1993, NTLM is newer than the previous protocols covered in this article but is still 31 years old. NTLM at one time was the default authentication protocol for Windows but was replaced by “Kerberos” as the default in 2000. Older versions of NTLM are very vulnerable to “Pass the Hash” attacks (this is where a tester can find a hash file on a computer, then pass that hash file to another system to trick it into thinking the tester is an authenticated user). Some systems still rely on NTLM for authentication today, so turning it off can be challenging. Recently, Microsoft announced that they are now working towards eliminating NTLM support from all future Windows systems. It is important to pay attention to and remediate any NTLM vulnerabilities in your environment to ensure that the attack surface is as small as possible. You should also start identifying systems that rely on NTLM so that you can work towards a future without this protocol.
The last set of vulnerabilities have to do with IPv6. While everything we have talked about so far has to do with getting rid of older protocols, battling IPv6 vulnerabilities requires not using future technologies. Every device on the Internet has a unique IP address. The original IP addressing scheme (called IPv4) allowed for just over 3.7 billion devices to be connected to the Internet. This is nowhere near enough to accommodate all the devices that need to be on the Internet, so in 2012 a new scheme called IPv6 was introduced that increased the number of supported addresses to 340 undecillion (that is 340 with 36 0’s after it!). While this is great for the expansion of the Internet, managing the risks of IPv6 on an internal network is difficult because most of our security tools are built for the older IPv4 scheme. Testers know this, and if they can use IPv6 on your network will use it to get around controls and your ability to detect them. It is recommended that you configure your network devices to always use IPv4 instead of IPv6 so that testers cannot use IPv6 against you.
While penetration testers are always finding new ways to get in, remediating the above vulnerabilities will turn your test from an “easy win” for the testers into a challenge. If you need further advice regarding how to protect yourself, or with any other cybersecurity topic, please contact us at support@bedelsecurity.com.