10 Most Common Vulnerabilities Found in Pen Tests

This is a vulnerability we often identify in web application tests.  ‘Injection attacks’ can include a number of attack types, such as cross-site scripting (XSS) , HTML injection, structured query language (SQL) injection, Host Header Injection, and XML injection.  These attacks are typically brought about by users inputting unexpected characters, commands, etc. into the application which can result in the application also behaving in an unexpected way.

Successful injection attacks can have serious consequences, such as the web application becoming compromised, the compromise of other users’ accounts and data, database compromise, and code execution on the underlying server.

This is a common finding for web application penetration tests when the application being tested allows you to upload files such as a CV document, profile picture, etc.  If there is no control over what files are being uploaded on the server, this can have a significant and negative impact and, in some cases, can lead to code execution on the server itself, malware distribution (as files are uploaded that someone else can then download), denial of service (DoS), and, if there are no restrictions on the size of the files users are able to upload, slowed system resources if a user uploads an extremely large file.

Controls over file uploads can and should be built into a web application; file uploads are a user input and, like any other user input, should be validated, sanitised and processed in a secure manner.  If you use third-party web applications, you will need to ensure you receive all of the necessary assurance from the vendor that the product you are subscribing to/purchasing is secure in this respect.  To do so, you could ask the vendor to provide you with a pen test report that has been performed on the application, any certifications it may have, or you could ask the vendor if you can perform a pen test on the instance they provide to you.

Legacy Link-Local Multicast Name Resolution (LLMNR) protocol and NetBios Name Service (NBT-NS) protocols are both legacy name resolution protocols which we sometimes find organisations fail to disable, as it provides them with backup name resolution protocol that can be relied on if the main ones fail.  However, these are usually not required due to their legacy status, and come with risks attached.  LLMNR and NBT-NS can make man-in-the-middle (MitM) attacks possible, as threat actors can control name resolution in the network and trick other hosts to send traffic through an attacker-controlled machine.  This would allow the threat actor to obtain usernames and NTLMv2 hashes, which can be cracked to obtain the plaintext password and relayed to access and execute code on another system in the network.

Server Message Block (SMB) signing is a mechanism which prevents certain types of attacks from being successful, and these attacks are typically the relay of credentials within an internal network.  While SMB signing is often enabled, it is not always enforced, and this frequently comes up as a finding in internal infrastructure penetration tests due to the fact that SMB is a service that should never be exposed on the internet, but typically is exposed on the internal network.

When SMB signing is enabled but not enforced, attackers will be able to perform MitM attacks, exploit a different vulnerability and then capture and relay credentials to affected servers.  This can lead to the disclosure of sensitive information or compromise of the host if admin credentials are relayed.

In both internal and external infrastructure tests, as well as in web application testing, we will often identify the use of the cleartext protocol within a network, meaning that data is transmitted without encryption.  Typical protocols we find in use include HTTP instead of HTTPS or telnet, Simple Network Management Protocol (SNMP) version 1 and version 2, FTP and TFTP, among many others (although those listed are the protocols we most commonly see).  Here, the main risk is, again, the disclosure of sensitive information and MitM attacks. However, in this case, the weaknesses are much more exploitable as an attacker will not need to break any encryption.  If an attacker is well-positioned and has access to the traffic that goes from a client to a service without encryption, they will be able to obtain any information being transmitted.

A brute force attack is the (generally automated) practice of attempting many passwords against a login page until the correct password is guessed.  An organisation has insufficient brute force protection if an attacker can attempt a brute force attack without either being delayed (by login throttling, which enforces a delay between one failed login attempt and the next), experiencing account lockout (where an account becomes locked after a certain number of failed attempts), or if it has not implemented multi-factor authentication (MFA).  When paired with a weak password policy, a lack of these protection mechanisms significantly increases the risk of a successful attack.

Certain services do not need to be accessible by anyone on the internet or by everyone within your network, however it is not unusual for our testers to find these services being unnecessarily exposed to the internet by organisations.  Sometimes, unnecessary or administrative ports will be exposed to the internet, such as Remote Desktop Protocol (RDP), SNMP, Secure Socket Shell (SSH), and Extensible Messaging and Presence Protocol (XMPP), as well as the administrative login interface for web applications (e.g., WordPress admin login).  By exposing these services, you will increase the size of your attack surface unnecessarily and increase an attacker’s chances of being able to gain unauthorised access.

In the bronze medal position is something we invariably identify when conducting penetration tests of both internal and external infrastructure, and of web applications.  In terms of external infrastructure, we will more often see this on the management interfaces rather than the publicly exposed, WordPress side, as organisations will generally understand that these areas are critical and more easily accessed by users, so will pay greater attention to their security.   However, we have seen certain telephonic protocols/systems being (perhaps mistakenly) exposed on the internet with default credentials in use, as well as management ports for network devices on non-default ports.  The majority of these findings are on internal networks, as organisations will develop a false sense of security due to these networks only being accessible by staff members.

The administrative interfaces for printers and scanners will sometimes have a weak/default password, or even no authentication at all, which allows attackers to gain access to the device settings simply by browsing the administrative page.  Organisations sometimes assume that unauthorised access to devices like printers and scanners carries little to no risk, however this is not necessarily the case.  Meanwhile, default credentials on heating, air conditioning, and CCTV systems are also extremely common.

As mentioned above, network devices can also be a source of issues here.  Within the internal network, we sometimes find Tomcat Manager being used with default credentials, and weak passwords used for Active Directories by domain users.  On web applications, a greater emphasis is often placed on usability than security, resulting in the applications allowing users to set weak passwords which are easily guessed by a malicious actor.   SNMP public/private community strings can also allow attackers to gain access to network devices’ or other devices’ configurations.  

The use of default/weak passwords can provide a foothold for threat actors to gain access to your network.  On the external side, if a domain user of a company that utilises (for example) Microsoft 365 has a weak password, an attacker can perform a password spray against the login page and subsequently gain access to sensitive information.  Meanwhile, some printers and scanners will allow you to send scans to your email address using an Active Directory credential, which can be obtained by a threat actor to move from a non-authenticated perspective to an authenticated perspective and gain further access.

To ensure high-quality passwords are used throughout your IT environment, we would recommend enforcing a minimum password length in conjunction with a deny list of common passwords (such as your company name, ‘password1234’, etc.), as well as awareness training for staff members which includes guidance around setting a secure password.  We would also recommend implementing MFA where possible, as this will provide an extra layer of protection.

Almost every penetration test we conduct reveals issues around communication encryption.  Generally, this will either relate to secure sockets layer and transport layer security (SSL/TLS) configuration, or to the certificates used to sign and encrypt these communications.  Typical findings in this area include the use of weak protocols, such as SSL3 and TLS1.0/1.1, weak cipher suites such as RC4 and 3DES, whilst on the certificates side, we sometimes find self-signed or expired certificates still being used on production systems.

If your communication encryption is weak, you are at risk of sensitive information being transmitted to and from those services, as weak encryption can lead to suitably-positioned attackers breaking the encryption and gaining access to the information you are transmitting.  With certificates, the main risk is MitM attacks.  If self-signed or expired certificates are present, for example on a web service, users can be used by an attacker to accept a fake certificate by clicking ‘accept’ on a ‘certificate is not secure’ warning; if users are already used to seeing and ignoring these warnings, a MitM attack is far more likely to be successful.

We have already discussed this in our previous blog on Common Cyber Essentials Challenges and How to Overcome Them, however, as this is top of the pile in terms of the most common vulnerability (we identify unsupported software in almost every penetration test we conduct), we have to highlight it here.  

This vulnerability applies to internal/external infrastructure as well as to web applications.  For the former, this will typically involve the use of unsupported operating systems (OS’), missing OS security patches, and the use of out-of-date or unsupported software such as DB servers, .NET Core/Framework, browsers, adobe, Microsoft Teams, Office, Java, etc.  Meanwhile, for web applications, the out-of-date/unsupported software we find often relates to the use of outdated JavaScript libraries (jQuery, Bootstrap, CKEditor, Moment.js) and software such as PHP, web servers (Apache, nginx, IIS, etc.), or WordPress/Plugins.

Having unsupported or out-of-date software installed on your machines can increase your organisation’s risk of being subject to remote code execution, DoS, and XSS attacks, as well as the risk of attackers gaining unauthorised access to sensitive information.  When software is no longer supported by a vendor, even widely-known vulnerabilities will not be fixed, leaving you at much greater risk of attack by a malicious actor.  Having unsupported and/or out-of-date software installed will also result in an automatic fail of Cyber Essentials and Cyber Essentials Plus.

To help ensure your software is kept up to date, we would recommend maintaining an asset register of the software you have installed, and utilising patch management tools to allow you to manage patching without having to manually update every piece of software on all of your organisation’s machines.

Just missing out on a top 10 entry was broken access controls, which are a common finding for web application tests, and can refer to a number of issues that result in an application not verifying whether a user requesting a resource has the necessary privileges to access it.   One simple example of this is Insecure Direct Object Reference (IDOR), where users can gain unauthorised access to other users’ data through both horizontal privilege escalation (accessing other users’ data with similar privileges) and vertical privilege escalation (low privilege user accessing pages/functionalities of a high privilege user).  Users may also be able to gain unauthorised access to premium functionalities.

There are a number of other findings which, whilst again not quite making the top 10 most common vulnerabilities we find, still make extremely frequent appearances in the pen tests conducted by our Cyber Team.  These include:

• IPv6 DNS poisoning and DNS takeover (which is very similar to the LLMNR/NBT-NS issues we described above)
• Weak PSK for corporate Wi-Fi
• Cleartext storage of passwords (scripts, excel, etc.)
• Employee susceptibility to social engineering attacks (physical, phishing, etc.)
• Credentials with the organisation’s domain email address found in a data leak
• Insufficient network segmentation.

‍