Saturday, May 8, 2021

Public ICS Disclosures – Week of 5-1-21

This week we have four vendor disclosures from ABB (2), WAGO, and WEIDMUELLER. There are vendor updates from Dell and Rockwell Automation. We have ten researcher reports for vulnerabilities in products from Delta Industrial Automation.

ABB Advisories

ABB published an advisory discussing the NAME:WRECK vulnerabilities in their AC 800PEC controller based products. ABB provides generic workarounds for the vulnerablity.

NOTE: The NAME:WRECK vulnerability associated with the ABB products is CVE-2016-20009 (WindRiver VxWorks). A report with exploit code was published for this vulnerability in August 2016. See page 9 of the NAME:WRECK report for commentary on this situation.

ABB published an advisory describing a path traversal vulnerability in the Cassia Access Controller for their Ability™ Smart Sensor. The vulnerability was reported by Claroty. ABB reports that the vulnerability has been patched an no action is needed.

WAGO Advisory

CERT-VDE published an advisory describing six vulnerabilities in the Web-Based Management (WBM) of WAGOs industrial managed switches. The vulnerabilities were reported by Dr. Tobias Augustin and Stephan Tigges of IKS, and Kai Gaul and Jan Rubenach of ABO Wind. WAGO has new firmware versions that mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The six reported vulnerabilities are:

• Exposure of sensitive information to an unauthorized actor - CVE-2021-20993,

• Cross-site scripting - CVE-2021-20994,

• Storage of user credentials in a cookie - CVE-2021-20995,

• Incorrect permission assignment for critical resource - CVE-2021-20996, and

• Insufficiently protected credentials - CVE-2021-20997

WEIDMUELLER Advisory

CERT-VDE published an advisory describing an exposure of resource to wrong sphere vulnerability in the WEIDMUELLER u-controls and IoT-Gateways. The vulnerability is self-reported. WEIDMUELLER has a new version that mitigates the vulnerability.

Dell Update

Dell published an update for their Wyse ThinOS advisory that was originally published on March 31st, 2021. There is no indication of what has changed in the advisory.

Rockwell Update

Rockwell published an update for their Logix Controllers advisory that was originally published on February 25th, 2021. The new information includes updating mitigation measures for 1783-CSP CIP Security Proxy.

NOTE: I suspect that NCCIC-ICS will update their advisory in the coming week.

Delta Reports

The Zero Day Initiative published 10 reports (ZDI-21-510 thru ZDI-21-519) for out-of-bounds read vulnerabilities in the Delta DOPSoft products. The vulnerabilities were reported by Natnael Samson. The vulnerabilities have been coordinated with NCCIC-ICS.

Friday, May 7, 2021

Correct FAA Failure to Act

Earlier this week the Department of Transportation published a regulatory review notice in the Federal Register seeking public comments on its current review of “existing regulations and other agency actions to determine whether they are consistent with the policies and National objectives set forth in these executive orders [EO 13990 and EO 13992].” The ‘action’ that I would like to draw to the Department’s attention is the inaction of the Federal Aviation Administration in complying with §2209 of PL 114-190 (130 STAT. 634) , the FAA Extension, Safety, and Security Act of 2016.

The Requirement

On July 15th, 2016 President Obama signed into law HR 636. Section 2209 of that bill required the FAA to “establish a process to allow applicants to petition the Administrator of the Federal Aviation Administration to prohibit or restrict the operation of an unmanned aircraft in close proximity to a fixed site facility” {§2209(a)}. Fixed facilities in the following categories would be able to request designation as an area where unmanned aircraft systems would be restricted from operation {§2209(b)(1)(C)}:

• Energy production, transmission, and distribution facilities and equipment,

• Oil refineries and chemical facilities,

• Amusement parks, and

• Other locations that warrant such restrictions.

Section 2209 gave DOT 180 days from the signing of the bill to establish the process described above. That would have been January 12th, 2017. To date no rulemaking activity has been published, nor is their a listing of such a rulemaking in either the current Unified Agenda or Long Term Actions Agenda.

To Limit Exposure

Part of the intent of Biden policy outlined in §1 of EO 13390 is “to limit exposure to dangerous chemicals and pesticides”. It would seem to me that a key component of ‘limiting exposure’ would be to help chemical facilities prevent accidental or deliberate releases of dangerous chemicals caused by actions or activities of UAS over their facilities. Clearly, this is the intention of §2209. Failure to provide chemical facilities with this security tool substantially limits their ability to address this mode of limiting exposure.

Proposed Action

The Department of Transportation should take immediate action to begin the rulemaking process on this requirement.

NOTE: A copy of this blog post will be submitted as a comment on the referenced DOT notice.

Thursday, May 6, 2021

Ransomware – What to Do?

Increasingly, it looks like Washington is finally waking up to the fact that ransomware is becoming a critical problem for the nation. This means that Congress might actually do something to fix the problem. Okay, if you believe that, I have some land for sale about 20 miles south of Key West. But really though, something does need to be done. What are the options?

Scope of the Problem

When ransomware was affecting just individual computers owned by small businesses and private citizens, it was not an issue of national concern. The money was small potatoes, and the effects were of no consequence to the economy. At this level the ‘solution’ was easy; routinely backing up files would allow owners of ransomed machines to erase the affected files and restore them from secure backups. Still, the key to ransomware at this level was the presence of cryptocurrencies, predominantly Bitcoin, that allowed the attacker to anonymously collect their toll.

To make real money, ransomware authors needed targets with deeper pockets, with more to lose from encrypted computers. Those targets would only be found in larger companies, corporations and government agencies. To be effective, the attacker had to be able to gain access to the internal network of the target and either find the most critical computer to encrypt or encrypt large portions of the network. Single computer backups were still effective so network encryption became the key. Network backups are harder to do (but not impossible by any means) and it is much more time consuming to delete and restore as a mitigation measure as more machines are involved. It was just easier to pay the ransom.

As attackers started increasing the amount of money demanded for removing their encryption, it became easier to justify the time and cost of backup, remove and restore. And it did not take long for attackers to realize that they needed to find another incentive to paying ransoms. They quickly hit on stealing sensitive data as part of their network invasion and encryption attack. If the target does not pay up, they just publicly release the data, ransomware has become extortionware.

Security Measures

The most obvious solution is to make it harder for the attackers to gain access to the network. This is much like rich families in Mexico increasing their personal security staffs to avoid being kidnapped. It works, for a while. Lesley Carhart made an interesting point about this tactic on Twitter®:

“The problem is that they are richy mc rich pants now because everyone paid up, and even if people secure mail really well they can sometimes now afford to buy 0days or really good black hats.”

As the attackers’ resources (money and expertise) increase the cost of defending against them increases even faster. The rich in Mexico have to pay their guards more than the kidnappers are able to pay them to look the other way. We are already at the point where a very large number of potential targets cannot afford (money and/or personnel) the security measures necessary to stop the initial intrusions.

Rather than trying to stop the initial penetration, another tactic might be to stop the spread through the network. If you can keep the problem down to a couple of computers with no sensitive information on them, then the remove and restore process becomes reasonable again, and sensitive information can be protected by encryption at rest (with encryption keys stored off the network). One way to do this is to completely rethink the concept of corporate networks and enforce radical (workgroup level) network segmentation with strong security controls for the minimum necessary movement between segments. This would require extensive system redesigns and a change in many corporate mindsets. A less radical level of network segmentation may be providing benefits, but if it does not allow for removal and restore as a workable ransomware response, it will not provide adequate ransomware protection.

Go After the Money

In the United States, kidnapping is not nearly as prevalent as it is in countries like Mexico. That is because law enforcement (particularly the FBI) has become very effective at investigating, arresting and prosecuting these crimes. And they have principally focused on making it difficult to collect the ransom payment by following the money. There are a couple of problems that make that difficult with respect to ransomware.

The first problem is following the money. Ransomware was not really practical until the advent of cryptocurrencies. That provided for an effectively untraceable method of paying the ransom. As with anything manmade, the anonymity of the transactions has decreased with the advent of blockchain explorers and technology like Coinpath®.

The major difference between kidnappers and ransomwarers (new word?) is that kidnappers have to have a local presence to put their hands on their victims. Ransomwarers can be anywhere in the world. This makes it more difficult to track the attackers. More importantly, in many instances it makes their arrest and prosecution practically impossible.

Tracking the Software

Another path to countering ransomware is tracking the software used to enter, transit and encrypt the systems to be ransomed. Federal intelligence agencies are getting better and better at tracking cyberattacks. Unfortunately, those agencies are not used to track criminal attacks. Law enforcement agencies do not have the same level of cyber tracking capabilities found in the intelligence agencies.

Doing Something

Okay, with all of that, what can Congress do? One suggested remedy has been for Congress to make it illegal to pay a ransomware demand. The thinking is that if the crooks cannot make any money with their attacks, they will not waste their time executing those attacks. A couple of problems with that. First, if affected entities do not report the attack, there is no way for the government to know whether or not they paid a ransom. Operations that figure the cost or recovering their networks in the classic method will be more that the ransom plus government fine will almost certainly pay the ransom and try to prevent the government from knowing that they were attacked.

Another approach being bandied about in the nation’s capital is to provide money to State, local and Tribal governments to help them increase the security on their systems to be able to avoid potential attacks. I certainly do not want stand in the way of that funding, but throwing money at the problem will only allow the politicians to look like they are doing something; see my comments above under security measures.

Another money throwing approach is to increase funding in DOJ (mainly the FBI as the action agency) to allow them to increase their capability to go identify the attackers behind the ransomware attacks. This will certainly help, but it will do little to stop the attackers unless the DOJ is provided with more effective tools that indicting cyber-criminals from Russia, China or North Korea that are unlikely to ever appear in a jurisdiction where they can be brought to trial in the United States.

My Suggestion

Here is a radical idea. Congress can define a ransomware attack on critical infrastructure as an attack on the sovereignty of the United States. They would have to tighten up the definition of ‘critical infrastructure’, but this would allow the President to use the intelligence infrastructure and cyber forces of the US military to ‘go after’ the perpetrators of ransomware. They would primarily be looking to empty bit coin wallets, obtain decryption keys and ‘destroying’ stolen files being used to extort ransomware payments. If they could obtain actionable information that could allow the perpetrators to be arrested and extradited to the United States, great, but disrupting the ability of the attackers to enjoy the fruits of their ‘labor’ would go a long way to reducing the level of ransomware.

2 Updates Published – 5-6-21

Today CISA’s NCCIC-ICS updated two control system security advisories for products from Open Design Alliance and multiple RTOS vendors.

ODA Update

This update provides additional information on an advisory that was originally published on February 16th, 2021. The new information includes:

• Adding a new out-of-bounds write vulnerability, and

• Adding a new affected product that is only affected by the new vulnerability.

NOTE: I briefly described the new vulnerability last Saturday.

Multiple RTOS Update

This update provides additional information on the BadAlloc advisory that was originally published on April 29th, 2021. The new information includes adding:

• Four new integer overflow or wraparound vulnerabilities – CVE-2021-27411, CVE-2021-26706, CVE-2021-27407, and CVE-2020-13603,

• Two new affected products - Micrium uC/LIB and Zephyr Project RTOS, and

• Mitigation measures for the new products.

NOTE: I mentioned the possibility that there would be additional RTOS that were affected last Friday.

Wednesday, May 5, 2021

DOT Publishes Regulatory Review Notice

Today DOT published a notice in the Federal Register (86 FR 23876-23877) that the Department was seeking public input on the regulatory review DOT is conducting in accordance with two Biden Administration executive orders; EO 13990 – “Protecting Public Health and the Environment and Restoring Science to Tackle the Climate Crisis”, and EO 13992 – “Revocation of Certain Executive Orders Concerning Federal Regulation”. DOT is inviting the public to provide input on existing rules and other agency actions for the Department's consideration regarding consistency with the policies and objectives of these executive orders.

The notice discusses the presidential directives from EO 13990 and EO 13992. It also mentions the specific directive from the President for DOT to review the Liquified Natural Gas by Rail rulemaking finalized last summer.

In requesting these public comments, DOT is looking for specific information about each recommendation. The items of interest listed below are not intended to limit target of recommendations, but rather to ensure that the recommendations will provide actionable items for consideration.

Specific reference to regulation or agency action,

Description of the effects of the identified regulation or agency action,

Description of potential alternative action, and

Examples of the affected entities or projects.

Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket number DOT-OST-2021-0036). Comments should be submitted by June 4th, 2021.

Bills Introduced – 5-4-21

Yesterday, with just the House meeting in pro forma session, there were 57 bills introduced. Two of those bills will receive additional coverage in this blog:

HR 2980 To amend the Homeland Security Act of 2002 to provide for the remediation of cybersecurity vulnerabilities, and for other purposes. Rep. Jackson Lee, Sheila [D-TX-18]

HR 2982 To amend title 32, United States Code, to authorize cybersecurity operations and missions to protect critical infrastructure by members of the National Guard in connection with training or other duty. Rep. Kim, Andy [D-NJ-3]

It will be interesting to see if HR 2980 is going to provide DHS with authority to take remote remediation actions like DOJ did with some of the Microsoft email servers.

TSA Extends Surface Transport Security Training Rule Compliance Date Again

Yesterday the TSA published a final rule in the Federal Register (86 FR 23629-23633) amending their Security Training for Surface Transportation Employees rule which was published last year and amended similarly twice, in May 2020 and October 2020. Yesterday’s rule also extends two of the compliance dates in the amended rule. It also corrects what TSA is calling ‘citation errors’ in the original rule.

Extension Dates

First, the rule extends the compliance deadline in §1570.109(b) for security program submission from March 22, 2021, to June 21, 2021.

For owner/operators that have already submitted their security program to TSA (about 30% of the affected organizations), the rule provides an additional 90 days (15 months instead of 12 months) from the date of TSA approval to complete the initial training required by 49 CFR 1570.111(a)(1).

Citation Errors

The first error being corrected is in §1570.203(a). TSA is (as it described in the preamble to the original rule) specifically adding bus operations of a public transportation owner/operator and OTRB owner/operator that are required to provide security training under the rule to the “reporting significant security concerns” requirements of §1570.203(a).

Secondly, the rule addresses an incorrect citation in §1582.101(c). It changes “described in §1580.301” to read “described in § 1580.101”.

Finally, again in §1582.101(c), it changes “paragraph (a)(1) or (a)(2)” to read “paragraph (a) or (b)”.

Effective Date

This direct final rule became effective yesterday, May 4th, 2021.

 
/* Use this with templates/template-twocol.html */