10 Most Common Vulnerabilities Found in Pen Tests

Jun Woo Lee
|
Head of Cybersecurity Testing at URM
|
PUBLISHED on
1 Aug
2024

Penetration testing, also known as ‘pen testing’, is a simulated cyber attack which has been authorised by an organisation in order to identify the vulnerabilities affecting its IT environment and remediate these before they can be maliciously exploited.  This type of testing is an extremely valuable exercise for organisations, allowing them to proactively strengthen and secure their environment and avoid the (often devastating) consequences of a breach.

As a long-standing provider of pen testing services, there are a number of vulnerabilities which frequently appear in the tests we conduct, many of which can be easily fixed by implementing basic, straightforward controls.  In this blog, Jun Woo Lee (Head of Cybersecurity Testing at URM) will draw upon his extensive experience as a pen tester to count down the 10 most common vulnerabilities our Cyber Team identifies when conducting penetration tests and the risks associated with each, as well as offering advice on how these vulnerabilities can be remediated/avoided.  This blog is based on a URM webinar, delivered in 2024 by Jun Woo and Lauren Gotting (New Business Manager at URM).  In the webinar, Jun Woo and Lauren provided key advice and guidance on how to get the most from a pen testing programme.

Injection Attacks

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.

Unrestricted File Uploads

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.

LLMNR/NBT-NS in Use

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.

SMB Signing not Enforced

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.

Cleartext Protocols in Use

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.

Insufficient Brute Force Protection

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.

Administrative/Unnecessary Services Exposed

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.

Default/Weak Passwords

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.

SSL/TLS Configuration and Certificate Weakness

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.

Out-of-date/Unsupported Software

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.

Other Noteworthy Mentions

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.

How URM can Help?

As a CREST and CREST OVS-accredited organisation, URM can offer your organisation a range of penetration testing services to help you identify any vulnerabilities present in your organisation’s environment and subsequently remediate these, with the assurance that the efficacy and trustworthiness of the testing you receive from us has been externally verified.  

URM can offer infrastructure and network penetration testing services to help you secure your organisation’s environment.  This can be either internal or external penetration testing, allowing you to determine the risk to your organisation both from compromised users with a degree of legitimate access, and from external threats outside your organisation.  Meanwhile, we can also conduct web and mobile application penetration testing, cloud pen testing, and business-led pen testing, depending on your organisation’s concerns and requirements.

At URM, we understand the ultimate objective of any CREST penetration testing is to enhance your security posture and mitigate risks.  As such, we will provide a retest of any critical or high vulnerabilities we identify during an assessment within the following 30 days, helping you to ensure the most significant risks to your environment are mitigated quickly.

Jun Woo Lee
Head of Cybersecurity Testing at URM
Jun Woo is the Head of Cybersecurity Testing at URM, with more than 10 years of experience working in information security and cybersecurity around Europe. Jun Woo is a Zero-Point Security Certified Red Team Operator (CRTO), an Offsec Offensive Security Certified Professional (OSCP), a CREST Registered Tester (CRT) and a Cyber Essential PLUS Lead Assessor, as well as having a MSc in Computer Engineering.
Read more

Have you considered an alternative approach to your penetration testing?

URM offers specialised business-led pen testing services in addition to more traditional testing approaches. These tests are tailored to your organisation’s unique concerns and requirements, often providing greater value and better outcomes.
Very concise webinar giving some interesting thoughts on transition etc. and guidance on preparation for transition.
Webinar 'ISO 27001:2022 – What’s new?'
contact US

Let us help you

Let us help you in your compliance journey by completing the form and letting us know how we can best support you.