Several Penetration Testing assessments that I’ve worked on lately have really made me think about the challenges organizations face within corporate information security programs. Recently, the biggest issue I’ve seen has to do with risk management, legacy applications, and network protocols that assist users requesting resources on the network or Internet. I’ve been finding a specific vulnerability that should not exist on any network, even those supporting legacy applications. It seems that alternative solutions for supporting those applications, however, may be pretty scarce.

So what can a business do to mitigate the risk associated with supporting legacy applications until those applications can be upgraded? In order to answer this question, let’s first look at a recent assessment so that we can dissect the root causes and figure out ways to mitigate, if not eliminate, the risk.

Legacy Application War Story

Day 1: The first thing we noticed at the start of this assessment was the presence of the Link Local Multicast Name Resolution (LLMNR) protocol. 

Domain administrator access was achieved on day one in this scenario. This was great, but it alone doesn’t add much value. So to get more information, we had to discover additional paths to achieve the same result, construct the bigger picture from those details, and provide effective guidance on remediation.

So to recap day one, we had found one way to obtain domain administrator privileges:

  1. LLMNR response poisoning led to several domain user account password hashes.
  2. Recovered several passwords from the captured hashes using offline password cracking techniques.
  3. Discovered one of those accounts had administrator privileges on the host.
  4. Logged into the user’s host with recovered credentials and discovered a local administrator account.
  5. The local administrator account was shared with additional hosts in the environment.
  6. A domain administrator was logged into one such host, meaning we now had credentials in clear text within the memory of the system.
  7. Domain administrator privileges achieved, Active Directory database was dumped, additional 1000+ user account passwords recovered.

Day 2: After poking around on a few of the hosts, we discovered a system with the MS08-067 vulnerability. To me, this can mean one of several things: One, this host was just overlooked during an upgrade. Two, this host was supporting a legacy application and, in addition, missing the patches that close this vulnerability.

For those who understand how Microsoft labels their security bulletins, you’ll notice the ‘08’ indicating the year when this bulletin was issued. So, yes, it is quite old and I’m still amazed when I find this particular vulnerability. Then again, legacy application support may necessitate keeping a vulnerable version of Windows XP, Windows Server 2000, or Windows Server 2003 around.

For day two, with the above process in mind from day one, we needed to see if the same was possible with the other hosts and the above-mentioned vulnerabilities discovered. Here’s what we did:

  1. MS08-067 exploitation led to NT Authority/SYSTEM on the vulnerable host.
  2. An additional local administrator account hash was recovered.
  3. This time the local administrator account that was found only worked on half as many systems as on day one.
  4. One domain administrator account found logged into one such host (a different host from day one).
  5. We now had a domain administrator account password stored in memory and could proceed as we did on day one.

Day 3: The third day was just as fruitful, with an outdated JBoss installation providing unauthenticated access to the JMXInvokerServlet and the EJBInvokerServlet servlets. This was yet another path to compromising the host, and again led me to believe either this was overlooked during an upgrade, or it too was supporting a legacy application.

Day three went much the same as day two, with the exception of a few steps:

  1. JMXInvokerServlet exploitation led to SYSTEM privileges on the host.
  2. Additional tools were uploaded to extract local account hashes, cached domain account hashes, and any credentials stored in memory.
  3. Local administrator account (the same one from day one) was retrieved.
  4. Local administrator account was shared among several other hosts (same as day one).
  5. Domain administrator credentials stored in clear text within the memory of a different host (same as day one).
  6. Active Directory database was dumped, with over 1000 account passwords recovered.

Recommendations:

After three days of work, we had enough information to piece together the multiple paths an attacker could take once inside the network. This would add far more value than just discovering one method of compromise.

My next step was to figure out how best to offer remediation recommendations. To do this, I needed to discover the root causes. So let’s break down some of the root causes of the various compromise methods to find the best remediation recommendations:

  1. Patch management
  2. Configuration management (JBoss & LLMNR)
  3. Change management
  4. User account management

After breaking down the above, we had a good idea of some of the recommendations we could make. To be a little more thorough, I wanted to find out why some of these issues might exist. To get this information, asking the organization the right questions, in the right way, is always a good idea. Any chance to get more information about an environment is an excellent opportunity to hone the final recommendation.

As it turns out, legacy apps were running on the MS08-067 host and on the vulnerable JBoss host. Several tests were run to see if they could run these applications in compatibility mode on Windows 7 and the updated version of JBoss. Unfortunately, as the client later communicated, the tests were unsuccessful. This is excellent information as it means we can begin to understand their business needs.

Armed with this information, here is how I would tailor the recommendations to mitigate the risk down to an acceptable level.

The following are short-term recommendations:

  1. If not needed, disable LLMNR through Group Policies on the domain.
  2. If not needed, disable SMB (port 445/TCP) on the vulnerable Windows XP box.
  3. Apply the missing patch to the Windows XP system to mitigate MS08-067 (KB958644).
  4. Create separate privileged and non-privileged accounts for domain administrators.

The following are more long-term recommendations:

  1. Review/update configuration management processes to make sure unnecessary services are disabled.
  2. Review/update change management processes to allow sufficient time for upgrades due to end-of-life milestones for software/hardware.
  3. Review/update account management processes to increase the password complexity requirements for privileged accounts, prevent shared local administrator accounts, and create both privileged and non-privileged accounts for users requiring elevated privileges.

Supporting legacy applications doesn’t have to be a thorn in the side of any risk management process. Following these recommendations will help avoid potential legacy application risks.

With compensating controls, careful planning and significant attention to detail, the risk associated with legacy applications can be managed effectively.

References:

https://technet.microsoft.com/en-us/library/security/ms08-067.aspx

https://www.redhat.com/en/technologies/jboss-middleware

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/4.3/html/Installation_Guide/Adminstration_Console_User_Guide-Configuration-Security-HTTPInvoker.html

https://tools.ietf.org/html/rfc4795