Getting Ready for a Pen Test: Step 1

By Eric Milam, Martin Bos ·

The mainstream media coverage of the recent Heartbleed Bug certainly caught the attention of people around the world. More consumers quickly discovered how easily their personal and confidential data could be stolen because of a long-overlooked security flaw. And businesses were scrambling to determine how this vulnerability could impact their corporate networks.

This recent scare may have caused you to start reassessing your organization’s information security program so you can determine where you currently stand, as well as seeing if your organization is truly prepared for a standard attack let alone, the next big vulnerability. Penetration testing – a method of evaluating computer and network security by performing a controlled attack on a computer system or network from external and internal threats – absolutely should be a part of those plans. But, it’s important to make sure your organization has taken the right steps before conducting a pen test. Otherwise, it’s a waste of your time and resources.

These are five common ways an attacker can gain access to your corporate network that you should address immediately:

1. Default passwords. All systems come with a default set of credentials. Attackers have a list of those defaults, which could allow an attacker to login to a computer system, upload malicious software, and access other password hashes that grant them access to your entire organization.

The fix: Change your default passwords, and never place a system in your environment without ensuring the default configuration has been changed. And ensure the new password is strong. Make sure that all systems and devices go through the same password-change policy as your user systems. For example, you could force every user to change passwords every 90 days, and change your service, local and device accounts as well.

2. Insufficient software maintenance. Your organization definitely uses third-party software such as web services, file sharing services, and other dependencies for applications. An attacker will always look to leverage these in hopes of compromising a service they provide or the underlying system itself.

The fix: Create a policy and plan to ensure these systems and applications receive the same amount of attention as your other systems. Keep in mind, the development environment is just as, if not more, important than the production environment. Test all patches and updates on a pre-production host. Once the patch has been verified, patch all affected applications and systems you’ve identified.

3. Unpatched software. Most organizations have a plan to handle patching. For example, Microsoft releases patches on the second Tuesday of every month. However, you may not be applying patches for various reasons (e.g., the system may be priority and cannot be patched), leaving you vulnerable.

The fix: Know what assets you have on your network and what services on which those assets are running. Develop a process and plan for applying patches in a timely manner, and make sure you are prepared to handle critical out-of-band patches. Last, identify assets that cannot be patched. If possible, remove them from the network or segment and provide other safeguards if it’s not possible to remove them.

4. Unprotected administrative consoles. Since middleware, Jboss, Tomcat and Cold Fusion, for example, either don’t require a login to reach the administrative page or install with a default set of credentials, they are often an entry point into the network.

The fix: Develop and implement an organization-wide user access policy that restricts access to administration consoles of devices and systems to trusted sources only. Additionally, integrate the hardening steps into a baseline template or image to ensure the hardening standards extend to future systems.

5. Deployment misconfigurations. Many companies build one image for a desktop and have one local administrative password for all desktops across their organization. If an attacker obtains that one password, it can be used across all desktops, giving the attacker access to virtually every system on the network.

The fix: Prevention of windows privilege escalation vectors requires a complex set of controls and does not have any single fix, unfortunately. The pass-the-hash attack has plagued Windows environments for more than 15 years. Here is a list of the key recommendations for addressing the issue in Windows environments:

  • Prevent remote login of local system accounts – Change the security policy of the systems to deny access to the local administrators group from the network.
  • Create unique local administrator account credentials for each system – Every local admin account should have a unique password that is changed frequently. Although this may seem like a daunting task, software exists to both manage and execute the task.
  • Restrict the use of domain cached credentials – Configure servers and desktop systems to not store any domain cached credentials. These systems should always be able to access a domain controller for authentication; therefore they do not need this functionality. For systems that require login when a domain controller is not available, such as laptops, configure them to store a limited number.
  • Disable account delegation – Delegation permissions allow an attacker to impersonate the security context of a token on any domain attached system because it stores the authentication credentials. Disabling delegation permissions for privileged accounts and service accounts greatly reduces the potential for privilege escalation in a windows environment.

The above tips are not meant to be “fixes” for the Windows privilege escalation issues, only baseline security recommendations to help make it more difficult to execute the attack. Solutions such as disabling NT LAN Manager in your domain and moving to smart cards is a much more effective way to mitigate this issue.

Now that you’ve addressed the most obvious ways an attacker can penetrate your corporate network, you’ve completed the first step in making sure your organization is ready for a pen test. In the second post in this series, we will discuss the next step you should take: determining what assets you have on your network and how to properly segment those assets. This will limit what data and how much of it an attacker can obtain if he/she does gain access to your network.