Posts Tagged ‘SCADA’
Wednesday, May 8, 2013 @ 10:05 AM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
Industrial cyber security is now a part of the discussion with heads of state within the international community – the Executive Order – Improving Critical Infrastructure Cybersecurity signed by President Obama in February being just one indication of the importance attached to this issue.
In the past, the main reason for securing a SCADA/ICS network was to protect against inadvertent network incidents or attacks from insiders. The risk of an external malicious cyber-attack was considered minimal.
RELATED STORIES
Securing SCADA: Compensating Controls
Making Patching Work for SCADA, ICS
Good, Bad and Ugly of SCADA, ICS Patching
And then we witnessed the rise of global terrorism in the new millennium — and the disclosure of Stuxnet.
In 2010, Stuxnet was successfully introduced into an apparently ‘air-gapped’ facility with the intent to destroy an industrial process. As I discussed in my blogs on Stuxnet, the worm used multiple methods to infiltrate the target site, the most famous of which was the use of a USB key. Its discovery had multiple effects:
1. The ‘bad guys’ switched their attention to industrial systems. Stuxnet’s fame drew attention to the existence of industrial systems and devices. It also made it clear how insecure they really were. In 2011 more industrial control system (ICS) vulnerabilities were made public (many with exploit codes available on the Internet), than in the entire previous decade. In 2012 there were even more vulnerabilities. 2013 shows every sign of breaking records again.
2. New advanced persistent threats targeting industry began to emerge. Stuxnet wasn’t the first advanced persistent threat (APT), but it was the first to focus on industry. As well, it was so well dissected by security experts that it became an “APTs for Dummies” cookbook on how to write attacks that target industrial companies.
Most recent APTs have focused on industrial espionage to steal business information from the energy industry, but others like Shamoon (which was not all that “advanced” or “persistent”) have been successful at destroying large computer systems. Expect to see lots more APTs discovered in the next few years. And if we don’t see more, it is likely due to the fact that we haven’t found them yet, not that they don’t exist. After all, industrial-focused APTs are clearly effective for their creators, so why would they stop creating them now?
3. Low-grade cyber “warfare” goes mainstream. Stuxnet has been widely attributed to a joint U.S./Israeli project to destroy Iran’s uranium enrichment program. Its existence has given tacit approval to other nations and political groups to use cyber-attacks as a form of undeclared warfare. Most recently, we have seen large scale attacks on South Korea that have been attributed to North Korea.
My advice? If you have critical industrial facilities in any politically sensitive region (such as the U.S., the Middle East or the Far East), now is the time to renew your cyber security efforts.
Networks get Connected
While the threat has increased significantly, the opportunity to connect to a SCADA or ICS system has too. In the good old days, industrial networks ran on proprietary networks, used proprietary equipment, and were isolated from business networks and the internet. This was the era of both ‘security by obscurity’ and ‘security by air gap’ (if you are a regular reader of my blog, you’ll know my views on the air gap theory).
But over the last decade, things have changed. Industrial networks have migrated from proprietary systems to commercial off-the-shelf technology like Ethernet, TCP/IP and Windows. What’s more, today’s industrial systems require a constant stream of updates from the outside world. There’s no denying it – the industrial floor is no longer isolated.
It’s also true that devices such as programmable logic controllers (PLCs) and distributed control systems (DCS) were designed with a focus on reliability and safety, rather than security. This makes many of them, particularly older units, easy to exploit. And the protocols that SCADA and ICS use to communicate are no different – designed to be reliable and easy to troubleshoot, most protocols lack even the most basic security features like authentication. As the Tofino test team likes to say, “If you can ping it, you can own it”.
Perfect Storm
Today it is clearly a game with the advantage going to the attacker – millions of decades-old systems that were never designed to be secure, increasing connectivity of SCADA and ICS, and a growing library of free tools and techniques to attack SCADA and ICS.
It’s evident then that there’s no simple solution to securing our critical infrastructure. The process is going to take a lot of time and effort – and very careful planning. But regardless of the pain points involved, investing in industrial network security is not only responsible, it’s necessary for any mission critical application.
If our heads of state are taking this issue seriously then so should industry.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.
Wednesday, April 24, 2013 @ 07:04 PM gHale
Wireless critical infrastructure control systems could suffer from attacks carried out over Software Defined Radio (SDR), security researchers said.
SCADA (Supervisory Control and Data Acquisition), Building Management Systems (BMS) and PLCs (Programmable Logic Controllers) all use a proprietary wireless technology which could potentially suffer from a hack using SDR equipment and a PC. The specialist data communicated by these systems could end up intercepted, captured and replayed to suspend service and cause widespread disruption, said researchers at Digital Assurance.
RELATED STORIES
Reflecting on Bioterrorism Threat
Ensuring Algae Remains Renewable
Software Cuts Wireless Traffic
Microgrid Project in Solar Village
These systems will also be at greater risk in the future as smart meters come online, increasing the attack surface of the network. The lowering price point, advances in processing power and difficulties in detecting SDR attacks are also likely to increase its appeal, the researchers said.
SCADA industrial control systems monitor and regulate utility services across multiple sites and distances and had some protection by the relative obscurity of the network in the past. Those days, however, are gone.
With up to 53 million smart meters across 30 million homes and businesses coming online between 2014-2019, the number of potential access points on to the network should increase dramatically.
The data relayed between these end devices can end up intercepted, captured, jammed or replayed using SDR equipment, providing the hacker with network-wide access to field devices, control stations, generating stations and transmission facilities, the researchers said.
Smart meters, which use the Zigbee standard, are vulnerable to signal capture. Chosen for its energy efficiency, Zigbee has suffered compromise before. Keys transmit in the clear, transmissions are prone to interference, and in the event of a signal jam, frequency hopping capabilities are poor. Attempts have gone on to secure Zigbee through authorization and pre-configured security keys but both require additional system management.
The lowering price point and ease of use of SDR equipment make it the ideal tool with which to capture, intercept and manipulate Zigbee and other widely used wireless standards, Digital Assurance researchers said. It has overcome many of the obstacles associated with wireless hacking, such as frequency hopping or advanced modulation techniques, and eradicates the need for expensive equipment or an in-depth knowledge of wireless standards on the part of the hacker.
SDR works by capturing radio frequency signals using a high-speed ADC (Analogue to Digital Converter) enabling the direct digitization of the radio frequency signal which can then undergo analysis by a DSP (Digital Signal Processor) before converting into output data stream. The user can analyze slices of spectrum, looking for carriers and modulated signals and go on to isolate the preamble and the payload, or message headers if searching for data streams, for instance.
“Wireless assaults on critical infrastructure will grow exponentially over the next few years, in line with the rollout of smart grid networks, and SDR provides the hacker with an opportunity to jump onto parts of this network,” said Greg Jones, Director, Digital Assurance. “To date, critical systems have relied upon their relative obscurity to protect them but that will have to change. The only way of protecting a wireless device from an SDR attack at present is to ensure that it has been designed, configured and deployed to resist over-the-air attacks. Very few vendors of such equipment will give this type of assurance so independent testing is currently the only option until the industry applies itself to developing a solution.”
Thursday, April 11, 2013 @ 02:04 PM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
When it comes to patching in SCADA and industrial control systems, there are pros and cons of using compensating controls as an alternative.
We all understand why rapid and continuous patching just won’t work on the plant floor. Fortunately, there are alternatives – otherwise known as “compensating controls.”
In the telecommunications industry, compensating controls are widely used to safely delay patch deployments so they can be incorporated into regular maintenance schedules. For example, telecommunications equipment vendors often suggest configuration changes that will block exploits of a known vulnerability without requiring a patch. Microsoft also offers this service to customers – included in most Security Bulletins is a section called “Workarounds,” which they define as:
RELATED STORIES
Making Patching Work for SCADA, ICS
Good, Bad and Ugly of SCADA, ICS Patching
SCADA Security: Open Phishing Season
IF-MAP for ICS, SCADA Security
“Workaround refers to a setting or configuration change that does not correct the underlying vulnerability but would help block known attack vectors before you apply the update.”
So far, only a few SCADA/ICS vendors have offered this strategy, but the possibilities are numerous. For example:
• Product Reconfiguration (e.g. Disable the HTTP port)
• Suggested Firewall Rules (e.g. Block all HTTP traffic)
• Suggested IDS Rules/Signatures (e.g. Install signatures for logins using a default password)
Basically, these controls aim to prevent any potentially “dangerous” traffic from getting to the device in the first place. In other words, if you can’t directly fix the flaw, remove the conditions where it could occur.
Advantages of Compensating Controls
The compensating controls strategy offers some clear benefits for vendor and customer.
Compensating controls are safer. Patches that turn out to be flawed usually cannot be removed from a system. However, removing an incorrect compensating control is often trivial.
Compensating controls put the asset owner in control of his/her fate. Patches can affect the entire operating system in a controller or computer. This often results in unintended consequences that are hard to predict. By using a compensating control, such as blocking a vulnerable service, it is easier to understand the impact on the industrial process.
Compensating controls can be released independently of product development and typically require less QA effort. This translates into a faster response to the customer’s security needs.
Compensating controls are independent of the product firmware. This means they often have less impact on product functionality, lowering customer resistance to using them. Finally, this strategy allows support of legacy products that are too old to justify the effort of a full firmware release.
Limitations of Compensating Controls
Of course, there are some limitations to this strategy. For example, vulnerabilities that involve encrypted sessions (such as HTTPS) often cannot be addressed with compensating controls – because it can be difficult to decrypt and inspect the traffic. But for a large number of the PLC and DCS vulnerabilities we have seen, the technique works well.
Requirements for Success
For compensating controls to work on the plant floor, there are a number of key requirements.
First, they must have a low impact on process reliability and safety. Any security “solution” that impacts process reliability or safety will be rejected by the end user.
Second, they must be simple to deploy. In the words of a manager of a chemical company to the ISA99 Committee on Control System Security: “We have to make this [security] something a plant superintendent, engineer, or senior operator can do in their spare time, or it will flop.”
For example, if the compensating control involves hardware, then the field technician should be required to do no more than:
1. Attach the hardware to a DIN rail or panel.
2. Attach instrument power.
3. Plug in network cables.
4. Walk away…
Good examples of this “Zero Configuration Deployment” strategy are the “Fixed Configuration Firewalls” offered by a number of Safety Integrated System (SIS) vendors. These firewalls contain factory configured protocol and signature rule sets designed specifically to match product and vulnerability requirements. They require no configuration by the end user – they just work out of the box.
But that isn’t the only benefit.
• Compensating controls are easy to install.
• Compensating controls can often be installed in a live system without requiring a shutdown.
• Compensating controls are easily upgradeable to address new threats as they appear.
Compensating Controls Strategy Secures Exposed PLCs
An excellent example of how compensating controls can quickly defend against vulnerabilities was demonstrated by Schneider Electric in late 2011. In December of that year, security researcher Ruben Santamarta publicly disclosed details of multiple vulnerabilities in Schneider’s Modicon PLC product line.
At the time of the disclosure, Schneider had produced a fix for two of the reported vulnerabilities, but was still working on patches for the others.
To help customers secure their PLCs while the other patches were being developed and tested, Schneider produced a guide entitled “Mitigation of the PLC Vulnerabilities Using a Tofino SA.” This detailed guide explained how to use an industrial firewall to filter out harmful traffic before it reached the PLC.
Special Rules for Complex Issues
In the Schneider Electric example, some of the mitigations were pretty simple to create. For example, blocking a debug service vulnerability was simple. All the user had to do was install a firewall. As long as they didn’t specifically add rules allowing the debug traffic, the vulnerability was mitigated.
Other mitigations can be more intricate.
For example, the FTP Buffer Overflow vulnerability (ICS-ALERT-12-020-03) could have been addressed by just blocking all FTP traffic. Unfortunately, since FTP traffic was essential for some processes, that approach wasn’t acceptable to Schneider’s customers.
Instead, we worked with Schneider to create “Special Rules.” These rules contained algorithms that looked specifically for the behaviors that suggest the FTP protocol is being exploited. If this behavior is discovered, then FTP messages are immediately blocked by the firewall.
Using Security Profiles with Compensating Controls
All these mitigations were easy to deploy through the use of “Security Profiles.” A security profile is a collection of firewall rules, special rules, and protocol definitions designed to address the vulnerabilities for a specific control product. The profile can also include complex checks that a traditional firewall cannot achieve.
Combining the security profiles with the firewall allowed Schneider to provide a defense for their customers. A defense that was immediately effective – and that did not require any changes to automation equipment or network configurations. Schneider clients could download a single, easy-to-deploy package of tailored rules they could deploy without impacting operations.
Site engineers could confirm the new rules would not harm their operations. As a result, industrial facilities can defend themselves against new threats without having to rely solely on patches for their PLCs, DCS and network hardware.
Strategies for Secure Control Systems
There is no denying SCADA and industrial control systems are difficult and risky to patch rapidly. Patching can work – but only when it is based on proper change control and aligns with maintenance schedules.
Furthermore, a patch strategy depends on the rapid release of well-designed and tested software updates for all control products as vulnerabilities are discovered. In my experience, when looking for a way to secure SCADA and industrial control systems, adopting a compensating controls strategy is a much more flexible and much less risky alternative.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.
Thursday, April 4, 2013 @ 03:04 PM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
From past writings on patching for control system security, you may think I am completely against patching. Guess what? I’m not against them!
Actually, I think applying patches is a critical part of good security. According to US-CERT, about 95 percent of all network intrusions could have been avoided by keeping systems up to date with appropriate patches. If you never patch, you are leaving your system open to a decade of malware.
RELATED STORIES
Good, Bad and Ugly of SCADA, ICS Patching
SCADA Security: Open Phishing Season
IF-MAP for ICS, SCADA Security
SCADA Security Directions
What I am against is patching as a knee-jerk reaction to security vulnerabilities. You can’t expect your control system to operate reliably if you don’t have a controlled process for patching.
In the words of Richard Brown, at Dow Chemical:
“Patch management is about managing the risk of change.”
Patches are changes to your system. Changes to your system need to be managed. One cannot blindly deploy new patches into the process control environment without risking disruption of operations. Thus careful policy and practice is required to balance the need for system reliability with the need for system security.
Prioritize Your Security Patches
There are a number of recommendations on patch management, but one of my favorites comes from the Edison Electric Institute (EEI). Their suggestion is to push down patches to machines on a priority basis. The priorities are based on two factors: the criticality of the system being patched and the criticality of the patch.
The EEI process requires two sub-systems to be set up. The first sub-system involves an inventory in which all machines are prioritized and categorized into groups that define when and how they are to be patched.
Some examples are “Early Adopters,” who receive patches as soon as available and act as Test/Quality Assurance machines. Typically, these are lab or training computers. “Business Critical” machines are those that are patched automatically when early adopters have been stable for a set period of time (depending on the patch’s level of risk) and approval for the patch has been received from the control system vendor. This escalates up to “No Touch” machines that require manual intervention and/or detailed vendor consultation before a patch is applied.
The second sub-system is a procedure for keeping track of newly released patches and their level of importance to process operations. Whenever a new vulnerability is announced and/or a patch fix is available, it is tracked for its potential impact — good and bad — on the company control system. This patch is then evaluated and prioritized for adoption based on its risk evaluation.
For example, the risk evaluation could follow a set process of questions to decide on urgency of patching and level of testing required. These questions might include such concerns as “Are we currently being exploited?” or “What is the severity level designated by the vendor?” or “Has it been tested by the vendor?”
The risk evaluation would result in an overall implementation level being set. Considerable guidance for making this evaluation is available from vendor sites, such as Honeywell’s Microsoft Security Hot Fixes Qualification Matrix (you’ll need login credentials to access this), which report on the testing status of newly released patches.
Implement a Patch Reaction Plan
The patch implementation levels are preset and tied to Reaction Plans. There are several different types of Reaction Plans. These vary according to the risk of not applying the patch.
For example, if the risk that a given patch addresses is low, then the adoption and testing cycle can be slower. If it is a very high risk, then the patch needs to be deployed more aggressively.
Any patching plan requires close cooperation with all software and system vendors. Many vendors already have a system of prioritizing patches and approving their application that should be tied into the internal patch management system. As mentioned earlier, Honeywell maintains a patch approval process that usually approves patches for their newer versions of software within five days of a Microsoft patch release — and often within hours if the patch is critical.
Once the decision is made to patch a system, it is critical to have a secure method to distribute those patches. Distributing them directly from the business systems is not a good idea. For example, the Honeywell Security Guidelines state:
“It is not best practice to distribute Microsoft hotfixes, patches, and updates to virus definition files directly from the business network to nodes on the process control network as this is contrary to the goal of minimizing direct communication between nodes on these networks.”
Most vendors recommend that a dedicated patch manager and an anti-virus server be located in the Demilitarized Zone (DMZ) between the control system and the IT network. Both roles can be often performed by a single server.
Finally, there are a number of automated tools and services available to assist companies in performing patch management. These typically include methods to inventory computers, identify relevant patches and workarounds, test patches, and report network status information to various levels of management.
Using this type of tool can significantly improve the response time for deploying critical patches, while at the same time reducing the work load on process control or security staff. For example, a major company involved in food processing reported that a single individual was able to successfully manage all PCN patching over six large company sites once the company deployed a patch management tool.
“Planned Patching is Good. Reactive Patching is Bad”
Don’t get me wrong, I’m not saying don’t patch! Far from it — patching for vulnerabilities is critical for good security. However, the IT strategy of rapid, reactive, continuous patching on a regular basis just isn’t feasible for SCADA and ICS systems.
For a patching strategy to be successful it must be planned properly and it must include testing and change management controls. Without these processes in place, you are putting the control system at serious risk.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.
Friday, March 29, 2013 @ 04:03 PM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
It is time to take a look at the good, the bad and the ugly details of patching as a means to secure SCADA and ICS systems. And to begin, let’s suppose you could install patches without shutting down the process (for example, through the staged patching of redundant controllers).
In a landmark study of the patches for post-release bugs in OS software, between 14.8 percent and 24.4 percent of all fixes are incorrect and directly impact the end user. And if that’s not bad enough, 43 percent of these faulty ‘fixes’ resulted in crashes, hangs, data corruption or additional security problems.
RELATED STORIES
SCADA Security: Open Phishing Season
IF-MAP for ICS, SCADA Security
SCADA Security Directions
BYOD Coming to Plant Floor
Address SCADA Vulnerabilities Now
What’s more, patches don’t always solve the security issues they were designed to address. Kevin Hemsley, a member of the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), said in 2011 ICS-CERT saw a 60 percent failure rate in patches fixing the reported vulnerability in control system products.
Good Patches Can Cause Issues
Most patches require the shutdown and restart of the manufacturing process. Some can also break or remove functionality previously relied on by the control system. For example, one of the vulnerabilities the Stuxnet worm exploited was a hardcoded password in Siemens’ WinCC SQL database.
At the time, Siemens was widely criticized for not quickly releasing a patch to remove the password. However, customers who took it upon themselves to manually change the password soon discovered that many critical control functions depended on this password to access accounts. In this case, the “cure” was even worse than the disease.
Patching Often Requires Experts
Another ugly truth about patching is that the process itself often requires staff with special skills to be present.
For example, the vulnerability exploited by the Slammer worm in January 2003 actually did have a patch (MS02-039) released in 2002. Unfortunately, this didn’t help an oil company with numerous production platforms in the Gulf of Mexico. The company started rolling out the patch in the summer of 2002, but issues with server restarts required Windows experts to be present during patching. Since very few of these experts were safety certified for platform access, most platforms were still not patched when Slammer hit six months later.
When There Are No Patches
Of course, you can only use patches to fix vulnerabilities if the vendor has created a patch. Unfortunately, this is the exception rather than the rule. At the SCADA Security Scientific Symposium (S4) in January 2012, Sean McBride noted less than half of the 364 public vulnerabilities recorded at ICS-CERT had patches available at that time.
Some accuse the vendors of indifference or laziness, but there are many factors that prevent the quick release of a patch.
In 2010, a major ICS vendor said internal testing of a mission critical product had revealed security issues. Unfortunately, these vulnerabilities were part of an embedded OS supplied by a 3rd party. The OS supplier refused to address the vulnerabilities, and so the ICS vendor (and its customers) faced a situation where patching was not possible.
In a 2011 case involving another ICS vendor, vulnerable backdoors were found in a PLC by an independent security researcher, who publically exposed them. The vendor designed a patch to remove backdoors, but then learned these backdoors were widely used by troubleshooting teams for customer support. To complicate matters, the company’s quality assurance (QA) process for product changes required four months to complete. This meant that even if customers were willing to sacrifice support for security, they were faced with a four month window of exposure while they waited for the proper testing of patches to be completed.
Users Choose Not to Patch
My last example highlights a core problem with a patch-based strategy for control system security. Many customers simply don’t want to run the risk of degrading service and increasing downtime. The vendor noted in the previous example privately told me they have a 10 percent patch download rate for released patches.
My own experience with an ICS security product confirms the reality of low patch acceptance in the field.
In September 2010, we released Tofino Industrial Security System version 1.6. This upgrade addressed a number of security and performance issues and was offered to all registered users at no charge — if downloaded within 30 days. Initial acceptance was low, so we repeated the offer for an additional 30 days. After two months, only 30 percent of users had downloaded the free upgrade. And that doesn’t necessarily mean they all installed it.
Planned Patching is Good
Let’s be clear — patching bugs is an important process for any control system. And patching for vulnerabilities is critical for good security. But the IT strategy of reactive, continuous patching on a monthly or weekly basis just won’t work for SCADA and ICS systems. Patching in a hurry is just plain dangerous.
SCADA/ICS vendors face multiple issues when trying to create “quick” patches — they have to consider safety and QA requirements that often delay patch releases. In other cases, a reasonable and safe patch just isn’t possible.
SCADA/ICS customers face similar concerns. And quite frankly, who can blame them for not wanting to increase downtime or expose their critical controller or server systems to safety risks?
Patch support for legacy products is also an issue – many expect a control product to operate for 20 years, putting it well outside the typical IT support window. Finally, as noted in the Slammer worm example, patches can require significant staff resources to install safely.
So create a patching plan that works for your process environment. Make sure that it includes processes for proper tests and change management controls.
Just don’t expect patches to be a quick fix for your control system’s security problems. If you do, you may discover new problems that are worse than the bugs the patches cure.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.
Thursday, March 21, 2013 @ 07:03 PM gHale
Schneider Electric released mitigations for vulnerabilities discovered during the Digital Bond SCADA Security Scientific Symposium, but they beg to differ on other issues a researcher disclosed.
Schneider released mitigations for the remotely exploitable vulnerabilities found by independent researcher Arthur Gervais who identified two vulnerabilities in the common Ethernet modules used across a broad range of Schneider’s PLC products, according to a report on ICS-CERT. The company does not plan to issue patches saying fixing these vulnerabilities would require significant changes to existing protocols and make any customer solutions currently using these features incompatible.
RELATED STORIES
SIMATIC Update Solves Bugs
Siemens Mitigates WinCC TIA Bugs
Schneider Mitigates Vulnerabilities
Indusoft Produces Hotfix for Bug
Additional issues reported by Gervais have also been investigated and the vendor and researcher disagree on whether Magelis XBT HMI issue is a valid vulnerability.
The Magelis XBT HMI panels have a security mode where a password must enable remote configuration uploads. After this mode initially enables, a factory default password is available. The user does not get a prompt or requirement to supply a new password, although this capability is available. Once the user supplies a new password, the factory default password is no longer valid. This does not fit the definition of a hard-coded password, because a user can change it. Users should be aware of the potential for configuration errors that can lead to significant security issues.
In addition, Schneider could not duplicate the reported Resource Exhaustion issue affecting the M340 PLC family given the information supplied by the researcher. Software versions or specific configuration differences could account for the inability of the vendor to duplicate the results. In Schneider Electric’s testing on this issue, the communications module does in fact stop communicating when the connection limit ends up exceeded, but the PLC continues its control functions and its operation remains unaffected. After the connection limit ends up exceeded, the communications module performs a soft reset. An attacker could not remotely exploit this observed behavior to deny PLC control functions. Because Schneider could not duplicate the researcher-reported behavior, the vendor could not go any further without more specific detailed information.
Other than that, Schneider does have mitigation details for an improper authentication vulnerability and cross-site request forgery vulnerability in its Modicon, Premium, and Quantum PLC modules.
Gervais identified multiple vulnerabilities in the common Ethernet modules used across a broad range of Schneider Electric’s PLC products.
The following Schneider Electric products suffer from the issue:
• Modicon M340 PLC modules
• Quantum PLC modules
• Premium PLC modules
A malicious attacker may remotely halt, reset, or change settings for PLC modules by exploiting these vulnerabilities. This could affect products deployed in the critical manufacturing, energy, water, agriculture and food, dams, transportation, postal, nuclear, government facilities, and defense industrial sectors worldwide.
The affected PLC products, Modicon M340, Quantum, and Premium lines are PLC devices used in the United States, China, Russia, and India, and throughout the rest of the world.
Products supporting the Factory Cast feature, including the Modicon M340, Quantum, and Premium PLC ranges, allow users to send Modbus messages embedded in HTTP POST requests using SOAP messages.
Modbus commands sent to the PLC via this mechanism do not undergo authentication. These messages can result in unintended consequences such as halting operation or modification of I/O data to and from the PLC. CVE-2013-0664 is the number assigned to this vulnerability, which has a CVSS v2 base score of 10.0.
The affected devices incorporate a Webserver interface that receives requests from clients without a mechanism verifying it was intentionally sent. It is possible for an attacker to trick a client into making an unintentional request to the Webserver, which would end up treated as an authentic request.
Valid commands could go to the PLC via specially crafted HTTP requests. CVE-2013-0663 is the number assigned to this vulnerability, which has a CVSS v2 base score of 8.5.
Schneider Electric has not issued a patch or software update to mitigate these vulnerabilities, but has issued a vulnerability disclosure notification that contains the following recommended mitigations for both vulnerabilities:
• Do not connect the affected PLC modules to an untrusted network.
• If a users need to make such a connection, block all HTTP access to the module from untrusted IP addresses using a firewall, and only allow HTTP connections from known IP addresses from secured workstations.
Thursday, March 14, 2013 @ 05:03 AM gHale
By Gregory Hale
Patching is often ineffective in providing protection from the multitude of vulnerability disclosures and malware targeting critical infrastructure systems today, new research shows.
While patching such systems is important as part of an overall defense in depth strategy, the difficulties of patching for industrial systems mean that compensating controls are often a better method of providing immediate protection, according to research from Tofino Security.
RELATED STORIES
Downtime: Utility Suffers Virus
Antivirus Not Catching New Viruses
Symantec Antivirus Bug
Sophos Fixes Critical Security Hole
Since the discovery of the Stuxnet malware in 2010, industrial infrastructure has become a key target for security researchers, hackers, and government agents. Designed years ago with a focus on reliability and safety, rather than security, Supervisory Control and Data Acquisition (SCADA) and Industrial Control Systems (ICS) are often easy to exploit.
As a result, there has been exponential growth in government security alerts for these systems in the past two years. In addition, they have attracted some of the most sophisticated (Stuxnet, Night Dragon, Flame) and damaging (Shamoon) cyber attacks on record.
The report, conducted by Eric Byres, CTO and vice president of engineering at Tofino Security, found:
• The number of vulnerabilities existing in SCADA/ICS applications is high, with as many as 1,805 vulnerabilities not yet found existing on some control system computers. After analyzing the amount of software on the average control PC in a refinery and then using a metric called Defect Density to calculate the number of expected vulnerabilities, the research showed this one refinery had 1,805 possible vulnerabilities for the average PC.
• The frequency of patching needed to address future SCADA/ICS vulnerabilities in controllers and computers likely exceeds the tolerance of most SCADA/ICS operators for system shutdowns. Unlike IT systems, most industrial processes operate 24×7 and demand high uptime. Weekly shutdowns for patching are unacceptable.
• Even when a user can install patches, they can be a problem. There is a 1 in 12 chance any patch will affect the safety or reliability of a control system, and there is a 60 percent failure rate in patches fixing the reported vulnerability in control system products. In addition, patches often require staff with special skills. In many cases, such experts often do not have proper certification for access to safety regulated industrial sites.
• Patches are available for less than 50 percent of publicly disclosed vulnerabilities.
• Critical infrastructure operators are reluctant to patch as it may degrade service and increase downtime.
When patching is not possible, or while waiting for a semi-annual or annual shutdown to install patches, an alternative is to deploy a workaround, also known as a “compensating control.” Compensating controls do not correct the underlying vulnerability; instead, they help block known attack vectors. Examples of compensating controls include product reconfigurations, applying suggested firewall rules, or installing signatures that recognize and block malware.
Another compensating control is rule and protocol definitions that address newly disclosed vulnerabilities. They provide a way for automation system vendors to create and securely distribute malware protection. Operators benefit from a package of tailored rules they can install without impacting operations. The result is critical industrial infrastructure facilities can quickly and effectively defend themselves against new threats.
“My research highlights the multiple challenges with patching for SCADA and ICS systems,” Byres said. “To secure facilities, critical infrastructure operators should pursue a defense in depth strategy that includes patching when possible, and use compensating controls for protection when patching is not possible.”
Click here for more information on ICS and SCADA patching from Eric Byres.
Friday, March 8, 2013 @ 05:03 PM gHale
Indusoft created a fix that mitigates a directory traversal vulnerability in Indusoft Studio and Advantech Studio applications, according to a report on ICS-CERT.
Indusoft originally produced this product that ended up rebranded to Advantech Studio (both products share the vulnerability).
RELATED STORIES
Emerson Issues Controller Hotfix
Mitigation for Emergency Broadcast System
Report: Holes Not Vulnerabilities After All
Schneider Faces Product Bugs
This remotely exploitable vulnerability — discovered by independent researcher Nin3 who released proof-of-concept (PoC) exploit code without coordination with ICS-CERT, the vendor, or any other coordinating entity known to ICS-CERT – has publicly available attacks targeting this vulnerability.
The following product versions suffer from the issue:
• Advantech Studio V7.0 and previous
• Indusoft Studio V7.0 and previous
Successful exploitation of this vulnerability could allow an attacker to download arbitrary files from the target system.
Indusoft designed and maintains Advantech Studio, which is a collection of automation tools that includes components required to develop human-machine interfaces (HMIs) and supervisory control and data acquisition (SCADA) system applications that run on various Windows platforms.
According to Advantech, Advantech Studio currently sees use at nearly 2,000 installations worldwide. Advantech Studio is in a variety of applications including energy, building automation, water and wastewater management, and manufacturing.
InduSoft products often integrate in as third-party components in other vendors’ products. Indusoft is a U.S.-based company that sells through distributors worldwide.
Advantech Studio contains a flaw in the CreateFileW function of the sub_401A90 routine in the NTWebServer.exe file. The issue occurs when handling an absolute path request, which may allow a remote attacker to gain access to arbitrary files.
CVE-2013-1627 is the number assigned to this vulnerability, which has a CVSS v2 base score of 7.8.
An attacker with a low skill would be able to exploit this vulnerability.
Indusoft created a hotfix for this vulnerability. In order to install the hotfix, customers should send a request to support@indusoft.com. Indusoft will send the installation files and assist the customer through the installation process.
Friday, March 8, 2013 @ 03:03 PM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
Last week I received an email purporting to be from the U.S. Internal Revenue Service (IRS).
Notice the U.S. Internal Revenue Service now uses Cyrillic script on its staff email addresses! And they use AOL as an email service, rather than irs.gov. (Is the U.S. budget sequestration really hurting that badly?
RELATED STORIES
IF-MAP for ICS, SCADA Security
SCADA Security Directions
BYOD Coming to Plant Floor
Address SCADA Vulnerabilities Now
The third fun item is that the link you are supposed to click on (irs.gov/pub/irs-pdf/forms2012/) actually resolves to prospectrealty.net/wp-content/plugins/Bridge-Book-Printer/forms.htm. (Note to Prospect Realty – you might want to secure your web site a little better.)
Obviously, this email is a phishing attack. The creators of the email want me to click on the fake IRS link. If I did, my browser would be directed to the Prospect Realty website they have hacked. There I would either see a page that looked like an IRS log-in page (so the crooks could steal any confidential corporate information I enter) or the site would try to download some nasty Java applet that would take over my computer (assuming I hadn’t patched Java recently).
This phishing attack is so crude and so obvious that it is funny.
But in another way, it isn’t funny at all.
Attacks like this only continue if they make their creators money. And the criminals behind them have very simple and effective ways to determine if their attacks are effective. They launch the email and then count the number of suckers that click in the next few hours. If they don’t get any clicks, they try something different. If they get enough victims, they launch the attack again against a new list of email addresses.
Now I received this same phishing email multiple times over several days – which leads me to believe that it was effective for the bad guys. Poor sods were clicking on the links. And these aren’t just any poor sods. Remember that this email is addressed to employers – not grandma or grandpa. So the email is an attack on the accounting teams in corporations, a group one might hope is very computer savvy.
So what is my point? In the SCADA and ICS world we worry a lot about highly sophisticated threats like Stuxnet attacking our companies. Yet it seems that completely amateurish attacks work too (remember Shamoon?). Crooks don’t need sophisticated teams of hackers to be successful in cybercrime. All they need are employees to be so poorly trained that they click on even the most obvious phishing email.
Industry has a long way to go to make IT and SCADA systems truly secure. To get there, it will cost a lot of money. But it seems like there are a lot of baby steps that still aren’t being taken on the road to security. Maybe it is time to take another look at those.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.