Circum Cyberes

By Ravi Nayyar

A Techno-Legal Update
15 min readJan 21, 2023

Okay, seeing that a ton of folks in cyber have a newsletter on the week’s happenings, I decided to have a crack. This is a pilot, hence, the lack of version numbering.

I have used the original headlines of the stories I comment on as headings. Headings in brackets are those I have come up with (eg because I am commenting on (a) social media post(s)).

Any feedback on my hot takes as well as this endeavour of mine is most welcome, folks!

Let’s dive in.

Ransomware Has Now Become a Problem for Everyone, and not Just Tech

The headline alone made me do a double-take.

What about NotPetya, WannaCry, the ransomware epidemic across the United States since 2019, Kaseya, Colonial Pipeline, JBS, Toll Group, attacks on healthcare worldwide, Costa Rica, or all major shipping companies (prior to the DNV hack)?

If we hone in on the article’s citation of the Royal Mail attack, why didn’t it cite WannaCry and the bricking of dozens of NHS trusts in 2017?

That didn’t already make ransomware ‘a problem for everyone’? Does the disruption of the operational resilience of CNI not affect everyone?

Lessons from Down Under’s Data Disasters Pt. 3

I highly recommend y’all read the latest edition of Prof Ciaran Martin’s newsletter in its entirety, but I want to hone in on one point he makes in relation to counter-ransomware policy:

Ransoms, along with low operating costs and low barriers to entry, are central to the criminal business model. And part of making that business model work (and these are my words, not those of Mr Krebs) is what I call a ‘pro-criminal narrative’ around ransoms. In other words, too many times organisations are told, through a variety of means, that the easiest or indeed only way out of the lonely and difficult crisis they face is to pay.

BINGO. Defenders and governments have agency. Governments — through cyber security agencies and regulators — especially have the agency to shape the information environment at home for ransomware. It’s time they did so to incentivise folks to not cough up ransoms.

Given that organisational decision-making at the victims of ransomware attacks is done by human beings, a key part of changing their behaviour is to change their underlying mindset. And critical to that is shaping the policy and operational context that mindset lives in.

This goes to the heart of Prof Martin’s point, as he cites the case of JBS, whose public justification for coughing up doesn’t quite pass the pub test. And indeed, because they paid despite that being the case, ‘it is a powerful example of just how strong the incentives to pay are’ and thus how powerful the ‘pro-criminal narrative’, that the victim lacks agency unless they pay up, is. Little wonder Prof Martin warns, ‘If what happened at JBS happens at scale, continuously, then we’re stuffed’.

As someone who is interested in how governments shape narratives, I wholeheartedly agree with Prof Martin when he calls for governments to work with the cyber resilience community to ‘change the pro-criminal narrative that paying is often the best option’, and indeed to recognise that advice ‘not to pay’, when paired with ‘thoughtful nods indicating that the authorities understand if the organisation takes the “wrong” decision’, doesn’t amount to much.

There is a clear need for governments to stress the merits of victims — like the Harris Federation — in refusing to give in to cybercriminals, as well as educate stakeholders on the distinction between ransomware attacks that brick systems alone versus those where the attacker demands payment to not disclose stolen data. Stakeholders like government and the press must work together to assure the responsible reporting and discussion of major ransomware attacks, as suggested by Prof Martin.

Otherwise, I reckon that if the Fourth Estate focuses entirely on or otherwise amplifies a sense of chaos or catastrophe in the case of a data extortion attack like that against Medibank, the narrative which will prevail among civil society and industry stakeholders would be that ‘everyone is utterly helpless and that the best advice would be, JBS-style, to pay up to make the problem go away’. And criminals will continue to demand big money. And get it, thanks in no small part to the information environment which the victims’ Boards operate in.

As Prof Martin says, ‘We have to shift the pro-criminal narrative… By telling the stories that show that paying doesn’t always pay’.

And as one of my uncles would say (translated from the Hindi), ‘It’s morning whenever you wake up’.

18k Nissan Customers Affected by Data Breach at Third-Party Software Developer

Thousands of Nissan North America (‘Nissan’) customers have had their personal information accidentally exposed on the Internet by a third-party software development service provider of the carmaker. Informed of the breach in June 2022, the service provider determined in September that the data that was exposed and stolen included that of Nissan customers.

Per Nissan’s advisory, the service provider had received certain data from Nissan to process as it tested software. That data was apparently put in an Internet-facing cloud repository by the organisation, following which the attackers grabbed at least some of it, including the PII of Nissan customers, including their ‘names, birth dates, and NMAC [Nissan Motor Acceptance Company, the financial services arm of Nissan] account numbers’, but not, per Nissan, Social Security numbers and credit card data.

Excellent targeting by the attackers — there is a solid chance that any major organisation’s third-party software development service provider will be sitting on a good deal of the former’s data. The attackers also leveraged the not-uncommon occurrence where tons of company data or customer PII can be simply left for the public to see in misconfigured cloud environments.

Of course, this attack is merely one which resulted in a data breach. Not one affecting Nissan’s ability to, say, source parts for manufacturing cars, like the one against Kojima Industries, Toyota’s plastic parts and electronic components supplier, in February 2022. That one forced Toyota to suspend production at fourteen of its own plants. But both attacks underline the criticality of cyber SCRM as part of operational risk management. Auditing suppliers, their governance frameworks, their compliance with relevant laws and contractual standards, their BCP, for instance.

The attack against Nissan’s service provider also underlines the criticality of software SCRM, given that a lot of companies outsource their software development to third parties. Imagine if Nissan was the subject of an actual software supply chain attack via its service provider, SolarWinds-/Kaseya-style. Much more serious implications for the interests of the carmaker’s shareholders than a PII breach.

Cyber-Attack on ShipManager Servers — Update

DNV is a Norwegian shipping classification society which provides an industry-leading marine fleet management software suite called ShipManager. ShipManager ‘supports management of vessels and fleets in all technical, operational and compliance aspects’, be it in relation to maintenance, procurement, safety and crew management, hull integrity, repair or analytics.

The company’s servers running ShipManager were ransomwared on 7 January, prompting the company to shut them down, leaving customers confined to using merely the ‘onboard, offline functionalities’ of the suite. Per DNV’s 19 January update on the attack, it doesn’t appear that any other DNV boxes or services were affected, with the infrastructure operating ShipManager isolated from the rest of the company. Good. The company said, however, ‘About 70 customers, operating around 1.000 vessels, are affected’. Not good.

Given that shipping is a critical infrastructure sector, this attack is a case study on the digital dependencies of CNI being weaponised in software supply chain attacks. I am reminded of how NotPetya bricked about one fifth of world shipping via Maersk’s software supply chain in 2017. Though originally targeting Ukraine, the malware pwned virtually Maersk’s entire IT infrastructure having entered through its Ukrainian operation. Which used a locally ubiquitous piece of accounting software called MeDoc, NotPetya’s initial attack vector. Of course, DNV looks to have been specifically targeted here, but both attacks reinforce the need for robust software SCRM by shipping companies. The DNV attack especially suggests that they have to be judicious when outsourcing critical operational activities to cloud-based software suites like ShipManager.

DNV advising affected customers to ‘consider relevant mitigating measures depending on the types of data they have uploaded to the [ShipManager] system’ seems a tad quaint in light of how much companies are dependent on the latter, putting aside their BCP.

Also note in general the issue of ‘negative externalities galore’ when it comes to failures in the cyber resilience of critical suppliers to operators of CNI.

Mexico’s Subway Drivers Depend on WhatsApp to Keep the Trains Running

The faulty state of the automatic pilot program of the Mexico City Metro requires conductors to manually operate its trains. But that requires them to use a radio-based communications network to coordinate their movements. Which is itself faulty.

As a result, the conductors ‘often have to use their own cellphones and WhatsApp chats to coordinate with the control center’.

Wowee. WhatsApp as a critical node of a CNI software supply chain, even if forced by circumstance in this case and as a ground-up ‘solution’ to the actual comms system being suboptimal. And the subsequent risks for the Metro that this invites.

It would certainly be quite ironic if the management of the Metro has factored in the operational resilience of WhatsApp into their BCP, given that they couldn’t assure the operational resilience of the automatic pilot and existing radiocommunications systems.

CircleCI Incident Report for January 4, 2023 Security Incident

CI/CD delivery platform, CircleCI, published a write-up going through a breach it suffered in early January. It said that the attacker nabbed a 2FA-backed SSO session cookie with the aid of malware deployed on a CircleCI employee’s laptop, which was compromised on 16 December 2022. The company’s antivirus software did not detect the malware.

Thus able to impersonate the employee, the attacker ‘escalate[d] access to a subset of our [CircleCI’s] production systems’. They leveraged the employee’s legitimate privileges to create production access tokens to ‘access and exfiltrate data from a subset of databases and stores, including customer environment variables, tokens, and keys’. The company believed that said exfiltration occurred on 22 December 2022 and that the attacker could potentially access the data through encryption keys that they extracted from a running process.

First things first, chef’s kiss to the attackers for their targeting. They compromised the machine of a juicy target within the organistion, given the target’s privileges. Underlines the need for organisations to keep auditing the access privileges of their employees and contractors.

On the point of the attacker stealing a 2FA-backed session cookie and CircleCI’s AV not picking up the malware, well, that just underlines how important cyber resilience is. Because attackers are getting smarter and will find a way through your perimeter. You have to assume compromise, so invest in solutions for monitoring your internals and nipping attackers in the bud. That said, I still don’t quite get how a company like CircleCI seemingly didn’t have good enough EDR to detect the malware on the employee’s laptop. But good on ’em for coming clean, ‘first step’ and all.

Thirdly, this incident stresses the importance of software SCRM, not least because a lot of software development life cycle occurs in the cloud (eg SaaS, IaaS, SaaS), on systems owned or otherwise-provided by third parties like CircleCI and the latter’s own suppliers.

Software SCRM makes the world go round, people!

(A Window unto Python)

Mastodon user, Stargirl, composed an informative, frank thread on the functioning of the Python open source software (‘OSS’) ecosystem. A thread which underlines the need for folks to understand the sheer diversity of stakeholder groups involved in making OSS ecosystems work (in a way) and the sheer diversity within said groups.

OSS ecosystems are populated and run by folks with different attitudes on a range of things. They are not bound, certainly to the same extent, by standards/structures/hierarchies like proprietary software ecosystems are. Even within ecosystems, you have different standards of cyber governance. I’m not saying that all OSS devs and package maintainers are aloof or apathetic (eg look at how the Apache Software Foundation and other OSS stakeholders rallied in response to Log4Shell), but OSS is a mixed bag. I guess it’s because that’s what open source software is all about.

Supply Chain Attack Using Identical PyPI Packages, “colorslib”, “httpslib”, and “libhttps”

Fortinet’s out with research on malicious Python packages — colorslib, httpslib and libhttps — published in January 2023 by an author called ‘Lolip0p’, who came on the scene not long before publication. Each package runs the same malicious binary executable on victim machines, though it is positioned as clean with an apparently ‘convincing project description’.

Fortinet thus calls for all Python users to ‘always perform due diligence before downloading and running any packages, especially from new authors’.

Threat actors seeking to inject malicious code into machines via OSS packages created from scratch is hardly new. Every week, malicious packages are discovered across OSS ecosystems. And those are the just the ones that get discovered.

Given all versions of the three malicious OSS packages in question being malicious, I am reminded of the issue with bad (whether malicious or vulnerable) dependencies plaguing other OSS projects and indeed proprietary software with OSS dependencies (many of which the software vendors may not be aware of).

To reinforce Fortinet’s point, you need to keep your wits about you.

MSI’s (in)Secure Boot

Dawid Potocki, a security researcher, discovered a serious issue embedded in the firmware for hundreds of MSI-designed motherboards. More specifically, a feature called ‘Secure Boot’ having insecure defaults.

Secure Boot is meant to stop the machine from loading operating systems not signed with a cryptographic key trusted by the firmware. It’s meant to.

But it didn’t. Since 2021 Q3 The firmware was accepting any operating system willy nilly because ‘MSI had changed their Secure Boot defaults to allow booting on security violations(!!)’. ‘Secure Boot’ was not checking for trusted keys, even when it was ‘enabled’.

Moral of the story:

Don’t trust that whatever security features you enabled are working, TEST THEM!

So much for ‘secure-by-default’, eh?

Assessing Potential Exploitation of Sophos Firewall and CVE-2022–3236

Cyber security firm, VulnCheck, has a write-up on the risk of exploitation of an unauthenticated and remote code execution vulnerability affecting the Sophos Firewall Webadmin and User Portal HTTP interfaces. Sophos patched the bug in December 2022, having sent out an automated hot fix in September.

But what is really concerning is the following finding:

More than 99% of internet-facing Sophos Firewalls haven’t upgraded to versions containing the official fix for CVE-2022–3236. But around 93% are running versions that are eligible for a hotfix, and the default behavior for the firewall is to automatically download and apply hotfixes (unless disabled by an administrator)… That still leaves more than 4,000 firewalls… running versions that didn’t receive a hotfix and are therefore vulnerable.

Many many many organisations don’t patch buggy systems?

Whodathunkit.

Ukraine Calls for ‘Cyber United Nations’ amid Russian Attacks

The chief of the State Special Communications Service of Ukraine (‘SSSCIP’) recently proclaimed:

We need the Cyber United Nations, nations united in cyberspace in order to protect ourselves… What we really need in this situation is a hub or a venue where we can exchange information, support each other and interact.

He also said that ‘there is a need for “one space, one cyberspace” shared by countries in the “civilized world”’.

Um, CERT-CERT/equivalent cooperation already happens. CTI sharing already happens. Be it regionally (eg EU/APAC) or bilaterally. Look at the UN norms for responsible state conduct in cyberspace (the UN Group of Governmental Experts which developed those norms had Russia on it).

Sure, the Russians won’t want to work with the Ukrainians, but the SSSCIP chief’s proposal (per the article) ‘would almost certainly mean the exclusion of Russia and its allies’.

In any case, I don’t know how the term, ‘civilised’, would wash with Global South countries who already have been demonised by elements of the Western commentariat for seeking to, eg, keep the lights on for their citizens amid skyrocketing oil prices caused by a war which is happening a few continents away from them and which they have little to do with in the first place.

There’s also this bit from the article:

Christopher Painter, who served as the State Department’s cyber coordinator under both the Obama and Trump administrations, … noted that likening it to the United Nations while not including every country “doesn’t really fit”.

Exactly.

Although, exclusivism would be, in a way, on brand for the UN. Just look at the P5.

Readout of Office of the National Cyber Director Meetings with Cybersecurity Researchers

The Office of the National Cyber Director in the US hosted a get-together for security researchers at the White House. The following bits of the official readout made me grin:

… discussed the critical importance of securing the foundational protocols that underlie our interconnected lives…

… participants broke up into small groups to discuss individuals’ perspectives on topics… [including] strengthening open-source software security…

Can’t wait to read the US National Cybersecurity Strategy when it comes out!

Ministries Flout Local Procurement Rules in Govt Contracts, Says DPIIT

The Indian government’s Department for Promotion of Industry and Internal Trade has flagged violations of domestic procurement rules by several Central ministries and their procurement arms. The breaches centred around agencies setting tender conditions — such as prerequisites — that effectively locked out Indian suppliers from popping a bid in.

I raise this story because one of the prerequisites agencies set was having products by Chinese electronics firm, Lenovo, in information technology contracts.

Okay, yes, HP and Dell were the other brands the agencies wanted, but come on, India, Lenovo?

Requiring any Chinese gear in government IT networks is akin to rolling out the red carpet for the Ministry of State Security/People’s Liberation Army’s Strategic Support Force/affiliated threat actors. Seriously, why on earth are Indian bureaucrats pushing for Lenovo gear? Who is advising them?

Please tell me that this is only sheer incompetence.

(The Issue with One Time Passwords)

Twitter user, Deepa Goyal, had the following views on the reliance by Indian organisations on one time passwords as an authentication factor:

I won’t comment on the specifics, but I was reminded of the thrust of what folks like Prof Ciaran Martin and Dr Ian Levy argue when it comes to status quo paradigms of cyber resilience not exactly working to protect civvies, especially older folks.

That is, we bombard our civvies with warnings, advice and so much messaging. And yet we still need to educate them on what risk, let alone cyber risk, is and how to calculate it. Governments would not be contemplating and/or enacting labelling regimes for things like IoT if information asymmetries favouring vendors were bad as they are.

We also bombard them with non-intuitive UIs for setting the right controls — assuming they can get to those interfaces in the first place (it’s hard as it is to quickly pick the right cookie settings on websites). Oh, and the controls that are given to them, they are not quite the easiest to implement, as in the case of OTPs. How would you feel about a barrage of text messages with authentication codes coming from multiple services?

Plus, these tweets capture merely part of the problem. Instead of SMS-based MFA, folks must switch to app-based MFA. Safer with no risk of having your authentication factor compromised through a SIM-swapping attack. Go for a hardware token if you’re super-committed. OS makers like Google, Apple and Microsoft are bringing in FIDO standards-based authentication called ‘Passkeys’, where the user’s computer or smartphone itself becomes a hardware token, replacing passwords.

OOPS! Learning from the Incident You Didn’t Have

This is a fascinating piece from LFI on governance and resilience, focused on what to take away from incidents.

The following bit caught me eye:

While incidents with greater business impact get more attention from an organization than incidents with smaller impact, it doesn’t necessarily follow that we can learn more from the great impact incidents than the lesser one.… And the difference between a high-profile incident and no incident at all might be something as mundane as a particular individual being out of the office on a certain day.

The last sentence is particularly important. We always study the high-profile incidents, but very rarely the cases where a breach could have become an incident but is headed off by the defenders, despite the non-incident breaches offering lessons on control design and response planning.

As the author says, ‘We can also learn just as much from an “incidents” when there is no impact at all!’

Why Indian Banks Want US Card Networks like Visa and Mastercard to Have a Share of UPI Pie

I have a few questions about this piece. The following bit in particular:

There’s no point in being parochial about payments. When the pie grows, everyone benefits. As for using credit cards for geopolitics, the stick can wait if a juicy carrot does the job just as well.

Excuse me?

The first sentence there is bizarre. As the author himself acknowledges, payments are geopolitics. The war in Ukraine showed this with the weaponisation of what was considered a global commons in the SWIFT network. To say otherwise is to ignore how the modern economy, where seemingly everything is/enables a dual-use good, actually works.

On the stick v ‘juicy carrot’, does the author really think that the Modi government will fail to tell the difference and thus sacrifice Indian interests?

Plus, India’s the fifth-largest economy in the world with thriving banking and FinTech sectors, and will most likely overtake Japan to become the third-largest economy in this decade. I reckon the Yankee card people need connection with the UPI more than the latter needs them.

Just pointing out also that the same author wrote a piece with the following headline merely a year after the PLA murdered 20 Indian soldiers at Galwan: ‘Why India Should Buy Chinese Vaccines’. Arguably ignorant of the level of vaccine research and development + manufacturing capacity in India at the time. Or the bilateral’s history.

(A Web Browser in a Car — Coz That’s How We Roll)

Twitter user, David Weston, was a tad frustrated at his car having a web browser:

To end on a general point, why any car should run on more lines of code than an F-35 is beyond me.

--

--

A Techno-Legal Update

Vignettes from the intersection of law and technology, and a word or two about sport. Composed by Ravi Nayyar.