Invensys Wonderware InTouch creates insecure NetDDE share

From SCADApedia

1 Vulnerability
2 Affected Systems
3 Impact
4 Detection
5 Remediation
6 External Links

Vulnerability

The default installation of the Wonderware InTouch 8.0 HMI creates a NetDDE share that is vulnerable to a variety of attacks. The share that is introduced is titled *|*. Because it uses wildcards for the Application and Topic fields in the share configuration, all local DDE applications are exposed to the network. The problem is further exacerbated by the permissions, which are set to grant “Full Control” to the “Everyone” group. In some Windows installations, the “Everyone” group includes anonymous users. This could allow for an attacker to compromise the HMI and be able to launch further attacks within the network.

[edit]

Affected Systems

The *|* share is created when InTouch 8.0 is installed on any Windows system that supports NetDDE. This includes the following:

Windows 95
Windows 98
Windows NT
Windows 2000 Workstation
Windows 2000 Server
Windows XP
Windows Server 2003

In Windows XP Service Pack 2, the NetDDE services are disabled by default but still could be vulnerable if the services are enabled. Windows Vista does not support the NetDDE protocol.

The vulnerable *|* share exists in other control system applications though the scope of its use is unknown at the time of this writing. Asset owners should check for existence of the vulnerable share regardless if the InTouch product is in use. In addition, some vendors may repackage elements of Wonderware's product that create the same vulnerability.

[edit]

Impact

InTouch is a widely deployed HMI product. The vendor has removed support for NetDDE in newer versions of the product, but there are likely many InTouch 8.0 systems still in use due to the long life cycle of control systems and the undesirable interruption associated with software upgrades. If an attacker can reach the HMI using the NetBIOS protocol, the vulnerable share can be exploited and used as a launching point for further attacks on other machines in the network. This can be accomplished using default DDE functionality built into Windows applications such as Windows Explorer, Program Manager, and Internet Explorer. The following is a partial list of ways an attacker can leverage the this functionality to compromise a remote machine:

Use the Windows Explorer functions (FOLDERS) to instruct the remote machine to download malicious code via FTP, HTTP, or SMB share
Use the Program Manager functions (PROGMAN) to instruct the remote machine to run programs at startup
Use the Program Manager functions (PROGMAN) to create hotkeys -- shortcuts that run every time a user on the system uses a particular key (e.g. run the TFTP command every time a user hits the enter key or space bar)
Use the Internet Explorer functions (IEXPLORE) to instruct the remote machine to browse to malicious websites or download malicious code

[edit]

Detection

Neutralbit, a consulting and research organization in Barcelona, Spain, developed a tool called nbDDE that can check for the existence of the vulnerable shares from a remote machine. The tool also allows NetDDE interaction with all available applications – including the ability to compromise a machine with poorly configured NetDDE shares. The nbDDE tool is available for download to Digital Bond site subscribers.

The vulnerability may be detected by manual inspection using the Microsoft built-in DDE share application, ddeshare.exe. In addition, Digital Bond plans to develop a Nessus signature or this vulnerability.

[edit]

Remediation

Asset owners should verify if the NetDDE protocol is used in their environment. If it is not used, the *|* share can simply be deleted. To further protect the system, it is also recommended that the NetDDE services be disabled.

If NetDDE is in use, new shares should be created with the DDE share utility that comply with the principle of least privilege. This includes specifying the Application, Topic, and Item names as well as changing permissions for the share to restrict access by user.

Compensating Controls

Use a firewall or other filtering to restrict access to the NetBIOS ports of the HMI
Verify that anonymous users are not included in the “Everyone” group

[edit]