15 Advisories Published – 4-13-21

Today CISA’s NCCIC-ICS published 15 control systems security advisories for products Siemens (12), JTEKT, Advantech, and Schneider Electric. One of the Siemens advisories also affects products from Milestone and another also affects products from PKE.

Milestone Advisory

This advisory describes a use of hard-coded cryptographic key in the Siemens Siveillance (Milestone) Video Open Network Bridge (ONVIF). The vulnerability was reported by Milestone PSIRT. Siemens has a hot fix and Milestone has an update to mitigate the vulnerability.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an authenticated remote attacker to retrieve and decrypt all user credentials stored on the ONVIF server.

Nucleus Advisory #1

This advisory describes a use of insufficiently random variables vulnerability in the Siemens Nucleus DNS module. This is one of the NAME:WRECK DNS vulnerabilities reported by Forescout and JSOF. Siemens has generic workarounds to mitigate the vulnerability.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit this vulnerability to allow an attacker to poison the DNS cache or spoof DNS resolving.

SIMOTICS Advisory

This advisory describes four vulnerabilities in the Siemens SIMOTICS CONNECT 400. The vulnerabilities were self-reported. These are NAME:WRECK vulnerabilities in the third-party Mentor DNS Module. Siemens has a new version that mitigates the vulnerabilities.

The four reported vulnerabilities are:

• Improper null termination - CVE-2020-27736,

• Out-of-bounds read - CVE-2020-27737, and

• Access of memory location after end of buffer - CVE-2020-27738 and CVE-2021-25677

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to allow an attacker to poison the DNS cache or spoof DNS resolving.

Tecnomatix Advisory

This advisory describes an out-of-bounds write in the Siemens Tecnomatix RobotExpert. The vulnerability was reported by Francis Provencher via the Zero Day Initiative. Siemens has a new version that mitigates the vulnerability. There is no indication that Provencher has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow remote code execution.

TIM Advisory

This advisory describes 14 vulnerabilities in the Siemens TIM 4R-IE. This is a third-party vulnerability (ntp.d in SNTP). The vulnerabilities are self-reported.

The 14 reported vulnerabilities are:

• Incorrect type conversion or cast - CVE-2015-5219,

• Improper input validation (4) - CVE-2015-7855 (exploit), CVE-2015-7705, CVE-2015-8138, and CVE-2016-1547,

• Improper authentication (2) - CVE-2015-7871 and CVE-2016-4953

• Security features - CVE-2015-7973,

• Null pointer dereference - CVE-2015-7977,

• Data processing errors (2) - CVE-2015-7979 and CVE-2016-1548,

• Exposure of sensitive information to an unauthorized actor - CVE-2016-1550, and

• Race condition - CVE-2016-4954

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to compromise the confidentiality, integrity, and availability of the device.

PKE Advisory

This advisory describes twelve vulnerabilities in the Siemens (and PKE) Control Center Server (CCS). The vulnerabilities were reported by Raphaël Rigo of Airbus Security Lab. Siemens (and PKE) has new versions that mitigate the vulnerabilities. There is no indication that Rigo has been provided an opportunity to verify the efficacy of the fix.

The 12 reported vulnerabilities are:

• Cleartext storage of sensitive information in GUI - CVE-2019-13947,

• Improper authentication (2) - CVE-2019-18337 and CVE-2019-18341

• Relative path traversal - CVE-2019-18338,

• Use of a broken or risky cryptographic algorithm - CVE-2019-18340,

• Exposed dangerous method or function - CVE-2019-18342,

• Path traversal - CVE-2019-19290,

• Cleartext storage in a file or on a disk - CVE-2019-19291,

• SQL Injection - CVE-2019-19292,

• Cross-site scripting (2) - CVE-2019-19293 and CVE-2019-19294, and

• Insufficient logging - CVE-2019-19295

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to allow an attacker to read and write arbitrary files and sensitive data and execute commands and arbitrary code.

NOTE: These vulnerabilities were removed from earlier Siemens Advisories, SSA-761617 and SSA-844761.

LOGO! Advisory

This advisory describes two vulnerabilities in the Siemens LOGO! engineering software products. The vulnerabilities were reported by Mashav Sapir from Claroty. Siemens provides generic workarounds to mitigate the vulnerabilities.

The two reported vulnerabilities are:

• Path traversal - CVE-2020-25243, and

• Uncontrolled search path element - CVE-2020-25244

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow a local attacker to take over the system where the software is installed.

NOTE: Someone slipped up on the listing of ‘Equipment’ and ‘Vulnerability’ in the ‘Executive Summary’ section of the advisory.

SINEMA Advisory

This advisory describes two vulnerabilities in the Siemens SINEMA Remote Connect Server. These are third-party vulnerabilities (libxml2). Siemens has a new version that mitigates the vulnerabilities.

The two reported vulnerabilities are:

• Missing release of resource after effective lifetime - CVE-2019-19956, and

• Infinite loop - CVE-2020-7595

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to allow an attacker to cause a memory leak or an infinite loop situation resulting in a denial-of-service condition.

SCALANCE Advisory

This advisory describes two vulnerabilities in the Siemens Web Server of SCALANCE X200. The vulnerabilities are self-reported. Siemens has a new version that mitigates the vulnerabilities.

The two reported vulnerabilities are:

• Heap-based buffer overflow - CVE-2021-25668, and

• Stack-based buffer overflow - CVE-2021-25669

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to cause a buffer overflow condition resulting in remote code execution.

Solid Edge Advisory

This advisory describes five vulnerabilities in the Siemens Solid Edge software tools. The vulnerabilities were reported by Francis Provencher and rgod via ZDI. Siemens has updates that mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The five reported vulnerabilities are:

• Out-of-bounds write - CVE-2020-28385, CVE-2021-25678, CVE-2021-27380,

• Untrusted pointer dereference - CVE-2020-26997, and

• Stack-based buffer overflow - CVE-2021-27382

NCCIC-ICS reports that an uncharacterized attacker with uncharacterized access could exploit the vulnerabilities to lead to a crash, arbitrary code execution, or data extraction on the target host system.

Nucleus Advisory #2

This advisory describes two infinite loop vulnerabilities in the Siemens Nucleus products. The vulnerabilities were self-reported. Siemens has a new version for one of the affected products that mitigates the vulnerabilities.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to cause a denial-of-service condition.

Nucleus Advisory #3

This advisory describes two vulnerabilities in the Siemens Nucleus DNS module. These are two of the NAME:WRECK DNS vulnerabilities reported by Forescout and JSOF. Siemens provides generic work arounds to mitigate the vulnerabilities.

The two reported vulnerabilities are:

• Out-of-bounds write - CVE-2020-15795, and

• Use of out-of-range pointer offset - CVE-2020-27009

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to allow a denial-of-service condition or for the execution of code remotely.

NOTE: There were two additional Siemens’ advisories published today that were not covered by NCCIC-ICS. If they are not covered on Thursday, I will address them on Saturday.

JTEKT Advisory

This advisory describes an improper resource shutdown or release vulnerability in the JTEKT TOYOPUC products. The vulnerability was reported by Younes Dragoni from Nozomi Networks. JTEKT has provided generic mitigation measures.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an unauthorized user to stop Ethernet communications between devices from being established.

Advantech Advisory

This advisory describes an incorrect permission assignment for critical resources in the Advantech WebAccess/SCADA. The vulnerability was reported by Chizuru Toyama of TXOne IoT/ICS Security Research Labs of Trend Micro. Advantech has a new version that mitigates the vulnerability. There is no indication that Toyama has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an attacker to login as an ‘admin’ to fully control the system.

Schneider Advisory

This advisory describes an improper restriction of XML external entity reference vulnerability in the Schneider SoMachine Basic products. The vulnerability was reported by Gjoko Krstikj of Applied Risk. Schneider has a new product that replaces the affected product and has updated the mitigation measures.

NOTE 1: This is actually based upon an update to a Schneider advisory that was published on May 22^nd, 2018.

NOTE 2: Schneider also published two advisories and two other updates today. If they are not covered by NCCIC-ICS on Thursday, I will address them here on Saturday.

S 600 Introduced - Drone Integration and Zoning Act

Last month Sen Lee (R,UT) introduced S 600, the Drone Integration and Zoning Act. The bill would provide for State and authority over ‘civil unmanned aircraft systems’ within 200-ft above the ground. Currently, sole jurisdiction over US airspace rest with the Federal Aviation Administration. This bill is nearly identical to S 2607 that was introduced by Lee in the last session, no action was taken on the earlier bill.

Moving Forward

Lee is a member of the Senate Commerce, Science, and Transportation Committee to which this bill was assigned for consideration. This means that he may have enough influence to have this bill considered in Committee. Because this bill makes a fundamental change in the regulation of aircraft operations in the United States, I suspect that there will be substantial bipartisan opposition to this bill. I do not expect to see the bill considered in Committee and it would certainly not make it to the floor of the Senate.

Commentary

The single largest problem with this bill is that while it gives some regulatory and enforcement authority to State, local governments, and tribal governments, it does not provide an exception to numerous federal regulations that would be violated by interfering with the operation of an unmanned aircraft system in flight. Thus, the regulatory authority provided by this bill would severely limited by the inability to enforce those regulations upon an aircraft in flight.

Until a consensus is reached about when and how a UAS differs from aircraft operated by a pilot inside the aircraft and how that would allow for lawful seizer of control of the aircraft in flight, most attempts at regulating where and when UAS operate are going to be doomed to failure.

S 652 Introduced – Moving FIRST Act

Last month Sen Cortez-Masto introduced S 652, the Moving and Fostering Innovation to Revolutionize Smarter Transportation (Moving FIRST) Act. The bill would require DOT to “establish the Strengthening Mobility and Revolutionizing Transportation (SMART) Challenge Grant Program to promote technological innovation in our Nation’s communities”. This is a follow-on program to the DOT’s Smart City Challenge program.

Grant Program

Section 4 of the bill would authorize DOT is provide four grants per year through FY 2026. The grants could by used for projects  that demonstrates a sound, innovative, integrated, and holistic approach and incorporates many aspects of the following ‘vision elements’ {§4(e)(1)}:

• Coordinated automation,

• Connected vehicles,

• Intelligent, sensor-based infrastructure,

• Architecture and standards,

• Low cost, efficient, secure, and resilient information and communications technology,

• Smart land use,

• Comprehensive analytics,

• User-focused mobility services and choices,

• Commerce delivery and logistics,

• Leverage the use of innovative aviation technology,

• Strategic business models and partnering opportunities,

• Smart grid, roadway electrification, and electric vehicles,

• Synchronization of technology, and

• Connected, involved citizens.

Agencies requesting grants will document an effective use of technology, including the extent to which the project will {§4(d)(3)}:

• Reduce congestion and delays for commerce and the traveling public,

• Improve the safety of transportation facilities and systems for pedestrians, bicyclists, and the broader traveling public,

• Provide access to jobs, education, and essential services, including health care and educational and training opportunities,

• Connect underserved populations and reduce their transportation costs,

• Contribute to medium- and long-term economic competitiveness,

• Improve the condition, reliability, and user experience of existing transportation facilities and systems,

• Promote connectivity between connected vehicles, roadway infrastructure, pedestrians, bicyclists, the public, and transportation systems,

• Use innovative strategies or technologies to pursue any of the primary selection criteria,

• Demonstrate strong collaboration among a broad range of participants, including the private sector, job centers, or the integration of transportation with other public service efforts, including working with existing mobile and fixed telecommunication service provides whenever possible,

• Improve the overall environment, including through improved energy efficiency, reduced dependence on oil, or reduced pollution,

• Promote or improve positive public health outcomes for a community,

• Increase resiliency of the transportation system,

• Incorporate relevant security solutions, including those needed for cybersecurity [emphasis added], and address emergency situations based on the scope and necessity,

• Include sufficient technical, physical, and administrative measures to ensure security of information and protection of individuals’ privacy, and

• Address issues identified by the Department of Transportation in the Beyond Traffic 2045 report.

Section 6 would authorize $100 million per year for the grant program, not more than $2 million of which may be used by DOT for program costs.

Moving Forward

Cortez-Masto is not a member of the Commerce, Science, and Technology Committee to which this bill was assigned for consideration, but one of her cosponsors {Sen Sinema (D,AZ)} is. This means that there may be enough influence to have this bill considered in Committee. Grant programs like this generally face little programmatic opposition; figuring out where the funds will come from is a likely stumbling block.

Commentary

A grant program like this is hardly the place to clearly explicate the necessity for, or composition of, a transportation cybersecurity program, so I suppose that we should be happy that cybersecurity is specifically mentioned as one of 13 technology measures that that will be used as criteria for approving a very limited number of grants. To increase the emphasis on cybersecurity, however, I would like to suggest the following changes to §4(d)(3):

“(B) improve the safety and security of transportation facilities and systems for pedestrians, bicyclists, and the broader traveling public;

• • •

“(G) promote the secure connectivity between connected vehicles, roadway infrastructure, pedestrians, bicyclists, the public, and transportation systems;”

Committee Hearings – Week of 4-11-21

This week both the House and Senate return to Washington from Spring Break. Lots of hearings scheduled on both sides of the Hill. Budget hearings for FY 2022 are starting up in the House and there is one cybersecurity hearing (maybe) in the Senate.

FY 2021 Budget

Lots of smaller agency hearings start things off in the House, but there is one hearing of note here:

4-15     DOT    THUD Subcommittee – House Appropriations

OMB does have a budget document available, but since this is really early in the Biden Administration, there is not much in the way of programmatic details. Cybersecurity is mentioned a couple of times, but mainly dealing with securing federal systems. The upcoming hearings will be unlikely to provide much more in the way of details.

Cybersecurity

According to the Senate’s hearing web page, the (new) Cybersecurity Subcommittee of the Senate Armed Services Committee will be holding a hearing on Wednesday to “examine future cybersecurity architectures.” There is no information about any upcoming hearings on the Armed Services Hearings web page, but that could be because of the extended break. I will keep an eye out for more information.

OCS Publishes Updated CSAT Portal User Manual – March 2021

Sometime last month (probably) the CISA Office of Chemical Security {the Chemical Facility Anti-Terrorism Standards (CFATS) folks} published an updated version of the Chemical Security Assessment Tool (CSAT) Portal User Manual. The new version is dated March 2021.

DHS stopped putting management of change information in their CFATS manuals a number of years ago, so we now have to determine what changes were made by inspection. This is a 131 page manual and I have not done a line-by-line inspection to determine all of the changes that were made. I did look at the table of contents and the listing of tables and figures; there were no changes made there.

In looking closely at a large selection of pages, I only found one change. On the top of page 58, under the heading of Top-Screen, the following change was made:

Old – “You may update this survey at any time after you submitted an initial Top-Screen.”

New – “You may update this survey after DHS has completed the review of your previous Top-Screen submission.”

This is a minor change in procedure, but it is of no real practical importance. Both versions of the manual follow that by stating: “The [Update] button appears only when your facility meets the conditions listed above.”

Facility Security Officers for covered facilities and consultants working with the facilities on CFATS implementation will need to download a copy of the new version.

BTW: CISA only lists one of the five CSAT manuals from the CSAT web page on their Guidance Document web page. Guess what? It is not this one.

Public Comments on CISA Vulnerability Discovery ICR Revision – 4-10-21

Last month DHS published [Link added 4-10-21 1422 EDT] a 60-day information collection request (ICR) notice to support the expansion of their Vulnerability Discovery program (VDP) to other agencies in the federal government. This post is (maybe?) part of a series of posts that looks at public comments submitted in response to that ICR. The end of the comment period is May 18^th, 2021.

To date there are two public responses to that ICR notice. One, of course, is from my blog post [.PDF download link], the other is from Andrew Hunt. Along with a brief comment, Hunt provides a marked-up copy [.PDF download link] of the 60-day ICR notice, clarifying the changes that he suggests.

Hunt suggests:

“Overall, shift language from 'all agencies with their web forms' to 'DHS CISA centralized reporting'. They have the expertise to collect this sensitive information, secure it appropriately, disseminate appropriately, and engage agencies to remediate their exposures. Review 'lawful method to practice...discover new vulnerabilities' language if that is not intended to provide safe harbor protections to hackers. Remove references to 'Solarwinds Hack' and replace with codenames (e.g. SunBurst, SunShuttle) or descriptions to reduce liability of brand damage to the Solarwinds company as it is trying to recover from this truly terrible attack. Reword the definition of a 'vulnerability' as more to do with redirection of expected execution and behavior rather than controls bypass. A vulnerability can exist without a defined/intended control.”

He makes the following additional points in the marked-up document:

• Controls are not always defined before being vulnerable. A better definition: ‘coerces hardware/software to execute or behave in unintended ways from the design’.

• “… lawful method to practice and discover new cyber methods to discover the vulnerabilities….” CLARIFY: this sounds like a safe-harbor statement for hackers.

• If you do not guarantee confidentiality, then no one will play with you. Exempt this from FOIA.

• Use one site, done right, secured, and managed by those with the experience to do so. Remediation of vulnerabilities are notified, then managed by CISA. Agencies follow CISA direction to properly mitigate the vulnerability.

Commentary

While Hunt’s comments are brief he brings up some interesting points. First, his suggestion that DHS run a centralized VDP meshes well with my observations about the requirements of 44 USC 3509. The more interesting point, however, is his take on the definition of ‘security vulnerabilities’ used in the ICR notice. That definition comes from 6 USC 1501(17) and it reads:

“The term "security vulnerability" means any attribute of hardware, software, process, or procedure that could enable or facilitate the defeat of a security control.”

Hunt makes the point that: “Controls are not always defined before being vulnerable. A better definition: ‘coerces hardware/software to execute or behave in unintended ways from the design’.” Playing with Hunt’s comments just a bit, I would like to offer this formal version of Hunt’s suggestion:

“The term “security vulnerability” means any attribute of hardware, software, process or procedure that would allow or cause that hardware, software, process or procedure to execute or perform in an unintended way from the design.”

Unfortunately, an ICR is not the appropriate vehicle for changing a regulatory definition. DHS is not, however, required to utilize the definition from §1501 in this ICR. They could instead use my formal definition above, substituting “Security vulnerabilities may be defined as” for the first five words of the revised definition.

His comment about removing the SolarWinds name from discussion in the ‘Supplementary Information’ portion of the Notice brings up an interesting point. While I personally do not care much about wounded corporate egos, DHS is not responding to the vulnerabilities in the SolarWind products (that is the sole responsibility of the company), they are responding to the effects of the attacks wrought by SunBurst, SunShuttle etc. Thus, naming them rather than SolarWinds is probably more appropriate.

Finally, I am not sure that I agree with his FOIA comment. Researchers have no need to ‘protect’ their discovery of vulnerabilities. Vendor and agency developers might, but their response is not the subject of the ICR. There would certainly be some justification for restricting access to the vulnerability information pending mitigation actions. Reported vulnerabilities should probably be protected as sensitive but unclassified information pending mitigation development.

OMB Denies Request for CG TWIC Risk Assessment ICR

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had rejected the Coast Guard’s new information collection request (ICR) for their “Transportation Worker Identification Credential (TWIC) Card Readers: Updated Risk Analysis”. The reason for the rejection was that the CG improperly submitted the new ICR. According to yesterday’s Notice:

“Terms of Clearance: Improperly submitted. DHS will resubmit with an information collection instrument and either a supporting statement B or an explanation of why such an analysis does not require statistical methods.”

The ICR Notice

According to the 60-day ICR notice published in the Federal Register on August 3^rd, 2020:

“The Coast Guard is conducting a risk analysis to determine which maritime facilities subject to TWIC Reader Rule would most benefit from the electronic TWIC inspection requirements. The purpose of this information collection is to gather the necessary information to conduct that analysis.”

The Coast Guard reported in that Notice that the respondents to the information collection would be “Maritime facility owners, operators and representatives”, and that the total time burden would be 600 hours. No burden costs were mentioned in the Notice.

Receiving no comments on the 60-day ICR notice, the CG published a nearly identical 30-day ICR notice on October 15^th, 2020.

The ICR Submission

On October 29^th the CG submitted a Supporting Statement A [.DOCX download link] providing the required justifications for the ICR. That document, after a discussion of the background of the TWIC Reader Rule and the delays in the implementation of that Rule, describes the purpose of the new information collection (page 2):

“The purpose of this collection of information is to gather the necessary information to conduct the revised risk analysis and population analysis.  Both the HSOAC assessment [link added] and the industry petition [.PDF download link added] stated that the Coast Guard underestimated the number of facilities that handle CDC in bulk and, in particular, the number of facilities transferring CDC via non-maritime means.  In addition, the 2016 TWIC Reader rule also applied to facilities that receive vessels carrying bulk CDC but do not transfer the bulk CDC to or from the vessel during the vessel-to-facility interface.  These facilities were not included in the original risk analysis for the 2016 TWIC Reader rule and, therefore, the Coast Guard does not have an accurate population estimate for these facilities.  The Coast Guard needs an accurate estimate of the number of facilities subject to the TWIC Reader rule to better identify which maritime facilities would benefit the most from the rule.  The information gathered from this collection of information would allow the Coast Guard to fill in gaps in the data and increase the accuracy of estimating the impact of the TWIC Reader rule.  The information necessary for this effort is not currently gathered by Coast Guard inspectors, nor is it included in facility security plans.”

The Supporting Statement goes on to explain:

“Given the nature of our collection of information method—where responses to an interview question may require follow-up and clarifying questions—the use of an online survey mechanism is not feasible.  The Coast Guard will manually collect information through semi-structured interviews.  To minimize the burden on respondents, interviews will be conducted via phone or in person at the respondent’s location.  We will create electronic interview narratives from participants to code and use for our analysis.  We estimate that 75% of the interview will be conducted via phone.”

The Statement also provides a more detailed burden estimate (page 3):

• The estimated annual number of respondents is 300. 

• The estimated annual number of responses is 300. 

• The estimated annual hour burden is 600. 

• The estimated annual cost burden is $39,600. 

No information collection document (survey or list of questions to be asked) was included in the submission to OIRA.

Commentary

The TWIC Reader Rule… the Grateful Dead probably described it best: “what a long, strange trip it's been”. Between the Coast Guard and the TSA there have been so many delays and missteps in the design and implementation of the electronic TWIC readers that this additional hiccup should probably have been expected.

The data collection documents are not (unfortunately) typically made public as part of the ICR notice and comment process, so the Coast Guard may be able to get away with publishing the survey question list and resubmitting this ICR to OIRA without going back through that Federal Register publication exercise. That and adding a brief explanation of why they do not expect to “employ statistical methods” to the data collected will probably allow OIRA to approve this ICR.

Then we can wait for another year or two for the CG to start a new rulemaking clarifying the TWIC Reader Rule. Just keep on truckin….