In my experience, when providing independent corporate penetration testing services to a wide range of public- and private-sector clients, there are number of common, easily exploitable vulnerabilities that should not be present in a well-managed network. To many security professionals, these vulnerabilities will seem obvious, but the fact remains that a surprising number of penetration tests turn them up. The bottom line: Addressing them prior to penetration testing can save your company valuable time and resources.
In this tip, I will highlight some of the most common network security issues and explain how to deal with them before a pen test:
Unpatched operating systems: If operating systems are going unpatched, it's usually because of a lack of resources or because a company fails to understand the sheer volume of security vulnerabilities that attackers may easily exploit; a glance at any one of Microsoft's monthly patch bulletins serves as proof. A further issue involves organizations using Windows Server Update Services (WSUS) to do their patching, but then not checking that the latest (or indeed any) patches have definitely been applied successfully.
Be sure to check your patch management tool is actually doing the job you think it is. Free tools, such as Nessus, can check three aspects of patching: whether the patch has been applied according to the registry; whether a reboot is required to install the patch; and whether the correct versions of the .exe and .dll files are present for the patch. Many Windows patches require a server reboot for the patch to actually be applied, but administrators are often afraid of rebooting their servers because doing so increases the possibility of a critical server failing . Consequently, the patch is not actually implemented, which leaves the server open to exploitation via a vulnerability that administrators may believe is patched. This unpatched server is then a potential weak point in the network that can more easily be compromised and used to gain access to the other servers on the network.
Unpatched applications: Whilst many organisations do have good processes in place to patch their operating systems, applications are often not included in an adequate patch management process. This problem is exacerbated by poor vendor and third-party patch management tool support for anything other than operating system patching, as well as the difficulty of supporting a complex portfolio of applications. However, not patching applications from enterprise databases down to desktop applications such as Adobe Flash Player can lead to significant security vulnerabilities on a network that a penetration test will certainly pick up on, draining resources that could have been spent on subtler and equally dangerous flaws .
Enabled default accounts: Failing to disable default accounts is surprisingly common. For example, when installed, older versions of Microsoft SQL Server would create a system administrator account set with either no password or "password" for authentication. (Current versions have resolved this issue.) With this account enabled, any attacker could easily log into your organisation's databases . There are plenty of websites that list default passwords for administrator accounts or service accounts for different applications, operating systems and network devices . When installing new applications, services and network infrastructures, it is important that all management accounts are configured with strong passwords that comply with your organisation's security policy. Manual password spot checks should be conducted on all remote management accounts.
Unpatched server management services: Embedded server management services, such as Hewlett-Packard's System Management and Dell Inc.'s Openmanage, often contain unpatched vulnerabilities that can be exploited across a network . However, these services are often overlooked and left enabled, even if they are not used and not patched. Decide whether you need these services, and if not, disable them.
Unused network protocols: Similarly, remote management protocols such as telnet or remote desktop protocol (RDP) are often left enabled when not in use, meaning the services are exposed and exploitable. If you don't need these services, then they should be disabled . Disabling such protocols is an application-specific process.
Non-standard system builds: Organisations should build systems from hardened standard builds based upon best practices from Microsoft, NIST or other trusted sources. This provides a common infrastructure for which is both easier to patch and to maintain security. Organizations that do not use common builds end up with a variety of enabled services and patch states. There only needs to be one exploitable vulnerability on one critical component for an attacker to potentially compromise sensitive business and personal information that is stored and processed by your IT systems. If the organisation is not using a common managed build, it should consider migrating to this approach over time.
The above patch management issues are straightforward to address and do not require the expert technical security knowledge and skills of a professional penetration testing team. By addressing these issues prior to performing a penetration test, you can get the best value from the test, leveraging the pen testers' expertise to check for less common vulnerabilities, and thereby improving the overall security of your systems.
About the author:
Neil O'Connor is a principal consultant at Activity Information Management Ltd. in Farnborough.