Critical Infrastructure Vulnerabilities

Beyond the Top 5 Vulnerabilities: ICS/SCADA IT/OT security

Access Control - An Overlooked Priority

Redbot Security has extensive experience in performing penetration assessments on industrial control and critical infrastructure systems.  Our expertise and hands on project experience allow us to identify OT vulnerabilities and provide effective solutions to bolster a company’s  security.  This article discusses many of the common vulnerabilities found within these systems along with exploring access control.

Common ICS/SCADA Security Vulnerabilities

  1. Cleartext Protocols: Many industrial control and critical infrastructure systems utilize antiquated protocols developed in the 1970s and 1980s before security consciousness was more prolific. Protocols like Modbus, Manufacturing Message Specification(MMS), DNP3 and more operate in cleartext which may allow malicious actors to steal and potentially manipulate data.
  2. Outdated Software: Many facilities operate under the adage “If it ain’t broke, don’t fix it.” Additionally, they also operate under extreme pressure to ensure continuity of operations. Typically, a halt in operations, even to deliver important updates, is considered unacceptable. This has led to ICS/SCADA networks having some of the highest rates of outdated software rivaled only by hospitals. Long since patched exploits such as EternalBlue or BlueKeep are not uncommon in ICS environments.
  3. Weak or Lack of Segregation: Network segregation is critically important to sensitive networks including ICS, payment card industry (PCI) and more. Proper network segregation would mean that in the event of a breach of the corporate IT network that the sensitive ICS/SCADA network would still be secure. Redbot Security has noted that many ICS environments are not properly segregated and often are connected by devices which are dual homed. Meaning if a device in the corporate IT network is compromised it may provide access to the ICS/SCADA environment.
  4. Default Configuration: There are a huge number of devices and applications required to effectively operate and administer an ICS environment. Often many of these devices possess default configurations, meaning the password and other potentially sensitive information is set to whatever the user manual or setup guide instructs. An attacker can simply research the device or application to find and use the credentials necessary to gain access.
  5. Insecure Remote Access: Remote access is a critical element to many ICS environments as there are often various disparate elements that cannot be quickly and efficiently managed without some form of remote capability. A secure remote access implementation should have the following features: Remote access should only be permitted when necessary, use a standardized connection method, encryption, strong authentication methods preferably including multifactor authentication, and up-to-date wireless implementations when applicable.

Diligence and Adaptation is Key

Addressing these concerns can do a lot to improve the security posture of ICS and critical infrastructure, but it is just the beginning.  Security Engineers in the ICS/SCADA field should already be aware of the above top five. Proactive Remediation , along with ongoing diligence and adaptation is key. Firstly, we should never consider an environment to be fully remediated, mitigating these top 5 issues is a constant process that needs consistent effort and awareness to stay ahead of the curve. Once proper mechanisms are in place it is imperative to keep in the fight by expanding that list of risks to mitigate, along with scheduled annual, biannual, or quarterly security testing.

Beyond The 5 Common Vulnerabilities: Hiding in plain sight.

In the multitude of ICS penetration tests, conducted by Redbot Security, we often find an issue that has the potential to be overlooked, but if left alone can introduce a critical level of risk. The weakness is so prolific that if you asked your OT or even some IT folks about it, they could describe it to you without even realizing the huge security risk it comes with. This flaw is simply lack of access control on guides, instructions, and training materials.

ICS networks can often be very complex. There are lots of moving parts with many different applications, protocols, and more, many of which are incredibly old and no longer have any sort of support beyond an owner’s manual from what can sometimes be as old as the 1980s. For this reason, many individuals who work in the field use guides and instructional material for themselves and their peers and to assist in training new personnel. These instructional materials play a crucial role in stewarding the profession and curating the knowledge and skills necessary for supporting operations. However well-meaning team members often do not account for the enormous level of risk that can be introduced through these documents. Often these use guides include information such as passwords, networking information, remote access details, and much more. In the hands of a malicious actor, these could incur devastating damage to an organization, including a halt in operations, physical damage, compromise of the domain administrator, deployed ransomware, and more.

Who has access?

On various  ICS/SCADA tests it is not uncommon to discover internal websites which do not require authentication. The information found typically  will include sensitive information; passwords for applications, credentials for an account with local admin privileges on most machines in the network, details for accounts with RDP access into certain environments, and much more. And many times, this disclosure of sensitive information is completely unknown to the security team managing the environment. Malicious Actors can leverage these materials to perform an attack chain which potentially will lead to eventual compromise of the domain administrator account.

Operations teams may sometimes take the initiative and develop these training materials without first informing the security team. It is likely that in their minds creating use guides is necessary to facilitate operations, and they are entirely correct in thinking so, but they may lack the perspective and awareness of how the information can be used by malicious actors.

So, what are some ways to ensure materials like this are not just floating around in your network without any form of access control? How can your security team find and mitigate any potential instances of this potentially critical security issue?

How do you store and disseminate information?

The first and most expedient method is to simply ask your operations(and possibly your IT) team “How do you store and disseminate information on how to maintain, connect to and administer your devices and applications?.” Chances are this will start a productive conversation that will result in your security team having a greater awareness of whether or not this information is handled in a secure manner.

What is hosted on web pages within your network?

Scan your IT environment for web (HTTP and HTTPS) ports using a tool like nmap. Some common web ports include 80, 443, 8080, 8443, 4443, and 8081. An example of an nmap scan could look like this:

The tool should identify open web ports in your network. After the command has completed, the next step is to use a tool like eyewitness to capture a screenshot of the home page of each open web port. We can take the XML output of the nmap scan and use it as input for eyewitness with the command:

Eyewitness will then go through all the ports discovered by nmap, screenshot them and generate a report that can be scrolled through. You and your team can evaluate each of the screenshots and even navigate to the page using the links beside the image. This way you can have a clear picture of what is hosted on web pages within your network. It is likely you will find an internally hosted website with instructional information on it. Additionally, you may find other sensitive information hosted on various web pages including passwords, network information, employee phone directories and more.

Redbot Security has identified numerous instances of instructional and other sensitive information being hosted in this way.

Verify Permissions

Another check that can be done is to verify permissions on Server Message Block (SMB) file shares throughout the network. A quick way to check this would be to use a tool like netexec. You can enumerate file shares throughout the network and check the permissions on them. Ensure permissions are granted only to authenticated users. A quick way to do this is to enumerate shares using null authentication.

The result of the command should tell you a list of machines which permit null authentication and whether a null account has read/write permissions on the file share. Look for potentially sensitive file shares, particularly those which pertain to operational instructions and training.

Conclusion

Sometimes checking for the top five security flaws or performing vulnerability scans can miss the grave nature of a lack of proper access controls to sensitive materials such as instructions and use guides. It is critically important that security teams have strong situational awareness of exactly what is hosted on their networks. Only by maintaining communication with operations teams, and regularly checking what is hosted in the environment can a security team ensure that there are not sensitive materials exposed for potential malicious actors to capitalize on.

Supplemental Resources

Related Articles