Tag Archives: Supply chain

Was können wir aus dem Kaseya-Supply-Chain-Angriff für die Cybersicherheitsstrategie ableiten?

17 Juli 2021

Die Analyse des Kaseya-Supply-Chain-Angriffs offenbart 3 Schwachstellen im Software- und Systemdesign von Lösungsanbietern:

  1. Ausführung mit administrativen Berechtigungen

SophosLabs hat den Ablauf auf dem Endpunkt im Detail analysiert.(1) Die Kommandos, die der Kaseya-Agent nach der Auslieferung der Malware ausführt, erfordern administrative Berechtigungen. Das bedeutet, dass der Agent mit administrativen Berechtigungen arbeitet.

Klartext: Jede Anwendung, die mit administrativen Berechtigungen ausführt werden muss, stellt ein Sicherheitsrisiko dar. Das Risiko erhöht sich drastisch, wenn die Anwendung ferngesteuert werden kann.

Gerade die Entwickler von Remote-IT-Management-Lösungen sollten sparsam mit administrativen Berechtigungen umgehen, damit die Angriffsfläche des Netzwerkes nicht vergrößert wird. Windows und Linux bieten Entwicklern Funktionen an, die einen weitgehenden Verzicht darauf ermöglichen.

Tipp: Die Nutzung von administrativen Berechtigungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Antivirus-Ausnahmen

Der Kaseya-Agent erfordert zur korrekten Ausführung mehrere Antivirus-Ausnahmen.(2) Die Remote-Control-Komponente benötigt weitere Ausnahmen.(3) Die Ausnahmen müssen für jeden Endpunkt, auf dem die Software genutzt werden soll, definiert werden.

Klartext: Jede Antivirus-Ausnahme reduziert das Sicherheitsniveau des gesamten Netzwerkes. Das Risiko erhöht sich drastisch, wenn die Ausnahme auf allen Endpunkten erforderlich ist.

Die Analyse von SophosLabs zeigt, dass ohne die Ausnahmen der Angriff mit hoher Wahrscheinlichkeit selbst von klassischen Antimalware-Lösungen erkannt worden wäre.

Tipp: Das Zusammenspiel mit vorhandenen Sicherheitslösungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Sichtbarkeit von IT-Management-Systemen in der DMZ

Das DIVD CSIRT berichtet am 4. Juli, dass zu Beginn des Angriffs 2.200 Kaseya VSA Server in den DMZ von Unternehmen sichtbar waren.(4)

Prinzipiell ist jedes Managementsystem in der DMZ, das für alle Internetteilnehmer sichtbar ist, ein Sicherheitsproblem. Wird in der Anwendungssoftware eine kritische Schwachstelle entdeckt, so beginnt ein Wettlauf gegen die Zeit.

Klartext: Die Sichtbarkeit von Managementsysteme in der DMZ ist auf die notwendigen externen Systeme einzuschränken. Vom Internet eingehende Verbindungen erhöhen das Risiko drastisch.

Tipp: Die notwenigen Kommunikationsverbindungen mit dem Hersteller sollten ein Auswahlkriterium bei der Produktauswahl sein. Ausgehende Punkt-zu-Punkt-Verbindungen (Server in der DMZ initiiert die Kommunikation) sind zu bevorzugen.

Tipp: Überprüfen Sie nach der Inbetriebnahme, ob der Systembetreiber die Anforderungen des Herstellers umgesetzt hat. Führen Sie die Prüfungen regelmäßig durch.

Fazit

Die hier identifizierten Schwachstellen müssen in die Cybersicherheitssstrategie eines Unternehmens einfließen: “The strategist must concentrate less on determining specific actions to be taken and far more on manipulating the structure within which all actions are determined.”(5)

Werden die identifizierten Schwachstellen bei Entwicklung, Auswahl und Betrieb von Softwareprodukten konsequent adressiert, so ändern sich die Rahmenbedingungen, in denen Cyberkriminelle agieren können. Die Widerstandsfähigkeit gegen Cyberangriffe wird dauerhaft erhöht.

Quellenangaben

1.         Loman M, Gallagher S, Ajjan A. Independence Day: REvil uses supply chain exploit to attack hundreds of businesses [Internet]. Sophos News. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/

2.         Kaseya. Anti-Virus and Firewall Exclusions and Trusted Apps [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229014948-Anti-Virus-and-Firewall-Exclusions-and-Trusted-Apps

3.         Kaseya. Antivirus Exclusion list for Remote Control components. [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229008988-Antivirus-Exclusion-list-for-Remote-Control-components-

4.         Gevers V. Kaseya Case Update 2 [Internet]. DIVD CSIRT. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://csirt.divd.nl/2021/07/04/Kaseya-Case-Update-2/

5.         Dolman EC. Pure strategy: Power and principle in the space and information age. London ; New York: Frank Cass; 2005. 218 S. (Cass series–strategy and history).

What can we learn from the latest hack on an U.S. Navy contractor?

17 June 2018

Report “China hacked a Navy contractor and secured a trove of highly sensitive data on submarine warfare” (1) published on 8 June 2018 in the Washington Post is really worth reading.

Attacks on the supply chain have become more common in recent years. Contractors are e.g. used as gateways to the customer network or customer information is exfiltrated from the contractors network.

The latter is the case here. The product development is outsourced. The information required for product development is available only in the contractors network and, in the worst case, remains there after handover to the customer.

Under normal conditions this is not critical. But when it comes to national security matters, e.g. in product development for defense agencies or for critical infrastructures, this may end in a catastrophe.

Picture credits: Wikimedia

In such cases proper classification of the information handed over to and created by the contractor is of crucial need. Since many contractors run an information security management system, the selection of protective measures is based upon the proper classification.

At least 614 GB of data were obviously not properly classified since “highly sensitive data related to undersea warfare” was stolen from the contractor’s unclassified network.

It is always good to remember Aristotle’s proverb “The whole is greater than the sum of its parts” when it comes to classification of information.

Have a great week.

1. Nakashima E, Sonne P. China hacked a Navy contractor and secured a trove of highly sensitive data on submarine warfare. Washington Post [Internet]. 2018 Jun 8 [cited 2018 Jun 16]; Available from: https://www.washingtonpost.com/world/national-security/china-hacked-a-navy-contractor-and-secured-a-trove-of-highly-sensitive-data-on-submarine-warfare/2018/06/08/6cc396fa-68e6-11e8-bea7-c8eb28bc52b1_story.html

Triton: Dangerous and Puzzling – Part III

18 March 2018

The reports published on Triton so far give no hint on how the attack was started. With Occam’s razor in mind I concluded in part II of this post series that it is very likely, that the attacker compromised the Engineering Service Providers (ESP) network and the systems used for developing the SIS software. Since the next software update is sure to come, it is only a matter of time until the SIS installation in the production network gets compromised.

In this part I will talk about how to prevent and protect against such attacks.

Part III: Prevention and Protection

To protect against such kind of attacks data integrity must be ensured across the entire supply chain.

Ensure Integrity Across the Supply Chain

Ensure Integrity Across the Supply Chain

Engineering Service Provider’s responsibilities

Build: The ESP must make sure that the project data and software cannot be compromised in his facilities during software design and build.

Transfer: The ESP must secure the data against manipulation during transport.

Plant Operator’s responsibilities

Validate: After handover, the operator must check that the software and project data fulfil only the intended functions, before the SIS or DCS is updated. This must be governed by a Standard Operating Procedures (SOP) with formal approvals.

Install: The operator must follow a SOP for secure update of SIS and DCS software.

In the following section I will give some best practice to achieve data integrity across the supply chain. Anti-malware solutions are not listed because they are industry standard. Nevertheless, it is important to note that in Triton like cases pattern based anti-malware solutions will not prevent or protect against the attack. Pattern based anti-malware solutions protect only against malware “in the wild”. That’s not the case here, thus we have to apply other means to ensure integrity.

Development network

  • Perform all project work in an isolated Development Network (D-NET) with a Development DMZ (D-DMZ).
  • Control remote access to the D-DMZ through a user proxy to allow access for authorized staff only. Two Factor Authentication is mandatory for access to the D-DMZ.
  • For remote user access to the D-NET use a jump station in the D-DMZ.
  • Terminate all connections from the Office Network to the D-NET in the D-DMZ.
  • Terminate all connections from the D-NET in the D-DMZ.
  • If an SIS or DCS is operated in the D-NET, it should be placed in an isolated in a network  zone (D-SIS) in the D-NET. Allow only incoming connections from the engineering station to the SIS or DCS. Terminate all outgoing connections from the D-SIS in the D-NET.

Data exchange

  • For data exchange with the Office network allow only outgoing connections from the D-DMZ to dedicated systems/ports in the Office network.
  • Don’t use the SMB protocol for exchange of data between the office network and the D-DMZ and D-NET.
  • Implement Network Access Control (NAC) in the D-DMZ and D-NET to block connections of untrusted devices.
  • Never connect mobile workstations used in the D-NET or D-DMZ to other networks and vice versa. Once such a workstation was connected to a network outside the D-NET or D-DMZ it is potentially compromised.

System hardening

  • Block all USB disk devices in the D-NET.
  • Block all internet access and e-mail in the D-DMZ and D-NET.
  • Lock down all workstations and servers in the D-NET and D-DMZ.
  • Perform regular integrity checks on all systems in the D-NET and D-DMZ.

Software development best practice

  • Set up software version control for all development work.
  • If contractually possible, handover only sources, makefiles and checksums to the operator.

  • Secure network transfer is the method of choice. Bundle all sources in an encrypted archive. Send the encryption key in a secure e-mail to the operator.
  • If transfer by USB devices is required use only USB devices with AES hardware encryption and key pad. Run a secure before the new software is copied.

  • Extract the software to a trusted development system in an isolated network zone of the operators network.
  • Validate the checksums of the sources and makefiles against the supplied checksum details.
  • Build the software.
  • Install the software on a test system and verify that only the intended functions are implemented.

  • Use a secure transfer method to move the new software and project data to the SIS or DCS  network.
  • Install the software with regards to the corresponding SOP.

Have a great week.

Triton: Dangerous and Puzzling – Part II

11 March 2017

Part II: Some thoughts on the access vector

For preparation of the attack the attacker had to gain in-depth knowledge about the victim’s network and SIS installation.

SIS installation

According to Schneider Electric such attack could only be successful for Triconex Tricon controllers configured with the model 3008 Main Processor and firmware versions 10.0 to 10.4.(1) Only this controller family seems to use PowerPC processors. Older Tricon controllers use National Semiconductor, newer systems use ARM processors.(2)

Since the binary malware components inject.bin and imain.bin were compiled in PowerPC byte code the attacker hat detailed knowledge about the installation, in particular the controller version. Without this knowledge about the controller version the attack would have failed because of a code mismatch.

Network

If the SIS controller and engineering station are operated in an isolated SIS network this attack is not possible. For remote control, the Remote Access Trojan (RAT) needs to open at least an outgoing connection to its Command and Control server (C&C) outside the production network.

Blocking incoming traffic to SIS network but allowing outgoing traffic from the SIS network to applications, e.g. a historian, in other production network partitions is industry standard (ISA-99). Unfortunately, the latter recommendation is often misunderstood. Instead of opening only connections to dedicated systems / ports in adjacent partitions the security devices are often opened for all outgoing network traffic, sometimes across partitions.

With this, once the RAT is installed on the engineering station a weak implemented industry standard fosters the connection with the attacker’s C&C server.

Attack vector: Compromised Supply Chain

At first sight this sounds like a bad thriller. But it gives some good answers to some important questions.

How did the attacker get the knowledge of the victim’s facilities?

  1. In-depth knowledge of the plant network and the SIS installation can be extracted from documentation stored on the plant operators computer systems or on the Engineering Service Providers (ESP) computer systems.
  2. An ESP network is in general less well protected against cyber-attacks than a highly secured production network.

Conclusion: It is very likely that the attacker compromised the ESP network and the systems used for developing the SIS software.

How could the attacker develop such mature code?

Once the attacker hijacked the ESP network he was able to develop and test his attack framework on a system very similar to the production SIS.

How was the SIS network / engineering station infected?

With the next project update the ESP transferred the compromised code, e.g. by USB stick, to the production network.

Have a great week.

  1. Hand A. Triton Gone Wild | Automation World [Internet]. Automation World. 2018 [cited 2018 Mar 3]. Available from: https://www.automationworld.com/triton-gone-wild
  2. Analyzing the TRITON industrial malware [Internet]. Midnight Blue Labs. 2018 [cited 2018 Mar 5]. Available from: https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware