Top 10 Vulnerabilities 2019-2020: Internal Network Pentest

The following information was compiled from more than 60 penetration test reports that have been produced during the year of 2020 and 2019 for various mid-sized organizations and businesses from around the world.

Top 10 vulnerabilities

The list is organized from the bottom (top 10) to the top 1.

10. Weak and default passwords

Hunting for weak and default credentials should be part of every decent penetration test. And in our case it was no different.

It sounds easy, fun and kinda exciting, doesn’t it? The reality is that without a sound automation the excitement fades away really quickly. And the automation doesn’t always work 100%!

Hunting for weak and default logins can be quite a labor and often times involves debugging and troubleshooting the automation, if we really want to cover the whole surface. Manual approach in most cases is extremely ineffective and tiring.

Luckily, there are many tools out there that can help in this area. And this makes it quite rare to not find any weak or default credential during a pentest. Thus, this finding made it to the Top #10.

One of the tools that always helps us to find default credentials is our hunter of default HTTP logins.

For other network services such as database interfaces, SSH, Telnet, SNMP and other services, we usually leverage Metasploit, Hydra, Medusa, Ncrack or similar tools capable of login attacks.

9. Outdated VMWare ESXi hypervisor

Most organizations heavily virtualize their infrastructure. It is not only cost-effective, but also practical.

The top virtualization solution that our customers use the most is the VMware ESXi platform and, surprise surprise, it rarely gets patched on time.

So that’s how this ended up being number 9 in our Top 10 list.

Although unpatched VMware ESXi servers are on the Top 10 list, it is rare to encounter such an outdated instance for which there would be publicly available exploits.

Usually this vulnerability is picked up by the Nessus vulnerability scanner.

8. Reuse of passwords

Every time we find a working credential, we try to reuse it elsewhere. And it turns out a lot of organizations are reusing passwords.

In fact, almost 4 organizations out of 10 are affected by this. It is just very difficult to really enforce proper procedures when it comes to password management and asset management.

Typical scenario is when a Windows machine gets compromised. What usually happens next is that the pentesters will collect password hashes (NTLM) from the system or flat out dump the plain text passwords from the LSASS subsystem using Mimikatz.

The pentesters will then perform password spraying or hash spraying over the network to see whether it works on some other machines as well. Here’s an example of using Metasploit smb_login scanner for the job:

SMB password spraying with Metasploit

But this is just one example. Passwords are reused across different systems, network appliances and more. Every password compromise usually leads to a cascade of other compromises.

7. Insufficient Network Segregation

Most organizations also have problems with proper network segregation and separation into VLANs.

A typical example is when the assessment is performed from a perspective of a standard non-privileged user (a typical employee). What can the employee see on the network? What systems can the employee reach?

For instance, why should the employee be allowed to access remote desktop (RDP) of the domain controllers? Why should the employee be allowed to reach various database interfaces? Or SSH servers?

We always advice our customers to isolate everything as much as possible in according to the principle of least privilege. But it just happens to be a problem for a lot of organizations.

6. IPMI password hash disclosure

More than 40% of the tested organizations were found to be prone to the IPMI 2.0 password hash disclosure vulnerability.

This vulnerability is basically a design flaw in the IPMI (Intelligent Platform Management Interface) protocol and there is no patch for it.

The IPMI service usually listens on port udp/623 alongside of the management web interface itself (e.g. Dell iDRAC, HP iLO etc.).

Now if we are able to reach the IPMI service, we are definitely going to be able to dump the password hashes from it. Here’s an example of using Metasploit ipmi_dumphashes scanner:

IPMI v2 password hashes obtained using Metasploit ipmi_dumphashes

If the passwords are weak, we can then easily crack them, for instance with John the Ripper:

IPMI v2 password hashes cracked with john-the-ripper

Nessus vulnerability scanner usually detects this vulnerability during the scans, but it’s always good to use the Metasploit ipmi_dumphashes scanner as well and try to crack the hashes.

The only mitigation strategy for this vulnerability is to disable the IPMI service or to isolate it on the network level (proper network segregation).

5. SMB 1.0 protocol

Another thing that is just chronic to a lot of networks is the support of SMBv1 on Windows systems.

There are usually always some systems in the network still supporting the version 1 of this nearly 40 years old protocol.

SMBv1 is inherently insecure and it is prone to multiple vulnerabilities including:

  • Remote code execution (RCE)
  • Denial of Service (DoS)
  • Man-in-the-Middle (MitM)
  • Information disclosure

Even Microsoft advises against it. SMBv1 should be simply disabled on all Windows systems, both servers and clients.

This vulnerability is usually picked up by the Nessus scanner, but it can be also identified using Nmap’s smb-protocols NSE script:

SMBv1 protocol identified using Nmap smb-protocols NSE script

4. NetBIOS over TCP/IP enabled

This issue has been found in more than 50% of all tested organizations. Here’s the problem:

ipconfig command showing that NetBIOS over TCP/IP is enabled

This setting is enabled by default on all Windows systems and it inherently opens up the network to man-in-the-middle (MitM) attacks.

The problem is the following 2 Windows protocols:

  • NBT-NS: NetBIOS Name Service
  • LLMNR: Link-Local Multicast Name Resolution

These protocols communicate on the broadcast addresses, which makes them prone to poisoning and replaying attacks. And these attacks are very easy to do thanks to the tools such as Responder, Inveigh or Impacket (and its ntlmrelayx.py script).

These tools automatically respond to the broadcasted requests sent by the victims. This can consequently result in capturing Net-NTLM password hashes or even directly accessing other systems in the network by replaying the authentication.

Here’s how poisoning typically looks like using Responder, which results in capturing Net-NTLM hash:

Capturing NetNTLM hash with Responder NBT-NS LLMNR poisoner

Now if the password is weak, we can successfully crack it:

NetNTLMv2 hash cracked with john-the-ripper

Now we’ve got a domain user account and we can start enumerating the Active Directory. But that’s another story..

3. Unpatched Windows systems

Very few organizations have patching policy so well under control that they wouldn’t have any vulnerable Windows system in their network.

In almost 60% of cases there were found Windows systems in the network lacking a critical security patch, or two. Some examples include:

  • CVE-2020-0796 aka. SMBGhost
  • CVE-2019-0708 aka. BlueKeep
  • MS17-010 aka. EternalBlue
  • MS16-047
  • MS15-034
  • etc.

These issues are typically picked up by the Nessus vulnerability scanner, however Metasploit and Nmap also contain functionalities to remotely detect some of the missing patches.

These vulnerabilities are usually ranked as critical since they allow to obtain remote code execution (RCE) on the target system with the highest privileges (nt authority\system):

Using MS17-010 EternalBlue exploit results in RCE as nt authority\system

2. Default SNMP community strings

The second place belongs to the default SNMP community strings. What are SNMP community strings, you may ask?

The SNMP protocol is a diagnostic protocol which can disclose vast amount of information about the target system:

SNMP default community string enumeration using snmpwalk

The problem is that the SNMP community string (“public” in our case) is the only means of authentication. So if an attacker can guess the SNMP community string, he/she can learn detailed information about the target system and plot further attacks against it.

Note that this applies only to the SNMP version 1 and 2 – SNMP version 3 uses stronger authentication mechanism with encryption.

This issue is typically picked up by the Nessus vulnerability scanner, however much better results can be obtained using the Metasploit snmp_login scanner.

The Metasploit smb_login scanner checks for more than 120 default community strings and can also detect whether the obtained access is read only or whether we can also write and modify some of the settings of the affected system.

1. Clear text protocols

The number one vulnerability reported in more than 60% cases is the usage of clear text protocols.

Every time we detect usage of clear text protocols or we find network services that use clear text protocols, we report them to the customer.

This includes protocols such as:

  • FTP (tcp/21)
  • Telnet (tcp/23)
  • SMTP (tcp/25) if it supports plain authentication
  • HTTP (tcp/80, tcp/8080 etc.) if there are login functionalities
  • POP3 (tcp/110) if it supports plain authentication
  • IMAP4 (tcp/143) if it supports plain authentication
  • SNMP (udp/161, udp/162) version 1 or 2
  • LDAP (tcp/389)
  • VNC (tcp/5900)
  • etc.

These protocols are inherently insecure due to the fact that they do not encrypt the communication. Any well positioned attacker who can eavesdrop on the communication can capture sensitive information traveling through the network.

See here how easy it is to capture passwords using a packet sniffer such as Wireshark.

Leave a Reply

Your email address will not be published.