Critical vulnerability in Citect’s SCADA software
Core Security Technologies issued an advisory disclosing a vulnerability that could severely impact organizations relying on Citect’s flagship industrial process control software, CitectSCADA. This discovery indicates that thousands of companies using Citect’s SCADA systems could unknowingly be exposing critical industrial processes and assets that they otherwise sought to protect if they do not immediately move to apply the vendor-provided patch, or other suggested workarounds for the vulnerability issued by the software maker.
According to CoreLabs, an attacker could potentially utilize the vulnerability to gain remote, unauthenticated access to a host system running CitectSCADA. If successfully exploited in this manner, the issue could allow an attacker to subsequently execute arbitrary code on vulnerable systems to take control of operations dependent on the vulnerable software.
Citect’s official security update for the issue – which is available from the vendor upon request – offers customers the option of:
- Disabling open database connectivity (ODBC)
- Automatically discarding malformed ODBC packets of the type that CoreLab’s research had indicated may be used to exploit the vulnerability.
However, the vendor maintains that no SCADA, PLC, DCS, RTU or Process Control networks should ever be exposed unprotected to the Internet. Rather, Citect advises that organizations operating such networks should either isolate the systems from the Internet entirely, or utilize technologies including firewalls to keep them protected from improper external communications.
Despite the fact that nearly all SCADA software makers maintain a similar stance in terms of advising customers to keep the systems walled-off from the Internet, the reality is that many organizations do have their process control networks accessible from wireless and wired corporate data networks that are in turn exposed to public networks such as the Internet, according to CoreLabs experts.
Vulnerability details
The vulnerability found in CitectSCADA could allow a remote un-authenticated attacker to force an abnormal termination of the vulnerable software (Denial of Service) or to execute arbitrary code on vulnerable systems to gain complete control of the software. The CitectSCADA and CitectFacilities applications include ODBC server capabilities to provide remote SQL access to a relational database. For that purpose, an ODBC Server component is used to service requests from clients on TCP/IP networks. Requests are serviced over a TCP high-port in which the application layer protocol reads an initial packet that specifies the length of data and then a second packet of data, of the same length is then read. Once the data is read from the network, it is then copied to an internal buffer of fixed size allocated in the stack without previously verifying that the buffer is big enough to store all the read data.
The vulnerability is related to a lack of a proper length-checking on data read from the network. A specially crafted combination of length and data packets could be used to exploit the vulnerability allowing an un-authenticated attacker to execute arbitrary code on vulnerable systems.
The bug is a texbook example of classic simple stack-based buffer overflow vulnerabilities of the 1990s that can be exploited by overwriting the return address of the currently running thread.
Fixes and workarounds
User organizations should deploy the vendor patch, which is available upon request or disable the vulnerable service (ODBC server) if it is not needed in their particular installation.
In general, process control networks should be physically isolated from corporate or other publicly accessible data networks. An isolated network will limit the exposure of systems with network-facing vulnerabilities to only accidental disruption or potentially malicious users or systems within the process control network itself.
However, if physical isolation of the process control network or patch deployment is not feasible, it is strongly recommended that strict access control mechanisms are enforced and monitored regularly to verify that only the absolute minimal set of required systems from both within and outside the process control network are allowed to connect to other systems within the process control network.