Have you ever wondered what are the most common vulnerabilities found during penetration tests? What are some of the typical security problems of corporate networks?
In this article we will be going through the Top 10 list of the most reported vulnerabilities during internal infrastructure penetration tests.
Disclaimer
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.
Before jumping to the list, let's briefly describe the testing methodology that was used across the board.
Methodology
The objective was to perform an internal infrastructure penetration test, physically on site, using a white-box (grey-box) approach.
This means that there were no restrictions on the tools being used for the testing and the scoping information was also shared beforehand.
The only "grey" aspect of it was that in the beginning the access to the network was not provided to the consultants.
So after the initial assessment of the network access controls (NAC bypass, WiFi assessment etc.), the consultants were typically whitelisted in the network in order to perform the actual test without getting blocked on the network level.
The testing was then performed from the perspective of a typical employee / non-privileged user on the network.
This methodology is one the most popular choices due to its cost-effectiveness. It allows to focus on the actual vulnerabilities rather than trying to circumvent existing security or compensatory controls that might be implemented.
Found this the other day on Twitter that kinda illustrates the point:
So what were the most reported vulnerabilities? Here goes the list..
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 with default passwords. 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.
Go back to top.
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.
Go back to top.
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:
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.
Go back to top.
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.
Go back to top.
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:
If the passwords are weak, we can then easily crack them, for instance 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).
Go back to top.
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:
Go back to top.
4. NetBIOS over TCP/IP enabled
This issue has been found in more than 50% of all tested organizations. Here's the problem:
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:
Now if the password is weak, we can successfully crack it:
Now we've got a domain user account and we can start enumerating the Active Directory. But that's another story..
Go back to top.
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-2021-26855 aka. ProxyLogon
· 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):
Go back to top.
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:
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.
Go back to top.
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.
Conclusion
So there you have it – an actual Top 10 list of vulnerabilities reported during internal infrastructure penetration tests.
Has it surprised you? Or disappointed you? How does your Top 10 look like? Please share your thoughts and experience in the comment section down below.
If you have enjoyed this article and you would like more, please subscribe to our mailing list and follow us on Twitter and Facebook to get notified about new content.
0 Nhận xét