- ICS -
Last update 01.10.2017 20:30:24
Introduction List Kategorie Subcategory 0 1 2 3 4 5
Code Execution Flaws Found in WECON Industrial Products
9.10.2018 securityweek ICS
A significant number of vulnerabilities have been found recently in products from China-based WECON, but the vendor has been slow to release patches.
WECON specializes in human-machine interfaces (HMIs), programmable logic controllers (PLCs), and industrial PCs. The company's products are used all around the world, particularly in the critical manufacturing, energy, and water and wastewater sectors.
An advisory published recently by ICS-CERT reveals that researchers Mat Powell and Natnael Samson discovered several vulnerabilities in WECON's PI Studio HMI software. The list includes a critical stack-based buffer overflow that allows remote code execution, a high severity out-of-bounds write bug that also allows code execution, and two medium severity information disclosure flaws.
According to ICS-CERT, WECON has confirmed the vulnerabilities, but it has yet to release any patches.
ICS-CERT has this year published four advisories describing vulnerabilities in WECON products, including a medium severity flaw in the company's PLC Editor ladder logic software, and several high and medium severity bugs in LeviStudio applications.
All the vulnerabilities for which ICS-CERT has published advisories were reported by Samson, Powell and other researchers through Trend Micro's Zero Day Initiative (ZDI).
In fact, ZDI has already published 116 advisories in 2018 and over a dozen will be published in the upcoming period. However, it's worth noting that ZDI typically publishes multiple advisories for a single CVE as each advisory covers a variation of the same vulnerability.
On the other hand, many of the ICS-CERT advisories and a vast majority of the advisories from ZDI were published before patches were made available by the vendor.
A majority of the security holes allow remote code execution, but since they are related to how the affected applications handle certain file types, the attacker would need to convince the targeted user to open a specially crafted file in order to trigger the exploit.
WECON PI Studio HMI software affected by code execution flaws
9.10.2018 securityaffairs ICS Vulnerebility
Security experts discovered several vulnerabilities in WECON’s PI Studio HMI software, the company has verified the issues but has not yet released patches.
Researchers Mat Powell and Natnael Samson discovered several vulnerabilities in WECON’s PI Studio HMI software, a software widely used in critical manufacturing, energy, metallurgy, chemical, and water and wastewater sectors.
Both experts have reported the flaw under the Trend Micro’s Zero Day Initiative,
WECON specializes in human-machine interfaces (HMIs), programmable logic controllers (PLCs), and industrial PCs. The company’s products are used all around the world, particularly in the critical manufacturing, energy, and water and wastewater sectors.
The list of flaws discovered by the experts includes a critical stack-based buffer overflow vulnerability, tracked as CVE-2018-14818, that could lead to remote code execution.
Another flaw tracked as CVE-2018-14810 is a high severity out-of-bounds write bug which may allow code to be executed in the context of an administrator,
The remaining issues are two medium severity information disclosure flaws tracked as CVE-2018-17889 and CVE-2018-14814.
“Successful exploitation of these vulnerabilities may allow remote code execution, execution of code in the context of an administrator, read past the end of an allocated object or allow an attacker to disclose sensitive information under the context of administrator.” reads the security advisory published by the ICS-CERT.
WECON has confirmed the vulnerabilities, but it has not revealed when it will release security patches.
Below the list of mitigation provided by the ICS-CERT:
“WECON has verified the vulnerabilities but has not yet released an updated version.” continues the security advisory.
“NCCIC recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:
Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.”
New Splunk IoT Solution Helps Secure ICS
7.10.2018 securityweek ICS
Splunk this week unveiled a new solution designed to help industrial organizations protect control systems, monitor and diagnose equipment, and predict downtimes.
Splunk for Industrial IoT, expected to become available on October 30, combines the capabilities of Splunk Enterprise, Splunk Industrial Asset Intelligence, and the Splunk Machine Learning Toolkit.
Splunk says the new solution can help organizations in the energy, utilities, transportation, oil and gas, and manufacturing sectors monitor, optimize and secure their industrial systems.
Using the capabilities of Splunk Enterprise, Splunk for Industrial IoT should help organizations secure their industrial control systems (ICS) from cyber threats through advanced analytics and actionable intelligence, while ensuring that services are not disrupted, the company says.
Splunk for Industrial IoT allows organizations to search, correlate and visualize different types of data in real time to obtain all the information needed to assess their security posture, conduct investigations, and respond to incidents.
Security is only one of the components of the industrial IoT product. Splunk says organizations can also use it to monitor and diagnose industrial assets such as turbines, pumps, and compressors. Customers can monitor the uptime and availability of supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS) and process control software.
In addition, Splunk says the new product can be used to identify early warning signs of an ICS downtime using prediction, anomaly detection and clustering algorithms.
“Industrial organizations are challenged daily to reduce costs, increase performance and secure their constantly expanding footprint of ‘connected’ devices to remain competitive in their industry,” said Dr. Ulrich Bock, Director of Data Analytics at ESE, a German industrial engineering firm. “Our partnership with Splunk is critical to the success of these customers, blending our knowledge of operational technology environments with Splunk’s powerful ability to make machine data accessible and usable to all. Splunk for Industrial IoT now makes it easy to harness and transform the massively growing volume of machine data into insights and energy to power and accelerate their digital transformation initiatives.”
No Patches for Critical Flaws in Fuji Electric Servo System, Drives
28.9.2018 securityweek ICS
ICS-CERT and Trend Micro’s Zero Day Initiative (ZDI) this week disclosed the existence of several unpatched vulnerabilities affecting servo systems and drives from Japanese electrical equipment company Fuji Electric.
According to ICS-CERT and ZDI, researcher Michael Flanders discovered two vulnerabilities in Fuji’s Alpha 5 Smart servo system, specifically its Loader software, version 3.7 and prior.
The product, mainly used in the commercial facilities and critical manufacturing sectors in Europe and Asia, makes adjustments to ensure that the motors powering various machines operate properly.Critical vulnerabilities found in Fuji Electric Alpha 5 Smart and FRENIC products
One of the flaws identified by Flanders in the Loader software of the Alpha 5 Smart system is a critical heap-based buffer overflow (CVE-2018-14794) that can allow a remote attacker to execute arbitrary code by tricking the targeted user into opening a specially crafted C5V file.
“The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length, heap-based buffer. An attacker can leverage this vulnerability to execute arbitrary code under the context of an administrator,” ZDI said in its advisory.
The second vulnerability affecting the servo system is a medium severity buffer overflow that can lead to disclosure of sensitive information when specially crafted A5P files are processed. When combined with other flaws, this bug can be exploited to execute arbitrary code with administrator privileges.
Flanders and researcher Ghirmay Desta also informed the vendor – through ZDI and ICS-CERT – that some FRENIC AC drives are affected by three vulnerabilities. These products are used worldwide to control motors present in factory equipment and other machines.
According to ICS-CERT, the FRENIC Loader, FRENIC-Mini (C1 and C2), FRENIC-Eco, FRENIC-Multi, FRENIC-MEGA, FRENIC-Ace, and FRENIC-HVAC products are affected by critical stack-based buffer overflow and buffer over-read issues (CVE-2018-14802 and CVE-2018-14790) that can allow arbitrary code execution. The researchers also discovered a medium severity out-of-bounds read bug that can lead to information disclosure.
An attacker can exploit these vulnerabilities by tricking the targeted user into opening specially crafted FNC files.
ZDI gives organizations 120 days to release patches before making limited details of a vulnerability public. The company has published a total of five advisories this week for these Fuji Electric flaws and they all have a “zero-day” status due to the lack of patches from the vendor.
Fuji Electric claims it’s working on patching the vulnerabilities. Until fixes become available, users have been advised to avoid opening untrusted files in the affected applications.
Threats posed by using RATs in ICS
25.9.2018 Kaspersky ICS Virus
While conducting audits, penetration tests and incident investigations, we have often come across legitimate remote administration tools (RAT) for PCs installed on operational technology (OT) networks of industrial enterprises. In a number of incidents that we have investigated, threat actors had used RATs to attack industrial organizations. In some cases, the attackers had stealthily installed RATs on victim organizations’ computers, while in other cases, they had been able to use the RATs that were installed in the organization at the time of the attacks. These observations prompted us to analyze the scope of the threat, including the incidence of RATs on industrial networks and the reasons for using them.
The statistical data presented in this paper was collected using the Kaspersky Security Network (KSN) from ICS computers protected by Kaspersky Lab products that Kaspersky Lab ICS CERT categorizes as part of the industrial infrastructure at organizations. This group includes Windows computers that perform one or several of the following functions:
supervisory control and data acquisition (SCADA) servers;
data storage servers (Historian);
data gateways (OPC);
stationary workstations of engineers and operators;
mobile workstations of engineers and operators;
Human Machine Interface (HMI).
As part of our research, we considered and analyzed all popular RATs for Windows, with the exception of Remote Desktop, which is part of the Windows operating system. Our research into this RAT is ongoing and will be presented in the next paper of the series.
The use of RATs in ICS
According to KSN data, in the first half of 2018, legitimate RATs (programs categorized as not-a-virus: RemoteAdmin) were installed and used on one ICS computer in three.
Percentage of ICS computers that have RATs legitimately installed on them (download)
The statistics support our observations: RATs are indeed often used on OT networks of industrial enterprises. We believe this could be due to attempts to reduce costs associated with maintaining ICS and minimize the response time in the event of malfunction.
As we were able to find out, remote access to computers on the OT network is not restricted to administrators and engineers inside the enterprise network’s perimeter. It can also be made available via the internet to users outside the enterprise network perimeter. Such users can include representatives of third-party enterprises – employees of system integrators or ICS vendors, who use RATs for diagnostics, maintenance and to address any ICS malfunctions. As our industrial network security audits have shown, such access is often poorly supervised by the enterprise’s responsible employees, while remote users connecting to the OT network often have excessive rights, such as local administrator privileges, which is obviously a serious issue in terms of ensuring the information security of industrial automation systems.
From interviews with engineers and operators of various industrial systems that we have audited, and based on an analysis of ICS user documentation, we have determined that RATs are most commonly used on industrial networks according to the following scenarios:
To control/monitor HMI from an operator workstation (including displaying information on a large screen);
To control/maintain HMI from an engineering workstation;
To control SCADA from an operator workstation;
To provide SCADA maintenance from an engineering workstation or a computer of a contractor/vendor (from an external network);
To connect multiple operators to one operator workstation (thin client-like architecture used to save money on licenses for the software used on operator workstations);
To connect to a computer on the office network from the OT network via HMI and perform various tasks on that computer (access email, access the internet, work with office documents, etc.).
Some of the scenarios listed above indicate that the use of RATs on the OT network can be explained by operational requirements, which means that giving up the use of RATs would unavoidably entail modifications to work processes. At the same time, it is important to realize that an attack on a poorly protected RAT could easily cause disruptions to the industrial process and any decisions on using RATs on the OT network should be made with this in mind. Tight controls on the use of RATs on the OT network would help to reduce the attack surface and the risk of infection for systems administered remotely.
TOP 20 countries by percentage of ICS computers on which RATs were used at least once during the first half of 2018 (to all ICS computers in each country) (download)
Scenarios of RAT installation on ICS computers
According to our research, there are three most common scenarios of RAT installation on ICS computers:
Installation of ICS software distribution packages that include RATs (using separate distribution packages or ICS software installers). RATs included in ICS software distribution packages make up 18.6% of all RATs we have identified on ICS computers protected by Kaspersky Lab products.
Percentage of RATs bundled with ICS products to all RATs found on ICS computers (download)
Deliberate installation of RATs by personnel or suppliers – network administrators, engineers, operators, or integrator companies. We do not undertake to judge whether these installations are legitimate. Based on our experience of industrial network audits and incident investigation, we can state that many such installations do not comply with the organization’s information security policy and some are installed without the knowledge of respective enterprises’ responsible employees.
Stealthy installation of RATs by malware. An example of this is a recent attack that we have investigated (see below).
RAT-related threats to ICS
Threats associated with the use of RATs on industrial networks are not always obvious, nor are the reasons for which RATs are used.
Most of the RATs we have identified on industrial systems have the following characteristics that significantly reduce the security level of the host system:
Elevated privileges – the server part of a RAT is often executed as a service with system privileges, i.e., NT SYSTEM;
No support for restricting local access to the system / client activity;
No logging of client activity;
Vulnerabilities (our report on zero-day vulnerabilities identified in popular RAT systems that are used, among other applications, in products by many ICS vendors, will be published by the end of the year);
The use of relay servers (for reverse connections) that enable RATs to bypass NAT and firewall restrictions on the network perimeter.
The most critical RAT-related problem is the use of elevated privileges and the absence of any means to limit these privileges (or to restrict a remote user’s local access). In practice, this means that if attackers (or malware) gain access to a remote user’s computer, steal authentication data (login/password), hijack an active remote administration session or successfully attack a vulnerability in the RAT’s server part, they will gain unrestricted control of the ICS system. By using relay servers for reverse connections, attackers can also connect to these RATs from anywhere in the world.
There are also other issues that affect RATs built into ICS software distribution packages:
RAT components and distribution packages are rarely updated (even if new versions of ICS distribution packages are released). This makes them more likely to contain vulnerabilities;
In the vast majority of cases, the default password is used – it is either hardcoded into the RAT by the ICS software vendor or specified in the documentation as “recommended”.
RATs are legitimate software tools that are often used on industrial networks, which means it can be extremely difficult to distinguish attacks involving RATs from legitimate activity. In addition, since the information security service and other employees responsible for ICS security are often unaware that a RAT is installed, the configuration of RATs is in most cases not analyzed when auditing the security of an industrial network. This makes it particularly important to control by whom, when and for what purposes RATs are used on the industrial network and to ensure that it is completely impossible to use RATs without the knowledge of employees responsible for the OT network’s information security.
Attacks of threat actors involving RATs
Everything written above applies to potential threats associated with the use of RATs.
Based on our analysis of KSN statistics, we were able to identify a number of attacks and malware infection attempts involving RATs installed on ICS computers. In most cases, attacks were based on the following scenarios (in the descending order of attack incidence):
A brute force network attack from the local network or the internet designed to crack logins/passwords;
An attacker or malware using a RAT to download and execute malware using stolen or cracked authentication credentials;
A remote user (probably a legitimate user deceived by attackers) using a RAT to download a Trojan to an ICS computer and then executing it; the Trojan can be disguised as an office document, non-industrial software (a game, multimedia software, etc.), a crack/keygen for office, application or industrial software, etc.;
A network attack from the local network or the internet on the server part of the RAT using exploits.
Brute force type network attacks (designed to crack logins/passwords) are the most common: their implementation does not require any special knowledge or skills and the software used in such attacks is publicly available.
It cannot be determined based on available data who connects to a RAT’s server part installed on an ICS computer – a legitimate user, an attacker or malware – or why. Consequently, we can only guess whether this activity represents a targeted attack, sabotage attempts or a client’s error.
Network attacks from the internet were most probably conducted by threat actors using malware, penetration testing tools or botnets.
Network attacks from the local network could indicate the presence of attackers (possibly including an insider) on the network. Another possibility is that there is a compromised computer on the local network that is either infected with malware or is used by the attacker as a point of presence (if the authentication credentials were compromised earlier).
Attacks on industrial enterprises using RMS and TeamViewer
In the first half of 2018, Kaspersky Lab ICS CERT identified a new wave of phishing emails disguised as legitimate commercial offers. Although the attacks targeted primarily industrial companies within the territory of Russia, the same tactics and tools can be used in attacks on industrial companies in any country of the world.
The malware used in these attacks installs legitimate remote administration software on the system — TeamViewer or Remote Manipulator System/Remote Utilities (RMS). In both cases, a system DLL is replaced with a malicious library to inject malicious code into a legitimate program’s process. This provides the attackers with remote control of the infected systems. Various techniques are used to mask the infection and the activity of the software installed on the system.
If necessary, the attackers download an additional malware pack to the system, which is specifically tailored to the attack on each individual victim. This set of malware may contain spyware, additional remote administration tools that extend the threat actor’s control of infected systems, malware to exploit vulnerabilities in the operating system and application software, as well as the Mimikatz utility, which makes it possible to obtain account data for Windows accounts.
According to available data, the attackers’ main goal is to steal money from victim organizations’ accounts, but possible attack scenarios are not limited to the theft of funds. In the process of attacking their targets, the attackers steal sensitive data belonging to target organizations, their partners and customers, carry out surreptitious surveillance of the victim companies’ employees, and record audio and video using devices connected to infected machines. Clearly, on top of the financial losses, these attacks result in leaks of victim organizations’ sensitive data.
Multiple attacks on an auto manufacturer
A characteristic example of attacks based on the second scenario was provided by attacks on the industrial network of a motor vehicle manufacturing and service company, in particular, on computers designed to diagnose the engines and onboard systems of trucks and heavy-duty vehicles. Multiple attempts to conduct such attacks were blocked by Kaspersky Lab products.
A RAT was installed and intermittently used on at least one of the computers in the company’s industrial network. Starting in late 2017, numerous attempts to launch various malicious programs using the RAT were blocked on the computer. Infection attempts were made regularly over a period of several months – 2-3 times a week, at different times of the day. Based in part on other indirect indicators, we believe that RAT authentication data was compromised and used by attackers (or malware) to attack the enterprise’s computers over the internet.
After gaining access to the potential victim’s infrastructure via the RAT, the attackers kept trying to choose a malicious packer that would enable them to evade antivirus protection.
The blocked programs included modifications of the malware detected by Kaspersky Lab products as Net-Worm.Win32.Agent.pm. When launched this worm immediately begins to proliferate on the local network using exploits for the MS17-010 vulnerabilities – the same ones that were published by ShadowBrokers in the spring of 2017 and were used in attacks by the infamous WannaCry and ExPetr cryptors.
The Nymaim Trojan family was also blocked. Representatives of this family are often used to download modifications of botnet agents from the Necus family, which in turn have often been used to infect computers with ransomware from the Locky family.
Remote administration tools are widely used on industrial networks for ICS monitoring, control and maintenance. The ability to manipulate the ICS remotely significantly reduces maintenance costs, but at the same time, uncontrolled remote access, the inability to provide 100% verification of the remote client’s legitimacy, and the vulnerabilities in RAT code and configuration significantly increase the attack surface. At the same time, RATs, along with other legitimate tools, are increasingly used by attackers to mask malicious activity and make attribution more difficult.
To reduce the risk of cyberattacks involving RATs, we recommend the following high-priority measures:
Audit the use of application and system remote administration tools on the industrial network, such as VNC, RDP, TeamViewer, and RMS / Remote Utilities. Remove all remote administration tools that are not required by the industrial process.
Conduct an audit and disable remote administration tools which came with ICS software (refer to the relevant software documentation for detailed instructions), provided that they are not required by the industrial process.
Closely monitor and log events for each remote control session required by the industrial process; remote access should be disabled by default and enabled only upon request and only for limited periods of time.
Forcepoint Launches Critical Infrastructure Business Unit
14.9.2018 securityweek ICS
Raytheon-owned cybersecurity solutions provider Forcepoint on Thursday announced the launch of a new business unit focusing on critical infrastructure.
The new unit will be led by David Hatchell, who has been named vice president of Critical Infrastructure. Hatchell, who previously led critical infrastructure units at Belden and Intel/McAfee, will report to Sean Berg, senior vice president and general manager for Forcepoint's Global Governments and Critical Infrastructure business.
Forcepoint launches ICS/critical infrastructure offering
The initial focus is on securing the industrial control systems (ICS) used by organizations in the energy, oil and gas, critical manufacturing and other critical infrastructure sectors.
Specifically, Forcepoint will deliver integrated behavior-based security products adapted for industrial environments, particularly solutions designed to provide more visibility into the potential threats facing ICS.
The company promises to provide solutions for secure segmentation where remote access is required, and a baseline for monitoring industrial environments for threats. The solutions are advertised as being in compliance with standards such as ISA/IEC 62443, NEI-08-09, and NERC-CIP.
ICS Cyber Security Conference
Some of these capabilities will be powered by Forcepoint NGFW, a product designed to detect exploitation attempts, block malware, and defeat evasion techniques across physical, virtual and cloud systems. Forcepoint NGFW can quickly scan encrypted traffic while providing granular privacy controls, the company said.
Another product offered to critical infrastructure organizations is Forcepoint Data Guard, which validates data transfers between OT and IT networks to ensure that only commands and data sets required for operations are allowed.
“Leveraging defense-grade approaches which are used by top government agencies, customers can deploy a variety of solutions for highly sensitive areas like nuclear and power generation, or meet simple DMZ and remote access requirements,” Hatchell wrote in a blog post. “Furthermore, the Forcepoint pedigree of understanding insider threats, or how actors behave once inside an environment to compromise system operations, gives us a unique viewpoint to address ICS challenges where they are most vulnerable—the human point of interaction with systems and data.”
Flaws Found in Fuji Electric Tool That Links Corporate PCs to ICS
14.9.2018 securityweek ICS
Several vulnerabilities rated “high severity” have been discovered by researchers in Fuji Electric V-Server. The vendor has released updates that should address the flaws.
The existence of the security holes, all of which could allow a remote attacker to execute arbitrary code, was made public this week when ICS-CERT published two advisories.
Fuji Electric V-Server is a tool that allows organizations to access programmable logic controllers (PLCs) located in the plant from PCs located on the corporate network. The two systems are linked over Ethernet via the Monitouch human-machine interfaces (HMI) that are used to monitor the PLCs. ICS-CERT says the product is used worldwide, mainly in the critical manufacturing sector.
According to ICS-CERT, Fuji Electric V-Server is affected by use-after-free, untrusted pointer dereference, heap-based buffer overflow, out-of-bounds write, integer underflow, out-of-bounds read, and stack-based buffer overflow vulnerabilities that may allow remote code execution, which could lead to a denial-of-service (DoS) condition or information disclosure.
A separate advisory from ICS-CERT describes a high severity buffer overflow affecting V-Server Lite. The flaw can be exploited for code execution – and again it can lead to a DoS condition or information leakage – using specially crafted project files.
All the vulnerabilities have been patched by Fuji Electric with the release of version 188.8.131.52.
The V-Server vulnerabilities were reported to the vendor via Trend Micro’s Zero Day Initiative (ZDI) by Steven Seeley of Source Incite. The flaw affecting the Lite version was identified by Ariele Caltabiano (aka kimiya) and also reported to Fuji Electric via ZDI.
ICS-CERT warned that public exploits are available for some of the vulnerabilities. This may refer to the fact that ZDI has published more than a dozen advisories describing security holes found by Seeley and Caltabiano in Fuji Electric V-Server. The ZDI advisories were published just as this article was being written – several hours after ICS-CERT released its own advisories – but they do not contain any technical information on the flaws.
According to the ZDI advisories, Seeley reported the vulnerabilities to the vendor in March 2018, while Caltabiano did so in June.
ZDI says the flaws “exist within the parsing of a VPR file” and they are caused by either the lack of validating the existence of an object prior to performing operations on that object, or the lack of proper validation for user-supplied data.
While the ICS-CERT advisories assign a “high severity” rating to the vulnerabilities, the ZDI advisories describe them as “medium severity” with a CVSS score of 6.8. The weakness found by Caltabiano has a CVSS score of 9.3 (critical) in the ZDI advisory.
Vulnerabilities affecting products that connect the corporate network to industrial control systems (ICS) can pose a serious threat since that is how many threat actors attempt to make their way onto sensitive systems.
A study conducted recently by Positive Technologies showed that in many organizations hackers can easily gain access to industrial environments from the corporate network.
ICS CERT warns of several flaws Fuji Electric Fuji Electric V-Server
13.9.2018 securityaffairs ICS Vulnerebility
Experts discovered several flaws in Fuji Electric V-Server, a tool that connects PCs within the organizations to Industrial Control Systems (ICS).
Experts discovered several vulnerabilities in Fuji Electric V-Server, a tool that connects PCs within the organizations to Industrial Control Systems (ICS) on the corporate network. The ICS-CERT published two advisories to warn of the existence of the flaws that could have a severe impact on a broad range of companies in the critical manufacturing sector.
The vulnerabilities rated as “high severity” could be exploited by a remote attacker to execute arbitrary code, The kind of issues affecting products that control ICS systems are very dangerous and pose a severe threat to the companies, their security is essential to avoid ugly surprises.
Vulnerabilities affecting products that connect the corporate network to industrial control systems (ICS) can pose a serious threat since that is how many threat actors attempt to make their way onto sensitive systems.
Fuji Electric V-Server devices access to programmable logic controllers (PLCs) on the corporate network via Ethernet. The control of the PLCs is implemented via the Monitouch human-machine interfaces (HMI).
“Successful exploitation of these vulnerabilities could allow for remote code execution on the device, causing a denial of service condition or information exposure.” reads the advisory published by the ICS CERT.
The list of vulnerabilities includes use-after-free, untrusted pointer dereference, heap-based buffer overflow, out-of-bounds write, integer underflow, out-of-bounds read, and stack-based buffer overflow vulnerabilities that could be exploited by remote attackers to execute arbitrary code and trigger denial-of-service (DoS) condition or information disclosure.
The bad news is that public exploits for some flaws are already available online.
The ICS-CERT also warns of another high severity buffer overflow in V-Server Lite that can lead to a DoS condition or information leakage. The flaw could be triggered by tricking victims into opening specially crafted project files.
The vendor addressed the issues with the release of version 184.108.40.206.
The flaws were reported to the vendor via Trend Micro’s Zero Day Initiative (ZDI) by researchers Steven Seeley from Source Incite and Ariele Caltabiano.
ZDI rated the flaws as “medium severity” with a CVSS score of 6.8, while the most severe issue was the one found by Caltabiano.
“This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Fuji Electric V-Server. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.” states the advisory from ZDI.
“The specific flaw exists within the parsing of a VPR file. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to execute code under the context of the V-Server process.”
The main source of infection on ICS systems was the internet in H1 2018
10.9.2018 securityaffairs ICS
Researchers from Kaspersky have published a new report on the attacks on ICS systems observed by its products in the first half of 2018.
Kaspersky Lab experts have published a new report titled “Threat Landscape for Industrial Automation Systems” report for H1 2018, that includes interesting data related to attacks against the ICS systems. The security firm detected over 19,400 samples belonging to roughly 2,800 malware families, most of which were not threats specifically designed to this category of devices.
Most of the malware was the result of random attacks rather than targeted operations conducted by nation-state actors.
The data confirms an increase in the attack against the ICS systems, 41.2% of the industrial control systems protected by Kaspersky. Compared to the first half of 2017, experts observed an overall increase of 5% in the number of attack attempts.
Most of the attacks were observed in the countries with a low pro capita GDP in Asia, Latin America, and North African, while the in the United States, only 21.4% of ICS systems were hit.
The countries with the highest number of attacks by percentage were Vietnam (75.1 percent), Algeria (71.6 percent) and Morocco (65 percent), while the safest regions for ICS systems were Denmark (14 percent), Ireland (14.4 percent) and Switzerland (15.9 percent).
The main attack channel was the internet, 27 percent of attacks was originated from web sources, 8.4 percent leveraged removable storage media, and just 3.8 percent came from email clients.
“This pattern seems logical: modern industrial networks can hardly be considered isolated from external systems. Today, an interface between the industrial network and the corporate network is needed both to control industrial processes and to provide administration for industrial networks and systems,” Kaspersky added.
Most of the attacks involved Trojans using either Windows or web browsers as a platform.
More information about the attacks against ICS systems in H1 2018 are available in the the full version of the report (PDF)
Malware on ICS Increasingly Comes From Internet: Kaspersky
8.9.2018 securityweek ICS
Kaspersky Lab products installed on industrial automation systems have detected over 19,000 malware samples in the first half of 2018, and the company has determined that the Internet is an increasingly significant source of attacks.
According to Kaspersky’s “Threat Landscape for Industrial Automation Systems” report for H1 2018, the company detected over 19,400 samples belonging to roughly 2,800 malware families. As expected, most of the attempts to infect industrial systems were part of random attacks rather than targeted operations.
An overall increase in malicious activity has led to attack attempts against 41.2% of the industrial control systems (ICS) protected by the security firm, which represents an increase of nearly 5 percentage points compared to the first half of 2017. Kaspersky detected 18,000 malware samples belonging to more than 2,500 families in that period.
Attacks were reported all around the world, but Asian, Latin American and North African countries had the highest percentage of attacked ICS computers, with up to 75% of devices targeted. In the United States, only 21.4% of industrial systems were targeted. Kaspersky noted that developed countries had recorded fewer attacks compared to ones with a low per capita GDP.
A majority of the detected threats were Trojans using either Windows or web browsers as a platform.
The security firm determined that the Internet was the source in 27.3% of attacks, which represents an increase of nearly 7 percentage points compared to the same period of last year. Removable media accounted for 8.4% and email clients for 3.8% of attacks, with no significant changes compared to the prior period.
“This pattern seems logical: modern industrial networks can hardly be considered isolated from external systems. Today, an interface between the industrial network and the corporate network is needed both to control industrial processes and to provide administration for industrial networks and systems,” Kaspersky said.
Asia, Africa and Latin America are not only the most targeted, but they also represent the main sources of threats blocked by Kaspersky’s products.
Flaw in Schneider PLC Allows Significant Disruption to ICS
6.9.2018 securityweek ICS
A vulnerability discovered in some of Schneider Electric’s Modicon programmable logic controllers (PLCs) may allow malicious actors to cause significant disruption to industrial control systems (ICS).
The flaw was identified by Yehonatan Kfir, CTO of industrial cybersecurity firm Radiflow, as part of an ongoing project whose goal is finding new ICS vulnerabilities. Advisories for this security hole were published recently by both Schneider Electric and ICS-CERT.
The vulnerability, tracked as CVE-2018-7789 and described as an issue related to improper checking for unusual or exceptional conditions, can be exploited by an attacker to remotely reboot Modicon M221 controllers.
According to Schneider, all Modicon M221 controllers running firmware versions prior to 220.127.116.11, which includes a patch for the issue, are impacted.Schneider Electric Modicon M221 controllers affected by serious vulnerability
Radiflow’s Kfir told SecurityWeek that while Schneider responded to the vulnerability in a “highly professional manner,” his company does not agree with the severity rating assigned by the vendor – ICS-CERT and Schneider assigned a CVSS score of 4.8, which puts the flaw in the “medium severity” category.
“In general the assessment for the scoring is usually assessed from the perspective of IT, which takes into account the vulnerability’s impact on the potential for confidential data to be compromised,” Kfir explained. “This of course is important, although less relevant to OT operations and as such the reason we think that the score could have been higher.”
“This CVE could have resulted in the controller getting stuck and causing its communication to drop from the OT network. Disconnecting the PLC from the HMI certainly has more than a low impact on the availability of the OT network. To recover from such a problem, an onsite visit from a technician to do a power reset is required. The impact of such a situation on availability seems much higher than reflected in the scoring,” the expert added.
In a press release Radiflow will publish on Thursday, the company says an attack exploiting this flaw “would cause significant downtime to the ICS network.”
The CVSS score is also lowered due to the “attack complexity” metric being described as “high.” Kfir admits that an attacker would need to be familiar with Schneider’s proprietary protocols in order to exploit the bug, but argued that threat groups focused on targeting industrial systems – one good example is the actor behind the Triton attack – have already demonstrated these types of capabilities.
“Although it may be complex for a novice to exploit this vulnerability, it would not have been difficult at all for experienced hackers to leverage this vulnerability,” Kfir said.
Radiflow says its researchers have identified two ways to exploit the vulnerability and they both work remotely. Worryingly, Kfir told SecurityWeek that a simple Shodan search revealed over 100 vulnerable devices directly accessible from the Internet.
“It is just a matter of a few clicks that could have led to a cyberattack to take down those vulnerable PLCs.” Kfir said.
Earlier this year, Radiflow reported that a piece of cryptocurrency mining malware worked its way onto servers connected to an OT network at a wastewater facility in Europe.
Other vulnerabilities in Modicon M221 controllers
Different advisories published in recent days by ICS-CERT and Schneider Electric describe three other vulnerabilities discovered by researchers in Modicon M221 controllers.
These security holes, all classified as “high severity,” can be exploited to upload the original PLC program, and decode the device’s password using a rainbow table.
Irfan Ahmed, Hyunguk Yoo, Sushma Kalle, and Nehal Ameen of the University of New Orleans have been credited for finding these flaws.
These security holes have also been addressed by Schneider with the release of firmware version 18.104.22.168.
Malware Found on USB Drives Shipped With Schneider Solar Products
6.9.2018 securityweek ICS
Schneider Electric recently informed customers that some of the USB flash drives shipped by the company with its Conext ComBox and Conext Battery Monitor products were infected with malware.
Conext ComBox and Conext Battery Monitor are both part of Schneider’s solar energy offering. ComBox is a communications and monitoring device for installers and operators of Conext solar systems, while Battery Monitor is designed to indicate hours of battery-based runtime and determine the charging state for a battery bank.
According to Schneider, some USB removable media devices shipped with these products were exposed to malware during manufacturing at a third-party supplier’s facility.USB drives shipped by Schneider Electric for Conext products infected with malware
While the France-based industrial giant says the malware should be blocked by all major cybersecurity products, it has advised customers not to use and “securely discard” the compromised devices.
“These USB removable media contain user documentation and non-essential software utilities. They do not contain any operational software and are not required for the installation, commissioning, or operation of the products mentioned above. This issue has no impact on the operation or security of the Conext Combox or Conext Battery Monitor products,” Schneider said in an advisory published last month.
Users who believe they may have accessed one of the potentially impacted flash drives have been advised to perform a full scan of their system. The problematic drives have been shipped with all versions of Conext ComBox (sku 865-1058) and all versions of Conext Battery Monitor (sku 865-1080-01).
SecurityWeek has reached out to Schneider to obtain more information regarding the incident, including how many customers were affected and the type of malware found on the devices, but the company has yet to respond.
Incidents involving major companies delivering USB drives infected with malware along the supply chain are not unheard of. Last year, IBM informed customers that it had been shipping malware-infected initialization USBs for its Storwize storage systems, which are used by Lenovo.
The pieces of malware involved in these incidents may not have been advanced, but infected USB drives can pose a serious threat to organizations – particularly in industrial environments where air-gapping is often still used to protect critical systems – and sophisticated threat actors have been known to develop complex USB malware.
Industrial Cybersecurity Firm Indegy Raises $18 Million
29.8.2018 securityweek ICS
Industrial cybersecurity firm Indegy on Tuesday announced that is has raised $18 million through a Series B funding round, bringing the total amount raised by the company to $36 million. The new funding adds to a $12 million Series A round announced by the company in July 2016.
Indegy offers a platform that protects industrial control systems (ICS) from cyber, insider and operator error (non-malicious intent) threats, by providing visibility into ICS networks and identifying changes to controllers that could indicate an attack, including changes to firmware, logic, and configuration updates.
"This capital infusion provides the financial resources required to scale up the company and capitalize on this market opportunity," said Barak Perelman, CEO of Indegy.
Indegy at SecurityWeek's ICS Cyber Security Conference
Indegy Exhibits at SecurityWeek's 2017 ICS Cyber Security Conference in Atlanta (Image Credit: SecurityWeek)
In May, the company launched a risk assessment service designed to help organizations evaluate exposures in their operational technology (OT) environments.
In addition to announcing its Series B financing, the company announced the appointment of two new executives to its management team: Joe Scotto as Chief Marketing Officer, who joined from BAE Systems, and former Imperva executive, Todd Warwick, who will serve as VP of Sales for the Americas.
The Series B round was led by Liberty Technology Venture Capital, with participation from energy and services firm Centrica plc, O.G. Tech Ventures and existing investors Shlomo Kramer, Magma Venture Partners, Vertex Ventures and Aspect Ventures.
Perelman will be presenting on addressing insider threats in OT environments at SecurityWeek’s 2018 ICS Cyber Security Conference in October.
Indegy is one of several security startups targeting the industrial space that have recently raised funding. Others include Nozomi Networks, Dragos, Bayshore Networks, CyberX, Claroty, and SCADAFence. Veteran industrial software firm PAS raised $40 million in April 2017. Darktrace, which has an offering targeted to the industrial sector, raised $75 million at a valuation of $825 million in July 2017.
Severe Flaws Found in Yokogawa Switches, Control Systems
24.8.2018 securityweek ICS
Japanese electrical engineering company Yokogawa published two security advisories last week to inform customers that some of its products are affected by serious vulnerabilities.
One of the flaws, for which ICS-CERT also published an advisory, is CVE-2018-0651, a high severity stack-based buffer overflow affecting the license management function present in some products.
Sending specially crafted data to the licensing function could cause it to stop, but users have been warned that an unprivileged attacker with network access to the targeted system may also be able to exploit the flaw for arbitrary code execution.
According to Yokogawa and ICS-CERT, the security hole impacts the ASTPLANNER production scheduling software, the TriFellows package for the CENTUM CS control system, STARDOM control systems, and the iDefine functional safety management tool for the ProSafe-RS process safety system.
Yokogawa has already released a patch for STARDOM controllers and it plans on issuing a fix for iDefine. ASTPLANNER and TriFellows customers have been advised to contact the company’s support team.
The second vulnerability, which impacts more than a dozen of Yokogawa’s Vnet/IP industrial switches, has also been classified as “high severity,” but no CVE identifier has been assigned.
The flaw affects the debugging functionality of these devices. The problem is related to the tcpdump command, which is used for monitoring and analyzing network traffic. The tcpdump command is disabled by default, but if users have enabled it, an unprivileged network attacker could use it to disrupt the connection or make changes to the switch’s configuration.
A few months ago, Yokogawa informed users that it released a firmware update for its STARDOM controllers to address a critical hardcoded credentials vulnerability that can be exploited remotely to take control of a device.
Flaws in Emerson Workstations Allow Lateral Movement
21.8.2018 securityweek ICS
Researchers working for two industrial cybersecurity firms have discovered several critical and high severity vulnerabilities in Emerson DeltaV DCS Workstations. The vendor has released patches that should resolve the flaws.
Emerson DeltaV Workstations are purpose-built computers specifically designed to run DeltaV applications. According to ICS-CERT, these systems are used worldwide, mainly in the chemical and energy sectors.
An advisory published last week by ICS-CERT reveals that DeltaV DCS Workstation versions 11.3.1, 12.3.1, 13.3.0, 13.3.1 and R5 are impacted by four serious vulnerabilities.
The security holes were discovered by Nozomi Networks and one of them was independently identified by Ori Perez, security researcher at CyberX.DeltaV Workstation vulnerabilities
The most serious of the flaws, based on its CVSS score, is CVE-2018-14793, a stack-based buffer overflow that can be exploited for arbitrary code execution via an open communication port.
Also highly severe is the vulnerability discovered by Perez, CVE-2018-14795, which ICS-CERT described as an improper path validation issue that may allow an attacker to replace executable files.
“We were able to analyze the protocol and issue specially crafted commands in order to achieve remote code execution using that vulnerability,” CyberX VP of Research David Atch told SecurityWeek. “The vulnerability is a result of a coding error, which means that default Windows security mechanisms such as ASLR and DEP won't prevent the remote code execution.”
The two other flaws, also classified as “high severity,” are a DLL hijacking issue that can lead to arbitrary code execution (CVE-2018-14797), and a vulnerability that allows non-admin users to change executable and library files on the affected workstations (CVE-2018-14791).
Exploiting these security holes can allow an attacker to move laterally within the targeted network and possibly take control of other DeltaV workstations, CyberX and Nozomi told SecurityWeek. However, there is currently no evidence of public exploits specifically targeting these flaws.
Exploitation of the vulnerabilities requires access to the targeted workstation, either over the local network or the Internet. However, CyberX says it has not seen any DeltaV workstations directly accessible from the Web.
Moreno Carullo, co-founder and chief technical officer at Nozomi, pointed out that the notorious Triton/Trisis malware also first targeted a workstation.
Emerson has provided patches for each of the affected DeltaV Workstation versions. The company also noted that application whitelisting can block exploitation of most of these flaws as it would prevent files from being overwritten.
“To limit exposure to these and other vulnerabilities, Emerson recommends deploying and configuring DeltaV systems and related components as described in the DeltaV Security Manual, which is available in Emerson’s Guardian Support Portal,” ICS-CERT said in its advisory.
Critical Flaws Found in NetComm Industrial Routers
13.8.2018 securityweek ICS Vulnerebility
An industrial router made by Australian telecommunications equipment company NetComm Wireless is affected by several serious vulnerabilities that can be exploited remotely to take control of affected devices.
According to an advisory published last week by ICS-CERT, NetComm 4G LTE Light industrial M2M routers running firmware version 22.214.171.124 and prior are impacted by four vulnerabilities. The list includes information disclosure, cross-site scripting (XSS) and cross-site request forgery (CSRF) issues that have been assigned the CVE identifiers CVE-2018-14782 through CVE-2018-14785.
Researcher Aditya K. Sood, who has been credited for finding the vulnerabilities, told SecurityWeek that one of the security holes allows an unauthenticated attacker to access information about a device’s web server. NetComm patches critical flaws in industrial routers
A CSRF vulnerability, present due to failure to enforce a token mechanism, can be exploited by a remote attacker to perform various actions, including to change the password to the router’s web interface.
An XSS flaw is caused by the failure of the application hosted on the embedded web server to implement input filtering and sanitization.
“Any arbitrary value passed by the remote user was processed and rendered in the application. As a result, the payload passed as a value gets executed in the browser. The attacker could have stolen session information or could have executed malicious code via the NetComm router web interface,” Sood explained.
The last vulnerability is an information disclosure issue that can be exploited by an attacker to obtain details on the router’s components.
The CSRF and XSS flaws have been classified by ICS-CERT as “critical,” while the information disclosure issues are said to be “high severity.” CSRF and XSS flaws typically require the targeted user to click on a link.
The flaws can be exploited remotely from the Internet. A search revealed the existence of hundreds of devices exposed to attacks, Sood told SecurityWeek.
“The vulnerabilities combined with other sets of attacks and specific command execution to alter the configuration could result in compromising the device at the system level,” the researcher explained.
The expert reported his findings via ICS-CERT in October 2017. NetComm appears to have released a firmware update that patches the security holes in mid-May 2018.
Flaws in Siemens Tool Put ICS Environments at Risk
9.8.2018 securityweek ICS
Serious vulnerabilities discovered by researchers in Siemens’ TIA Portal for SIMATIC STEP7 and SIMATIC WinCC can be exploited by threat actors for lateral movement and other purposes in ICS environments.
The TIA Portal (Totally Integrated Automation Portal) is a piece of software from Siemens that gives organizations unrestricted access to the company’s automation services.
Researchers at industrial cybersecurity firm Nozomi Networks discovered that the default installation of the TIA Portal is affected by two high severity improper file permission vulnerabilities.
One of them, CVE-2018-11453, allows an attacker with access to the local file system to insert specially crafted files that can cause the TIA Portal to enter a denial-of-service (DoS) condition or allow the hacker to execute arbitrary code. Exploiting the flaw does not require special privileges, but the victim needs to attempt to open the TIA Portal for the exploit to be triggered, Siemens said in its advisory.
Nozomi Co-founder and Chief Technology Officer Moreno Carullo told SecurityWeek that the company sent a proof-of-concept (PoC) to ICS-CERT and Siemens that shows how this security hole can be exploited for code execution.
The second vulnerability, CVE-2018-11454, is related to an improper file permission configuration issue in specific TIA Portal directories.
“[The flaw] may allow an attacker with local privileges in the machine where the software is installed to manipulate the resources inside the misconfigured directories (eg., adding a malicious payload),” Carullo explained. “While a legitimate user uses the software suite to transfer configuration (in a licit way) to the targeted device, using the TIA Portal software, a maliciously-added file would be automatically executed by the remote device.”
Siemens has released updates for SIMATIC STEP7 and SIMATIC WinCC versions 14 and 15 to address the vulnerabilities. For earlier versions, users can prevent exploitation by restricting operating system access to authorized users, and processing GDS files only from trusted sources.
Nozomi believes these types of flaws can pose a significant risk to ICS environments.
“These types of flaws may enable an advanced persistent threat (APT) to be installed in the ICS and act by itself hidden from regular ICS engineers in a plant. So it could be used to build bigger malwares,” Carullo said.
Reconnaissance, Lateral Movement Soar in Manufacturing Industry
9.8.2018 securityweek ICS
An unusually high volume of malicious internal reconnaissance and lateral movement have been observed in the manufacturing industry, which experts believe is a result of the rapid convergence between IT and OT networks.
The data comes from the 2018 Spotlight Report on Manufacturing released on Wednesday by threat detection company Vectra. The report is based on observations from another report released on Wednesday by the company, the 2018 Black Hat Edition of the Attacker Behavior Industry Report, which shows attacker behavior and trends across nine industries.
The Attacker Behavior Industry Report shows that Vectra has detected a significant number of threats in manufacturing companies. This industry has generated the third highest number of detections, after the education and energy sectors.
The cybersecurity firm has focused on botnets, command and control (C&C) traffic, data exfiltration, reconnaissance and lateral movement.
In the case of manufacturing organizations, it discovered a significant volume of malicious internal behavior, which suggests that adversaries are already inside the network. For example, Vectra noted that in many instances there was twice as much lateral movement as C&C traffic.
“These behaviors reflect the ease and speed with which attacks can proliferate inside manufacturing networks due to the large volume of unsecured IIoT devices and insufficient internal access controls,” Vectra said in its report. “Most manufacturers do not invest heavily in security access controls for business reasons. These controls can interrupt and isolate manufacturing systems that are critical for lean production lines and digital supply chain processes.”
Many factories connect their industrial internet of things (IIoT) systems to regular computers and enterprise applications for data telemetry and remote management purposes. The use of widely used protocols instead of proprietary protocols makes it easier for malicious actors to infiltrate networks, spy on the targeted organization, and steal data, Vectra said.
According to the company, a recently observed spike in internal reconnaissance in the manufacturing sector was the result of internal darknet scans and SMB account scans. Internal darknet scans are when a device on the network looks for internal IP addresses that do not exist, while SMB account scans occur when a host quickly uses multiple accounts via the SMB protocol.
“Manufacturing networks consist of many gateways that communicate with smart devices and machines. These gateways are connected to each other in a mesh topology to simplify peer-to-peer communication. Cyberattackers leverage the same self-discovery used by peer-to-peer devices to map a manufacturing network in search of critical assets to steal or damage,” Vectra said.
As for lateral movement, the company has seen a wide range of activities, but the most common are SMB brute-force attacks, suspicious Kerberos clients, and automated replication, which occurs when an internal host sends similar payloads to multiple systems on the network.
“IIoT systems make it easy for attackers to move laterally across a manufacturing network, jumping across non-critical and critical subsystems, until they find a way to complete their exploitative missions,” the firm explained.
Honeypot Highlights Danger to ICS Systems From Criminal Hackers
7.8.2018 securityweek ICS
A security firm established a sophisticated honeypot masquerading as a power transmission substation for a major electricity provider. The purpose was to attract attackers and analyze how they operate against the energy sector of the critical infrastructure.
Within two days of going live on June 17, the honeypot developed and operated by Cybereason was found, prepped by a black-market reseller, and sold on in the dark web underworld. xDedic RDP Patch was found in the environment. This is a tool developed by the owners of the xDedic underground forum that allows multiple simultaneous uses of the same RDP credentials. xDedic is a forum that focuses on selling RDP credentials. The initial attacker, notes the report, "also installed backdoors in the honeypot servers by creating additional users, another indicator that the asset was being prepared for sale on xDedic."
On June 27, eight days after the first incursion, a new criminal entity arrived. It was immediately clear, explains Cybereason in a report published today, that this attacker had just one purpose -- to pivot from the IT side of the 'substation' and gain access to the OT environment.
The honeypot had been designed to look like a typical substation: an IT side separated by a firewall from the OT side, comprising the industrial control systems separated from the pumps, monitors, breakers and other hardware elements of the energy provider.
ICS Cyber Security Conference
It was immediately clear that these were attackers with skills beyond script kiddies. "The attackers appear to have been specifically targeting the ICS environment from the moment they got into the environment. They demonstrated non-commodity skills, techniques and a pre-built playbook for pivoting from an IT environment towards an OT environment," said Cybereason CISO Israel Barak.
The attackers showed no interest in anything but the ICS assets. But with access to the ICS devices on the IT side of the environment, the attackers were still denied immediate access to the target OT by the firewall. Blocked by the firewall, the attackers used multipoint network reconnaissance.
"The attackers," reports Cybereason, "moved from the remote server, to the SharePoint server, to the domain controller, to the SQL server to run network scans to determine if one of these assets would allow them to access the ICS environment. Instead of scanning the full network, attackers focused on scanning for assets that would give them access to the HMI and OT computers."
But this was not a nation-state attack. "I would place the attackers in the upper echelon of criminal hackers, just below the expertise of state operators," Ross Rustici, Cybereason's senior director for intelligence services told SecurityWeek. They made mistakes and were too noisy to be the best of the best -- for example, they disabled the security tools on one of the servers, which would present an immediate red flag to the security team.
Cybereason had installed its own platform in the honeypot -- but intentionally in a manner that would make its removal simple. The attackers removed it. The Cybereason platform was re-installed with some hardening, but less than the level recommended by the firm. Again, the attackers were able to disable the hardened version. "After that incident," notes the report, "the platform was installed a third time based on our recommended guidelines and the attackers haven’t been able to deactivate it."
This gives us some insight into the attackers. They were not sufficiently competent to be stealthy, but were not afraid of being discovered. They persisted, even though they would have known that their presence had been detected. This argues against a state actor, who would firstly avoid detection, but then, if detected, most likely silently withdraw.
To be fair, Rustici wasn't expecting a state attacker. "Nation-state attacks against the critical infrastructure of an adversary state are effectively military operations; and military operations are planned with incredible detail," he said. "Such adversaries will be aware of all an energy provider's substations, and while we designed the honeypot sufficient to fool cybercriminals, it would not have withstood the standard reconnaissance and reconnoitering of a military operation."
What this tells us, however, is that the critical infrastructure is a target for standard criminals. The most obvious motivation would be extortion -- taking control of the substation and holding it to ransom. Detection would not be considered important if the endgame of extortion was still possible. But the motivation could also be just for the kudos or even CV-building.
ICS environments are often complex and use a diverse set of control system vendors. Without familiarity of the OT environment and assets, it becomes more challeging for attackers to cause any significant disruption.
The danger is that criminal hackers are more clumsy than elite state actors. Current geopolitical tensions encourage nation states to explore the critical infrastructure of adversaries looking for an advantage in case of an escalation into actual warfare; but for the moment, that type of preparatory cyberwarfare is stealthy reconnaissance. State actors do not wish to be discovered.
These criminals were clumsy and not concerned with being discovered. This type of activity, warns Cybereason, "dramatically increases the risk of a mistake having real-world consequences... Hackers seeking to make a name for themselves or simply prove that they can get into a system are far more likely to cause failures out of ignorance rather than malice. This makes incident response and attribution harder, but it also is more likely to result in an unintended real-world effect."
The long-term danger to the critical infrastructure may come from nation-sate attacks -- but the immediate danger is more likely to come from less competent cyber criminals. Cybereason recommends that companies with ICS environments should operate a unified SOC. "Companies may have a NOC monitoring the OT environment, but a combined SOC lets you see all operations as they move through the network. Having this visibility is important because attackers could start in the IT environment and move to the OT environment," said Barak.
Boston, MA-based threat-hunting Cybereason raised $100 million in Series D funding from SoftBank Corp in June 2017 -- bringing the total raised to $189 million. It was founded by Lior Div, Yonatan Amit, Yossi Naar in 2012. All three are veterans of Israel's elite IDF 8200 intelligence unit.
Industry Reactions to U.S. Indicting 12 Russians for DNC Hack
22.7.2018 securityweek ICS
The U.S. last week indicted 12 Russian intelligence officers over their alleged role in a hacking operation targeting the Democratic National Committee (DNC) and Hillary Clinton’s 2016 presidential campaign.
The charges, part of special counsel Robert Mueller’s investigation into Russia’s attempt to interfere in the presidential election, were announced just days before President Donald Trump met his Russian counterpart, Vladimir Putin.
Industry professionals have commented on the charges, their impact, the possible threat actors responsible for the operation, and how these types of attacks can be avoided.
And the feedback begins...
John Hultquist, Director of Intelligence Analysis, FireEye:
“While we had already been aware of much of the information covered in the indictment, there were several interesting insights into the organizations that lie behind the intrusion operators we track. In particular, the document indicates that more than one GRU unit was involved in efforts to undermine the elections. The first of these units, Unit 26165, resembles APT28, the operator who we originally suspected of carrying out the DNC incident. The second of these two units, Unit 74455, is implicated in incidents affecting election systems.
We have been actively tracking an actor we believe was tied to those incidents, and have found some connection between those incidents and others, such as efforts to target the 2017 French elections, and disruptive attacks on the 2018 Olympics, as well as other incidents. Ultimately, though much of their activity remains opaque, we believe GRU organizations have been behind many of the most aggressive incidents in recent memory, including the economically devastating NotPetya attacks and attacks on Ukraine’s grid.”
John Gomez, CEO, Sensato:
“When you consider all that is going on and developing with the Russian hackers, it is important to note that we are very much in the embryonic stages of learning what, specifically, occurred. As more and more comes to light, I suspect we will come to appreciate the high level of sophistication that was employed to carry out the attacks. This attack was planned far in advance. It relied upon the coordination of various assets, including the development of fake personas, the recruitment of cybercriminals, monitoring news feeds, and establishing on-the-ground assets that could be plied for information and intelligence. The attackers timed the attacks to shake confidence and cause confusion.
Although the Russian hackers targeted our government, the real lesson here is that this level of sophistication is not isolated to the Russian hackers identified in the U.S Federal indictment. Rather, we are seeing that other criminal organizations, nation states, and even terrorists are employing the same level of sophistication in their operations. This development with Russia simply highlights what many of us have known all along: Attackers, regardless of motivation, have matured their tactics, techniques, and procedures. They’re innovating at a pace that far outstrips the defenses that most organizations have erected. Even basic attacks, such as phishing, are not the same approaches used a few years ago.
We may be appalled, shocked, and even outraged. Yet, maybe the biggest lesson is that despite all efforts, we failed at protecting one of our most treasured assets--the democratic process. What is more appalling is that many will continue to believe that the adversaries our IT organizations faced just a few years ago are the same adversaries our IT organizations face today. Hopefully, what has occurred with Russia will be a wake-up call, not only at the national level, but within our own organizations. If Russia can manipulate an electoral process, what could they and other, highly focused, well-funded cyber attackers do to our economy, our healthcare organizations, and other critical infrastructure systems like transportation or communications?”
Richard Ford, Chief Scientist, Forcepoint:
“We shouldn’t be distracted by talks of how they did this or why but instead – how will the international community respond to these types of asymmetric attacks that impact the very core of our democratic process? While an indictment is a nice gesture, it has little real consequences beyond drawing yet more attention to the issue.
Cybersecurity knows no borders, and so it is relatively easy for a nation state – or even an enthusiastic group of individuals – to launch attacks from the safety of their own country that can be impactful but carry very little personal risk. How we decide to treat these offensive cyber operations is one of the most pressing questions of our time, and those questions cannot be answered by governments alone. Attacks often involve third-party infrastructure, and vulnerabilities in this infrastructure have to be addressed by those in the commercial world.
It’s time for us as an international community to truly come together and determine not only what constitutes acceptable behavior online at the nation state level, but what checks and balances can be meaningfully put in place to those states that refuse to adhere to these agreed upon practices.”
Ross Rustici, Head of Intelligence Research, Cybereason:
"This further confirms the links already exposed from the indictments related to the social media influence campaigns. The concentrated effort of the Russia state to influence the election is undeniable. The most surprising thing about this is not only the relative ease of the intrusions but the wide spread campaign perpetrated by the GRU. This only serves to reinforce the dramatic changes that the internet has brought to influence operations around world. The ease with which intelligence agencies can have a direct influence in the information age is something that they could only dream of during the Cold War."
Kevin Mitnick, Chief Hacking Officer, KnowBe4:
“After reading the Russian indictment I was surprised to see that the Russians use the same exact methods we use to test our client's security controls. Our security engineers have never failed to get in when we can use social engineering (phishing, etc) during an assessment.
The biggest takeaway was that spearphishing is *still* the easiest way the bad guys get in. Why the DNC didn't use Multi-Factor Authentication is beyond me. I believe it is the lack of security awareness training that made it easy for the Russians to hack our election.”
Leo Taddeo, CISO, Cyxtera:
“The indictment teaches cyber security professionals several important lessons. Many legacy security solutions, even when used in combination, simply aren’t designed to mitigate the risks presented by today's adversaries.
A user-Centric, context-aware model is non-negotiable – Access controls that require only user name and password are effectively useless. Given the seemingly unstoppable effectiveness of spearphishing, enterprises must assume that one or more of their users has had their credentials compromised. An effective security solution must do more than just verify a user name and password. It must be be able to tell if the context of a remote connection is suspicious, such as if it originates from an unusual location or time of day, or from a device with no antivirus software installed. It should also be able to ask for additional authentication steps like one-time passwords (OTP), adjust user permissions on the fly and ultimately block access according to the level of risk. To accomplish this, organizations must adopt a user-centric context-aware model that is built on the principle of least privilege.
Authenticate first, connect second – The indictment specifically calls out that the conspirators conducted scanning on the network IP protocols. The fundamental reason for this vulnerability is that TCP/IP – which was originally designed to operate in an environment where the user community knew and trusted each other – is based on implicit trust, with a “connect first, authenticate second” approach. In today’s hyperconnected and highly adversarial threat landscape, this approach puts organizations at risk. Alternate access control technologies, such as Software-Defined Perimeter (SDP), are built on an “authenticate first, connect second” approach ensure that only authorized users can connect to network resources. This reduces the attack surface and significantly improves security. With Software Defined Perimeter, all resources are invisible to the dangerous reconnaissance techniques outlined in the indictment.
Manage the risks of third-party access – The indictment reveals the conspirators hacked into the DNC’s computers through their access to the DCCC network. Then, they installed and managed different types of malware to explore the DNC network and steal documents. This highlights the need for organizations to better manage the risks of third-party access. By using a solution that leverages the Software-Defined Perimeter (SDP) security framework, organizations can ensure that all endpoints attempting to access a given infrastructure are authenticated and authorized prior to accessing any resources on the network. This not only applies the principle of least privilege to the network, it also reduces the attack surface area by hiding network resources from unauthorized or unauthenticated users.”
Flaws Expose Siemens Protection Relays to DoS Attacks
18.7.2018 securityweek ICS
Siemens has informed customers that some of the company’s SIPROTEC protection relays are exposed to denial-of-service (DoS) attacks due to a couple of vulnerabilities present in the EN100 communication module.
SIPROTEC devices provide control, protection, measurement and automation functions for electrical substations. These products use the EN100 ethernet module for IEC 61850, PROFINET IO, Modbus, DNP3 and IEC 104 communications.
Researchers at ScadaX, an independent group of experts focusing on ICS and IoT security, discovered that the EN100 module and SIPROTEC 5 relays are impacted by two DoS vulnerabilities that can be exploited by sending specially crafted packets to the targeted device’s TCP port 102.Siemens SIPROTEC relays affected by DoS vulnerabilities
Exploitation of the flaws causes the device’s network functionality to enter a DoS condition, which Siemens says compromises the system’s availability. Manual intervention is required to restore the impacted service.
An attacker needs access to the targeted organization’s network and IEC 61850-MMS communication needs to be enabled in order to exploit the flaws, but no user interaction is required.
The vulnerabilities are similar, but one of them, tracked as CVE-2018-11451, has been classified as “high severity,” while the other, CVE-2018-11452, which impacts the EN100 module if oscilographs are running, has been rated “medium severity.” Siemens noted that SIPROTEC 5 relays are only affected by the more serious flaw.
Siemens has released firmware updates for some of the impacted devices to address the flaws, and advised users to block access to port 102 with an external firewall to prevent attacks on systems for which patches have yet to be made available.
Industry professionals have often warned that DoS vulnerabilities are far more severe in the case of industrial control systems compared to regular IT systems due to the fact that they impact availability, which is a top priority in industrial environments.
In the case of Siemens’ SIPROTEC relays, the threat is not just theoretical. Researchers reported last year that the attackers behind the Industroyer/Crashoverride malware, which was linked to the December 2016 attack on an electrical substation in Ukraine, had also developed a DoS tool that exploited CVE-2015-5374 to cause SIPROTEC relays to become unresponsive.
Israeli Firm Radiflow Raises $18 Million to Grow Industrial Cybersecurity Business
18.7.2018 securityweek IT ICS
Israeli cyber security firm Radiflow, which provides cybersecurity solutions for industrial control systems (ICS) and Supervisory control and data acquisition (SCADA) networks, announced on Wednesday that it has raised $18 million in venture funding through an investment round led by Singapore-based engineering company ST Engineering.
Radiflow’s product offerings include risk assessment, threat detection and secure remote access tools with industrial asset visibility and anomaly detection.
Under a strategic partnership, ST Engineering has integrated Radiflow’s detection and prevention tools with its SCADA system.
Radiflow logoMore specifically, Radiflow said that its tools would be integrated with ST Engineering’s Rail Command, Control and Communications (C3) Systems (SCADA) to offer an end-to-end cybersecurity solution for the rail transport industry.
Radiflow says the investment will be used to expand its sales team to support growing market demand, strengthen its brand globally and support product development.
Radiflow also recently announced partnerships with Palo Alto Networks and RSA, to make field deployments easier and help ensure compliance with new regulations, including NERC CIP and the EU NIS Directive.
Radiflow will demonstrate its technology at SecurityWeek’s 2018 ICS Cyber Security Conference, taking place October 22-25, 2018 in Atlanta.
Radiflow is one of several cybersecurity startups targeting the industrial space that have raised funding. Some others include Dragos, Indegy, Bayshore Networks, CyberX, SCADAfence and Nozomi Networks. Veteran industrial software firm PAS raised $40 million in April 2017. Darktrace, which has an offering targeted to the industrial sector, raised $75 million at a valuation of $825 million in July 2017. Just last month, New York-based Claroty announced that it had raised $60 million in a Series B funding round, bringing the total amount raised by the company to date to $93 million.
Power Grid Protection Firm SEL Patches Severe Software Flaws
18.7.2018 securityweek ICS
Several vulnerabilities, including ones rated high severity, have been discovered in management and configuration tools from power grid protection company Schweitzer Engineering Laboratories (SEL). The vendor has released software updates to address the flaws.
The security holes were discovered by Gjoko Krstic, a researcher with industrial cybersecurity firm Applied Risk. The flaws affect SEL Compass, a tool designed for managing SEL products, and AcSELerator Architect, an app that streamlines the configuration and documentation of IEC 61850 control and SCADA communications.
According to advisories published by Applied Risk and ICS-CERT, AcSELerator Architect 126.96.36.199 and prior versions are affected by two vulnerabilities. One of them, a high severity XML External Entity (XXE) vulnerability, can lead to information disclosure and in some cases to arbitrary code execution or a denial-of-service (DoS) condition. The flaw, tracked as CVE-2018-10600, can be exploited by getting the targeted user to open a specially crafted template or project file.Vulnerabilities found in SEL products
“The vulnerability is triggered when input passed to the XML parser is not sanitized while parsing the XML project and/or template file (.selaprj). This attack can also be used to execute arbitrary code (in certain circumstances, depending on the platform) or cause a denial of service (DoS) condition (billion laughs) via a specially crafted XML file including multiple external entity references,” Applied Risk wrote in its advisory.
The second flaw affecting AcSELerator Architect, identified as CVE-2018-10608, is a medium severity DoS issue that can be triggered using a malicious FTP server.
“The vulnerability can be triggered when an attacker provides the victim with a rogue malicious FTP server and listens for connections from the AcSELerator Architect FTP client feature. Once the victim gets connected to the evil FTP via the TCP protocol, a 100% CPU exhaustion occurs rendering the software to hang (not responding), denying legitimate workflow to the victim until the application is forcibly restarted,” Applied Risk explained.
As for SEL Compass, the application is affected by a high severity insecure file permissions issue that can be exploited for privilege escalation. This bug is tracked as CVE-2018-10604.
“The vulnerability exists due to the improper permissions on the SEL Compass directory, with the 'F' flag (Full) for 'Everyone' group. This gives an authenticated attacker the ability to modify or overwrite any file in the Compass directory with malicious code (trojan or a rootkit). This could result in escalation of privileges or malicious effects on the system the next time that a privileged user runs Compass,” Applied Risk said in a different advisory.
SEL patched the vulnerabilities with the release of SEL Compass v188.8.131.52 and SEL AcSELerator v184.108.40.206. Applied Risk told SecurityWeek that it took the vendor more than three months to release the updates.
SEL recently teamed up with industrial cybersecurity firm Dragos to “arm the electric power community with the tools to better detect and respond to threats within their industrial control system (ICS) networks.”
Siemens warns of several flaws affecting Central Plant Clocks
4.7.2018 securityaffairs ICS
Siemens disclosed several vulnerabilities in some of its SICLOCK central plant clocks, including ones that have been rated as “critical.”
Siemens is warning of the presence of six vulnerabilities in some of its SICLOCK central plant clocks that used to synchronize time in industrial environments.
“In the event of failure or loss of reception from the primary time source, the central plant clock ensures stable continuation of the clock time, and tracking of the system time without time jumps as soon as reception is restored.” reads the Siemens official website.
The vulnerabilities have been assigned the CVE identifiers CVE-2018-4851 through CVE-2018-4856, three of them have been classified as critical.
“SICLOCK TC devices are affected by multiple vulnerabilities that could allow an attacker to cause Denial-of-Service conditions, bypass the authentication, and modify the firmware of the device or the administrative client.” reads the security advisory.
One of the critical vulnerabilities tracked as CVE-2018-4851 could be exploited by attackers with access to the network to cause the targeted device to enter a denial-of-service (DoS) condition and potentially reboot by sending it specially crafted packets.
The successful exploitation of this flaw doesn’t require user interaction.
“An attacker with network access to the device, could cause a Denial-of-Service condition by sending certain packets to the device, causing potential reboots of the device.” reads the security advisory.
“The core functionality of the device could be impacted. The time serving functionality recovers when time synchronization with GPS devices or other NTP servers are completed. The vulnerability could impact the availability of the device, and could impact the integrity of the time service functionality of the device.”
The second critical vulnerability, tracked as CVE-2018-4853, can be exploited by an attacker with access to UDP port 69 to modify the firmware on a vulnerable device.
The flaw could be exploited by an attacker to run his own code on the SICLOCK device.
The third critical issue tracked as CVE-2018-4854 can be exploited by an attacker with access to UDP port 69 to modify the administrative client stored on the device.
“An attacker with network access to port 69/udp could modify the administrative client stored on the device.” continues the advisory.
“If a legitimate user downloads and executes the modified client from the affected device, then he could obtain code execution on the client system.”
Siemens also reported a high severity vulnerability that could be exploited by a network attacker to bypass authentication.
The other issues discovered by Siemens are a medium severity flaw that could be exploited to launch a man-in-the-middle (MitM) attack and intercept unencrypted passwords stored in client configuration files, and a low severity flaw that can be exploited by an attacker with admin access to the management interface to lock out legitimate users.
Siemens says it’s not aware of any instances where these flaws have been exploited for malicious purposes.
The flaws impacted the SICLOCK TC100 and SICLOCK TC400.
Siemens did not release firmware updates for the products because they are in phase out, the industrial giant only provided workarounds and mitigations to mitigate the risk of attacks.
Rockwell Patches Flaw Affecting Safety Controllers From Several Vendors
25.6.2018 securityweek ICS
In April, at SecurityWeek’s ICS Cyber Security Conference in Singapore, industrial cybersecurity firm Applied Risk disclosed the details of a serious denial-of-service (DoS) vulnerability affecting safety controllers from several major vendors. Rockwell Automation is one of those vendors and the company has now released patches for its products.
In an advisory published last week, Rockwell Automation informed customers that the flaw impacts Allen-Bradley CompactLogix 5370 and Compact GuardLogix 5370 programmable automation controllers, which are used to control processes in the critical infrastructure, water systems, entertainment, automotive, food and beverage, and other sectors.
The vulnerability is tracked by Rockwell as CVE-2017-9312 and it has been classified as “high severity” with a CVSS score of 8.6. CompactLogix 5370 L1, L2 and L3, and Armor CompactLogix 5370 L3 small controllers, and Compact GuardLogix 5370 and Armor Compact GuardLogix 5370 L3 safety controllers running firmware version 30.012 and prior are affected. The security hole has been patched with the release of version 31.011.Rockwell patches controller vulnerability
A remote attacker can exploit the vulnerability to cause affected devices to enter Major Non-Recoverable Fault (MNRF) mode, which results in a DoS condition that requires the user to re-download the application program in order to restore the system.
“An MNRF is a controlled action taken by the controller when it is determined that the controller could no longer continue safe operation. When a Logix controller determines that an MNRF is the right course of action, the controller is designed to fault, taking it out of run mode, logging diagnostic data, and then invalidating and deleting the controller’s memory. This action requires an application program reload to guarantee the controller has a valid program to continue safe operation,” Rockwell Automation said in an advisory (customer account required).
According to Applied Risk’s own advisory, the vulnerability exists due to “incorrect processing of TCP ACK packet additional options by the listener at Ethernet/IP TCP port (default 44818).”
“An incorrect order on the NOP option leads to an immediate device reboot and enters a ‘Major Fault’ mode which must be resolved manually. To trigger the vulnerability, the NOP option must be put first and the number of options must be more than one,” Applied Risk explained.
In addition to applying firmware updates, Rockwell has advised customers to block all traffic to Ethernet/IP and other CIP protocol-based devices from outside the manufacturing zone, minimize network exposure for control systems, and use VPNs where remote access is required.
Since the underlying issue that causes the vulnerability is related to Ethernet/IP, one of the most widely used industrial network protocols, researchers believe products from other vendors are likely affected as well. No other companies have been singled out, but Applied Risk did reveal at the ICS Cyber Security Conference that its researchers tested safety controllers from several major vendors, including Siemens, ABB, Pilz, and Phoenix Contact.
Given the significant role of safety controllers in industrial environments, causing a device to enter a DoS condition could have serious consequences, including physical damage to equipment and physical harm to people, experts warned.
“The impact of such an attack would be highly dependent on the nature of the attack, the design of the control system and other controls a user may have in place,” Rockwell said.
Two Critical flaws affect Schneider Electric U.motion Builder. Patch them now!
17.6.2018 securityaffairs ICS
Schneider Electric has patched last week four flaws affecting the U.motion Builder software, including two critical command execution vulnerabilities.
Schneider Electric U.motion Builder is a tool designed for creating projects for U.motion devices that are used in critical manufacturing, energy, and commercial facilities industries.
“This exploit occurs when the submitted data of an input string is evaluated as a command by the application,” reads the advisory published by Schneider. “In this way, the attacker could execute code, read the stack, or cause a segmentation fault in the running application.”
The critical stack-based buffer overflow vulnerability tracked as CVE-2018-7784, it received the CVSS Score of 10.
The flaw was reported by the Chinese researcher who uses the online moniker “bigric3” that also reported a critical remote command injection vulnerability, tracked as CVE-2018-7785, that can lead to authentication bypass.
The CVE-2018-7785 Remote Command Injection flaw also has been assigned CVSS scores of 10.
Both flaws can be exploited easily exploited by a remote attacker without specific skills.
Bigric3 has also reported a medium severity cross-site scripting (XSS) vulnerability, tracked as CVE-2018-7786, in the U.motion Builder application.
The last issue addressed by Schneider with the release of version 1.3.4 is an improper validation of input of context parameter in an HTTP GET request. The flaw, tracked as CVE-2018-7787, was reported by the CVE-2018-7787 Wei Gao of Ixia.
This issue has been classified as having medium severity.
The ICS-CERT and the U.S. National Cybersecurity & Communications Integration Center (NCCIC) have published a security advisory that also includes mitigations to minimize the risk of exploitation of this vulnerability.
According to the NCCIC, users should:
Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.
Perform proper impact analysis and risk assessment prior to deploying defensive measures.
Siemens Patches Vulnerabilities in SCALANCE, Other Devices
15.6.2018 securityweek ICS
Siemens this week published five new security advisories describing several vulnerabilities discovered in its switches, routers, building automation products, and medical devices.
One of the advisories covers a high severity flaw that allows an unprivileged attacker to execute arbitrary code with elevated privileges by sending a specially crafted DHCP response to an affected device’s DHCP request. The attacker requires access to the local network segment that hosts the targeted device.
The security hole affects SCALANCE X switches, SCALANCE X-204RNA access points, RUGGEDCOM WiMAX private wireless WAN devices, and RFID 181-EIP and SIMATIC RF182C RFID communication modules.SCALANCE X switch vulnerability
Updates that patch the vulnerability are available for some SCALANCE X switches, while for the other products the vendor has advised customers to apply a series of mitigations that should prevent attacks.
Some SCALANCE X switches are also impacted by two cross-site scripting (XSS) flaws, including one that is persistent. Updates and mitigations are available for both security holes.
Siemens also told customers that SCALANCE M875 industrial routers are impacted by six vulnerabilities. Three of them have been classified as high severity, including two command execution flaws that can be exploited by an authenticated attacker with admin privileges, and a cross-site request forgery (CSRF) bug.
The other flaws, rated “medium” severity, have been described as an arbitrary file download issue, an XSS vulnerability, and insecure storage of administrator passwords. Exploitation of all vulnerabilities requires access to the targeted device’s web interface and in some cases involves convincing the user to click on a link or visit a certain page.
The vulnerabilities have been addressed with the release of SCALANCE M876-4 routers, but users can also protect their devices against attacks by applying mitigations recommended by Siemens.
A separate advisory published this week by the automation giant describes two high severity flaws affecting Healthineers RAPID-Lab 1200 series and RAPIDPoint 400/405/500 Blood Gas Analyzers, medical devices used for blood sample analysis.
The weaknesses include a privilege escalation issue that can be exploited both locally and remotely, and the presence of a default account that allows attackers to access the device on TCP port 5900.
Siemens has also published an advisory for additional building automation products vulnerable to attacks due to the use of a Gemalto license management system (LMS).
The company said there was no evidence that any of these flaws had been exploited in the wild when the advisories were published.
Critical Flaws Patched in Schneider Building Automation Software
15.6.2018 securityweek ICS
Schneider Electric recently patched four vulnerabilities in its U.motion Builder software, including two critical command execution flaws. Advisories have been published by both the vendor and ICS-CERT.
Schneider Electric’s U.motion is a building automation solution used around the world mainly in the energy, critical manufacturing and commercial facilities sectors. U.motion Builder is a tool designed for creating projects for U.motion devices.
A Chinese researcher who uses the online moniker “bigric3” discovered that U.motion Builder is affected by a critical stack-based buffer overflow vulnerability (CVE-2018-7784).
“This exploit occurs when the submitted data of an input string is evaluated as a command by the application,” Schneider said in an advisory. “In this way, the attacker could execute code, read the stack, or cause a segmentation fault in the running application.”
Another critical flaw discovered by bigric3 is CVE-2018-7785, which has been described as a remote command injection issue that can lead to authentication bypass.
Both these security holes have been assigned CVSS scores of 10. They can be exploited remotely even by an attacker with a low skill level.
Register for SecurityWeek’s 2018 ICS Cyber Security Conference
Bigric3 has also been credited for finding a medium severity cross-site scripting (XSS) vulnerability in the U.motion Builder application.
Another flaw in U.motion Builder was discovered by Wei Gao of Ixia. The researcher found that the “improper validation of input of context parameter in an HTTP GET request” can lead to the disclosure of sensitive information. This issue has also been classified as having medium severity.
Schneider patched these vulnerabilities with the release of version 1.3.4. All prior versions are impacted.
In addition to the patch, ICS-CERT and the U.S. National Cybersecurity & Communications Integration Center (NCCIC) have provided a series of general recommendations for minimizing the risk of attacks.
Crestron Patches Command Injection Flaw in DGE-100 Controller
12.6.2018 securityweek ICS
Crestron recently addressed a command injection vulnerability in the console service preinstalled on the Digital Graphics Engine 100 (DGE-100) and other hardware controllers made by the company.
Tracked as CVE-2018-5553, the vulnerability has a base CVSSv3 score of 9.8 and is considered Critical severity. Discovered by Rapid7, the security bug is the result of lack of input sanitization and allows an attacker able to connect to the device over TCP port 41795 to gain root-level access.
The DGE-100 controller allows users to connect a touchscreen interface to external sources over HDMI, USB, or Ethernet. The device, which is usually paired with the Crestron TSD-2220 HD touchscreen display, is typically deployed in corporate meeting spaces or control rooms and is distributed globally.Critical vulnerability in Crestron DGE-100
The Crestron console service on DGE-100 is listening on TCP port 41795 and requires “a proprietary management tool” to use. The hardware controller, however, does not require credentials for administrative access to the console service by default.
“By connecting to this service with netcat and using the `ping` command with an argument constructed of shell-expandable variables, it is possible to inject operating system commands that will be executed by this console, which itself runs as root,” Rapid7 explains in a report.
The vulnerability occurs only if the default configuration is left in place, which means that credentials are not required for administrative access. Thus, anyone able to connect to the device’s TCP port 41795 can elevate to a root shell on the device, the security firm explains.
By exploiting the issue, an attacker could co-opt the device for a persistent “beachhead” into the affected network. The attacker would have unfettered access to the device’s core functionality, thus being able to intercept and modify any data, including what’s served over the Ethernet, HDMI, or USB ports.
The issue was discovered in March 2018 and reported to the vendor in early April. All DGE-100 devices running firmware version 1.3384.00049.001 and lower with default configuration are vulnerable. Crestron noted in an advisory published last week that TS-1542-C and DM-DGE-200-C devices are also impacted.
A patch was released on June 4 and owners of affected devices are advised to apply it as soon as possible. The update (firmware 1.3384.00059.001 or higher address the bug) is available on Crestron’s website.
“Crestron took immediate action upon receiving the information and has created updates to remediate this concern. Crestron has no evidence of any customers being impacted by this issue. If customers have configured their systems based on our published security best practices, then the risk is low as an authenticated user would be required to exploit this vulnerability,” the vendor said.
Critical Flaws Expose ABB Door Communication Systems to Attacks
11.6.2018 securityweek ICS
Researchers discovered several critical vulnerabilities in door communication systems made by Switzerland-based industrial tech company ABB. Both patches and workarounds have been made available by the vendor.
The vulnerable product is the ABB IP Gateway (also sold under the Busch-Jaeger brand), a component of ABB’s door communication solutions, which include audio and video intercoms, fingerprint readers, and access code keypads. The IP Gateway provides the connection between the intercom, the local network and the mobile application that can be used to remotely monitor and control the system. The company’s solutions are used by organizations around the world.
According to a security advisory published recently by ABB, researchers Maxim Rupp and Florian Grunow of ERNW discovered several potentially serious vulnerabilities in the IP Gateway running firmware versions 3.39 and prior.Vulnerabilities found in ABB IP Gateway
Grunow discovered a remote code injection flaw that allows an attacker with access to the local network to take control of the targeted device. The vulnerability affects the local configuration web server and it can be exploited by sending specially crafted messages to the system.
Rupp identified a total of three vulnerabilities. One of them, CVE-2017-7931, allows an attacker to bypass authentication and access configuration files and application pages on the web server simply by navigating to their associated URL.
According to an advisory published by ICS-CERT, which Rupp has described to SecurityWeek as accurate, the configuration files that can be accessed by exploiting this flaw can contain passwords stored in clear text, an issue tracked as CVE-2017-7933. ABB’s advisory claims plaintext passwords can be obtained by an attacker from the user’s browser cookies following a successful login.
Finally, ABB IP Gateway is affected by a cross-site request forgery (CSRF) bug, tracked as CVE-2017-7906, that allows an attacker to conduct various actions on behalf of a legitimate user. These types of attacks can be carried out remotely, but they typically require some user interaction (e.g. clicking on a link, visiting a malicious webpage).
ICS-CERT, whose advisory does not mention the issue identified by Grunow, has classified all the vulnerabilities as being critical or high severity.
ABB says it has patched the vulnerabilities with the release of firmware version 3.40. The company has also provided workarounds and noted that attacks can be mitigated by using security best practices for protecting a network against external attacks. The most important recommendation is that users ensure the web server cannot be accessed directly from the Internet.
The vendor is not aware of any attempts to exploit these vulnerabilities in the wild and noted that details of the security holes have not been made public.
Triton ICS Malware Developed Using Legitimate Code
8.6.2018 securityweek ICS
The developers of Triton, a recently discovered piece of malware designed to target industrial control systems (ICS), reverse engineered a legitimate file in an effort to understand how the targeted devices work.
Triton, also known as Trisis and HatMan, was discovered in August 2017 after a threat group linked by some to Iran used it against a critical infrastructure organization in the Middle East. The malware targets Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers, which use the proprietary TriStation network protocol. The malware leveraged a zero-day vulnerability affecting older versions of the product.Triconex controller targeted by Triton ICS malware
FireEye’s Advanced Practices Team has conducted a detailed analysis of the threat, which it describes as a malware framework, in an effort to determine when and how it was created.
The TriStation protocol is designed for communications between PCs (e.g. engineering workstations) and Triconex controllers. With no public documentation available, the protocol is not easy to understand, but it has been implemented by Schneider through the TriStation 1131 software suite.
It’s unclear how the attackers obtained the hardware and software they used to test the malware. They may have purchased it or borrowed it from a government-owned utility. The software could have also been stolen from ICS companies or other organizations that use Triconex controllers.
FireEye believes, however, that the malware developers did not build the TriStation communications component from the ground up. The company’s analysis suggests that the hackers copied code from legitimate libraries.
Specifically, researchers discovered significant similarities between the code found in the malware and code in a legitimate TriStation software file named “tr1com40.dll.”
While reverse engineering the legitimate DLL file may have helped them understand how TriStation works, the code in the malware suggests it did not answer all their questions. This may have led to the problems experienced by the threat group during its attack on the critical infrastructure organization.
Triton was discovered after it accidentally caused SIS controllers to initiate a safe shutdown. Experts believe the attackers had been conducting tests, trying to determine how they could cause physical damage.
“Seeing Triconex systems targeted with malicious intent was new to the world six months ago. Moving forward it would be reasonable to anticipate additional frameworks, such as TRITON, designed for usage against other SIS controllers and associated technologies,” FireEye said in its report. “If Triconex was within scope, we may see similar attacker methodologies affecting the dominant industrial safety technologies.”
Industrial cybersecurity firm Dragos reported recently that the threat group behind the Triton attack, which it tracks as Xenotime, is still active, targeting organizations worldwide and safety systems other than Schneider’s Triconex.
Serious Flaws Found in Philips Patient Monitoring Devices
8.6.2018 securityweek ICS
Researchers have discovered serious vulnerabilities in patient monitoring devices from Philips. The vendor has shared some recommendations for mitigating the risks until patches are made available.
A total of three flaws were identified by Medigate in Philips IntelliVue patient monitors (MP and MX series) and Avalon fetal monitoring systems (FM20, FM30, FM40 and FM50). Advisories describing the issues have been published by Medigate, Philips and ICS-CERT.
The most serious of them, based on its CVSS score of 8.3, allows an unauthenticated attacker to access memory and write to the memory of a targeted device. A similar flaw allows an unauthenticated attacker to read memory, but this issue has been assigned a severity rating of “medium.”Vulnerabilities found in Philips fetal monitoring system
Another high severity vulnerability is related to the devices exposing an “echo” service that can be leveraged by an attacker to cause a stack-based buffer overflow.
“The vulnerabilities allow a remote unauthenticated attacker to write memory on the device, which may allow remote code execution. Successful exploitation could open up a window for an attacker to read and/or write to the memory, which in turn could lead to a denial of service to the monitor, a breach of patient health information (PHI), as well as harm the integrity of the patient data,” Medigate said.
Philips expects to release patches in the second and third quarters of 2018. In the meantime, users have been advised to consult security and network configuration guides provided by the company to mitigate the risk.
“At this time, Philips has received no reports of exploitation of these vulnerabilities or incidents from clinical use that we have been able to associate with this problem, and no public exploits are known to exist that specifically target these vulnerabilities,” Philips said in its advisory.
The company also pointed out that exploiting these flaws requires “significant technical knowledge and skill,” and access to the local area network (LAN) hosting the affected devices.
Earlier this year, Philips informed customers that dozens of vulnerabilities affected the company’s IntelliSpace Portal, a visualization and analysis solution designed for healthcare organizations.
Group That Caused Power Outage Stops Focusing Exclusively on Ukraine
7.6.2018 securityweek ICS
Electrum, the Russia-linked hacker group believed to be responsible for the 2016 power outage in Ukraine, no longer focuses exclusively on this country, according to industrial cybersecurity firm Dragos.
Electrum is said to have used Crashoverride/Industroyer, a piece of malware designed to target industrial control systems (ICS), to cause the power outage in December 2016. Researchers have also found links to Sandworm (aka TeleBots and BlackEnergy), which has been blamed for the 2015 power outage that hit Ukraine. Sandworm is also believed to have played a role in the ongoing VPNFilter campaign.
According to Dragos, Electrum initially focused on development and facilitating Sandworm attacks. However, starting with the Crashoverride attack, it took on operational tasks as well.
The group is still active and starting with last year it has been seen focusing on organizations outside of Ukraine. While Dragos is unable to disclose which regions have been targeted, the company tells SecurityWeek that the hackers have launched attacks on organizations in the water and electric sectors.
The security firm has been monitoring Electrum and earlier this year it came across new information on the threat actor’s infiltration techniques and capabilities of the Crashoverride malware. Researchers say the group relies on common attack methods rather than zero-day vulnerabilities and exploits.
“For instance, the group used Microsoft SQL database servers as the gateway that bridges both the business and industrial control networks, to successfully compromise industrial control systems where they used stolen credentials to execute code,” explained Sergio Caltagirone, director of threat intelligence at Dragos.
The company told SecurityWeek it had not identified any new deployment of the Crashoverride malware. “Crashoverride was a very specific framework for electric grid attacks. We would only expect to see this immediately prior to an ICS impact,” it said.
“The group’s ongoing activity and link to the Sandworm team indicate Electrum’s sponsor could direct ICS disruption operations to other geographic areas,” Caltagirone noted. “Dragos considers Electrum to be one of the most competent and sophisticated threat actors currently in the ICS industry.”
Dragos has published brief reports on several of the groups that pose a threat to ICS, including Iran-linked Chrysene, Russia-linked Allanite, and Xenotime, the group believed to be behind the Triton/Trisis attacks.
Last week, it reported that a threat actor linked to North Korea’s Lazarus Group had stopped targeting organizations in the United States.
GRIMM Opens Security Research Lab for ICS, Connected Vehicles
24.5.2018 securityweek ICS
Cybersecurity research and engineering firm GRIMM has opened a new Grand Rapids, MI-based cybersecurity research lab. GRIMM provides security consulting, engineering and research services, including vulnerability research/testing and security training, to both government agencies and private sector enterprises.
The new lab will enable the company to work closely on cybersecurity initiatives within the advanced manufacturing, aerospace, automobility and defense industries based in the region; and in particular it is designed to engage with companies in the automotive and aviation industries, including OEMs. It will major on the embedded (IoT) devices integral to the industrial control systems of these industries.
"Practically every new vehicle has connected or autonomous components and smart city technologies are being deployed into urban infrastructure on a regular basis. The realities of the Internet of Everything means that distributed systems, from industrial control systems to aerospace manufacturing operations and everything in between, must have security measures embedded or run the risk of exposing countless enterprises, systems and users to vulnerabilities," said Brian DeMuth, GRIMM CEO. "GRIMM's Michigan lab will enable our team of researchers and security experts to become more deeply embedded into the critical industries -- automobility, aerospace, defense and manufacturing -- that support these advanced technologies."
Connected cars are a case in point. "By 2020, there will be a quarter billion connected vehicles on the road, enabling new in-vehicle services and automated driving capabilities, according to Gartner, Inc. During the next five years, the proportion of new vehicles equipped with this capability will increase dramatically, making connected cars a major element of the Internet of Things (IoT)." (Gartner) By 2020, one in five vehicles on the road worldwide will have some form of wireless network connection.
But the rush to connectivity is introducing serious security concerns. GRIMM's new cybersecurity research facility will focus on embedded systems engineering to support its current car hacking initiatives and cyber research in the automobility and aerospace sectors. In the last month automobile vulnerabilities have included a bug in a misconfigured server run by Calamp that would allow attackers to track the vehicle's locations, steal user information, and even cut the engine.
Earlier this month it was announced that some Volkswagen vehicles could be remotely hacked by an undisclosed vulnerability that would enable attackers to control the on-board microphone to listen in on the driver and passengers, access the system's address book and history while introducing the possibility of tracking the car via its navigation system.
Just yesterday, it was announced that Chinese researchers from Keen Security Lab had discovered more than a dozen locally and remotely exploitable flaws in certain BMW cars.
"Yesterday's disclosure that a number of BMW vehicles are susceptible to a range of cyber vulnerabilities highlights that as we continue to add more connected and autonomous capabilities into vehicles, the surface area to secure becomes exponentially larger," Bryson Bort, GRIMM chairman and founder told SecurityWeek. "This is precisely why GRIMM is announcing the opening of its dedicated cybersecurity lab in Michigan where it will work closely on initiatives within the advanced manufacturing, auto and defense industries based in the region. It will enable GRIMM to work more closely with original equipment manufacturers, suppliers, and other stakeholders in the automobility sector and beyond to improve the holistic security of automotive, aviation, and industrial control systems to address the challenges of cybersecurity in these fields."
Critical Flaws Patched in Phoenix Contact Industrial Switches
21.5.2018 securityweek ICS
Several vulnerabilities, including ones rated critical and high severity, have been patched in industrial ethernet switches made by Phoenix Contact, a Germany-based company that specializes in industrial automation, connectivity and interface solutions.
The vulnerabilities, described in advisories published recently by ICS-CERT and its German counterpart CERT@VDE, can be exploited remotely to cause a denial-of-service (DoS) condition, execute arbitrary code, and gain access to potentially sensitive information.
The security holes, discovered by researchers at Positive Technologies, impact Phoenix Contact FL SWITCH 3xxx, 4xxx, 48xx series devices running firmware versions 1.0 through 1.33. The flaws have been patched by the vendor with the release of version 1.34.Several vulnerabilities patched in Phoenix Contact industrial switches
The most serious of the vulnerabilities, based on its CVSS score of 9.1, is CVE-2018-10730, which allows an attacker who has permission to transfer configuration files to/from the switch or permission to upgrade the firmware to execute arbitrary OS shell commands.
“CGI applications config_transfer.cgi and software_update.cgi are prone to OS command injection through targeted manipulation of their web-request headers,” CERT@VDE said in an advisory. “If the vulnerability is exploited, the attacker may create their own executable files that could further exploit the integrity of the managed FL SWITCH. For example, the attacker may deny switch network access.”
The second most serious issue, with a CVSS score of 9.0, is CVE-2018-10731. This flaw, caused by a stack-based buffer overflow, can be exploited to gain unauthorized access to the device’s OS files and inject executable code.
Another stack-based buffer overflow affecting FL SWITCH products is CVE-2018-10728, which can be exploited for DoS attacks and executing arbitrary code. An attacker can leverage this flaw to disable Web and Telnet services, CERT@VDE warned.
The last vulnerability patched by Phoenix Contact in its industrial switches is a medium severity weakness that allows an unauthenticated attacker to read the content of a device’s configuration file.
This is not the first time researchers from Positive Technologies have found vulnerabilities in switches from Phoenix Contact. In January, ICS-CERT and CERT@VDE disclosed flaws that could have been exploited to gain full control of affected devices and possibly interrupt operations in the ICS network.
Researchers said at the time that they had not found any of these switches connected directly to the Internet and noted that these devices are typically used for internal PLC networks.
OPC UA security analysis
11.5.2018 Kaspersky Analysis ICS
This paper discusses our project that involved searching for vulnerabilities in implementations of the OPC UA protocol. In publishing this material, we hope to draw the attention of vendors that develop software for industrial automation systems and the industrial internet of things to problems associated with using such widely available technologies, which turned out to be quite common. We hope that this article will help software vendors achieve a higher level of protection from modern cyberattacks. We also discuss some of our techniques and findings that may help software vendors control the quality of their products and could prove useful for other software security researchers.
Why we chose the OPC UA protocol for our research
The IEC 62541 OPC UA (Object Linking and Embedding for Process Control Unified Automation) standard was developed in 2006 by the OPC Foundation consortium for reliable and, which is important, secure transfer of data between various systems on an industrial network. The standard is an improved version of its predecessor – the OPC protocol, which is ubiquitous in modern industrial environments.
It is common for monitoring and control systems based on different vendors’ products to use mutually incompatible, often proprietary network communication protocols. OPC gateways/servers serve as interfaces between different industrial control systems and telemetry, monitoring and telecontrol systems, unifying control processes at industrial enterprises.
The previous version of the protocol was based on the Microsoft DCOM technology and had some significant limitations inherent to that technology. To get away from the limitations of the DCOM technology and address some other issues identified while using OPC, the OPC Foundation developed and released a new version of the protocol.
Thanks to its new properties and well-designed architecture, the OPC UA protocol is rapidly gaining popularity among automation system vendors. OPC UA gateways are installed by a growing number of industrial enterprises across the globe. The protocol is increasingly used to set up communication between components of industrial internet of things and smart city systems.
The security of technologies that are used by many automation system developers and have the potential to become ubiquitous among industrial facilities across the globe is one the highest-priority areas of research for Kaspersky Lab ICS CERT. This was our main reason to do an analysis of OPC UA.
Another reason was that Kaspersky Lab is a member of the OPC Foundation consortium and we feel responsible for the security of technologies developed by the consortium. Getting ahead of the story, we can say that, following the results of our research, we received an invitation to join the OPC Foundation Security Working Group and gratefully accepted it.
OPC UA protocol
Originally, OPC UA was designed to support data transport for two data types: the traditional binary format (used in previous versions of the standard) and SOAP/XML. Today, data transfer in the SOAP/XML format is considered obsolete in the IT world and is almost never used in modern products and services. The prospects of it being widely used in industrial automation systems are obscure, so we decided to focus our research on the binary format.
If packets exchanged by services running on the host are intercepted, their structure can easily be understood. There are four types of messages transmitted over the OPC UA protocol:
The first message is always HELLO (HEL). It serves as a marker for the start of data transfer between the client and the server. The server responds by sending the ACKNOWLEDGE (ACK) message to the client. After the initial exchange of messages, the client usually sends the message OPEN, which means that the data transmission channel using the encryption method proposed by the client is now open. The server responds by sending the message OPEN (OPN), which includes the unique ID of the data channel and shows that the server agrees to the proposed encryption method (or no encryption).
Now the client and the server can start exchanging messages –MESSAGE (MSG). Each message includes the data channel ID, the request or response type, a timestamp, data arrays being sent, etc. At the end of the session, the message CLOSE (CLO) is sent, after which the connection is terminated.
OPC UA is a standard that has numerous implementations. In our research, we only looked at the specific implementation of the protocol developed by the OPC Foundation.
The initial stage
We first became interested in analyzing the OPC UA protocol when the Kaspersky Lab ICS CERT team was conducting security audits and penetration tests at several industrial enterprises. All of these enterprises used the same industrial control system (ICS) software. With the approval of the customers, we analyzed the software for vulnerabilities as part of the testing.
It turned out that part of the network services in the system we analyzed communicated over the OPC UA protocol and most executable files used a library named “uastack.dll”.
The first thing we decided to do as part of analyzing the security of the protocol’s implementation was to develop a basic “dumb” mutation-based fuzzer.
“Dumb” fuzzing, in spite of being called “dumb”, can be very useful and can in some cases significantly improve the chances of finding vulnerabilities. Developing a “smart” fuzzer for a specific program based on its logic and algorithms is time-consuming. At the same time, a “dumb” fuzzer helps quickly identify trivial vulnerabilities that can be hard to get at in the process of manual analysis, particularly when the amount of code to be analyzed is large, as was the case in our project.
The architecture of the OPC UA Stack makes in-memory fuzzing difficult. For the functions that we want to check for vulnerabilities to work correctly, the fuzzing process must involve passing properly formed arguments to the function and initializing global variables, which are structures with a large number of fields. We decided not to fuzz-test functions directly in memory. The fuzzer that we wrote communicated with the application being analyzed over the network.
The fuzzer’s algorithm had the following structure:
read input data sequences
perform a pseudorandom transformation on them
send the resulting sequences to the program over the network as inputs
receive the server’s response
After developing a basic set of mutations (bitflip, byteflip, arithmetic mutations, inserting a magic number, resetting the data sequence, using a long data sequence), we managed to identify the first vulnerability in uastack.dll. It was a heap corruption vulnerability, successful exploitation of which could enable an attacker to perform remote code execution (RCE), in this case, with NT AUTHORITY/SYSTEM privileges. The vulnerability we identified was caused by the function that handled the data which had just been read from a socket incorrectly calculating the size of the data, which was subsequently copied to a buffer created on a heap.
Upon close inspection, it was determined that the vulnerable version of the uastack.dll library had been compiled by the product’s developers. Apparently, the vulnerability was introduced into the code in the process of modifying it. We were not able to find that vulnerability in the OPC Foundation’s version of the library.
The second vulnerability was found in a .NET application that used the UA .NET Stack. While analyzing the application’s traffic in wireshark, we noticed in the dissector that some packets had an is_xml bit field, the value of which was 0. In the process of analyzing the application, we found that it used the XmlDocument function, which was vulnerable to XXE attacks for .NET versions 4.5 and earlier. This means that if we changed the is_xml bit field’s value from 0 to 1 and added a specially crafted XML packet to the request body (XXE attack), we would be able to read any file on the remote machine (out-of-bound file read) with NT AUTHORITY/SYSTEM privileges and, under certain conditions, to perform remote code execution (RCE), as well.
Judging by the metadata, although the application was part of the software package on the ICS that we were analyzing, it was developed by the OPC Foundation consortium, not the vendor, and was an ordinary discovery server. This means that other products that use the OPC UA technology by the OPC Foundation may include that server, making them vulnerable to the XXE attack. This makes this vulnerability much more valuable from an attacker’s viewpoint.
This was the first step in our research. Based on the results of that step, we decided to continue analyzing the OPC UA implementation by the OPC Foundation consortium, as well as products that use it.
OPC UA analysis
To identify vulnerabilities in the implementation of the OPC UA protocol by the OPC Foundation consortium, research must cover:
The OPC UA Stack (ANSI C, .NET, JAVA);
OPC Foundation applications that use the OPC UA Stack (such as the OPC UA .NET Discovery Server mentioned above);
Applications by other software developers that use the OPC UA Stack.
As part of our research, we set ourselves the task to find optimal methods of searching for vulnerabilities in all three categories.
Fuzzing the UA ANSI C Stack
Here, it should be mentioned that there is a problem with searching for vulnerabilities in the OPC UA Stack. OPC Foundation developers provide libraries that are essentially a set of exported functions based on a specification, similar to an API. In such cases, it is often hard to determine whether a potential security problem that has been discovered is in fact a vulnerability. To give a conclusive answer to that question, one must understand how the potentially vulnerable function is used and for what purpose – i.e., a sample program that uses the library is necessary. In our case, it was hard to make conclusions on vulnerabilities in the OPC UA Stack without looking at applications in which it was implemented.
What helped us resolve this problem associated with searching for vulnerabilities was open-source code hosted in the OPC Foundation’s repository on GitHub, which includes a sample server that uses the UA ANSI C Stack. We don’t often get access to product source code in the course of analyzing ICS components. Most ICS applications are commercial products, developed mostly for Windows and released with a licensing agreement the terms of which do not include access to the source code. In our case, the availability of the source code helped find errors both in the server itself and in the library. The UA ANSI C Stack source code was helpful for doing manual analysis of the code and for fuzzing. It also helped us find out whether new functionality had been added to a specific implementation of the UA ANSI C Stack.
The UA ANSI C Stack (like virtually all other products by the OPC Foundation consortium) is positioned as a solution that is not only secure, but is also cross-platform. This helped us our during fuzzing, because we were able to build a UA ANSI С Stack together with the sample server code published by the developers in their GitHub account, on a Linux system with binary source code instrumentation and to fuzz-test that code using AFL.
To accelerate fuzzing, we overloaded the networking functions –socket/sendto/recvfrom/accept/bind/select/… – to read input data from a local file instead of connecting to the network. We also compiled our program with AddressSanitizer.
To put together an initial set of examples, we used the same technique as for our first “dumb” fuzzer, i.e., capturing traffic from an arbitrary client to the application using tcpdump. We also added some improvements to our fuzzer – a dictionary created specifically for OPC UA and special mutations.
It follows from the specification of the binary data transmission format in OPC UA that it is sufficiently difficult for AFL to mutate from, say, the binary representation of an empty string in OPC UA (“\xff\xff\xff\xff”) to a string that contains 4 random bytes (for example, “\x04\x00\x00\x00AAAA”). Because of this, we implemented our own mutation mechanism, which worked with OPC UA internal structures, changing them based on their types.
After building our fuzzer with all the improvements included, we got the first crash of the program within a few minutes.
An analysis of memory dumps created at the time of the crash enabled us to identify a vulnerability in the UA ANSI C Stack which, if exploited, could result at least in a DoS condition.
Fuzzing OPC Foundation applications
Since, in the previous stage, we had performed fuzzing of the UA ANSI C Stack and a sample application by the OPC Foundation, we wanted to avoid retesting the OPC UA Stack in the process of analyzing the consortium’s existing products, focusing instead on fuzzing specific components written on top of the stack. This required knowledge of the OPC UA architecture and the differences between applications that use the OPC UA Stack.
The two main functions in any application that uses the OPC UA Stack are OpcUa_Endpoint_Create and OpcUa_Endpoint_Open. The former provides the application with information on available channels of data communication between the server and the client and a list of available services. The OpcUa_Endpoint_Open function defines from which network the service will be available and which encryption modes it will provide.
A list of available services is defined using a service table, which lists data structures and provides information about each individual service. Each of these structures includes data on the request type supported, the response type, as well as two callback functions that will be called during request preprocessing and post-processing (preprocessing functions are, in most cases, “stubs”). We included converter code into the request preprocessing function. It uses mutated data as an input, outputting a correctly formed structure that matches the request type. This enabled us to skip the application startup stage, starting an event loop to create a separate thread to read from our pseudo socket, etc. This enabled us to accelerate our fuzzing from 50 exec/s to 2000 exec/s.
As a result of using our “dumb” fuzzer improved in this way, we identified 8 more vulnerabilities in OPC Foundation applications.
Analyzing third-party applications that use the OPC UA Stack
Having completed the OPC Foundation product analysis stage, we moved on to analyzing commercial products that use the OPC UA Stack. From the ICS systems we worked with during penetration testing and analyzing the security status of facilities for some of our customers, we selected several products by different vendors, including solutions by global leaders of the industry. After getting our customers’ approval, we began to analyze implementations of the OPC UA protocol in these products.
When searching for binary vulnerabilities, fuzzing is one of the most effective techniques. In previous cases, when analyzing products on a Linux system, we used source code binary instrumentation techniques and the AFL fuzzer. However, the commercial products using the OPC UA Stack that we analyzed are designed to run on Windows, for which there is an equivalent of the AFL fuzzer called WinAFL. Essentially, WinAFL is the AFL fuzzer ported to Windows. However, due to differences between the operating systems, the two fuzzers are different in some significant ways. Instead of system calls from the Linux kernel, WinAFL uses WinAPI functions and instead of static source code instrumentation, it uses the DynamoRIO dynamic instrumentation of binary files. Overall, these differences mean that the performance of WinAFL is significantly lower than that of AFL.
To work with WinAFL in the standard way, one has to write a program that will read data from a specially created file and call a function from an executable file or library. Then WinAFL will put the process into a loop using binary instrumentation and will call the function many times, getting feedback from the running program and relaunching the function with mutated data as arguments. That way, the program will not have to be relaunched every time with new input data, which is good, because creating a new process in Windows consumes significant processor time.
Unfortunately, this method of fuzzing couldn’t be used in our situation. Owing to the asynchronous architecture of the OPC UA Stack, the processing of data received and sent over the network is implemented as call-back functions. Consequently, it is impossible to identify a data-processing function for each type of request that would accept a pointer to the buffer containing the data and the size of the data as arguments, as required by the WinAFL fuzzer.
In the source code of the WinAFL fuzzer, we found comments on fuzzing networking applications left by the developer. We followed the developer’s recommendations on implementing network fuzzing with some modifications. Specifically, we included the functionality of communication with the local networking application in the code of the fuzzer. As a result of this, instead of executing a program, the fuzzer sends payload over the network to an application that is already running under DynamoRIO.
However, with all our efforts, we were only able to achieve the fuzzing rate of 5 exec/s. This is so slow that it would take too long to find a vulnerability even with a smart fuzzer like AFL.
Consequently, we decided to go back to our “dumb” fuzzer and improve it.
We improved the mutation mechanism, modifying the data generation algorithm based on our knowledge of the types of data transferred to the OPC UA Stack.
We created a set of examples for each service supported (the python-opcua library, which includes functions for interacting with virtually all possible OPC UA services, proved very helpful in this respect).
When using a fuzzer with dynamic binary instrumentation to test multithreaded applications such as ours, searching for new branches in the application’s code is a sufficiently complicated task, because it is difficult to determine which input data resulted in a certain behavior of the application. Since our fuzzer communicated to the application over the network and we could establish a clear connection between the server’s response and the data sent to it (because communication took place within the limits of one session), there was no need for us to address this issue. We implemented an algorithm which determined that a new execution path has been identified simply when a new response that had not been observed before was received from the server.
As a result of the improvements described above, our “dumb” fuzzer was no longer all that “dumb”, and the number of executions per second grew from 1 or 2 to 70, which is a good figure for network fuzzing. With its help, we identified two more new vulnerabilities that we had been unable to identify using “smart” fuzzing.
As of the end of March 2018, the results of our research included 17 zero-day vulnerabilities in the OPC Foundation’s products that had been identified and closed, as well as several vulnerabilities in the commercial applications that use these products.
We immediately reported all the vulnerabilities identified to developers of the vulnerable software products.
Throughout our research, experts from the OPC Foundation and representatives of the development teams that had developed the commercial products promptly responded to the vulnerability information we sent to them and closed the vulnerabilities without delays.
In most cases, flaws in third-party software that uses the OPC UA Stack were caused by the developers not using functions from the API implemented in the OPC Foundation’s uastack.dll library properly – for example, field values in the data structures transferred were interpreted incorrectly.
We also determined that, in some cases, product vulnerabilities were caused by modifications made to the uastack.dll library by developers of commercial software. One example is an insecure implementation of functions designed to read data from a socket, which was found in a commercial product. Notably, the original implementation of the function by the OPC Foundation did not include this error. We do not know why the commercial software developer had to modify the data reading logic. However, it is obvious that the developer did not realize that the additional checks included in the OPC Foundation’s implementation are important because the security function is built on them.
In the process of analyzing commercial software, we also found out that developers had borrowed code from OPC UA Stack implementation examples, copying that code to their applications verbatim. Apparently, they assumed that the ОРС Foundation has made sure that these code fragments were secure in the same way that it had ensured the security of code used in the library. Unfortunately, that assumption turned out to be wrong.
Exploitation of some of the vulnerabilities that we identified results in DoS conditions and the ability to execute code remotely. It is important to remember that, in industrial systems, denial-of-service vulnerabilities pose a more serious threat than in any other software. Denial-of-service conditions in telemetry and telecontrol systems can cause enterprises to suffer financial losses and, in some cases, even lead to the disruption and shutdown of the industrial process. In theory, this could cause harm to expensive equipment and other physical damage.
The fact that the OPC Foundation is opening the source code of its projects certainly indicates that it is open and committed to making its products more secure.
At the same time, our analysis has demonstrated that the current implementation of the OPC UA Stack is not only vulnerable but also has a range of significant fundamental problems.
First, flaws introduced by developers of commercial software that uses the OPC UA Stack indicate that the OPC UA Stack was not designed for clarity. Unfortunately, an analysis of the source code confirms this. The current implementation of the protocol has plenty of pointer calculations, insecure data structures, magic constants, parameter validation code copied between functions and other archaic features scattered throughout the code. These are features that developers of modern software tend to eliminate from their code, largely to make their products more secure. At the same time, the code is not very well documented, which makes errors more likely to be introduced in the process of using or modifying it.
Second, OPC UA developers clearly underestimate the trust software vendors have for all code provided by the OPC Foundation consortium. In our view, leaving vulnerabilities in the code of API usage examples is completely wrong, even though API usage examples are not included in the list of products certified by the OPC Foundation.
Third, we believe that there are quality assurance issues even with products certified by the OPC Foundation.
It is likely that use fuzz testing techniques similar to those described in this paper are not part of the quality assurance procedures used by OPC UA developers – this is demonstrated by the statistics on the vulnerabilities that we have identified.
The open source code does not include code for unit tests or any other automatic tests, making it more difficult to test products that use the OPC UA Stack in cases when developers of these products modify their code.
All of the above leads us to the rather disappointing conclusion that, although OPC UA developers try to make their product secure, they nevertheless neglect to use modern secure coding practices and technologies.
Based on our assessment, the current OPC UA Stack implementation not only fails to protect developers from trivial errors but also tends to provoke errors –we have seen this in real-world examples. Given today’s threat landscape, this is unacceptable for products as widely used as OPC UA. And this is even less acceptable for products designed for industrial automation systems.
Allanite threat actor focused on critical infrastructure is targeting electric utilities and ICS networks
10.5.2018 securityaffairs ICS
Security experts from the industrial cybersecurity firm Dragos warn of a threat actor tracked as Allanite has been targeting business and industrial control networks at electric utilities in the United States and the United Kingdom.
Dragos experts linked the campaigns conducted by the Dragonfly APT group and Dymalloy APT, aka Energetic Bear and Crouching Yeti, to a threat actors they tracked as ‘Allanite.’
Allanite APTAllanite has been active at least since May 2017 and it is still targeting both business and ICS networks at electric utilities in the US and UK.
Experts believe the APT group is conducting reconnaissance and gathering intelligence for later attacks.
Today, we're unveiling a public dashboard of ICS-focused activity groups that aim to exploit, disrupt, and potentially destroy industrial systems. Each week this month, we'll release new content discussing these adversary details that you can read here: https://dragos.com/adversaries.html …
4:53 PM - May 3, 2018
83 people are talking about this
Twitter Ads info and privacy
For those that are unaware of Dymalloy APT, the threat actor was discovered by Dragos researchers while investigating the Dragonfly’s operations. The Dragonfly APT group is allegedly linked to Russian intelligence and it is believed to be responsible for the Havex malware.
According to the researchers, the TA17-293A alert published by the DHS in October 2017 suggests a link between Dragonfly attacks with Allanite operations
Dragos experts highlighted that Allanite operations present similarities with the Palmetto Fusion campaign associated with Dragonfly by the DHS in July 2017.
At the same time, the experts believe the threat actor is different from Dragonfly and Dymalloy.
Like Dragonfly and Dymalloy, Allanite hackers leverage spear phishing and watering hole attacks, but differently from them, they don’t use any malware.
Is Allanite a Russia-linked threat actor?
Many security experts linked the APT group to Russia, but Dragos researchers did not corroborate the same thesis.
According to the Dragos, the hackers harvest information directly from ICS networks in campaigns conducted in 2017.
At the time the group has never hacked into a system to cause any disruption or damage.
The report published by Dragos on the Allanite APT is the first analysis of a collection of related to threat groups targeting critical infrastructure.
Summary info on threat actors will be made available through an Activity Groups dashboard, but users interested in the full technical report need to pay it.