Vor einigen Tagen (Stand: 07. Juli 2021) hat eine Cybercrime-Gruppe – man vermutet, es war REvil oder ein „Geschäftspartner“ (Affiliate) – eine neue Schwachstelle in der Fernwartungssoftware VSA des Herstellers Kaseya innerhalb eines kurzen Zeitraums bei vielen Zielfirmen ausgenutzt. Dieser Angriff nahm schnell sehr große Ausmaße an – unter anderem mussten in Schweden landesweit Supermärkte schließen. Nach aktuellem Kenntnisstand sind mindestens 40 Kunden von Kaseya betroffen. Insgesamt sind aber vermutlich noch mehr Firmen Opfer dieses Angriffs geworden, da unter den Kunden von Kaseya wiederum viele IT-Dienstleister sind, deren Kunden über die Zugänge dieser IT-Dienstleister infiziert wurden. Aktuell wird von mehreren Hundert bis hin zu 1.500 ausgegangen. Wie der Angriff technisch von statten ging, lässt sich bei Heise nachlesen.
Dieser Angriff ist in vielerlei Hinsicht interessant und besonders gefährlich:
- Erstens, weil es sich um einen Supply-Chain-Angriff handelt: Die betroffenen Firmen wurden nicht über eine Lücke oder Fehlkonfiguration in eigenen Systemen angegriffen, sondern über eine Abhängigkeit von einer Drittpartei bzw. Dienste/Software der Drittpartei. Im konkreten Fall bestand bei knapp 40 bis 50 Firmen die Abhängigkeit die Software VSA von Kaseya. Im Falle vieler der meisten anderen Firmen allerdings handelt es sich um eine „echte“ Supply-Chain-Attacke: Sie wurden über die 40 bis 50 Firmen gehackt, die teilweise bei ihnen als IT-Dienstleister agieren und selbst vom Angriff betroffen waren. Somit wurden legitime administrative Zugänge Dritter genutzt, um den Angriff durchzuführen.
- Zweitens, weil – so scheint es aktuell – ein Zero Day Exploit zum Einsatz kam, der die Umgehung von Authentifizierungsmechanismen (Authentication Bypass) erlaubt und in Folge das Ausführen von beliebigem eigenem Code der Angreifer (sogenannte Remote Code Execution). Gegen Zero Days können sich Angriffsopfer nicht direkt wehren, da noch keine Sicherheitsaktualisierungen bereitstehen.
- Drittens, weil das Ziel der Angriffe inhärent mächtig und gefährlich ist: eine Fernwartungs- und Administrations-Software.
In dieser Konstellation scheint es, dass sich Firmen fast nicht gegen solche und ähnliche Angriffe wehren können: Es standen keine Sicherheitsaktualisierungen zur Verfügung, die hätten installiert werden können. Es handelte sich um ein Problem außerhalb des eigenen Einflussbereichs in einer Komponente eines Drittherstellers, das man nicht selbst durch Konfiguration oder eigene Änderungen hätte beheben können, oder man wurde „vom“ eigenen IT-Dienstleister gehackt. Allerdings bestehen dennoch Möglichkeiten, sich zu schützen: In diesem Artikel wollen wir praktische Hilfestellung geben, wie man einer solchen Situation – Supply-Chain-Angriffe und/oder Zero Days – durch Prävention nicht ausgeliefert sein muss.
Ansatz 1: Reduktion der Angriffsfläche & der potenziellen Ausgangspunkte für Angriffe
Fernwartungssoftware folgt üblicherweise einem von zwei Verbindungsmodellen: dem Server-Client-Modell oder dem Vermittlermodell. Beim Server-Client-Modell läuft eine Instanz der Fernwartungssoftware und nimmt eingehende Verbindungen entgegen. Beim Vermittlermodell, welches vor allem dann zum Einsatz kommt, wenn Systeme netzwerkseitig nicht direkt erreichbar sind, zum Beispiel wegen Firewalls oder NAT (Network Address Translation), verbinden sich beide Systeme – das zu wartende System wie auch das System des Administrators – mit einem öffentlich erreichbaren Vermittlungssystem und nutzen dieses, um Daten auszutauschen, auch wenn das zu administrierende System normalerweise nicht erreichbar wäre.
In den meisten Unternehmen kommt Fernwartungssoftware im Client-Server-Modell zum Einsatz. Das hat eine wichtige Implikation aus Sicherheitssicht: Man kann durch Firewalls kontrollieren, von wo aus überall Verbindungen erlaubt werden. In anderen Worten, man kann die IP-Adressbereiche, aus denen sich mit der Fernwartungssoftware verbunden werden kann, auf ein absolutes Minimum reduzieren. Beispielsweise kann man einstellen, dass Verbindungen mit der Fernwartungssoftware nur aus IP-Adressbereichen erlaubt sein sollen, die der eigenen Firma gehören.
Damit schränkt man nicht nur ein, wer versuchen kann, sich zur Fernwartung anzumelden. Auch Exploits gegen solche Software werden somit verhindert, wenn bereits auf Netzwerkebene Verbindungen unterbunden werden.
Die Beschränkung der Quell-Adressbereiche, aus denen Verbindungen zur Fernwartung aufgebaut werden können, ist ein Sonderfall des sogenannten Principle of Least Privilege, welches nachfolgend behandelt wird. Diese Empfehlung, Verbindungsquellen einzuschränken, gilt übrigens nicht nur für Produkte wie Kaseya VSA, sondern auch für RDP, Telnet, Administrationsoberflächen in Web-Anwendungen und generell für alle Formen der administrativen Zugänge. Wo möglich sollten die Adressbereiche, von denen auf administrative Schnittstellen zugegriffen werden kann, auf das absolut notwendige Minimum, am besten auf Firmen-IP-Adressbereiche oder einen Jump Server/Jump Host, beschränkt werden.
Diese Maßnahme hilft natürlich nur begrenzt, wenn der Angriff aus den echten Netzen des eigenen IT-Dienstleister kommt – für diesen Fall gibt es aber weitere Maßnahmen, die in den folgenden Abschnitten beschrieben werden.
Ansatz 2: Principle of Least Privilege
Das Principle of Least Privilege ist ein sehr generelles Prinzip, welches leider oft zu eng aufgefasst und nur auf Nutzer- und Dateisystemrechte wird. Es besagt, dass nur solche Zugriffe möglich sein sollten, die absolut notwendig sind – beispielsweise für die korrekte Funktionsweise von Systemen und Geschäftsprozessen oder für die Arbeit von Angestellten. Alles, was über das absolut notwendige Minimum hinausgeht, soll von Hause aus verboten werden.
Oft wird dieses Prinzip nur im Kontext von Nutzerrechten und Zugriffsbeschränkungen, vor allem auf Dateifreigaben, angewendet. Es lässt sich jedoch auf beliebig viele andere Bereiche (nicht nur in der IT) anwenden. Hierzu einige Beispiele:
- Netzwerkverbindungen: Dies haben wir schon unter Ansatz 1 behandelt. Generell sollten alle Netzwerkverbindungen per Default verboten werden – und nur solche zugelassen werden, die absolut notwendig sind.
- Funktionen in Anwendungen: Nutzer sollten nur genau solche Funktionen nutzen können, die sie wirklich benötigen und ihren Rollen entsprechen.
- Ausführung von Anwendungen: Nutzer sollten nur genau solche Anwendungen und Programmformate (egal ob Binärprogramme wie .exe, Office-Makros oder Skript-Formate wie .js/.vbs/.wsf/.wsh…) ausführen können, die absolut notwendig sind. Alles andere sollte verboten werden, zum Beispiel via Application Whitelisting.
- Zugriffsrechte auf Dateien auf Netzwerklaufwerken und Dateifreigaben (wie bereits genannt)
- Zugriffsrechte auf andere sicherbare Objekte, beispielsweise im Active Directory
Es gibt noch viele weitere Beispiele. Im Falle von Servern, die aus dem Internet erreichbar sind, lässt sich dieses Prinzip an mehreren Stellen anwenden, um die Möglichkeiten von Angreifern stark einzuschränken:
- Beschränkung der IP-Adressen, von denen eingehende Verbindungen zur Fernwartungssoftware bzw. ihrer Ports aufgenommen werden können (s. Ansatz 1)
- Beschränkung der ausgehenden Verbindungen, die von Servern, welche aus dem Internet erreichbar sind, Richtung Rest des Firmennetzes aufgebaut werden können (s. Ansatz 3)
- Beschränkung der Administratorkonten auf den entsprechenden Servern: Konten mit Administrationsrechten für Server, die aus dem Internet erreichbar sind, sollten nur auf diesen Servern Administrator- und Anmelderechte haben und auf keinen anderen Systemen. Somit können diese Konten nicht dazu missbraucht werden, sich auf andere Systeme auszubreiten. Dies ist insbesondere auch dann wirksam, wenn man nicht direkt vom Angriff auf VSA per direkter Verbindung aus dem Internet betroffen ist, sondern legitime administrative Zugänge von IT-Dienstleistern genutzt werden.
Ansatz 3: Segmentierung und Isolierung
Ähnlich wie Brandschutztüren Gebäudesegmente gegen bereits ausgebrochene Brände schützen und den Schaden räumlich isolieren können, kann man auch Firmennetze in Segmente aufteilen, um somit Schadensbegrenzung zu betreiben. Dies ist auf mindestens zwei Ebenen möglich:
- Netzwerkebene: Üblicherweise sollten aus dem Internet erreichbare Server in einem eigenen Netzwerk- und somit Firewall-Segment stehen, damit die von ihnen ausgehenden Verbindungen Richtung Firmennetz stark reglementiert werden können. Hierdurch kann man verhindern, dass ein Angreifer, der aus dem Internet erreichbare Server unter seine Kontrolle bringt, sich nicht auf Netzwerkebene aus dem Internet-erreichbaren Bereich (meist DMZ genannt) Richtung Innennetz ausbreiten kann.
- Active Directory: Hier gibt es wiederum zwei Möglichkeiten, mit denen verhindert werden kann, dass ein Angreifer die Active-Directory-Nutzerkonten auf initial kompromittierten Servern verwenden kann, um den Rest des Netzwerks unter seine Kontrolle zu bringen:
- Erstens die Auftrennung des Active Directory selbst: Entweder in einen Forest mit mehreren Domänen (wobei es sich allerdings laut Microsoft auf Grund des inhärenten Trust nicht um eine Sicherheitsgrenze handelt, hier muss man somit stark aufpassen und zusätzliche Sicherheitsmaßnahmen einführen) oder in zwei separate Forests. Hier kann eine separate Domäne oder Forest für die DMZ, also die Zone der Server, die von außen erreichbar sind, aufgesetzt werden.
- Zweitens die Aufspaltung des Active Directory in Ebenen mit unterschiedlichen Privilegien und Schutzniveaus. Dieses Konzept nannte sich ursprünglich ESAE (Enhanced Security Admin Environment, ursprünglich mit drei Schichten) und heißt nach einigen Änderungen am Konzept mittlerweile Privileged Access Strategy.
Ferner gibt es Lösungen, um Systeme, bei denen eine Infektion festgestellt wurde, automatisch netzwerkseitig komplett zu isolieren, zum Beispiel durch Endpoint Protection- bzw. Endpoint Detection and Response (EDR)-Lösungen, die den Infektionsstatus an Firewalls melden, die dann das betroffene System sofort isolieren. Dann sind keine ausgehenden Netzwerkverbindungen von diesem System zu anderen Systemen mehr möglich und eine Ausbreitung der Schadsoftware wird verhindert. Dies setzt natürlich voraus, dass diese auch erkannt wird.
Generell gilt: Je feingranularer und in je mehr Dimensionen (Ebenen nach ESAE/PAS, Forests/Domänen nach Netzwerkbereichen) aufgetrennt wird, desto kleiner ist der Bereich, der geschädigt wird, bevor sich der Angriff weiter ausbreiten kann.
Ansatz 4: Defense in Depth: Mehrschichtige Verteidigung
Heutzutage ist es generell wichtig, dass man sich nicht nur auf eine oder einige wenige Sicherheitsmaßnahmen sowie auf die Sicherheit am Perimeter, d.h. die Sicherheit am Übergang des Firmennetzes zum Internet, verlässt. Stattdessen ist ein mehrschichtiger Ansatz gefragt, der Defense in Depth genannt wird. Der Grund dafür ist, dass Angreifer heute leider meist in der Lage sind, einzelne Sicherheitsmaßnahmen zu umgehen. Wenn man derer nur eine oder zwei hat – zum Beispiel nur eine Firewall und eine Endpoint Protection/Antivirus -, wird diese zum Single Point of Failure, der einfach und sogar automatisiert durch Malware ohne menschliche Intelligenz umgangen werden kann.
Wenn man hingegen auf mehrere Verteidigungsschichten setzt, sinkt mit jeder Schicht die Wahrscheinlichkeit, dass Angreifer Erfolg haben. Eine gute Sicherheitsstrategie, die dem Defense-in-Depth-Ansatz folgt, besteht somit aus mehreren der folgenden Komponenten:
- Endpoint Protection
- Endpoint Detection and Response (EDR, entweder als Teil der Endpoint Protection oder separat)
- Firewall-Regeln nach Principle of Least Privilege und zwar sowohl eingehend aus dem Internet wie auch zwischen DMZ und Rest des eigenen Netzwerks
- Event Tracing for Windows (ETW) per Sysmon
- Netzwerksegmentierung
- Application Whitelisting
- Gehärtetes Active Directory (z.B. durch ESAE/PAS oder separate Forests)
- Separate Administrator-Konten für DMZ-Server und interne Server
- Geräteisolierung bei Infektion
- Einschränkung der IP-Adressbereiche, aus denen sich mit Fernwartungslösungen verbunden werden kann (dies ist eigentlich nur ein Sonderfall des Principle of Least Privilege)
- Logging & Monitoring
- Einsatz eines SIEMs, welches Ereignisse im Netzwerk sammelt, korreliert und bei ungewöhnlichem Verhalten Alarm schlägt
- Anomalieerkennung
- Regelmäßiges und zeitnahes Einspielen von Sicherheitsupdates im Rahmen eines Patch-Management-Konzepts
- Härtung von Servern und Clients, sowohl auf Betriebssystem- wie auch auf Dienste- und Anwendungsebene
Diese Liste ist nicht vollständig – es gibt noch mehr Sicherheitsmaßnahmen, die ergriffen werden können. Je mehr davon vorhanden sind, desto geringer ist die Wahrscheinlichkeit, dass ein Angreifer alle umgehen kann und der Angriff somit erfolgreich ist.
Ansatz 5: Penetrationstests
Man sollte sich nicht nur Sicherheitsmaßnahmen überlegen und implementieren, sondern diese auch einem praktischen Test unterziehen. Insbesondere sollte man nicht nur blind darauf vertrauen, dass man entweder nicht zum Ziel von Angriffen wird oder, falls doch, die Angreifer schon keinen Erfolg haben werden. Sicherheit ist ein komplexes und kompliziertes Thema – genau wie Autos oder Flugzeuge ohne Tests nicht zugelassen werden, sollte auch IT-Sicherheit überprüft werden, damit man nicht blind darauf vertrauen muss, dass diese schon irgendwie klappen wird.
Für verschiedene Parteien in der Konstellation, wie sie nun beim Kaseya-VSA-Angriff auch besteht, gibt es verschiedene Gründe, Penetrationstests durchzuführen:
- Hersteller von Software: Umfassende Penetrationstests auf die Eigenentwicklungen können verhindern, dass man selbst zur nächsten Kaseya wird. Wird die selbst entwickelte Software als Angriffsvektor für umfassende Hacking-Angriffe auf die eigenen Kunden verwendet, ist der Reputationsschaden enorm und es gibt ein großes Risiko für finanzielle und rechtliche Konsequenzen.
- Firmen im Allgemeinen: Penetrationstests auf Firmen und deren Infrastrukturen decken zwar in den meisten Fällen keine Zero-Day-Schwachstellen in Drittherstellerprodukten auf, sie finden aber Sicherheitslücken, Konfigurationsfehler und fehlende Sicherheitsmaßnahmen auf Netzwerkebene. Die unter Ansatz 4 genannten Maßnahmen können somit durch Penetrationstests auf Vorhandensein, Effektivität, korrekte und sichere Konfiguration sowie Nichtumgehbarkeit geprüft werden.
Fazit
Das Funktionieren von Zero-Day-Exploits auf extern erreichbaren Komponenten aus dritter Hand lässt sich, realistisch gesehen, kaum verhindern. Das heißt jedoch nicht, dass Firmen keine Maßnahmen ergreifen können, um solchen Angriffen nicht dennoch vorzubeugen, die Erfolgschancen der Angreifer massiv zu reduzieren, ihren eigenen Handlungsspielraum zu maximieren oder die Folgeeffekte eines erfolgreichen Angriffs am Perimeter (d.h. auf im Internet erreichbare Systeme) zu minimieren.
In diesem Artikel haben wir 5 Ansätze vorgestellt, die Unternehmen nutzen können, um sich auch unter diesen schwierigen Vorzeichen – Zero-Day-Lücke und Supply-Chain-Angriff – gegen Angriffe zu wappnen, die Angriffswahrscheinlichkeit zu minimieren und den Angreifern den Wind aus den Segeln zu nehmen. Sollten Sie dabei Unterstützung benötigen, kontaktieren Sie uns gerne.