Saturday, March 31, 2018

Public ICS Disclosures – Week of 03-24-18


This week we have one vendor notification from Siemens and two exploits for previously disclosed vulnerabilities in products from Hikvision and Advantech.

Siemens Advisory


This advisory describes 8 vulnerabilities in Siemens Building Technologies Products. The vulnerabilities were reported by Sergey Temnikov and Vladimir Dashchenko from Kaspersky Lab. The newest version of the license management systems for the affected products mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

These reported vulnerabilities are the Gemalto Sentinel LDK RTE vulnerabilities that have been previously reported by Siemens in other products.

Hikvision Exploit


This exploit provides proof-of-concept code for an attack on IP cameras from Hikvision. The backdoor vulnerability was previously disclosed on May 4th, 2017. The exploit was published by Matamorphosis on Exploit-DB.com.


Advantech Exploit


This exploit provides proof-of-concept code for an attack on the WebAccess products from Advantech. The stack-based buffer overflow vulnerability was previously disclosed on January 14th, 2016. The exploit was published by Chris Lyne on Expoit-DB.com.

Commentary


I noted in an earlier post that this set of Gemalto vulnerabilities probably effects a wide range of ICS products (including products from at least three other major ICS vendors) and suggested that ICS-CERT should have done an alert on these vulnerabilities. It is not too late to do so.

While both of the exploited vulnerabilities describe above were previously reported by ICS-CERT as not having publicly available exploits, ICS-CERT does not make a practice of removing that language from their advisories when exploits do become publicly available. It would probably be valuable to the ICS security community if that practice were changed.

Friday, March 30, 2018

HR 5074 Reported in House – Cyber Response Teams


Earlier this month the House Homeland Security Committee published their report on HR 5074, the DHS Cyber Incident Response Teams Act of 2018. The bill was passed in the House on March 19th. The date on the report is also the 19th, but the report was not actually published by the GPO until well after the debate and vote in the House.

Authorizing Existing Programs


The report makes it clear that the ‘cyber hunt and incident response teams’ authorized by the bill are, in fact, the activities currently being undertaken by the US-CERT and the National Cybersecurity and Communications Integration Center’s (NCCIC’s) Hunt and Incident Response Teams (HIRT). This is the reason that the bill specifies {§2(b)} that no additional funding is authorized; the funding for these activities is already included in the line items for NCCIC spending.

The provisions of the new 6 USC 148(f)(2) authorizing the use of “cybersecurity specialists from the private sector” on the existing US-CERT and HIRT teams is, however, a potential expansion of the capabilities of those teams. The Report states that allowing the participation of these outside experts would (pg 2) “allow industry professionals to bring innovative approaches and ideas into the federal government and makes progress in bringing the technical expertise and skills that help execute the DHS role in cybersecurity”.

Commentary


Neither the report nor the bill mentions any of the response activities of the DHS Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) which also operates as part of the NCCIC and was formerly part of the US-CERT (Actually, the current relationship between the ICS-CERT and the current US-CERT is not actually very clear.) Presumably, since the bill would add the term ‘control systems’ (even though undefined) to §148 {via (f)(1)(D)} the response activities of ICS-CERT, especially their away teams, would fall broadly under the authorization provided in this bill.

Unfortunately, the failure to define the term ‘control system’ or modify the definition of ‘information system’ in §148(a)(5) to specifically include control systems means that this bill would do nothing to actually codify the importance of control system security in NCCIC activities or oversight. This is unlikely to change if/when this bill is considered in the Senate.

ICS-CERT Publishes Four Advisories


Yesterday the DHS ICS-CERT published three control system security advisories for products from Siemens (2) and WAGO as well as a medical device security advisory for products from Phillips.

SIMATIC Advisory


This advisory describes an improper input validation vulnerability in the Siemens SIMATIC product line. The vulnerability was reported by Vladimir Dashchenko from Kaspersky Lab and independent researcher cdev1. A new version is available for one product that mitigates the vulnerability and activating an existing control mitigates the vulnerability in others. There is no indication that either of the researchers have been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to cause a denial-of-service condition on the remote and local communication functionality of the affected products. A system reboot is required to recover.

TIM 1531 Advisory


This advisory describes an incorrect implementation of an algorithm vulnerability in the Siemens TIM 1531 IRC communications modules. The vulnerability is self-reported. A new version is available that mitigates the vulnerability.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to enter a denial-of-service condition, or allow the attacker to read and manipulate data and configuration settings of the affected device.

WAGO Advisory


This advisory describes an improper shutdown or release vulnerability in the WAGO 750 Series PLC. The vulnerability was reported by Younes Dragoni of Nozomi Networks. WAGO has released new firmware that mitigates the vulnerability. There is no indication that Dragoni has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow a denial-of-service condition affecting the ability of the device to establish connections to commissioning and service software tools. The WAGO security advisory notes that the vulnerability only affects the WAGO communication via WAGO Ethernet TCP/IP driver and that communications are still possible via the 3S TCP/IP level 2 driver and WAGO Service
Communication over TCP/IP.

Phillips Advisory


This advisory describes a large (indeterminate) number of vulnerabilities in the Phillips  iSite and IntelliSpace picture archiving communications systems (PACS). The vulnerabilities are self-reported. Phillips has provided multiple options for mitigating up to 99.9% of the vulnerabilities.

The reported vulnerabilities include:

• Improper restrictions of operations within the bounds of a memory buffer (#?);
• Code/source code vulnerabilities (at least 18);
• Information exposure (#?);
• Improper control of generation of code (#?);
• Weaknesses in OWASP to ten (at least 6);
• Improper restriction of XML external entity reference;
Other 3rd party component vulnerabilities (#?)

ICS-CERT reports that a relatively low-skilled attacker with uncharacterized access could exploit the vulnerabilities to provide unexpected input into the application, execute arbitrary code, alter the intended control flow of the system, access sensitive information, or potentially cause a system crash.

Comment: This is a really flakey advisory and it certainly does not appear to be a problem at ICS-CERT. I am pretty sure that the authors of this advisory wanted to say that: “These products are just screwed up.” Unfortunately, that type of broad characterization is even less helpful than this report. Oh, and Phillips? The comment on their product security web page is priceless: “Philips will continue to add cybersecurity vulnerability remediation improvements through our Secure Development Lifecycle (SDL) as threats continue.” At least they did self-report this fiasco.

NOTE: These vulnerabilities were not reported on the FDA Medical Device Safety Communications page.

Missing Siemens Update


On Tuesday (the same day that Siemens announced the two advisories above) Siemens announced that they had updated their advisory on the improper input validation vulnerability in the Siemens SIMATIC, SINUMERIK, and PROFINET IO products reported last week by ICS-CERT. The update removed a product from the affected product list.

Thursday, March 29, 2018

HR 5239 Introduced – DOE Cyber Sense


Earlier this month Rep Lata (R,OH) introduced HR 5239, the Cyber Sense Act of 2018. The bill would require DOE to establish “a voluntary Cyber Sense program to identify and promote cyber-secure products intended for use in the bulk-power system” {§2(a)}. Similar provisions were included in §1106 of HR 8 in the 114th Congress (passed in House, stalled in Senate).

Cyber Sense Program


As I mentioned above, this bill has very similar requirements to establish and maintain a testing program “to identify products and technologies intended for use in the bulk-power system that are cyber-secure, including products relating to industrial control systems” {§2(b)(1)}. There are, however, three significant differences between this bill and the earlier §1106 provisions.

First, this bill removes the requirement for DOE to “promulgate regulations regarding vulnerability reporting processes for products tested and identified under the Cyber Sense program” that was found in §1106(b)(3). Both bills contain provisions requiring DOE to “establish and maintain cybersecurity vulnerability reporting processes and a related database” {(b)(2) in the respective sections}.

Second, this bill adds a requirement for DOE to “provide reasonable notice to the public, and solicit comments from the public, prior to establishing or revising the Cyber Sense testing process” {§2(b)(6)}.

Finally, in the disclosure protection paragraph, there are two changes. The first is structural; since the language in §1106(c) referred to the disclosure reporting regulations that are not included in HR 5239, the disclosure protection language now refers to the broader vulnerability reporting processes and database in §2(b)(2). Second, the language specifically prohibiting disclosure under “section 552(b)(3) of title 5, United States Code, and any State, tribal, or local law requiring disclosure of information or records” {§1106(c)} has been removed in the new bill.

Moving Forward


Both Latta and his co-sponsor, Rep McNerney (D,CA) are senior members of the Energy and Commerce Committee to which this bill was assigned for consideration. Thus, it would seem likely that they would have the influence necessary to have the bill considered by Committee. There are no provisions in the bill that would draw the specific ire of the regulated community, so I suspect that there would be bipartisan support for this bill both in the Committee and before the full House.

Commentary


The vulnerability reporting requirements of the earlier bill were going to be problematic, because the regulated community has very little to do with the disclosure and reporting of vulnerabilities. Establishing effective regulations for vulnerability reporting would have to be targeted at either the independent researcher community (which is increasingly international in scope) or the manufacturers of the affected devices (which is very much international).

The earlier attempt to bring vulnerability reporting for Cyber Secure devices under the disclosure rules of the Critical Energy/Electric Infrastructure Information (CEII) program was doomed to failure. First, the CEII program only prohibits information disclosure by Federal, State and local governments agencies (including, of course FERC and NERC). It would not preclude independent researchers or vendors from releasing vulnerability information.

The interesting thing about the CEII provisions of both of these bills is that there might end up being unintended effects on ICS-CERT. A large portion of the devices that would likely be tested under the cyber sense program would also be used in control systems in other industries not directly affected by the CEII program. If ICS-CERT were notified by the operator of the Cyber Sense program (NERC?) of vulnerabilities reported under §2(b)(2), they would not be able share that information under their normal alert/advisory publication program. Similarly, if ICS-CERT were to share information with the Cyber Sense program, it could be argued that they could not subsequently share that information with the wider industrial control system community.

What the program should be required to do instead of labeling the vulnerabilities as CEII would be to require notifications to be made to registered members of the bulk power industry and then after a set period of time (two months?) the Cyber Sense operator would be required to notify ICS-CERT for general vulnerability publication for the remaining affected industries. Similarly, ICS-CERT would be required to check vulnerability disclosures to see if they involve Cyber Sense listed devices. If so, they would be required to first notify the Cyber Sense operator and withhold general industry notification for the same set period of time.

EPA Withdraws RQ Adjustment NPRM


Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that the EPA had withdrawn its notice of proposed rulemaking (NPRM) regarding possible modifications to reportable quantities. The NPRM was submitted earlier this month.


No reason was given for the rulemaking’s withdrawal. Having said that, this is not the typical Trump Administration removal of an Obama Administration rulemaking, so I suspect that we may see this rulemaking resubmitted sometime in the future.

BTW: There is an interesting EPA web page on the topic of RQ modifications that dates back to only September 28th, 2016.

Wednesday, March 28, 2018

HR 5240 Introduced – DOE Cybersecurity Programs


Earlier this month Rep McNerney (D,CA) introduced HR 5240, the Enhancing Grid Security through Public-Private Partnerships Act. The bill would require the Department of Energy (DOE) to establish a voluntary security program for electric utilities and provide a report to Congress on cybersecurity of electricity distribution systems.

Voluntary Security Program


Section 2 of the bill would require DOE to establish a program that would {§2(a)}:

• Develop, and provide for voluntary implementation of, maturity models, self-assessments, and auditing methods for assessing the physical security and cybersecurity of electric utilities;
• Provide training to electric utilities to address and mitigate cybersecurity supply chain management risks;
• Increase opportunities for sharing best practices and data collection within the electric sector;
• Assist with cybersecurity training for electric utilities;
• Advance the cybersecurity of third-party vendors that work in partnerships with electric utilities; and
Provide technical assistance for electric utilities subject to the program.

Distribution System Cybersecurity Report


Section 3 of the bill would require DOE to prepare a report to Congress that would assess {§3(a)}:

• Priorities, policies, procedures, and actions for enhancing the physical security and cybersecurity of electricity distribution systems to address threats to, and vulnerabilities of, such electricity distribution systems; and
• Implementation of such priorities, policies, procedures, and actions, including an estimate of potential costs and benefits of such implementation, including any public-private cost-sharing opportunities.

Moving Forward


Both McNerney and his sole co-sponsor, Rep Lata (R,OH) are senior members of the House Energy and Commerce to which this bill was assigned for consideration. They would certainly seem to have the influence necessary to see this bill considered in Committee.

There is nothing in the bill that would draw specific opposition and it would appear that there would be broad bipartisan support for the bill both within Committee and on the floor of the House should it reach that body.

Commentary


This is another motherhood and apple pie bill that is a perfect example of form over function. No monies are authorized for the programs, there is no deadline for the report to Congress, and there is not even a snazzy name for the voluntary program. This is simply a congressional look at us, we are doing something bill.

Normally, I would suspect that bills of this sort would have been crafted by Committee staff, given that there is bipartisan sponsorship by two different Committee members. I do not think that this is the case with this bill. Both §2 and §3 contain language providing protection from disclosure information provided to DOE by utilities in developing the voluntary program and the report to Congress. While this is certainly necessary when considering any security programs, the wording is incomplete. I would have expected to see Committee Staff, who should be experts in DOE programs, to have referred to the Critical Energy Infrastructure Information (CEII) program used by FERC, to provide more comprehensive information protection and to limit that protection to only security related matters.

Tuesday, March 27, 2018

ICS-CERT Publishes Two Advisories


Today the DHS ICS-CERT published a medical device security advisory for products from Phillips and a control system security advisory for products from Schneider electric.

Phillips Advisory


This advisory describes two vulnerabilities in the Phillips Alice 6 System sleep diagnostic system. The vulnerabilities are apparently self-reported. Phillips plans on producing a new product version in December that will mitigate the vulnerability.

The two reported vulnerabilities are:

• Improper authentication - CVE-2018-5451; and
Missing encryption of sensitive data - CVE-2018-7498

ICS-CERT reports that a relatively low-skilled attacker using publicly available exploits could remotely exploit the vulnerabilities to gain visibility to usernames/passwords and personal data. Insufficient encryption and cryptographic integrity checks can lead to altered, corrupted, or disclosed sensitive data. Disclosure of personal data can occur by replacing a trusted node with a malicious node.

NOTE: These vulnerabilities were not reported on the FDA Medical Device Safety Communications page.

Schneider Advisory


This advisory describes three vulnerabilities in the Schneider Modicon products. The vulnerabilities were separately reported by Nikita Maximov, Alexey Stennikov, and Kirill Chernyshov of Positive Technologies as well as Meng Leizi and Zhang Daoquan. Schneider has described generic work arounds to mitigate the vulnerabilities.

The three reported vulnerabilities are:

• Stack-based buffer overflow - CVE-2018-7240;
• Use of hard-coded credentials - CVE-2018-7241; and
• Use of broken or risky cryptographic algorithm - CVE-2018-7242

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to allow a remote unauthorized attacker access to the file transfer service on the device, which could result in arbitrary code execution or malicious firmware installation.

NOTE: These are the Modicon FTP vulnerabilities that I reported on Saturday.

EPA Sends Hazardous Substance Spill Prevention Rule to OMB


Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received a notice of proposed rulemaking (NPRM) from the EPA on preventing spills of hazardous substances. This rulemaking is being undertaken in response to a consent decree entered into in February 2016. That decree requires the EPA to issue an NPRM on or before June 16th, 2018 and a final rule by August 29th, 2019.

The listing for this rulemaking in the Fall 2017 Unified Agenda makes it clear that the Trump Administration is still looking for ways to circumvent this consent decree, which is not unexpected given its publicly professed point of view on government regulations.

The simplest way to comply with this requirement would be for the EPA to amend the current spill prevention, control and countermeasures (SPCC) regulations under 44 USC 112 to add hazardous substances to the oil spill regulations. While simple from a rule writing perspective this would certainly affect a large portion of the economy (see the listing of potentially effected sectors in the rulemaking description) and would be very costly. We might, however, see the Trump Administration do this to demonstrate a strongly negative cost-benefit relationship.

It could take some time for OIRA to approve this NPRM. I do not expect to see this rulemaking published before the mandated date.

Monday, March 26, 2018

ISCD Publishes CFATS Quarterly – March 2018


Today the DHS Infrastructure Security Compliance Division (ISCD) published a news item on their Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center that the latest issue of the CFATS Quarterly Newsletter had been released. Additionally, ISCD published a new fact sheet in their chemical protection for specific industry sector series; this one is for the pulp and paper industry.

CFATS Quarterly


This issue of the Quarterly continues the tradition of a user-focused (as opposed to agency-focused) newsletter intended to provide useable information to the regulated industry. The first and last articles address specific Risk Based Performance Standard (RBPS) issues, and both lead with interesting questions.

The first deals with the ‘know your customer’ requirements under RBPS 5. It addresses the idea of preventing a business from inadvertently shipping DHS chemical of interest (COI) to potential terrorists and, thus, obviating their need to stage a physical attack on the covered facility. There is a nice segue to the introduction of the flyer ISCD published last year reminding customers that receive COI of their potential CFATS reporting requirements. One important item missing from the RBPS 5 discussion is guidelines on reporting attempts of acquiring COI by questionable entities.

The last article of the newsletter looks at RBPS 9 and the need for building relationships with local emergency response personnel. It includes a list of possible activities that a facility might want to consider, including a fairly innovative one; “Creating a toolkit for responders that contains items like the facility emergency contacts, facility layout, access credentials or a two-way radio”. I particularly like the idea about the radio, but I doubt most facilities want to spring for providing enough radios for all of the potential response agencies. An alternative would be to have this type of tool-kit available at the front gate for responding units.

In between these two articles are additional bits of useful information and one small agency ‘look-at-me’ piece. Without pointing fingers, this is the type of publication that agencies should publish, not 3-color glossy corporate-reports.

Pulp and Paper Industry


Last year, as part of their industry outreach program, ISCD started publishing a series of CFATS fact sheets that looked at various industry groups and the chemicals used by companies in those industries that could make them subject to the CFATS program. Since the CFATS program is a chemical security, as opposed to chemical industry security, program it appears to be necessary to remind various companies of their legal reporting responsibilities under the CFATS program.

The latest version is for the Pulp and Paper industry. Most of the content of these different outreach flyers are the same, as they deal with the CFATS program requirements. The only ‘new’ information here is the listing of common chemicals in the pulp and paper industry that are listed COI and thus could trigger CFATS reporting requirements.

I do wish that ISCD had provided a link to their ‘First Steps’ factsheet in this (and all of the other industry factsheets). It provides a brief overview of how to proceed when a facility has determined that they have a CFATS reporting requirement. It would be a valuable addition to these industry factsheets.

Saturday, March 24, 2018

House Passes HR 5089 – Surface Transportation Security


On Thursday the House passed HR 5089, the Strengthening Local Transportation Security Capabilities Act of 2018, by a strongly bipartisan vote of 397 to 1 (the single Nay was a Republican). The bill was debated on Monday, but the recorded vote was demanded and then delayed until Thursday.

As with HR 5074, this bill was considered on the floor ‘as amended’. Neither bill was amended at the markup hearing conducted earlier this month, but the reported language for HR 5089 did include a minor revision of the language in §3(a). The revised language added: “, as appropriate, from” before the words “the Office of Intelligence and Analysis”. Minor, relatively inconsequential changes like this are not uncommon in reported language coming out of committee.

The bill now waits for the Senate leadership to decide if the bill will be considered in that body. Based upon the vote in the House, I do not suspect that there will be any substantial opposition in the Senate. I would expect to see the bill considered under the ‘without objection’ process; no debate and no vote.

Public ICS Disclosure – Week of 3-17-18


This week we have seven vendor disclosures for products from Schneider (5) and ABB (2). We also have an exploit announcement for a previously disclosed vulnerability in a product from Hikvision.

MiCOM Px4x Advisory #1


This advisory describes a denial of service vulnerability in the Schneider MiCOM Px4x rejuvenated product. The vulnerability is self-reported. Schneider has provided firmware updates and described work arounds to mitigate the vulnerability.

MiCOM Px4x Advisory #2


This advisory describes a denial of service vulnerability in the Schneider MiCOM Px4x with legacy Ethernet board product. The vulnerability is self-reported. Schneider has described generic work arounds to mitigate the vulnerability.

MiCOM P540D Advisory


This advisory describes a denial of service vulnerability in the Schneider MiCOM P540D with legacy Ethernet board product. The vulnerability is self-reported. Schneider has provided firmware updates and described generic work arounds to mitigate the vulnerability.

MGE Advisory


This advisory describes four vulnerabilities in the Schneider MGE SNMP/Web Card 66074. The vulnerabilities were reported by Ilya Karpov and Evgeny Druzhinin of Positive Technologies. Schneider has replacement NMC kits available for some of the affected products and they describe generic workarounds.

The four reported vulnerabilities are:

• Authorization bypass - CVE-2018-7243;
• Information exposure - CVE-2018-7244;
• Improper authorization - CVE-2018-7245; and
• Clear-text transmission of sensitive information - CVE-2018-7246

Modicon Web Servers Advisory


This advisory describes four vulnerabilities in the Schneider Modicon PLC embedded web server. The vulnerabilities were reported by Positive Technologies. Schneider has described generic workarounds to mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The four reported vulnerabilities are:

• Denial of Service - CVE-2018-7759;
• Authorization bypass - CVE-2018-7760;
• Arbitrary code execution - CVE-2018-7761; and
• Buffer overflow - CVE-2018-7762

Modicon FTP Advisory


This advisory describes three vulnerabilities in the Schnedier Modicaon PLC FTP servers. The vulnerability is self-reported. Schneider describes generic workarounds to mitigate the vulnerability.

The three reported vulnerabilities are:

• Arbitrary code execution - CVE-2018-7240;
• Hardcoded accounts - CVE-2018-7241; and
• Vulnerable hash algorithms - CVE-2018-7242

ADMS netCADOPS Advisory


This advisory describes a bounds checking vulnerability. The vulnerability was reported by Ismail Erkek – Barikat. ABB has described generic workarounds to mitigate the vulnerability. There is no indication that the researcher has been provided an opportunity to verify the efficacy of the fix.

CCLAS Advisory


This advisory describes three vulnerabilities in the ABB CCLAS laboratory information management system. The vulnerabilities are self-reported. ABB has a new version that mitigates the vulnerabilities.

The three reported vulnerabilities are:

• Path traversal (2); and
• Cross-site scripting

Hikvision Exploit


This announcement describes an exploit for the password in configuration file vulnerability reported last year in a number of Hikvision IP cameras. Hikvision previously reported that the “configuration file is encrypted and is therefore not readable, and protects users’ credentials”, but promised to upgrade the protections in future firmware updates. Neither ICS-CERT nor Hikvision have reported that promised firmware update.

Friday, March 23, 2018

Bills Introduced – 03-22-18


Yesterday with the House and Senate preparing to leave for their Easter Recess, 94 bills were introduced. Of these, two may be of specific interest to readers of this blog:

HR 5399 To amend the Homeland Security Act of 2002 to clarify that grants made pursuant to the Urban Area Security Initiative and the State Homeland Security Grant Program may be used to increase the preparedness of high-risk State, local, territorial, and tribal governments against weapons of mass destruction and biological and chemical attacks, and for other purposes. Rep. Gabbard, Tulsi [D-HI-2]

S 2620 A bill to establish a Federal cyber joint duty program for cyber employees of Federal agencies. Sen. Peters, Gary C. [D-MI]

As always, the large number of bills introduced before a major break in congressional attendance in Washington is not an indicator of congressional zeal. Rather, it is an indicator of campaigning initiatives. The talking points provided by most of these bills show that the introducing congresscritters are committed/interested in specific concerns of their constituents. The vast majority of these bills will see no congressional action beyond their introduction

It will be interesting to see if the wording of HR 5399 will allow the use of these grants for preparedness activities for attacks on chemical facilities or chemical transportation assets designed to specifically release hazardous chemicals. I am not going to hold my breath.

As with any of these clearly federal-limited cyber efforts, I will be watching this bill to see if it includes specific provisions related to industrial control system cybersecurity efforts. Yes, the federal government does have ICS, if you include building automation and security systems under the ICS umbrella.

ICS-CERT Publishes 2 Advisories and Siemens Update


Yesterday the DHS ICS-CERT published two control system security advisories for products from Beckhoff and Siemens. They also updated a previously published advisory for products from Siemens. The two Siemens products were mentioned in a previous blog post.

Beckhoff Advisory


This advisory describes an untrusted pointer dereference vulnerability in the Beckhoff TwinCAT PLC products. The vulnerability was reported by Steven Seeley of Source Incite. According to the Beckhoff security advisory, the company has updates available that mitigate the vulnerability. There is no indication that Seeley has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker with uncharacterized access could exploit the vulnerability to escalate privileges. ICS-CERT reports that Matlab modules need to be recompiled after updating.

Siemens Advisory


This advisory describes an improper access control vulnerability in the Siemens SIMATIC WinCC OA UI mobile app. The vulnerability was reported by Alexander Bolshev from IOActive, and Ivan Yushkevich from Embedi. Siemens has updates available that mitigate the vulnerability. There is no indication that the researchers have verified the efficacy of the fix.

ICS-CERT reports that an uncharacterized attacker on an adjacent network could exploit the vulnerability to read and write data from and to the app’s project cache folder. The Siemens security advisory notes that a social engineering attack is required to convince the App user to connect to an attacker-controlled WinCC OA server

Siemens Update


This update provides new information on an advisory that was originally published on January 25th, 2018 and updated on February 6th. The update removes a product from the affected product list.

Thursday, March 22, 2018

Rules Committee Approves HR 1625 Amendment – FY 2018 Spending Bill


Late last night the House Rules Committee met to consider the rule for the floor consideration of the Senate amendment to HR 1625. This bill has become the vehicle for the Consolidated Appropriations Act, 2018. The Committee approved a closed rule for the consideration of the bill, with one hour of debate and no floor amendments to be considered.

The Spending Bill


The Committee web site has a link to the full amendment that is the spending bill. There are also links to most of the separate divisions of the bill (essentially individual spending bills) to make it somewhat easier to wade through the bill. The divisions of potential specific interest to readers of this blog include:

• Division B CJS;
• Division C DOD;
• Division F DHS; and
Division L THUD

Division S of the bill contains a number of provisions that are separate from the actual spending bills, but need to be reauthorized, at least on a short-term basis. There is no separate Division S document, but the Committee did provide a summary document providing a very brief description of the programs covered.

The Explanatory Statement for this spending bill has not been published. The rule for the consideration of this bill (H Res 796) allows the Chair of the Appropriations Committee to insert the Statement in today’s Congressional Record. The Statement provides most of the details normally seen in the committee reports on the individual spending bills.

Moving Forward


The House will almost certainly take up this bill this afternoon. Due to the late availability of the huge bill, it is not yet clear if the Republicans will have enough votes to pass this bill on their own or if they will receive any support from House Democrats. I suspect that the bill will pass.

The big question will, of course, be the Senate. I would like to hope that the negotiators have done an adequate job to ensure that they have the necessary votes, but you can never tell for sure with a bill as complex as this. There is an interesting news report about the potential delay of the consideration of the bill in the Senate by a single Senator.


Bills Introduced – 03-21-18


Yesterday with the House and Senate both in session, there were 34 bills introduced. Of those two (see note below) may be of specific interest to readers of this blog:

HR 5366 To amend title 18, United States Code, to provide for certain authorized actions regarding interdiction of unmanned aircraft, and for other purposes. Rep. Hartzler, Vicky [R-MO-4]

HR 1625 TARGET Act [Consolidated Appropriations Act, 2018] House Amendment to Senate Amendment to H.R. 1625 (Rules Committee Print 115-66—Showing the text of the Consolidated Appropriations Act, 2018)

NOTE: Okay, HR 1625 was not actually introduced yesterday in the formal sense of the word. The House Rules Committee published the text that will be considered as substitute language for the Senate amendment to HR 1625. The important thing is that this will now be the omnibus spending bill for 2018. More on this bill later.

Wednesday, March 21, 2018

Bills Introduced – 03-20-18


Yesterday, with both the House and Senate in session, there were 33 bills introduced. Of those, one may be of specific interest to readers of this blog:

HR 5356 To establish the National Security Commission on Artificial Intelligence. Rep. Stefanik, Elise M. [R-NY-21]

Okay, I am not an AI geek, but this sounds like it may be interesting. It was assigned to too many committees (5) to have much chance of advancing, but I am probably going to be watching this one anyway. It will be real interesting to see how they define ‘artificial intelligence’.

I have to mention another bill (actually a resolution) in passing; no further coverage here. H Res 791 was introduced “Expressing support for the designation of Cesar Chavez's birthday, March 31, as National Border Control Day”. I’m not sure if this was intended as irony or a slap at Cesar Chavez; it is hard to tell with Rep Gohmert (R,TX).

ICS-CERT Publishes 2 Advisories and 3 Updates

Yesterday the DHS ICS-CERT published two new control system advisories for products from Siemens and Geutebruck. It also updated three previously published control system advisories for products from Siemens (2) and AutomationDirect. ICS-CERT has missed some recent Siemens updates and an advisory.

Siemens Advisory


This advisory describes an improper input validation vulnerability in the Siemens SIMATIC, SINUMERIK, and PROFINET IO products. The vulnerability is being self-reported by Siemens. Siemens has provided updates that mitigate the vulnerability is some products and has provided generic workarounds for the remaining products while updates are developed for them.

ICS-CERT reports that an uncharacterized attacker on an adjacent network could exploit this vulnerability to execute a denial-of-service condition requiring a manual restart to recover the system. The Siemens security advisory notes that OSI Layer 2 access is required to exploit the vulnerability.

Geutebruck Advisory


This advisory describes six vulnerabilities in the Geutebruck IP cameras. The vulnerabilities were reported by Davy Douhine of RandoriSec and Nicolas Mattiocco of Greenlock. Geutebruck has a new firmware version that mitigates 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:

• Improper authentication - CVE-2018-7532;
• SQL injection - CVE-2018-7528;
• Cross-site request forgery - CVE-2018-7524;
• Improper access control - CVE-2018-7520;
• Server-side request forgery - CVE-2018-7516; and
• Cross-site scripting - CVE-2018-7512

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to lead to proxy network scans, access to a database, adding an unauthorized user to the system, full configuration download including passwords, and remote code execution.

SIMATIC Update


This update provides additional information on an advisory that was originally published on February 27th, 2018. It provides updated version information and mitigation measures for:

• SIMATIC IPC547G: Update BIOS to R1.21.0

SIPROTEC Update


This update provides additional information on an advisory that was originally published on July 6th, 2017, and updated on July 18th, on July 28th, on October 10th, on November 30th, and then again on January 4th, 2018. It provides updated version information and mitigation measures for:

• SIPROTEC 7SJ66: All versions prior to V4.30


AutomationDirect Update


This update provides additional information on an advisory that was originally published on November 9th, 2017. It adds a new product (Do-more Designer) to the list of vulnerable products and provided mitigation links for that product.

Missing Siemens Updates


Siemens has published updates and advisories that have not been covered in this latest series of ICS-CERT publications. Normally, I would not mention the ones from yesterday (two updates here and here, and a new advisory here), but today’s new Siemens advisory was also released yesterday. There is also an update from last week (here) that was not mentioned.

Two of the updates (here and here) are for the Spectre and Meltdown vulnerabilities in the Siemens Industrial products. ICS-CERT is unlikely to update their alert to reflect these new mitigation measures since the existing link to the Siemens advisory will take someone to the new information. This is a potential problem for anyone that is relying on ICS-CERT for information, but because of the way that ICS-CERT does their updates (and does not provide detailed change information) this appears to be unavoidable.

Tuesday, March 20, 2018

House Passes HR 5074 – Cyber Incident Response Teams


Yesterday the House passed HR 5074, the DHS Cyber Incident Response Teams Act of 2018, by a voice vote. The bill would authorize the establishment and use of “cyber hunt and incident response teams” in the National Cybersecurity and Communications Integration Center (NCCIC). No additional funding is provided in this bill.

As I mentioned yesterday, this bill has been officially referred to as being considered “as amended” and no amendments were offered or approved when the bill was considered by the House Homeland Security Committee. The Congressional Record for yesterday (pg H 1661) makes the same statement. I have reviewed the original bill, the reported version (published overnight) and the version published in the Record and can find no differences between these three versions. Maybe there will be some explanation when the Committee Report (H Rept 115-607) is printed later this week.

It is difficult to predict whether or not this bill will be taken up by the Senate. If it does make it to the Senate floor, I suspect that it will be at the end the day under the Senate’s ‘without objection’ procedures; meaning no debate and no vote.

If this bill does become law, it will have an interesting potential consequence. With the use of the term ‘control systems’ in the new paragraph (f)(1)(D) of 6 USC 148, we see an official opening of the NCCIC to consideration of control system incidents, particularly since the term is used with these incident response teams. The IT-limited definition of ‘information systems’ in §148 has not specifically prohibited NCCIC from consideration of ICS incidents, but it has not provided specific authorization either. I would still prefer to see the definition of ‘information systems’ at §148(a)(5) to an ICS inclusive definition (as in §1501), but the provision in this bill should make it reasonably clear that NCCIC should consider control system incidents as part of its area of interest.

Monday, March 19, 2018

S 1281 Reported in Senate – Hack DHS Act


Earlier this month the Senate Homeland Security and Governmental Affairs Committee published their report on S 1281, the Hack the Department of Homeland Security (Hack DHS) Act of 2017. The Committee amended and approved the bill at a markup hearing conducted on October 4th, 2017.

Changes to Bill


The Committee approved a substitute language amendment to the bill. Several minor changes were made to the bill. For example; in two different places in the bill the term ‘information technology’ was modified by preceding it with the words ‘Internet facing’.

The most extensive changes were found in §2(b) and §2(c). The changes to (b) were mostly changes in the order of the subparagraphs in (b)(2), but wording was added to change the hacker registration to a process with the contractor running the program rather than directly with DHS.

The changes in §2(c) deal with the required report to Congress on the pilot program. Two new subparagraphs were added, and one was deleted. The added subparagraphs deal with the “the current number of outstanding previously unidentified security vulnerabilities and Department remediation plans” {§2(c)(4)} and “types of compensation provided” {§2(c)(6)}. The removed subparagraph {§2(c)(5)} would have required more details about the types of compensation provided.

Moving Forward


With the bill being reported out of Committee by voice vote indicates that the bill has significant bipartisan support within the Committee. This will probably translate into a lack of significant opposition if the bill were to make it to the floor of the Senate, and I would suspect that it would be considered under the Senate’s unanimous consent procedure with no debate and no formal vote.

Commentary


The minor change made by adding the words ‘Internet facing’ could significantly reduce the number of systems that could be included in the pilot bug bounty program outlined in the bill. It reflects a common misunderstanding of the vulnerability of computer systems that are not ‘Internet facing'. The lack of ‘Internet facing’ is not even the same as the fabled ‘air gapped’ protection of control systems. Information systems will typically be accessible by networked computers that are Internet accessible even if the information system is not internet facing.

The addition of this limitation on the systems to be included in the pilot program is even more confusing because the term ‘Internet facing’ is not defined in the bill. If the staff really wanted to limit the application of the program they should have included a definition that specified what limits they expected the Department to apply.

There was one interesting definition change made in the bill. The original bill cited 44 USC 3502 for the definition of ‘information system’. The new version of the bill instead uses the definition from 40 USC 11101. This really is not a change in definition since §11101(5) refers back to §3502 for the definition of the term. The term is still the IT-limited definition of the term, so no Department control system (building automation or access control systems for example) would be considered for the pilot program.

Committee Hearings – Week of 03-18-18


There are a significant number of hearings scheduled this week with both the House and Senate in session. Budget hearings predominate, but none that are of specific interest to readers of this blog. In fact, I do not see any hearings of specific interest here this week. There are, however, two bills that will make it to the floor of the House this week that I am watching and, of course, there is a spending bill deadline approaching at the end of the week.

On the Floor of the House


There are a number of bills that are scheduled to come to the floor on Monday under the suspension of the rules provisions of the House. These provisions limit debate, prohibit floor amendments, and require a super-majority to pass. Bills of potential interest include:

HR 5074, the DHS Cyber Incident Response Teams Act of 2018;
HR 5089, Strengthening Local Transportation Security Capabilities Act of 2018;

Interestingly, both of these bills are listed in the Majority Leader’s schedule as being considered “as amended”. The Homeland Security Committee mark-up hearing for both of these bill resulted in an order for each bill that the bill be “reported to the House with a favorable recommendation, without amendment”. No report has been published for either bill (will probably be submitted today and published later this week), so I cannot tell if Chairman McCaul (R,TX) subsequently ordered some revisions be made to the bill. It would not be too unusual for minor technical revisions to be made after mark-up, but substantial revisions are seldom made.

FY 2018 Spending Bill


The current continuing resolution (CR, HR 1892) will expire on Friday night. The hope has been that the House and Senate will consider and pass an omnibus spending bill this week that would include all of the non-DOD operations of the government (DOD spending was included in the last CR). News reports (see here for example) would seem to indicate that there is still some hard negotiating to be done on this bill.

Is there a chance that there will be another CR? It increasingly seems that there is always a chance. One remote possibility is that a CR for the rest of the fiscal year could be passed, keeping the current funding levels. While the inclusion of DOD spending in HR 1892 would seem to make that possibility easier, it would violate the agreement to increase spending levels in non-DOD areas that allowed HR 1892 to eventually be passed.

Saturday, March 17, 2018

CFATS Authorization – Excluded Facilities


This is part of a continuing series of blog posts on my proposed changes to the CFATS authorization. The current authorization for the program ends on December 18th, 2018. These posts address some of the language that I would like to see in any re-authorization bill. Earlier posts in the series include:


The current CFATS authorization lists five types of facilities that are ‘excluded’ from the requirements of the CFATS program {6 USC 621(4)}:

• A facility regulated under the Maritime Transportation Security Act of 2002 (Public Law 107–295; 116 Stat. 2064);
• A public water system, as that term is defined in section 300f of title 42;
• A Treatment Works, as that term is defined in section 1292 of title 33;
• A facility owned or operated by the Department of Defense or the Department of Energy; or
A facility subject to regulation by the Nuclear Regulatory Commission.

The presumption is that the federal programs that are responsible for the facility oversight already adequately address site security concerns. This presumption was a political decision made when the CFATS program was originally authorized in 2006. Since the program was developed there has been no outside comparison of the various security requirements of the various programs.

Study Requirement


The major problem in comparing these security programs is that only the CFATS program is specifically targeted at protecting chemicals from terrorist attacks. What is needed is a formal program comparison that specifically addresses the security controls that provide protections to on-site chemicals found in Appendix A to 6 CFR 27. To that end, I would include the following language:

Sec. 632 – Excluded Facility Study

(a) The Comptroller General will, within 180 days, prepare a report to Congress on the comparative security requirements between the existing CFATS regulations, as defined in §621(1), and the provisions associated with the federal programs regulating excluded facilities, as that term is defined in §621(4). The study will compare the program requirements that would prevent:

(1) The release of chemicals identified as a release security issue in Appendix A to 6 CFR Part 27;
(2) The theft or diversion of chemicals identified as theft security issue in Appendix A to 6 CFR Part 27; and
(3) The sabotage of chemicals identified as a sabotage security issue in Appendix A to 6 CFR Part 27.

(b) The report will specifically identify any deficiencies in the respective regulatory program as compared to the CFATS regulations to provide equivalent levels of protection for chemicals identified in (a)(1), (2) and (3);

(c) The report to Congress will be unclassified with a classified annex if deemed appropriate by the Comptroller General. The unclassified version of the report will be published on the CFATS web site.

(d) The Secretary, in consultation with the Environmental Protection Agency, the Department of Energy, the Department of Defense and the Nuclear Regulatory Commission, will, within 1 year of the publication of the report required in (a), report to Congress on any recommendations for changes in changes in the excluded facilities provisions of this subchapter that would correct deficiencies noted in (b) above.

Public ICS Disclosure – Week of 03-10-18


We have two exploit code releases this week for industrial control systems, the vulnerability for one was previously reported by ICS-CERT. The vulnerable products come from Prisma Industriale and Advantech.

Prisma Exploit


Gjoko 'LiquidWorm' Krstic published exploit code for a hard-coded credential vulnerability in the Prisma Industriale Checkweigher, an in-line weighment device. The vulnerability had been previously published by Zero Science Labs; who had attempted to coordinate the disclosure with the vendor.

The vulnerability reportedly allows a successful attacker administrator level access to the device.

Advantech Exploit


Chris Lyne published exploit code for a directory traversal vulnerability in the Advantech WebAccess products. The vulnerability was previously reported by ICS-CERT and ZDI. According to ZDI, the vulnerability allows a successful attacker administrative-level remote-code execution ability.

Friday, March 16, 2018

TSA Publishes 2017 Surface Enforcement Summary


Earlier this week the DHS Transportation Security Administration (TSA) published a notice in the Federal Register (83 FR 11236-11240) providing a summary of the enforcement actions that were undertaken in the surface transportation security realm for calendar year 2017. Looking at the results it is apparent that the TSA significantly stepped up its enforcement of the Transportation Workers Identification Credential (TWIC) program under 49 CFR 1570. For the second year in a row TSA reported no enforcement actions under the rail security provisions of 49 CFR 1580.

The table below shows a summary of the last four year’s enforcement activities. The total for this year’s report is a little overstated because there were twenty instances in this report where two or more violations were reported for a single incident.

Did not allow TSA Inspection
Rail Car Chain of Custody
4
1
Rail Car Security
Rail Car Location
1
Reporting Security Concern
1
1
Use of another’s TWIC
8
5
4
15
Direct the use of another's TWIC
7
3
41
Fraudulent Manufacture of TWIC
2
5
8
Use of an altered TWIC
15
34
134
Total
14
31
46
198

The continued failure to report any railroad enforcement actions would tend to indicate that the TSA is effectively ignoring rail security issues. This is hardly surprising with the very small Surface Transportation Security inspection force and the very widely spread rail network. It is much easier to concentrate efforts in the fairly limited port areas of the country. What is disappointing however, it the apparent failure to look at rail security operations in the port areas where the inspection forces are apparently concentrated.

In previous years reporting (see here for example) I tried to summarize the information provided on fines proposed and assessed. This year, with the huge increase in the reported incidents, I have not attempted to do so. Most of the incidents reported resulted in just warnings being issued. The largest fine proposed this year was $6,000 and the largest actually assessed was $2,000. With the violations being typically assessed against individuals rather than commercial organizations, these figures are probably reasonable.

One final point that is interesting in this TSA report; the file numbering system that TSA uses to track their surface transportation security enforcement activities. It consists of a four-digit year number, a three-character city code, and a four-number sequence code. The city code is the international airport code for the city involved instead of the 4-character code for the port involved. This is just another indication of the extreme airport bias of the TSA.


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