Tag: Critical Infrastructure

Categories
Links Writing

American Telecommunication Companies’ Cybersecurity Deficiencies Increasingly Apparent

Five Eyes countries have regularly and routinely sought, and gained, access to foreign telecommunications infrastructures to carry out their operations. The same is true of other well resourced countries, including China.

Salt Typhoon’s penetration of American telecommunications and email platforms is slowly coming into relief. The New York Times has an article that summarizes what is being publicly disclosed at this point in time:

  • The full list of phone numbers that the Department of Justice had under surveillance in lawful interception systems has been exposed, with the effect of likely undermining American counter-intelligence operations aimed at Chinese operatives
  • Phone calls, unencrypted SMS messages, and email providers have been compromised
  • The FBI has heightened concerns that informants may have been exposed
  • Apple’s services, as well as end to end encrypted systems, were not penetrated

American telecommunications networks were penetrated, in part, due to companies relying on decades old systems and equipment that do not meet modern security requirements. Fixing these deficiencies may require rip-and-replacing some old parts of the network with the effect of creating “painful network outages for consumers.” Some of the targeting of American telecommunications networks is driven by an understanding that American national security defenders have some restrictions on how they can operate on American-based systems.

The weaknesses of telecommunications networks and their associated systems are generally well known. And mobile systems are particularly vulnerable to exploitation as a result of archaic standards and an unwillingness by some carriers to activate the security-centric aspects of 4G and 5G standards.

Some of the Five Eyes, led by Canada, have been developing and deploying defensive sensor networks that are meant to shore up some defences of government and select non-government organizations.1 But these edge, network, and cloud based sensors can only do so much: telecommunications providers, themselves, need to prioritize ensuring their core networks are protected against the classes of adversaries trying to penetrate them.2

At the same time, it is worth recognizing that end to end communications continued to be protected even in the face of Salt Typhoon’s actions. This speaks the urgent need to ensure that these forms of communications security continue to be available to all users. We often read that law enforcement needs select access to such communications and that they can be trusted to not abuse such exceptional access.

Setting aside the vast range of legal, normative, or geopolitical implications of weakening end to end encryption, cyber operations like the one perpetrated by Salt Typhoon speak to governments’ collective inabilities to protect their lawful access systems. There’s no reason to believe they’d be any more able to protect exceptional access measures that weakened, or otherwise gained access to, select content of end to end encrypted communications.

  1. I have discussed these sensors elsewhere, including in “Unpacking NSICOP’s Special Report on the Government of Canada’s Framework and Activities to Defend its Systems and Networks from Cyber Attack”. Historical information about these sensors, which were previously referred to under the covernames of CASCADE, EONBLUE, and PHOTONICPRISM, is available at the SIGINT summaries. ↩︎
  2. We are seeing some governments introducing, and sometimes passing, laws that would foster more robust security requirements. In Canada, Bill C-26 is generally meant to do this though the legislation as introduced raised some serious concerns. ↩︎
Categories
Links Writing

Vulnerability Exploitability eXchange (VEX)

CISA has a neat bit of work they recently published, entitled “Vulnerability Exploitability eXchange (VEX) – Status Justifications” (warning: opens to .pdf.).1 Product security teams that adopt VEX could assert the status of specific vulnerabilities in their products. As a result, clients’ security staff could allocate time to remediate actionable vulnerabilities instead of burning time on potential vulnerabilities that product security teams have already closed off or mitigated.

There are a number of different machine-readable status types that are envisioned, including:

  • Component_not_present
  • Vulnerable_code_not_present
  • Vulnerable_code_cannot_be_controlled_by_adversary
  • Vulnerable_code_not_in_execute_path
  • Inline_mitigations_already_exist

CISA’s publication spells out what each status entails in more depth and includes diagrams to help readers understand what is envisioned. However, those same readers need to pay attention to a key caveat, namely, “[t]his document will not address chained attacks involving future or unknown risks as it will be considered out of scope.” Put another way, VEX is used to assess known vulnerabilities and attacks. It should not be relied upon to predict potential threats based on not-yet-public attacks nor new ways of chaining known vulnerabilities. Thus, while it would be useful to ascertain if a product is vulnerable to EternalBlue, today, it would not be useful to predict or assess the exploited vulnerabilities prior to EternalBlue having been made public nor new or novel ways of exploiting the vulnerabilities underlying EternalBlue. In effect, then, VEX is meant to address the known risks associated with N-Days as opposed to risks linked with 0-Days or novel ways of exploiting N-Days.2

For VEX to best work there should be some kind of surrounding policy requirements, such as when/if a supplier falsely (as opposed to incorrectly) asserts the security properties of its product there should be some disciplinary response. This can take many forms and perhaps the easiest relies on economics and not criminal sanction: federal governments or major companies will decline to do business with a vendor found to have issued a deceptive VEX, and may have financial recourse based on contactual terms with the product’s vendor. When or if this economic solution fails then it might be time to turn to legal venues and, if existent approaches prove insufficient, potentially even introduce new legislation designed to further discipline bad actors. However, as should be apparent, there isn’t a demonstrable requirement to introduce legislation to make VEX actionable.

I think that VEX continues work under the current American administration to advance a number of good policies that are meant to better secure products and systems. VEX works hand-in-hand with SBOMs and, also, may be supported by US Executive Orders around cybersecurity.

While Canada may be ‘behind’ the United States we can see that things are potentially shifting. There is currently a consultation underway to regenerate Canada’s cybersecurity strategy and infrastructure security legislation was introduced just prior to Parliament rising for its summer break. Perhaps, in a year’s time, we’ll see stronger and bolder efforts by the Canadian government to enhance infrastructure security with some small element of that recommending the adoption of VEXes. At the very least the government won’t be able to say they lack the legislative tools or strategic direction to do so.

  1. You can access a locally hosted version if the CISA link fails. ↩︎
  2. For a nice discussion of why N-days are regularly more dangerous then 0-Days, see: “N-Days: The Overlooked Cyber Threat for Utilities.” ↩︎
Categories
Quotations

2019.1.14

Between 2002 and 2009, the [Industrial Control System Cyber Emergency Response Team] conducted more than 100 site assessments across multiple industries–oil and natural gas, chemical, and water–and found more than 38,000 vulnerabilities. These included critical systems that were accessible over the internet, default vendor passwords that operators had never bothered to change or hard-coded passwords that couldn’t be changed, outdated software patches, and a lack of standard protections such as firewalls and intrusion-detection systems.

But despite the best efforts of the test-bed and site-assessment researchers, they were battling decades of industry intertia–vendors took months and years to patch vulnerabilities that government researchers found in their systems, and owners of crucial infrastructure were only willing to make cosmetic changes to their systems and networks, resisting more extensive ones.

Kim Zetter, Countdown to Zero-Day
Categories
Links Writing

Another ‘Victory’ for the Internet of Things

Researchers have found, once again, that sensitive systems have been placed on the Internet without even the most basic of security precautions. The result?

Analyzing a database of a year’s worth of Internet scan results [H.D. Moore]’s assembled known as Critical.io, as well as other data from the 2012 Internet Census, Moore discovered that thousands of devices had no authentication, weak or no encryption, default passwords, or had no automatic “log-off” functionality, leaving them pre-authenticated and ready to access. Although he was careful not to actually tamper with any of the systems he connected to, Moore says he could have in some cases switched off the ability to monitor traffic lights, disabled trucking companies’ gas pumps or faked credentials to get free fuel, sent fake alerts over public safety system alert systems, and changed environmental settings in buildings to burn out equipment or turn off refrigeration, leaving food stores to rot.

Needless to say, Moore’s findings are telling insofar as they reveal that engineers responsible for maintaining our infrastructures are often unable to secure those infrastructures from third-parties. Fortunately, it doesn’t appear that a hostile third-party has significantly taken advantage of poorly-secured and Internet-connected equipment, but it’s really only a matter until someone does attack this infrastructure to advance their own interests, or simply to reap the lulz.

Findings like Moore’s are only going to be more commonly produced as more and more systems are integrated with the Internet as part of the ‘Internet of Things’. It remains to be seen whether vulnerabilities will routinely be promptly resolved, especially with legacy equipment that enjoys significant sunk costs and limited capital for ongoing maintenance. Given the cascading nature of failures in an interconnected and digitized world, failing to secure our infrastructure means that along with natural disasters we may get to ‘enjoy’ cyber disasters that are both harder to positively identify or subsequently remedy when/if appropriately identified.

Categories
Links

Social and Economic Threats to the Internet’s Infrastructure

Bruce Schneier, talking about the social and economic threats to the Internet’s infrastructure

Categories
Links Writing

Major Critical Infrastructure Vulnerabilities Disclosed

For years, researchers have warned that the systems that run critical infrastructure have systemic and serious code-based vulnerabilities. Unfortunately, governments have tended to use such warnings as a platform to raise ‘cyber-warfare’ arguments. Many such arguments are thinly-disguised efforts to assert more substantive government surveillance and control over citizens’ rights and expressions of freedom. Few of these arguments genuinely address the concerns researchers raise.

In the face of governmental lacklustre efforts to secure infrastructure, researchers have disclosed critical vulnerabilities in many of the systems responsible for manufacturing facilities, water and waste management plants, oil and gas refineries and pipelines, and chemical production plants. What’s incredibly depressing is this:

The exploits take advantage of the fact that the Modicon Quantum PLC doesn’t require a computer that is communicating with it to authenticate itself or any commands it sends to the PLC—essentially trusting any computer that can talk to the PLC. Without such protection, an unauthorized party with network access can send the device malicious commands to seize control of it, or simply send a “stop” command to halt the system from operating.

These kinds of ‘attacks’ or ‘exploits’ are possible because the most basic security precautions are not integrated into the logic controllers running such infrastructure. On the one hand this makes sense: many PLCs and the infrastructure they are embedded in were created and deployed prior to ‘the Internet’ being what it is today. On the other, however, one has to ask: if the money spent on security theatre at airports had been invested in hardening actual PLCs and other infrastructure, where would critical infrastructure security be today?