Legacy Applications and SolarWinds – 4 Reasons Why CIOs Need to Move on from Them

The SolarWinds attack was not only an attack on the Software Supply Chain.  It also had secondary consequences.  To illustrate this, we will use the example of Microsoft Active Directory, the authentication technology utilized by most corporate networks, which was also affected by it.  The goal of this example is to show how accommodating one legacy technology can put an entire network at risk.  This includes newer secured applications.  According to the late John F. Kennedy, a rising tide lifts all boats.  It only took one well-placed hole to sink one like the Titanic.

One of those holes was that all the password hashes on a network were visible to platforms managed by vulnerable versions of their Orion network management software.  The CISA advisory indicated that affected organizations need to remove legacy encryption support for Kerberos, the security technology that underpins Microsoft Active Directory.  The technology Microsoft uses to verify messages as authentic is based on an older cryptographic hashing algorithm, SHA-1, that NIST has specifically approved for the purpose.  The effect of using legacy algorithms was that every password on the network became easily hackable due to lax security.

Vulnerable shops had the MD5 hashing algorithm enabled for communication with previous versions of Windows.  According to Microsoft, the use of MD5 allows machines running Windows 2000, Windows XP, or Windows Server 2003 to authenticate to Active Directory Networks.  MD5, according to the Internet Engineering Task Force, is so old and insecure that NIST does not recommend it or advertise its usage.  MD5 is so old that it is not used to help secure web browser communications in the current version supported by Microsoft 365, Transport Layer Security (TLS) 1.2.  SHA-1 is moving toward obsolescence, and we expect a future update to Windows 10 to disable it by default when Microsoft implements newer technologies in Active Directory.

This one example of how the use of legacy technologies can be that well-placed hole.  This article is going to go over four areas in which the use of legacy technologies that do not support modern security standards can turn your network into the Titanic.  We will provide examples of how this can happen, and what you can do to address these.  These technologies are Encryption/Hashing Support, Authentication, Network/File Protocols, and File Transfer Protocols.

Encryption/Hashing Support

The National Institute of Standards and Technology (NIST), maintains a web site called Cryptographic Standards and Guidelines that explains the current encryption and hashing algorithms they support.  Many legacy applications we use in healthcare do not support the latest supported algorithms.  For example, that legacy Java application server may only support Secure Sockets Layer or older versions of TLS.  Those were exposed as highly vulnerable with the Heartbleed vulnerability several years ago that allowed recovery of encrypted data.

Your Virtual Private Networking (VPN) software can also use older encryption methods, and several vendors were also impacted by Heartbleed because of it.  What you need to do as a leader is understand what encryption algorithms are used in the environment you manage.

A good vulnerability scanner can assist you here.  For each of the instances of vulnerable algorithms you discover, you need to determine if you can upgrade the applications to support modern ones.  If not, then you need to move away from using them.

Even with new technologies such as Blockchain, this is critical.  Someone will present a method by which to break or reduce the effectiveness of an algorithm or implementation at DEFCON or Chaos Communication Congress.  Your time to upgrade or update will be greatly reduced when this occurs.


Authentication not only covers the Active Directory example above, it also can cover web authentication standards such as OAuth or SAML, Virtual Private Network authentication, or Secure Shell (SSH or OpenSSH).  Before Microsoft integrated OpenSSH into Windows Server 1709 and higher and Windows 10, it was a third-party install with multiple sources that had to be maintained.  You could also purchase third-party versions of it from numerous vendors.  Third-party vendors also may have embedded older OpenSSH servers into their application software.

This means that likely there are several scenarios for legacy authentication running in your environment:

  • Older Active Directory authentication algorithms enabled
  • Older and vulnerable web authentication standards enabled
  • Older unsupported versions/distributions of OpenSSH
  • Older commercial SSH packages that no longer get paid maintenance.
  • Older commercial packages that no longer get support

Again, the use of a good vulnerability scanner that looks for outdated authentication standards and older SSH versions using authenticated scans is critically important.  Checking authentication algorithms and standards as part of this is also.  When planning, know that there will be a time when Microsoft introduces new hashing algorithms as part of Active Directory Authentication.

The Windows 7-era machines that run applications now will not have this support forever.  If you have systems that you cannot replace that are on these versions and unsupported, either put them on their own separate Active Directory network that does not communicate with the primary one or remove them from your production one.  Leaving them on your Active Directory domain puts all your machines at risk.  All it takes is one login from an insecure machine and many of your defenses go away.

Network/File Protocols

There was no better way to demonstrate that the old Server Message Block version 1.0 (SMB v1) file sharing protocol was well past its time than the WannaCry attacks of 2017.  This was a 30-year-old protocol designed for DOS and OS/2.  It was being run for backward compatibility for applications, services, and interoperability.  Older file sharing protocols also only generally support the authentication and encryption methods supported at the time they were implemented.  Normally, newer ones are not backported to older versions.

Keeping systems around that utilize legacy file sharing protocols such as SMB version 1 opens your organization up to multiple risks.  Authentication criteria is passed using legacy methods, which allows credentials to be harvested and cracked more easily.  Older code means that likely older systems with numerous vulnerabilities that will not be patched will also be exposed to the network and Internet.  These protocols, even if implemented on newer systems, lower your security.

Again, scan for these on your network using credentialed scans, and develop plans to address discovered issues.

File Transfer Protocols

There’s file sharing, then there’s file transfer.  It is 2021.  We still have File Transfer Protocol (FTP) servers in use.  The current IETF RFC for FTP is 959, released in October 1985.  We still have numerous insecure encryption algorithms used in older FTP and Secure FTP servers.  It is a mess to firewall off properly  Many of the same vulnerabilities from Secure Shell are also present here.

This is more of an issue because this involves often involves transfer of sensitive data between different organizations.  Many times, there are binding contracts that require that data be kept secure between them.  Not only are credentials exposed using older algorithms or plaintext, so is critical data between organizations.

This is where having a good network monitoring tool becomes very useful.  Monitor network traffic, determine where the file transfer traffic is originating from, and catalog it.  Compare against your asset management system and existing interfaces.  Make sure that the software you run has been secured, uses certified algorithms, and is kept up to date.

If you are running FTP, just stop.  Find a more secure method that is not older than many of your team members.

All of these require good communication.  No one is going to update their packages to fix issues or get you newer versions that are more secure unless you directly address these issues.  For too long in IS we have operated under blind assumptions.  One of them is that there was little risk to keeping legacy systems around.  SolarWinds indirectly demonstrated how one insecure system can lay waste to an entire network through indirectly allowing access to easily hackable legacy data.  With this article today, we hope to have provided you with an understanding of what the risks really are, how to scan for them in your environment, and how to address them.  Let us lift all boats, and not re-enact Titanic.

About the author

Mitch Parker, CISO

Mitch Parker, CISO

Mitchell Parker, MBA, CISSP, is the CISO, at IU Health. Mitch has eleven years’ experience in this role, having established effective organization-wide programs at multiple organizations. He is responsible for providing policy and governance oversight and research, third-party vendor guidance, proactive vulnerability research and threat modeling services, payment card and financial systems security, and security research to IU Health and IU School of Medicine. In this role, Mitch collaborates across the organization and with multiple third parties to improve the people, processes, and technologies used to facilitate security and privacy for the benefit of IU Health’s patients and team members.

Add Comment

Click here to post a comment