Schlagwort-Archive: Sicherheitsbedrohungen

Aufkommende Ransomware-Techniken für gezielte Angriffe

Originalartikel von Trend Micro

Wie Trend Micro im Halbjahresbericht 2020 darlegt, sagen die Zahlen zur Lösegeldforderung auf den ersten Blick nicht mehr viel aus. Zwar ist die Zahl der Infektionen, der Offenlegungen von Unternehmen und der Ransomware-Familien zurückgegangen, doch der geschätzte Geldbetrag, der für den Zugriff auf die verschlüsselte Daten ausgegeben wurde, ist stetig gestiegen. Cyberkriminelle greifen Institutionen und Unternehmen an, für die der Zugriff auf ihre Daten und die Wiederherstellung ihre Systeme sehr wichtig ist. Deshalb können die Kriminellen exorbitante Lösegeldforderungen stellen.

Bild 1. Die Gesamtzahl der Ransomware-Familien ist von 2012 bis 2020 zurückgegangen (oben). Das zeigen die monatlichen Erkennungszahlen für neue Ransomware-Familien im ersten Halbjahr 2020 (unten).

Die Bedrohungsakteure zielen nicht mehr auf einzelne Benutzer und Maschinen ab, um zufällige Ransomware-Infektionen auszulösen. Deshalb fehlt es in der Öffentlichkeit an Aktualisierungen und Mundpropaganda über deren Verbreitung. Betroffene Unternehmen und Behörden versuchen, Stillschweigen über die Angelegenheit zu bewahren, bis sie intern gelöst ist. Die Öffentlichkeit wird erst dann auf diese Vorfälle aufmerksam gemacht, wenn Nachforschungen angestellt oder wenn Vorfälle schliesslich gemeldet werden. Doch diese Verlautbarungen geben nur wenige Einzelheiten (wenn überhaupt) darüber, wie die Organisationen zu Opfern wurden oder ob dabei Lösegeld gezahlt wurde. Leider bietet die Bezahlung von Cyberkriminellen keine Garantie dafür, dass die Dateien wieder zugänglich werden oder dafür, dass es in Zukunft keine weiteren Angriffe geben kann.

Arten der Ransomware

Wie bereits erwähnt, gibt ein Vergleich der Erkennungszahlen mit denen von 2019 ein nur unvollständiges Bild des Geschehens. Eine Analyse der Techniken und Routinen der früher und derzeit installierten Ransomware macht deutlich, dass die Cyberkriminellen mittlerweile ihre Aufmerksamkeit auf bestimmte Ziele und grössere Geldsummen lenken, die sie von ihren Opfern erpressen können. Diese Ziele sind häufig in Branchen oder Organisationen mit kritischen öffentlichen Geschäftsvorgängen und Infrastrukturen zu finden.

Bedrohungsakteure können immer noch willkürlich Spam-E-Mails an ein Verzeichnis von E-Mail-Adressen senden, um mindestens ein Opfer anzulocken. Doch die jüngsten Angriffe sind gezielter, und die Opfer wurden vorher ausgekundschaftet, um einen grösstmöglichen Gewinn zu erzielen. Im Laufe der Jahre haben die Forscher drei verschiedene Arten von Ransomware beobachtet mit verschiedenen Routinen für das Eindringen in die Systeme der Opfer.

Wurm-basierte oder Legacy Ransomware

Wurm-basierte Ransomware verbreitet sich ähnlich den Würmern über replizierte Kopien ihrer selbst durch Systeme. Legacy Ransomware nutzt den eingestellten Support für Betriebssysteme aus. Sie setzen auf Schwachstellen als Einstiegspunkte und beeinträchtigen andere Systeme im Netzwerk auch ohne menschliche Interaktion. Einige dieser Bedrohungsvektoren lassen sich verhindern, wenn von den Herstellern veröffentlichte Patches aufgespielt oder die virtuellen Patches von Sicherheitsanbietern heruntergeladen werden, wenn der Support für ein Betriebssystem endet.

Ransomware-Routinen, die Zero-Day-Schwachstellen ausnutzen, können jedoch den grössten Schaden in Systemen anrichten. Ein Beispiel dafür ist WannaCry, das 2017 eingeführt wurde, Monate nachdem die Gruppe Cyberkrimineller Shadow Brokers mehrere Hacker-Tools veröffentlichte, darunter EternalBlue. Die Ransomware verbreitete sich rasch in Unternehmen auf der ganzen Welt und hielt Systeme als Geiseln und deren Betrieb im Stillstand, bis Forscher den Kill Switch in der Kodierung der Routine fanden.

Gängige Ransomware

Diese Art von Ransomware wird über Spam verbreitet. Cyberkriminelle kennen die Opfer nicht und senden die infizierten E-Mails einfach an eine Liste von Adressen, die sie gesammelt, gestohlen oder gekauft haben. Sie setzen Social Engineering-Techniken ein, um die Opfer zu täuschen, so dass diese die E-Mail oder den bösartigen Anhang öffnen und so ihre Systeme mit Lösegeldern infizieren.

Bei den meisten dieser Routinen verschlüsselt die Malware fast alle Arten von Dateien, die sich in einem System befinden können, wie z. B. Mediendateien, Dokumente, ausführbare Dateien und Anwendungen. Zu diesen Routinen gehört vermutlich auch eine Datei oder eine ausführbare Datei, in der die Höhe des Lösegeldes angegeben ist, sowie Support-Anweisungen, wie die Opfer Kryptowährungen erwerben können, um ihre Dateien wiederherzustellen. Dennoch gibt es keine Garantie dafür, dass ihnen der Entschlüsselungsschlüssel zugesandt wird oder dass ihre Dateien nach Zahlung des Lösegelds wiederhergestellt werden.

20162017201820192020 1H
LOCKY82,805WCRY321,814WCRY616,399WCRY416,215WCRY109,838
KOVTER50,390CERBER40,493GANDCRAB14,623LOCKY7,917LOCKEY6,967
NEMUCOD46,276LOCKY29,436LOCKY10,346CERBER5,556CERBER2,360
CERBER40,788CRYSIS10,573CERBER8,786GANDCRAB4,050CRYSIS1,100
CRYPTESLA26,172SPORA8,044CRYSIS2,897RYUK3,544SODINOKIBI727

Tabelle 1. Top fünf Ransomware-Familien von 2016 bis zum ersten Halbjahr 2020 (Daten aus dem Smart Protection Network, SPN)

Lesen Sie die Historie dieser Familien im Originalartikel.

Solch gängige Ransomware ist mittlerweile ein geringeres Problem für Unternehmen. Viele heute verfügbare Sicherheitssysteme und auch veröffentlichte Patches umfassen Mechanismen, die über verhaltensbasierte und Dateiüberwachungs-Technologien die Malware erkennen.

Gezielte oder auf Einbrüchen basierte Ransomware

Gezielte oder auf einem Einbruch basierte Ransomware beinhaltet die Techniken in Routinen, die in den letzten Jahren eingesetzt wurden. Diese Art von Ransomware dringt in ein System mittels z.B. gestohlener RDPs ein, über nicht gepatchte Schwachstellen und schlecht gesicherte Anwendungen. Von Untergrund-Websites können Cyberkriminelle Zugangsdaten wie RDP-Benutzernamen und Passwörter erwerben. Sie können auch Social-Engineering-Techniken einsetzen, um die benötigten Zugangsdaten zu phishen, oder die Zielcomputer mit Malware wie InfoStealer infizieren, um die Bedrohungsvektoren zu finden, die sie missbrauchen können.

Cyberkriminelle nutzen die genannten Zugangsdaten auch, um in die Systeme eines Unternehmens einzubrechen. Manchmal wird dies mit einer Eskalation der Privilegien, Tools oder Methoden kombiniert, die die installierte Sicherheit ausschalten. Im Fall des Vorhandenseins von technologisch fortschrittlicheren Systeme, wie z.B. Verhaltens-/Dateierkennung, ist Living Off the Land Binaries and Scripts (LOLBAS) eine Möglichkeit, der Erkennung beim Ausführen von Ransomware zu entgehen.

Auch hier fügen die Kriminellen Anleitungen in die Lösegeldforderung mit ein, wie das Opfer Bitcoins erwerben kann. Da die Erpresser ihre Ziele kennen, ist die Forderung häufig höher als bei den gängigen Ransomware-Angriffen. Sie setzen darauf, dass die Unternehmen ihre Dateien bzw. Systeme sofort wieder nutzen müssen. Cyberkriminelle können auch Fristen setzen, damit die Sicherheitsteams die Infektion vor Ablauf der Zeit unmöglich allein beheben können und deswegen das Opferunternehmen gezwungen ist zu zahlen. Mittlerweile drohen einige Cyberkriminelle ihren Opfern auch, die verschlüsselten Dateien zu veröffentlichen oder  die gestohlenen Informationen im Untergrund zu verkaufen, sollte das Lösegeld nicht rechtzeitig bezahlt werden.

Bei dieser Art der Ransomware-Angriffe werden nicht alle Dateien verschlüsselt, sondern eher bestimmte Dateitypen oder Anwendungen, die für den Alltagsgeschäftsbetrieb unerlässlich sind, so etwa Systemdateien und ausführbare Dateien. Auch hier gibt es keine Garantie, dass die Dateien wieder verwendbar sind, wenn das Opfer zahlt. Auch besteht die Gefahr, dass die Kriminellen weitere Arten von Malware installieren, die nicht auffindbar ist und für weitere Angriffe genutzt wird.

Zu den Zielen gehören auch mittelständische Betriebe wie Krankenhäuser, die als einträglich angesehen werden, weil ihre Sicherheitssysteme weniger fortschrittlich sein könnten und sie dennoch über genügend Ressourcen verfügen, um das Lösegeld zu bezahlen.

Im Jahr 2016 begannen Crysis und Dharma als gängige Arten von Ransomware. Die Techniken beider Routinen änderten sich jedoch schnell, um höher bezahlte potenzielle Opfer durch den Einsatz anderer Software und gestohlener RDPs anzugreifen. Dharma zeigte, wie vielseitig Ransomware sein kann, denn die Malware passte ihre Routinen an und nutzte andere legitime Software, um die Überwachung und Aufmerksamkeit umzulenken. Crysis wiederum nahm Unternehmen ins Visier und erlangte selbst nach der Entfernung der Malware wieder Zugang,  indem sie andere angeschlossene Geräte wie Drucker und Router für spätere Angriffe infizierte. Sie wurde als RaaS im Untergrund angeboten und war damit auch weiteren Hackern leicht zugänglich.

Charakteristiken neuer Techniken und Ziele

Diese Ransomware-Techniken des Eindringens in Systeme gezielter Opfern sind nicht neu. Unternehmen und Institutionen mit kritischer Infrastruktur gelten als hochwertige Ziele Da zudem im Untergrund mehr gestohlene Daten wie RDP-Zugangsdaten angeboten werden, können sich riskante Online-Gewohnheiten (wie das Recycling von Benutzernamen und Passwörtern) nicht nur für einzelne Benutzer, sondern auch für ein ganzes Unternehmen als schädlich erweisen.

Bild 2. Die wichtigsten Zielbranchen auf der Grundlage der Ransomware-Erkennung für 1H 2020 (Daten aus dem Trend Micro Smart Protection Network)

Die Ransomware-Routinen sind nun in der Lage, mit fortgeschrittenen Verschleierungstechniken ihre Erkennung zu vermeiden. Auch können sie über die Beschränkung auf nur wenige und bestimmte Dateitypen manche Sicherheitssysteme umgehen, vor allem solche ohne Monitoring von Dateien und Verhalten. So erlauben es die Routinen der Ransomware  Ryuk, das Netzwerk zu infizieren und dann durch laterale Bewegung nach Systemen zu suchen, die den grössten Gewinn versprechen.

Ransomware-Trends

Die Sicherheitsforscher gehen davon aus, dass die eingesetzten Routinen bezüglich ihrer Installation und Verschleierungstechniken komplexer werden und noch mehr Unternehmen und Behörden ins Visier nehmen.

Ebenso werden auch weiterhin mehr Regierungsbehörden und Grossunternehmen mit ihren Assets und nach aussen gerichteten Systeme zum Ziel werden. Von Websites, Anwendungen, E-Mails, Dateien und zentralisierten Kontrollsystemen bis hin zu firmeneigenen Geschäfts- und vertraulichen Sicherheitsinformationen könnten Kunden und Mitarbeiter gleichermassen gefährdet sein.

Auch das Industrial Internet of Things (IIoT) und Industrial Control Systems (ICS) könnten profitable Ziele darstellen. Produktionslinien und Lieferketten dienen als Ziele und Bedrohungsvektoren, und Störungen in diesen automatisierten Sektoren könnten sich nicht nur für das Unternehmen, sondern auch für die Wirtschaft und den Ruf eines Landes als katastrophal erweisen.

Fazit

Es gibt einige Best Practices, die Einzelpersonen, Unternehmen und Institutionen zu ihrem Schutz beachten sollten:

  • Gute Passwort-Strategie verwenden: Keine Benutzernamen und Passwörter für die Online-Konten und –Geräte wiederverwenden sowie die Standard-Anmeldedaten für alle Geräte ändern.
  • Netzwerksegmentierung einführen: Unternehmen sollten das Prinzip der geringsten Privilegien umsetzen und den Zugriff auf wichtige Daten und Systemverwaltungswerkzeuge einschränken.
  • Überprüfen der RDP-Servereinstellungen: Sie müssen regelmässig überwacht und aktualisiert werden. Empfehlenswert ist auch der Einsatz eines Brute-Force-Schutzsystems für RDP-Server sowie die stetige Aktualisierung der Anzahl der Benutzer und Konten mit RDP-Zugriff. Benutzer mit RDP-Zugriff müssen komplizierte und sichere Passwörter verwenden, die regelmässig geändert werden.
  • Überwachen der nach aussen gerichteten Server: IT-Teams sollten gewährleisten, dass die Patch-Zeitpläne eingehalten werden. Bei Implementierungsschwierigkeiten sind virtuelle Patching-Lösungen ein bewährtes Schutzmittel.
  • Aufbewahren der Sicherheitskopien von wichtigen Informationen: Mit der 3-2-1-Methode werden drei Sicherungskopien in mindestens zwei verschiedenen Formaten aufbewahrt, von denen eine separat und ausserhalb des Standorts lagert.
  • Ungeprüfte und verdächtige E-Mails und eingebettete Links nicht öffnen: Ist der Absender unbekannt, und sind die Nachricht und ihre Anhänge nicht verifiziert, so sollte die Nachricht gelöscht und/oder melden die E-Mail sofort an das Sicherheitsteam gemeldet werden.
  • Konsequentes Patchen und Aktualisieren der Systeme, Netzwerke, Software, Geräte, Server und Anwendungen: Sobald die Hersteller Patches oder Updates veröffentlichen, sollten diese angewendet werden, um zu verhindern, dass Schwachstellen offen bleiben, die von Bedrohungsakteuren ausgenutzt werden können.
  • Auf keine Lösegeldforderungen eingehen: Die Bezahlung ermutigt Cyberkriminellen nur, ihre Aktivitäten fortzusetzen. Es gibt auch keine Garantie dafür, dass verschlüsselte Daten abgerufen oder nicht gestohlen werden oder dass es nicht zu anderen späteren Angriffen kommt.

Trend Micro-Lösungen

Ein mehrschichtiger Ansatz kann Ransomware davon abhalten, Netzwerke und Systeme zu erreichen. Unternehmen sollten ihre gesamte IT-Infrastruktur vor Malware und Einbrüchen schützen. Mittelständler können den Schutz von Trend Micro™ Worry-Free™ Services Advanced, und für Heimanwender bietet Trend Micro Internet Security funktionsreichen Schutz für bis zu zehn Geräten. Trend Micro Ransomware File Decryptor Tool kann Dateien entschlüsseln, die von bestimmten Ransomware-Varianten verschlüsselt wurden.

Wie ein Bezahlsystem zur Grundlage einer Security Strategie wird

von Richard Werner, Business Consultant

Ja, der Titel ist ernst gemeint. Eigentlich schaut man sich immer zuerst nach der Ware um und kümmert sich dann um den Preis, aber gerade in der Cloud laufen die Dinge anders. Deshalb ist es an der Zeit, sich auch mit neuen Ideen zu beschäftigen. Um zu verstehen, warum Überlegungen zum Bezahlmodell in der Cloud bei der Auswahl des Security Providers viel Mühe sparen kann, ist es wichtig, zuerst die Motivationen zu verstehen, die ein Unternehmen dazu treibt, ganz oder teilweise in die Cloud zu gehen.

Flexibilität

Die Mär, die Cloud sei billiger, hält sich hartnäckig. Doch gerade in Sicherheitskreisen weiss man, dass dies so nicht stimmt. Zieht ein Unternehmen im Rahmen einer Migration System um System in die Cloud und vergleicht erst anschliessend die Kosten, so läuft die Aktion bestenfalls auf eine Nullsumme hinaus. Und genau darum geht es aber nicht, denn die Cloud soll ein Unternehmen agiler machen und Über- bzw. Unterkapazitäten ausgleichen.

Als Beispiel dafür, wie Flexibilität in der IT Security zum Erfolg führen kann, mag hier die Geschichte eines Serviceanbieters aus Texas dienen. Dieses Unternehmen offeriert seinen Kunden weltweit Dienstleistungen rund um das Thema Event-Management. Vom Ticketverkauf bis zur Event-Organisation kann alles gebucht werden. Das Unternehmen hatte 2019 mit dem „Problem“ zu kämpfen, erfolgreich zu sein. Aufgrund der schnellen Ausweitung des Angebots kam es regelmässig zu Kapazitätsengpässen. Da das Geschäft dennoch starken Schwankungen unterlag, war die Beschaffung, Verteilung und Koordinierung von Rechenkapazitäten zur grössten IT Herausforderung geworden. Der Gang in die Cloud löste das Problem. Aufgrund unbegrenzter Kapazitäten sowie der Möglichkeit je nach Bedarf automatisiert Systeme zu- oder abzuschalten, konnte die häufig saisonal bzw. regional bedingten Kapazitätsänderungen ohne logistische Herausforderung abgebildet werden.

Logistic kills Deployment

Die IT-Sicherheitsabteilung des Anbieters erstellte daraufhin zusammen mit ihrem Security Provider ein Konzept, welches es erlaubte, das Sicherheitsniveau des Rechenzentrums weitestgehend in der Cloud abzubilden. Die Sache hatte nur einen Haken: Als die IT-Security bei den Fachabteilungen anfragte, welcher Aufwand zu erwarten sei, um die benötigten Lizenzen zu erwerben bzw. abzuschätzen in welchem Masse Mehraufwand bezüglich des Managements von zwei verschiedenen Security-Lösungen auf Sicherheitsmitarbeiter zukäme, wurde ihnen mit einem Schulterzucken geantwortet.

Der Grund, in die Cloud zu gehen, war genau der, dass diese Fragen offen waren. Je nach Auftragslage wurden mitunter für einen kurzen Zeitraum grosse Kapazitäten benötigt. Parallel zeigte der wirtschaftliche Erfolg des Unternehmens (vor Corona), dass die Gesamtanforderung weiter ansteigen würde. Das Unternehmen wollte seinen Erfolg schlicht nicht von der Verfügbarkeit der Rechenleistung abhängig machen. Da sich die Security-Anforderungen des Unternehmens an Compliance Vorgaben (speziell DSGVO und PCI-DSS) ausrichteten, waren Mindestanforderungen verpflichtend einzuhalten.

Hier stellte sich der erstellte Prozess als derart unflexibel und technisch komplex heraus, dass für die Cloud-Bestandteile des Unternehmens die Einrichtung und Dokumentation der Compliance eine beträchtliche logistische Herausforderung mit sich brachte. Unter anderem führte dies dazu, dass sich Abteilungen genötigt sahen, entweder ihre Aufträge zu verzögern oder auf die rechtzeitige Bereitstellung von Security zu verzichten. Der daraus erwachsende Konflikt, entweder Geschäftsoptionen zu gefährden oder zumindest temporär die Einhaltung der Compliance zu „übersehen“, eskalierte zunehmend.

Als sich das Unternehmen schliesslich aufgrund der Empfehlung seines Cloud Managed Service-Partners für Trend Micro entschied, war die Situation bereits derart eskaliert, dass die Lösung ohne weiteren Proof of Concept in bereits bestehende Live-Systeme integriert wurde. Bei vergleichbaren technischen Optionen war im Besonderen die komplette Integration in Cloud- und On-Premise-Operationen, so wie die flexible Möglichkeit, die Kosten anhand des Bedarfs auszurichten, entscheidend. Die Lizenzen wurden nach Bedarf sowohl in der Cloud als auch On-Premise berechnet. Das hatte während Corona übrigens auch einen ungeplanten Vorteil. Für die Eventagentur brachen in kurzer Zeit immer mehr Märkte ein, bis am Ende fast alles stand. Durch die Abrechnung nach Bedarf wurden so enorme Geldmengen eingespart, weil Systeme nicht bezahlt werden mussten, die nichts mehr zu tun hatten.

„Bring Your Own License“ versus „Pay as You Go“

Sieht man sich im Bereich Cloud-Migration um, so finden beide Bezahlmodelle ihren Platz: „Bring Your own License“ ist dabei der klassische Weg der Vorauszahlung. Der Vorteil dieser Lösung ist, dass sie die Kosten planbar macht, und sie obendrein mit dem Lieferanten verhandelt werden können. Die klassische Migration, Maschine für Maschine, kann so ohne weitere Lizenzabfrage durchgeführt werden. Der Nachteil dieser Lizenzierung ist, dass sie jegliche Flexibilität unmöglich macht. Werden mehr Lizenzen benötigt, muss das Unternehmen einen Beschaffungsprozess starten – Bedarfsabschätzung eingeschlossen. Benötigt es weniger, hat es halt „draufgezahlt“. Bei der nächsten Verhandlung geht das Spiel dann von vorn los.

„Pay as You Go“ wiederum versucht diese Nachteile auszugleichen. Hier wird nach Verbrauch abgerechnet. Moderne Verfahren ermöglichen eine Minuten genaue Taktung. Werden neue Maschinen gestartet, werden diese automatisch erfasst und mit den vorgegebenen Security-Einstellungen versorgt. Genauso werden sie wieder ausgecheckt, wenn die Systeme nicht mehr benötigt werden. Security wird damit automatisch zu einem Punkt der Betriebskosten. Die Ausgaben steigen oder fallen je nach Erfolg des Unternehmens.

Gemeinsam verwalten

Beide Bezahlmethoden haben ihre Vor- und Nachteile. Wie bereits erwähnt, entscheidet der Anwender mit der Auswahl letztlich darüber, welche Flexibilität seine Sicherheitsabteilung haben wird. Unabhängig davon, für welche Methode ein Unternehmen sich entscheidet, letztendlich geht es darum, dass Sicherheit das tut, wofür sie da ist, nämlich das Geschäft des Unternehmens zu schützen.

Entscheidend dabei ist, dass alles, was mit IT Security zu tun hat, schnell und einfach visualisiert werden kann. Wie auch immer das Datacenter aufgebaut ist, Hybrid oder Multicloud, immer werden Systeme zwischen den Formfaktoren hin und her migriert, flexibel errichtet oder auch ausgeschaltet. Um den Management-Aufwand zu minimieren und auch die Übersicht über Compliance- oder IT-Security-Aufgaben zu erhalten, sollten Organisationen vor allem nach einer Lösung Ausschau halten, die alles gemeinsam verwaltet. Sonst wird IT-Security schnell zu einem logistischen Alptraum.

Fazit

Flexibel zu sein, zahlt sich für Unternehmen aus. Den Erfolg von logistischen Bedürfnissen abzukoppeln heisst, das Business kann nach Bedarf wachsen — „The Sky is the Limit“. Aus Sicht der IT-Security kommt noch hinzu, dass aus „Bremsern“ Partner werden. Damit wird auch Security nicht mehr als Belastung empfunden, sondern als notwendige Massnahme geschätzt.

Für weitere wertvolle Informationen zur Migration in der Cloud melden Sie sich für das Webinar an.

Kampf der Linux Kryptowährungs-Miner um Ressourcen

Originalbeitrag von Alfredo Oliveira, David Fiser

Das Linux-Ökosystem steht in dem Ruf, sicherer und zuverlässiger als andere Betriebssysteme zu sein. Das erklärt möglicherweise auch, warum Google, die NASA und das US-Verteidigungsministerium Linux für ihre Online-Infrastrukturen und -Systeme nutzen. Leider ist die weite Verbreitung der Linux-Systeme auch für Cyberkriminelle sehr attraktiv. Mittlerweile wird ein rücksichtsloser Kampf um Rechenleistung zwischen den verschiedenen Kryptowährungs-Mining- Programmen, die auf Linux-Systeme abzielen, ausgetragen. Der Beitrag stellt die Angriffskette dar, einschliesslich der Verschiebung der Eintrittspunkte unter anderem auf Docker-Umgebungen und Anwendungen mit offenen APIs.

Kryptowährungs-Mining ist an sich nicht bösartig, doch nicht alle, die nach der profitablen Kryptowährung schürfen, tun dies legal. Und da der Markt für Kryptowährungen mehr als 350 Milliarden $ übersteigt, handelt es sich dabei um wahre digitale Schätze.

Cyberkriminelle missbrauchen Kryptowährungs-Mining, indem sie Mining-Malware auf den Geräten ahnungsloser Benutzer installieren und deren Verarbeitungskapazitäten ohne Autorisierung nutzen. Auf diese Weise können sie mühelos profitieren, ohne in die notwendige Kryptowährungs-Mining-Infrastruktur investieren zu müssen.

In den letzten Jahren hat es einen massiven Anstieg bei Mining Malware gegeben, vor allem solcher für Monero. Diese bietet vollständige transaktionale Anonymität und Vertraulichkeit und ist damit ideal für den Missbrauch bei illegalen Aktivitäten geeignet. Cyberkriminelle versuchen, ihre potenziellen Einkünfte zu maximieren, indem sie sich auf leistungsstarke Geräte mit beträchtlichen Rechenkapazitäten konzentrieren und dort weitere Mining-Malware vernichten, um so die Plattformen und Geräte, die sie infizieren können, zu erweitern.

Die Sicherheitsforscher von Trend Micro analysierten KORKERDS, eine Linux Malware-Variante, die ein Rootkit mitbringt, das bösartige Prozesse vor den Monitoring-Tools auf einem infizierten System verbirgt. Eine weitere Linux-Malware Skidmap kann die Sicherheitseinstellungen auf einem infizierten Gerät herabsetzen und liefert böswilligen Akteuren den Backdoor-Zugriff.

Beide Varianten nutzen komplexe Techniken zum Missbrauch der Ressourcen eines Opfers. Nun gibt es eine Charakteristik, die immer häufiger anzutreffen ist und die die Forscher in ihren Honeypots aber auch in der Praxis gefunden haben – nämlich Routinen, die andere ähnliche Malware in infizierten Geräten, Systemen und Umgebungen deaktivieren und entfernen.

Eine der Routinen dieser Mining Malware besteht darin, nach einer Infektion nach weiteren Mining-Konkurrenten zu suchen. Entdeckt sie eine solche Malware, schaltet sie die Prozesse ihrer Konkurrenten ab, löscht ihre Spuren aus dem System und sorgt dafür, dass diese Konkurrenten nicht mehr laufen können.

Diese Mining-Samples zielen nicht nur auf Linux-Host-Rechner ab, die als persönliche Geräte verwendet werden, sondern auch auf leistungsstarke Tools, die Unternehmen im Rahmen von DevOps nutzen, wie etwa Docker und Redis.

Die analysierten Samples suchen nicht nur nach ressourcenintensiven Prozessen auf dem Host-Rechner, sondern auch nach Docker-Containern, die für Mining genutzt werden. Mit diesem Verhalten soll gewährleistet werden, dass die zuletzt eingesetzte Malware die Rechenleistung des Hosts nutzen kann.

Auch Cyberkriminelle haben ihren Horizont erweitert und greifen die AWS-Infrastruktur an, auf der mit Mining-Malware infizierte Docker- sowie Kubernetes-Systeme laufen und stehlen AWS-Anmeldedaten.

Bild. Die Infektionskette von Kryptowährungs-Mining Malware in offenen APIs

Ein häufiger Trend oder eine Technik, die in der Vergangenheit von Malware-Akteuren eingesetzt wurde, bestand darin, eine Schwachstelle in einem öffentlich gehosteten Dienst auszunutzen, um Privilegien für die Codeausführung zu erlangen. Diese Technik ermöglichte es einem Angreifer, ein Botnet zu erstellen oder einen Coinminer im System zu installieren. Eine neuere Technik ist immer häufiger anzutreffen, bei der nach offenen APIs gesucht wird, die es ermöglichen, sich Zugriff auf Container oder Privilegien für die Codeausführung zu verschaffen. Auch hat sich die Mining Malware von On-Premise-Geräten hin zu Containern und in die Cloud verlagert. Technische Einzelheiten zum Ablauf liefert der Originalbeitrag.

Schutz vor Mining Malware

Um Systeme, Geräte und Umgebungen zu schützen, sollten IT- und Systemadministratoren Best Practices befolgen, so etwa die konsequente Anwendung des Prinzips der Mindestprivilegien, regelmässiges Patching und Aktualisieren von Systemen, Einsatz von Mehrfaktorauthentifizierung, Nutzen von verifizierten Sicherheits-Extensions sowie Aufstellen von Zugangskontrollrichtlinien. Auch ist es von Bedeutung, API-Konfigurationen zu überprüfen, um sicherzustellen, dass Anfragen von einem festgelegten Host oder internen Netzwerk kommen. Des Weiteren sind regelmässige Scans des Hosts nach offenen Ports wichtig sowie eingeschränkter SSH-Zugang.

Unternehmen können sich auch mithilfe von Lösungen schützen wie Trend Micro™ Hybrid Cloud Security, die mit einer schlanken, funktionsstarken und automatisierten Sicherheit die DevOps Pipeline sichern kann. Sie liefert mehrere XGen  Threat Defense-Techniken für die Sicherheit von physischen, virtuellen und Cloud Workloads zur Laufzeit. Unterstützt wird die Lösung durch die Cloud One™ Plattform, die ein einheitliches, zentrales Dashboard für die hybriden Cloud-Umgebungen liefert sowie Network Security, Workload Security, Container Security, Application Security, File Storage Security und Conformity-Services.

Für Organisationen, die Sicherheit als Software für Runtime-Workloads, Container-Images sowie Datei- und Objektspeicher suchen, scannt Deep Security™, Deep Security Smart Check Workloads und Container-Images in jedem beliebigen Intervall in der Entwicklungs-Pipeline auf Malware und Schwachstellen, um Bedrohungen zu verhindern, bevor die Assets eingesetzt werden.

Unternehmenssicherheit in Gefahr durch das neue flexible Arbeiten

von Trend Micro

COVID-19 hat die Welt in den letzten Monaten auf verschiedene Weise verändert, am deutlichsten jedoch ist der schnelle Wechsel zu Remote Working infolge der durch Regierungen verhängten Lockdown-Massnahmen zu beobachten gewesen. Trend Micro hat im Rahmen einer Umfrage die Gewohnheiten von Arbeitnehmern im Homeoffice während der Pandemie untersucht. Offiziellen Zahlen des Bitkom zufolge arbeitete infolge der Corona-Pandemie jeder zweite Berufstätige (49%) ganz oder zumindest teilweise im Homeoffice. Obwohl dies zur Unterstützung der Produktivität unter aussergewöhnlichen Umständen unerlässlich war, droht es auch, Organisationen neuen Cybersicherheitsrisiken auszusetzen.

Das Problem mit dem Smart Home

Für den Bericht „Head in the Clouds“ wurden mehr als 13.000 Remote-Mitarbeiter in 27 Ländern weltweit (davon 504 in Deutschland) befragt. Obwohl viele vorgeben, Cybersicherheit heute ernster zu nehmen, ist die Wahrheit etwas anders geartet. Eines der Hauptrisiken, laut Studienergebnissen, entsteht durch Smart Home-Systeme.

Smart Home-Geräte sind heutzutage allgegenwärtig – von Smart TVs und Home Sicherheitssysteme bis zu vernetzten Lautsprechern und Wasserkochern. Sie sind darauf zugeschnitten, den Alltag einfacher, sicherer und produktiver zu gestalten. Doch hat eine Studie der Postbank 2019 gezeigt, dass nahezu jeder Dritte deutsche Haushalt einen digitalen Sprachassistenten nutzt.

Diese Gadgets weisen bekanntermassen Schwachstellen auf, wie z.B. Firmware-Fehler und werkseitig voreingestellte Logins, die leicht zu knacken sind. Bot-Angriffe wie Mirai und seine Nachfolger haben diese Schwächen sehr erfolgreich ausgenutzt, insbesondere bei Produkten weniger bekannter Marken.

Doch über das blosse Kompromittieren und Einbinden eines anfälligen Geräts in ein Botnet hinaus gibt es potenziell noch ausgefeiltere Möglichkeiten für funktionierende Angriffe. Die Studienautoren fanden heraus, dass mehr als die Hälfte 62% der Remote-Mitarbeiter in Deutschland IoT-Geräte besitzen, die mit dem Home-Netzwerk verbunden sind, wobei 7% weniger bekannte Marken einsetzen. Diese Geräte könnten theoretisch gekapert werden, um einem Angreifer Zugang zu einem Heimnetzwerk zu verschaffen. Und dann ist es nur ein kurzer Weg bis ins Firmennetzwerk, über Laptops oder PCs, die ebenfalls miteinander vernetzt sein können.

Unternehmen unter Beschuss

Ein Angriff auf ein Unternehmen stellt für die Akteure nicht unbedingt eine einfache Aufgabe dar, doch wird sie erleichtert, wenn Laptops und andere Geräte mit Unternehmenszugriff schlecht gesichert sind. Zwei Fünftel (45%) der deutschen Studienteilnehmer erklärten, dass sie von persönlichen Geräten aus auf Unternehmensdaten zugreifen. Diese Geräte sind häufig weniger gut geschützt als die im Unternehmen: So erklärten 52% der Remote-Mitarbeiter kein aktives Passwort für ihr Geräte zu nutzen.

Des Weiteren greifen 65% der Remote-Mitarbeiter von ihrem Arbeits-Laptop auf das Heimnetzwerk zu. Diese sollten zwar sicherer sein, aber es gibt keine Garantie dafür, vor allem, wenn Manager sie schnell ausgeben, ohne dass die IT-Abteilung Zeit hat zu prüfen, ob AV vorinstalliert ist. Nicht alle IT-Sicherheitsfunktionen sind in der Lage, solche Geräte aus der Ferne zu verwalten. Eine kürzlich veröffentlichte Studie liefert beunruhigende Zahlen: 93% der Unternehmen weltweit haben derzeit Sicherheitsaufgaben verschoben, so etwa Patching während der Pandemie.

All dies geschieht zu einer Zeit, in der Cyberkriminelle es auf abgelenkte Remote-Mitarbeiter als potenziell schwaches Glied in der Cybersicherheitskette von Unternehmen abgesehen haben. Im Mai sah sich das National Cyber Security Centre (NCSC) gezwungen, ein Adisvory nicht nur bezüglich Phishing-Angriffen unter dem COVID-Thema, sondern auch für Angriffe auf Remote-Access-Infrastrukturen herauszugeben.

Was nun?

So vorhersehbar es auch klingt, die Antwort liegt in dem bewährten Trio aus Menschen, Verfahren und Technologie. Als erstes geht es um die Menschen, die ein verbessertes Awareness-Training erhalten müssen. Dieses sollte auf verschiedene Persönlichkeitstypen zugeschnitten sein, um die Wirksamkeit zu maximieren.

Als Nächstes sollten sich Unternehmen auf die Neugestaltung und Durchsetzung von Sicherheitsrichtlinien und -prozessen konzentrieren, um der neuen Realität der Heimarbeit Rechnung zu tragen und sicherzustellen, dass die Mitarbeiter sich an die Vorschriften halten. Sie müssen die Bedrohung, die von intelligenten Heimnetzwerken und persönlichen Geräten ausgeht, kennen und wissen, wie sie diese mindern können, z.B. durch Isolierung von IoT-Geräten in Gastnetzwerken.

Schliesslich sollten Organisationen sicherstellen, dass alle Endpunkte und Heimnetzwerke der Mitarbeiter angemessen geschützt sind. Cloud-basierte Tools können einen Grossteil der Arbeit leisten, um Kosten zu minimieren und den Verwaltungsaufwand für überlastete IT-Teams zu verringern.

Der Lebenszyklus eines kompromittierten (Cloud) Servers

Originalbeitrag von Bob McArdle

Trend Micro Research hat ein breit angelegtes Forschungsprojekt zum cyberkriminellen Hosting und zur Infrastruktur im Untergrund durchgeführt. Ein erster Report dazu beschäftigte sich mit dem Angebot von Hacker-Infrastrukturen im Untergrund. In dem aktuellen zweiten Teil geht es um den Lebenszyklus von kompromittierten Servern und den verschiedenen Phasen, um daraus Gewinn zu schlagen. Es gilt dabei zu beachten, dass es für Kriminelle keine Rolle spielt, ob der Server On-Premise oder in der Cloud betrieben wird.

Cloud- versus On-Premise-Server

Cyberkriminellen ist es gleichgültig, wo sich die Server befinden. Sie können den Speicherplatz und die Rechenressourcen ausnutzen oder Daten stehlen, egal auf welche Art von Server sie zugreifen. Alles, was am meisten exponiert ist, wird höchstwahrscheinlich missbraucht.

Mit fortschreitender digitalen Transformation und zunehmendem Arbeiten von zuhause werden Cloud-Server am wahrscheinlichsten Bedrohungen ausgesetzt. Leider sind viele IT-Teams in Unternehmen nicht darauf eingerichtet, für die Cloud denselben Schutz zu bieten wie für On-Premise-Server.

Die Forscher betonen, dass dieses Szenario nur für Cloud-Instanzen gilt, die die Speicher- oder Verarbeitungsleistung eines lokalen Servers replizieren. Container oder serverlose Funktionen fallen nicht der gleichen Art von Kompromittierung zum Opfer. Wenn der Angreifer das Cloud-Konto kompromittiert – im Gegensatz zu einer einzelnen laufenden Instanz – entsteht ein völlig anderer Angriffszyklus, da die Angreifer Rechenressourcen nach Belieben in Anspruch nehmen können. Obwohl dies möglich ist, liegt der Fokus der Erforschung nicht darauf.

Alarmsignale für einen Angriff

Viele IT- und Sicherheitsteams suchen möglicherweise nicht nach früheren Stadien des Missbrauchs. Bevor Server jedoch von Ransomware betroffen sind, gibt es andere Alarmsignale, die die Teams auf die Bedrohung aufmerksam machen könnten.

Wenn ein Server kompromittiert und für Kryptowährungs-Mining (auch als Kryptomining bekannt) verwendet wird, kann dies eine der grössten Alarmsignale für das Sicherheitsteam sein. Die Entdeckung von Cryptomining Malware, die auf irgendeinem Server läuft, sollte dazu führen, dass das Unternehmen unverzüglich Massnahmen ergreift und eine Reaktion auf den Vorfall (Incident Response) einleitet, um diesen Server zu sperren.

Dieser Indicator of Compromise (IOC) ist wichtig, denn obwohl Cryptomining-Malware im Vergleich zu anderen Malware-Typen häufig als weniger schwerwiegend angesehen wird, dient sie auch als Taktik zum Geld machen. Sie kann im Hintergrund laufen, während der Serverzugriff für weitere bösartige Aktivitäten verkauft wird. Beispielsweise könnte der Zugang für die Nutzung als Server für unterirdisches Hosting verkauft werden. Gleichzeitig könnten die Daten exfiltriert und als persönlich identifizierbare Informationen (PII) oder für Industriespionage verkauft werden, auch könnten sie für einen gezielten Ransomware-Angriff verscherbelt werden. Dieses Szenario nutzen zumindest einige Access-as-a-Service (AaaS)-Kriminelle als Teil ihres Geschäftsmodells.

Lebenszyklus eines Angriffs

Attacken auf kompromittierte Server folgen einem allgemeinen Muster:

  • Ursprüngliche Kompromittierung: In dieser Phase ist es klar, dass ein Krimineller den Server übernommen hat.
  • Asset-Kategorisierung: Dies ist die Phase der Bestandsaufnahme. Der Kriminelle nimmt seine Einschätzung anhand von Fragen vor, wie etwa: Welche Daten befinden sich auf diesem Server? Besteht die Möglichkeit einer lateralen Bewegung zu etwas Lukrativerem? Wer ist das Opfer?
  • Exfiltrierung sensibler Daten: Der Kriminelle stiehlt unter anderem Unternehmens-E-Mails, Client-Datenbanken und vertrauliche Dokumente. Dies kann jederzeit nach der Kategorisierungsphase passieren, wenn der Angreifer etwas Wertvolles entdeckt hat.
  • Kryptowährungs-Mining: Während der Angreifer einen Kunden für den Serverraum, einen Zielangriff oder andere Mittel zur Geldgewinnung sucht, wird Cryptomining eingesetzt, um im Verborgenen Geld zu verdienen.
  • Wiederverkauf oder Nutzung für gezielte Angriffe mit dem Ziel, mehr Geld zu verdienen: Abhängig davon, was der Kriminelle bei der Kategorisierung der Assets findet, könnte er seinen eigenen gezielten Ransomware-Angriff planen, den Serverzugang für Wirtschaftsspionage oder für weitere Zwecke verkaufen.

Der Lebenszyklus eines kompromittierten Servers bezüglich der Möglichkeiten Gewinn daraus zu ziehen

Häufig ist der Einsatz gezielter Ransomware die letzte Phase. In den meisten Fällen zeigt die Kategorisierung der Assets Daten auf, die zwar für das Unternehmen wertvoll sind, die sich jedoch nicht unbedingt für Spionage eignen.

Ein tiefgreifendes Verständnis der Server und des Netzwerks ermöglicht es Kriminellen hinter einem gezielten Ransomware-Angriff, das Unternehmen dort zu treffen, wo es am meisten schmerzt. Diese Kriminellen kennen den Datenbestand, wissen, wo sie sich befinden, ob es Backups der Daten gibt und vieles mehr. Mit einer so detaillierten Blaupause der Organisation können sie kritische Systeme abriegeln und ein höheres Lösegeld fordern. Das zeigt auch der Halbjahresbericht 2020 von Trend Micro.

Darüber hinaus hat zwar ein Ransomware-Angriff die sichtbare Dringlichkeit für die Abwehr, aber derselbe Angriff könnte auch darauf hinweisen, dass etwas weitaus Schwerwiegenderes wahrscheinlich bereits stattgefunden hat: der Diebstahl von Unternehmensdaten, und dies ist bei der Reaktionsplanung des Unternehmens zu berücksichtigen. Noch wichtiger ist, dass sobald ein IOC für Krypto-Währung gefunden wurde, das Unternehmen in der Lage ist, den Angreifer sofort zu stoppen, um später erhebliche Zeit und Kosten zu sparen.

Letztendlich ist die Sicherheit der Hybrid-Cloud von entscheidender Bedeutung, um diesen Lebenszyklus zu verhindern, unabhängig davon, wo die Daten eines Unternehmens gespeichert sind.

Grundlagen der Sicherheit für Kubernetes Cluster

Originalbeitrag von Magno Logan, Trend Micro Research

Obwohl Kubernetes noch nicht sehr lange verfügbar ist, steht die Plattform bereits auf Platz drei bei den bei Entwicklern beliebtesten Produkten. Umso wichtiger ist das Wissen darum, wie die Sicherheit von Kubernetes, und in diesem Fall von Clustern, gewährleistet werden kann. Ein früherer Beitrag beinhaltete bereits einen Überblick über die Sicherheit für die 4 Cs (Cloud, Cluster, Container and Code) in Cloud-nativen Systemen. Jetzt geht es um die Darstellung der Massnahmen für die Sicherheit des Master-Knoten, API-Servers, etcd und für Netzwerk-Policies.

Betreibt ein Unternehmen seine Cluster als Managed Services wie etwa Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) oder Google Kubernetes Engine (GKE), so muss der Cloud-Anbieter die Kontrolle über die Sicherheit übernehmen. Dennoch ist ein besseres Verständnis der verfügbaren Sicherheitsoptionen hilfreich, um sicherzustellen, dass der Cloud-Anbieter die empfohlenen Best Practices befolgt. Betreibt eine Organisation ihre eigenen Control Planes, ist das tiefgreifende Wissen zur Sicherheit noch wichtiger.

Das Control Plane

Das Kubernetes Control Plane fungiert als Hauptknoten im Cluster und verwaltet die Worker Nodes. Damit geht es um das Gehirn, das dieses komplexe System in einem guten Zustand und am Laufen hält.

Bild 1. Skizze eines Kubernetes Clusters und dessen Komponenten (Quelle: Kubernetes.io)

Die Abbildung zeigt, dass die Hauptkomponenten für den Cluster im Control Plane sitzen und dass die gesamte Kommunikation über den kube API-Server (kube-apiserver) läuft, der letztendlich ein REST API ist, das alle Management- und Betriebsfunktionen definiert und kontrolliert. Böswillige Akteure bemühen sich um Zugriff auf den kube-apiserver und das Control Plane. Sobald diese kompromittiert sind, können sie den gesamten Cluster kompromittieren, indem sie die Pods (in denen die Container platziert sind) manipulieren, neue aufsetzen, bereits laufende bearbeiten oder sogar ganz entfernen.

Eine der grundlegenden Massnahmen zur Sicherung des Control Plane ist die Integritätsüberwachung der kritischen Kubernetes-Dateien. Auf diese Weise kommt sofort über jede Änderung der Konfiguration eine Benachrichtigung. Aus Sicht der Kubernetes-Sicherheit sind kritische Dateien diejenigen, die den gesamten Cluster beeinträchtigen können, wenn sie kompromittiert werden. Eine Liste der wichtigsten Dateien und Verzeichnisse, die das Team ständig überwachen muss, zusammen mit den empfohlenen Ownership- und Berechtigungsebenen sind in der neuesten CIS Kubernetes Benchmark v1.5.1 detailliert aufgeführt. Bei den meisten dieser Werte handelt es sich um die Standardwerte der Kubernetes-Installation. Eine Tabelle ist im Originalbeitrag aufgeführt.

Der API Server

Den API-Server der Öffentlichkeit zugänglich zu machen, ist ein kritischer Fehler, den immer noch viele machen, und es ist der häufigste Einstiegspunkt für Angreifer, die darüber den Cluster übernehmen können. Viele Angreifer und Bots suchen im Internet ständig nach offen zugänglichen Kubernetes-API-Servern.

Der einfachste Test, um festzustellen, ob der Server im Internet zugänglich ist, besteht darin, den API-Server von einer externen IP aus zu treffen. Hier hilft eine curl-Anfrage oder https://my-control-plane-ip:6443/api. Gibt es eine Antwort auf die Anfrage, so ist das API öffentlich erreichbar. In einem solchen Fall gibt es mehrere Möglichkeiten einen Fix aufzubringen, je nachdem wie der Zugriff auf das API erfolgt. Die beste und sicherste Option ist die folgende:

Entwickler sollten das Cluster API nur über das interne Netzwerk (oder Unternehmens-VPN) erreichen können. Dies lässt sich leicht erreichen, indem die entsprechenden Regeln für die Firewall oder Sicherheitsgruppen (im Fall von AWS) festgelegt werden. Hier muss allerdings darauf geachtet werden, dass in einer Notfallsituation, in der der Cluster-Administrator keinen sofortigen Zugriff auf den Firmen-Laptop oder ein VPN hat, der Zugriff auf den Cluster durch eine sichere Auflistung der IP des Cluster-Administrators gewährleistet ist, vorzugsweise auf den spezifischen API-Port.

Der Zugang auf den Cluster auf GKE lässt sich auch über die Einstellungen des Master Authorized Networks einschränken. Damit entsteht eine weitere Schutzebene für den Fall, dass jemand die Firewall-Regeln manipulieren kann. Der folgende Befehl tut dies:

gcloud container clusters create –enable-master-authorized-networks –master-authorized-networks=CIDR

Des Weiteren kann der Admin prüfen, ob der kube-apiserver die empfohlenen Sicherheitseinstellungen aufweist:

ps -ef | grep kube-apiserver

Weitere Informationen dazu umfasst der Originalbeitrag.

RBAC-Autorisierung

Mit RBAC lässt sich festlegen, wer worauf in dem Cluster zugreifen kann. Die Aktivierung der Autorisierung für RBAC im Cluster wird dringend empfohlen, insbesondere für die Produktion. Zudem kann allen Benutzern der Zugriff auf den Kube-System-Namensraum untersagt werden, wo sich alle Pods des Control Planes befinden.

Das RBAC-Autorisierungsmodul ist in den neuesten Versionen standardmässig aktiviert. Es müssen lediglich die geeigneten Rollen festgelegt und diese bestimmten Nutzern zugewiesen werden. Doch können böswillige Nutzer RBAC deaktivieren. Dies lässt sich mit demselben Befehl überprüfen, der für den Check der Kube API Serverkonfigurationen genutzt wird:

ps -ef | grep kube-apiserver

Beim Einsatz der RBAC-Autorisierung lassen sich vier Arten von API-Objekten nutzen:

  • Role: enthält Regeln, die einen Berechtigungssatz innerhalb eines Namensraums repräsentieren.
  • RoleBinding: vergibt Berechtigungen einer Role an einen oder mehrere Nutzer.
  • ClusterRole: enthält Regeln, die einen Berechtigungssatz auf Cluster-Ebene repräsentieren.
  • ClusterRoleBinding: vergibt Berechtigungen für Nutzer auf ClusterRole-Ebene.

Bild 2. Bezug der Nutzer zu Roles über RoleBindings beziehungsweise von ClusterRoles zu ClusterRoleBindings

Weitere technische Einzelheiten beinhaltet der Originalbeitrag sowie die offizielle Dokumentation.

etcd

etcd ist der Hauptspeicherort für Daten im Cluster. Alle Clusterobjekte werden hier vorgehalten. Er ist hierarchisch aufgebaut und standardisiert, daher nutzen Kubernetes-Installationen etcd für das Speichern von REST API Objekten sowie für Installationskonfigurationen. Wird etcd exponiert, so könnten kritische Daten verloren gehen. Leider kommen Fehlkonfigurationen häufig vor, wie 2.600 exponierte etcd-Services auf Shodan in diesem Jahr zeigen.

Wie bei jedem Datenspeichersystem sollten die gleichen Sicherheitsprinzipien auf etcd angewandt werden. Sowohl die Verschlüsselung im Transit als auch At-Rest sollte vorhanden sein. Derzeitige Kubernetes Standardinstallationen beinhalten bereits die geeigneten Schlüssel und Zertifikate sowie TLS-Verschlüsselung (siehe CIS Kubernetes Benchmark).

Gelingt es einem Angreifer auf irgendeine Weise, den API-Server zu umgehen und Objekte direkt in etcd zu manipulieren, so wäre es, als hätte er vollen Zugriff auf den gesamten Cluster. Er könnte Pods erstellen, Geheimnisse lesen und sensible Daten wie Anmeldeinformationen einsehen. Um dies zu verhindern, müsste nicht nur die Verschlüsselung während der Übertragung aktiviert sein, sondern auch die Verschlüsselung im Ruhezustand (At-Rest).

Das Netzwerk

Standardmässig können alle Pods in einem Cluster mit jedem anderen Pod auf demselben Cluster kommunizieren, einschliesslich Pods aus verschiedenen Namensräumen, und dies schliesst den Hauptnamensraum des Kube-Systems ein, in dem das Control Plane untergebracht ist. So legt es die Netzwerk-Policy fest, die bei der Kubernetes-Installation konfiguriert wird.

Eine Netzwerk-Policy definiert, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren. NetworkPolicy-API-Ressourcen verwenden Labels, um Pods auszuwählen und Regeln zu definieren, die angeben, welche Art von Datenverkehr für die ausgewählten Pods zulässig ist. Diese Richtlinien können helfen, den Zugriff zwischen Pods oder Namespaces einzuschränken. Der gesamte Zugriff kann über Labels in YAML-Dateien konfiguriert werden, so dass z.B. der Zugriff von Pods auf andere Pods im Namensraum des kube-Systems blockiert werden kann.

Hinweis: Es bedarf einer Netzwerklösung oder eines Container Network Interface (CNI), das das NetworkPolicy-Objekt unterstützt. Andernfalls hat dies keine Auswirkungen auf den Cluster.

Für alle aufgeführten Punkte gibt der Originalbeitrag weitere technische Informationen, und auch eine Kubernetes Security Liste auf GitHub bietet Blogs, Artikel, Tools und Videos zum Thema. In einem weiteren Beitrag werden sich die Autoren mit dem Schutz von Worker Nodes, Kubelet sowie den Pods befassen.

Durchgängiges Deep Learning für Cybersicherheit

Originalartikel von Spark Tsao, Data Scientist

Die Branche der Cybersicherheit ist eine der vielen Bereiche, die ganz erheblich von KI profitiert haben. Effizient eingesetzt verbessert die künstliche Intelligenz die Fähigkeiten von Cybersicherheitslösungen, ein breites Spektrum der Bedrohungen zu erkennen, einschliesslich brandneuer oder nicht klassifizierter Gefahren. Der Prozess der effizienten Nutzung der KI umfasst unter anderem in der Regel modernste Modelle, eine iterative Methode zur Verbesserung der Genauigkeit des Modells und genau gekennzeichnete Daten.

In vielen Cybersicherheitsunternehmen, die KI einsetzen, werden die genannten Anforderungen – insbesondere der Prozess der genauen Kennzeichnung von Daten – durch Bedrohungsexperten unterstützt. Diese kümmern sich neben anderen manuellen Aufgaben oder Prozessen, die handgefertigte Eingaben produzieren, um die Vorverarbeitung der Daten und die Extraktion sowie Entwicklung der Funktionalität. Im Wesentlichen ermöglichen diese von Experten handgefertigten Eingaben eine eindeutigere Ausführung von Modellen, da die zugrunde liegende Struktur der Daten somit genau dargestellt werden kann, wodurch die Fähigkeiten zur Erkennung von Bedrohungen verbessert werden.

Das Aufkommen neuer Methoden zur Erkennung von Bedrohungen mit Hilfe der KI stellt jedoch den Bedarf an handwerklichem Input von Experten in Frage. Insbesondere beinhalten diese Methoden durchgehende, Deep Learning-Lösungen, die von einigen als der nächste grosse Meilenstein in der Malware-Erkennung angepriesen werden. In solchen Lösungen werden die von Expertenerarbeiteten Eingaben durch solche ersetzt, die von automatisierten Prozessen bereitgestellt werden. Während dies in einigen Industriezweigen, die KI für verschiedene Zwecke einsetzen, wohl immer mehr akzeptiert wird, wirft das Fehlen handwerklicher Eingaben von Experten die Frage auf, ob handwerkliche Eingaben von Experten bei der Entwicklung einer effizienten KI-gestützten Cybersicherheitslösung noch relevant sind oder nicht.

Ein Ansatz untersuchte Malware-Binärdateien, die als Graustufenbilder dargestellt wurden, was die textuellen und strukturellen Ähnlichkeiten und Unterschiede entweder zwischen Binärdateien derselben und anderer Malware-Familien oder zwischen Malware und gutartiger Software aufzeigte. Dadurch wird das manuelle Feature-Engineering vermieden, was Zeit spart und den Arbeitsaufwand für Cybersicherheitsunternehmen verringert. Ein weiterer Ansatz umfasst einen Prozess, bei dem die Engine mit Rohdaten gefüttert wird, die aus Byte-Rohwerten bestehen, und Output erzeugt, der die Klassifizierung einer bösartigen oder gutartigen Datei anzeigt.

Informieren Sie sich eingehender über die Entwicklungen im durchgängigen Deep Learning für Cybersicherheit und über die derzeitige und künftige Effizienz.

Trend Micro Halbjahresbericht 2020: Sicherheit in pandemischen Zeiten

von Trend Micro

Die Covid-19-Pandemie hat die Cybersicherheitslandschaft in der ersten Hälfte 2020 stark geprägt. Während sich die Menschen an neue Arbeits- und Schulumgebungen anpassten, mussten Unternehmen für ihre Mitarbeiter Setups für die Arbeit zu Hause (Work-from-Home, WFH) schaffen und dabei dafür sorgen, dass deren Systeme auch sicher sind. Böswillige Akteure machten sich die Situation zunutze, indem sie das Thema Covid-19 für ihre Angriffe nutzten. Gruppen von Bedrohungsakteuren setzten ihre Kampagnen fort und dehnten ihre Reichweite auf neue Ziele und Plattformen aus, während sich die Betreiber von Ransomware weiterhin auf gezielte Angriffe konzentrierten. Trend Micro gibt in einer Zusammenfassung zur Jahresmitte 2020 den Überblick über die Trends und Ereignisse der ersten Jahreshälfte.

Böswillige Akteure haben schon immer gesellschaftlich relevante Ereignisse zur Durchsetzung ihrer Pläne genutzt, und bei Covid-19 ist das nicht anders. Die Sicherheitsforscher fanden eine Vielzahl von Vorfällen, in denen Cyberkriminelle pandemiebezogene Köder für ihre bösartigen Aktivitäten einsetzten, von relativ harmlosen Betrugsmaschen bis hin zu destruktiven Kampagnen, die fortgeschrittene Malware verbreiteten.

Der abrupte Wechsel auf WFH-Setups stellte Unternehmen vor zahlreiche Herausforderungen. Abgesehen von der Notwendigkeit, den Mitarbeitern die für die Aufrechterhaltung des Betriebs benötigten Werkzeuge zur Verfügung zu stellen, hatten Unternehmen mit Fragen der Kommunikation, Konnektivität und sogar der Zuweisung von IT-Ressourcen zu kämpfen.

Bild 1. Zahl und Verbreitung von Covid-19-Bedrohungen in der ersten Hälfte 2020

Ransomware-Betreiber konzentrieren sich auf ausgewählte Ziele

Ransomware hat sich von seinen opportunistischen Wurzeln, zu denen nicht personalisierte Spam-Kampagnen gehörten, zu einem gezielteren Ansatz entwickelt, bei dem oft der Diebstahl von Credentials und andere komplexe Techniken eingesetzt werden, um das Zielsystem zu kompromittieren. Die Hauptopfer dabei sind Organisationen, die viel zu verlieren haben und in der Lage sind, hohe Lösegeldforderungen zu erfüllen. Darüber hinaus stellten die Forscher auch einen wachsenden Trend fest, bei dem Betreiber von Ransomware ihren Opfern mit der Veröffentlichung ihrer Daten drohen, falls das Lösegeld nicht bezahlt wird.

Bild 2. Halbjahresvergleich der Anzahl der entdeckten Ransomware-bezogenen Komponenten (Dateien, Emails und URLs)

Schwachstellen sind weiterhin ein relevantes Problem

Mit der Verlagerung hin zur Remote-Arbeit ist das Patching wichtiger denn je. In der ersten Jahreshälfte wurde eine grosse Anzahl veröffentlichter und gepatchter Schwachstellen gemeldet, darunter mehrere kritische Fehler, die bereits in der Praxis ausgenutzt wurden. Für die Unternehmen könnte dies zu einer zusätzlichen Arbeitsbelastung ihres IT-Personals führen, das diese Updates implementieren und darüber hinaus sicherstellen muss, dass die IT-Infrastruktur des Unternehmens unter den neuen Arbeitsumgebungen so nahtlos wie möglich funktioniert.

Zwischen Ende 2019 und Anfang 2020 wurden zwei verschiedene Gruppen von Schwachstellen entdeckt, die Industrial Internet of Things (IIoT)-Geräte betreffen. Solche Sicherheitslücken könnten einen erheblich schädlichen Einfluss auf betroffene Branchen und Organisationen haben und zu möglichen zukünftigen Regelungen für das IIoT im Allgemeinen führen.

Bild 3. Halbjahresvergleich der Anzahl der Schwachstellen, die das ZDI-Programm veröffentlicht hat

Mehrschichtige Sicherheit als Verteidigung vor heutigen vielfältigen Bedrohungen

Die Herausforderungen im Bereich der Cybersicherheit, denen viele Organisationen in der ersten Hälfte des Jahres 2020 ausgesetzt waren, beweisen, dass eine mehrschichtige Lösung, die eine Mischung aus Fähigkeiten zur Bedrohungsabwehr bieten kann, am besten für eine umfassende Sicherheitsimplementierung geeignet ist, die sowohl in Büro- als auch in Privatumgebungen funktioniert.

Weitere Einzelheiten liefert der Report:

Unsichere gRPC-Implementierungen können APIs gefährden

Originalartikel von David Fiser, Security Researcher

Unternehmen setzen immer häufiger Microservice-Architekturen für ihre Anwendungen ein, weil diese Dienste ein effizientes Infrastrukturmanagement ermöglichen, Updates und Verbesserungen können einfacher bereitgestellt und Anwendungen auf Wunsch skaliert werden. Im Zuge dieses Architekturwechsels entsteht auch die Notwendigkeit einer effizienten Kommunikation zwischen den Microservices. Diese kritische und komplexe Kommunikation zwischen Client- und Server-Anwendungen lässt sich mit gRPC, einem universellen Remote Procedure Call (RPC)-Framework, bewerkstelligen. Obwohl es noch recht neu ist (2015 von Google entwickelt), hat das Framework schnell an Popularität gewonnen. Doch können noch Sicherheitsfragen entstehen, wenn Entwickler gRPC in ihre Projekte aufnehmen. Und da gRPC APIs eine wichtige Rolle für die allgemeine Anwendungssicherheit spielen, liefert Trend Micro auch Empfehlungen für den Schutz von gRPC-Implementierungen.

gRPC kann für das Design neuer Protokolle verwendet werden, die Genauigkeit, Effizienz und Sprachunabhängigkeit erfordern, denn das Framework unterstützt mehrere Sprachen sowohl für Server als auch für Clients. Es handelt sich um ein Cloud Native Computing (CNCF)-Projekt und wird in grossen Unternehmen wie Netflix, dem Finanzdienstleister Square und der Platform-as-a-Service (PaaS) Docker eingesetzt.

gRPC lässt sich mit anderen RPC Frameworks wie SOAP und REST vergleichen. Obwohl RESTful-APIs weit verbreitet sind und typischerweise HTTP verwenden, um Informationen zwischen Anwendungen oder Diensten und dem JavaScript Object Notation (JSON)-Datenformat auszutauschen, haben gibt es Einschränkungen hinsichtlich Leistung und textbasierter Ausrichtung. Viele Unternehmen haben ihre APIs von REST auf gRPC migriert, um die Vorteile des Binärprotokolls von gRPC zu nutzen. gRPC verwendet standardmässig als darunterliegende Schicht HTTP/2, ein binärbasiertes Protokoll. HTTP/2 unterstützt mehrere Streams und Anfragen innerhalb einer TCP-Verbindung. Weitere Einzelheiten bietet der Originalbeitrag.

Bild 1. Arbeitsweise des gRPC Framework in einer Online Shopanwendung mit Produkt- und Bezahlservices, die über ein API interagieren

Mögliche Bedrohungen und Risiken für gRPC

Sicherheitslücken

gRPC unterstützt mehrere Programmiersprachen. Es gibt zwei Arten von Implementierungen, die innerhalb der unterstützten Sprachen verwendet werden: Implementierungen, die die Sprache selbst verwenden, und Wrapper um den von gRPC geschriebenen C-Code.  Diese Wrapper ermöglichen die Übersetzung von in verschiedenen unterstützten Sprachen geschriebenen Aufrufen in C-Aufrufe. Die Wahrscheinlichkeit, dass ein Entwickler eine Schwachstelle in das System einführt, ist hoch, da mehr Funktionen zusammen mit Memory-Managementfunktionen implementiert werden müssen. Auf der anderen Seite verringert die Verwendung von Sprachen wie Java oder Go, die bereits viele Funktionalitäten implementiert haben und sich auch um Fragen der Speicherverwaltung kümmern, die Wahrscheinlichkeit von potenziellen Fehlern. Insbesondere die Bedeutung der Auswahl geeigneter Sprachen könnte eine wichtige Rolle bei der Erhöhung der Sicherheit von Systemen spielen. Eine Übersicht im Originalbeitrag.

Unsichere Datenübertragungskanäle und Zugangsdaten dafür

Es ist sehr wahrscheinlich, dass bei einem Remote Procedure Call Daten zum Zielserver übertragen werden. Deshalb sollten Entwickler auf die Einrichtung sicherer Kanäle für die Datenübertragung achten. Dadurch werden nicht nur Datenlecks verhindert, sondern auch Man-in-the-Middle (MiTM)-Angriffe, über die Angreifer Servicedaten leaken könnten. Ein Data Leak kann Implementierungsdetails zum Service oder zur Infrastruktur öffentlich machen und somit weitere Angriffe ermöglichen oder zur Kompromittierung der Infrastruktur oder des Service führen.

Es liegt in der Verantwortung des Entwicklers, eine sichere Implementierung unter den verschiedenen Authentifizierungsmechanisem zu wählen. Das Kopieren und Einfügen von Patterns mit Schlüsselwörtern wie „InsecureChannelCredentials“ sollte vermieden werden. Eine Code-Suche auf Github.com nach dem Schlüsselwort „InsecureChannelCredentials“ und C++ (für gRPC üblich) gab über 11.000 Code-Ergebnisse. Wahrscheinlich sind diese vielen Suchvorgänge mit Demos und Beispielen verbunden. Dennoch gibt es immer noch einige Projekte, die diese verwenden.

Probleme bei der Procedure-Implementierung

Die grösste Schwachstellenfläche befindet sich innerhalb der Remote Procedure-Implementierung. Für nicht sehr erfahrene Entwickler empfiehlt es sich, Memory-sichere Sprachen zu verwenden, um Fehler in der Speicherverwaltung wie Buffer Overflows oder UaF-Fehler Used After Free) zu vermeiden, die zu einer Remote Code Execution führen. Doch durch diese Massnahme werden logische Fehler, die im Code auftauchen könnten, nicht vermieden. Dafür müssen Entwickler einen hohen Standard in Entwicklungsprozesse setzen, den Best Practices für sichere Softwareentwicklung folgen und proaktive Kontrollmechanismen installieren, gemäss den OWASP Top 10 Proactive Controls-Empfehlungen in den OWASP Secure Coding Practices.

Ein zentralisierter Authentifizierungsmechanismus für kritische Teile des Systems wird auch innerhalb isolierter Netzwerke oder privater Clouds dringend empfohlen. Im Fall von Fehlkonfigurationen kann die Ausnutzung von Schwachstellen innerhalb der Umgebung als Einstiegspunkt für einen unberechtigten Zugriff dienen, der den gRPC-Dienst erheblich beeinträchtigen könnte.

Die Fachleute raten auch davon ab, gRPC-Authentifizierungsdetails in Supply-Chain-Management-Systemen (SCM), insbesondere in öffentlich zugänglichen Systemen, hart zu codieren oder sie dort vorzuhalten. Sie sollten an einem sicheren Ort gespeichert und nur bei Bedarf abgerufen werden.

Denial-of-Service-Angriffe

gRPC lässt sich sowohl als „versteckter“ Messaging Service in einer isolierten Umgebung als auch als API-Ersatz in der Öffentlichkeit zugewandten REST API-Services einsetzen. Es gibt einen bereits bekannten und dennoch nicht gefixten Bug, der Service-Aufrufe ablehnt, bis der Service neu gestartet wird. Der Fehler wird angestossen, wenn eine höhere Zahl von Verbindungen in kurzer Zeit geöffnet werden. Weitere technische Details und Empfehlungen für einen Workaround bietet der Originalbeitrag.

Sicherheitsempfehlungen für gRPC

gRPC bietet einen umfassenden Leitfaden zu den unterstützten Authentifizierungsmechanismen, die mit dem Protokoll arbeiten, so etwa SSL/TLS mit und ohne Google Token-basierter Authentifizierung. Entwickler können auch ihr eigenes Authentifizierungssystem über das Credentials Plugin-API anschliessen.

Auch sollten Sicherheitslösungen zum Einsatz kommen, die Inhalte prüfen, sodass keine bösartige Payload das System über die Nachrichten, die vom Client auf den Server und umgekehrt gehen, infiltrieren kann. Die Lösungen müssen dafür sorgen, dass kritische Daten in Transit sicher sind, den Status eines Service im Auge behalten und Authentifizierung und Autorisierung durchsetzen.

Trend Micro-Lösungen

Die Service-Plattform Trend Micro Cloud One™ , die Trend Micro™ Hybrid Cloud Security unterstützt, ermöglicht es Entwicklern, Anwendungen auf ihre Art zu entwickeln und zu betreiben. Sie umfasst Mechanismen, die über vorhandene Infrastruktur, Tool-Ketten und Anforderungen hinweg arbeiten.

Application Security von Cloud One liefert diagnostische Einzelheiten zu Code-Schwachstellen sowie Schutz vor automatisierten Angriffen über Bedrohungen wie SQL Injection und RCE zur Laufzeit. Darüber hinaus gibt es eine vollständige Abdeckung und Berichterstattung über jede Angriffsinstanz sowie Einblicke in die Identität eines Angreifers und die Angriffsmethodik.

Cloud One bietet ausserdem die folgenden Cloud-Sicherheitstechnologien an:

Happy Birthday: 15 Jahre Zero Day Initiative (ZDI)

Originalbeitrag von Brian Gorenc

In diesem Jahr wird die ZDI 15 Jahre alt. Alles begann 2005, als 3Com ein neues Programm namens Zero Day Initiative ankündigte. Geplant war, Forscher, die bisher unbekannte Software-Schwachstellen („Zero-Day-Schwachstellen“) entdecken und sie verantwortungsbewusst offenlegen, finanziell zu belohnen. Die Informationen über die Schwachstelle sollten genutzt werden, um Kunden frühzeitig mithilfe von TippingPoint IPS (Intrusion Prevention System)-Filtern zu schützen, während die ZDI mit dem Hersteller des betroffenen Produkts zusammenarbeitete, um die Schwachstelle zu beheben. In dem Jahr veröffentlichte die ZDI gerade mal ein Advisory zu Symantec VERITAS NetBackup. Fünfzehn Jahre später sind es mehr als 7.500 Advisories, und die ZDI hat sich zum weltweit grössten herstellerunabhängigen Bug-Bounty-Programm entwickelt.

Von einer 15-jährigen Reise zu sprechen, ist eine Untertreibung. Es gab einige Höhen und Tiefen, aber das Programm ist stärker denn je und befindet sich auf Kurs zum bislang erfolgreichsten Jahr des Bestehens. Daher ist es der richtige Zeitpunkt, um einen Blick zurück auf einige der bemerkenswerteren Ereignisse zu werfen.

2005 – 2010

2006 kaufte die ZDI nur zwei Apple-Bugs, 2010 waren es bereits 52. Java-Bugs, insbesondere Sandbox Escapes waren zu der Zeit ebenfalls beliebt. Es fühlt sich etwas merkwürdig an, auf den Wechsel vom Kauf von Bugs in dem, was man einfach „Java“ nannte, solchen in „Sun Microsystems Java“ und schliesslich zu Bugs in „Oracle Java“ zurück zu blicken.

In dieser Zeitspanne fiel auch der erste Pwn2Own-Wettbewerb 2007. Damals galten Apple-Geräte als unüberwindbar. Doch scharfsinnige Sicherheitsforscher wussten es besser, und Dino Dai Zovi bewies dies und gewann ein MacBook sowie 10.000 $. Seither ist der Wettbewerb exponentiell gewachsen. Inzwischen gibt es drei verschiedene Wettbewerbe: Pwn2Own Vancouver, der sich auf Unternehmenssoftware konzentriert; Pwn2Own Tokio, der sich auf Verbrauchergeräte konzentriert und Pwn2Own Miami, der dieses Jahr mit Schwerpunkt auf ICS-SCADA-Produkte eingeführt wurde. Pwn2Own diente auch als „Coming-out“ für viele hochkarätige Forscher, die nach dem Gewinn des Wettbewerbs in verschiedenen prestigeträchtigen Teams und Projekten arbeiten.

2010 – 2015

Dies war eine Übergangszeit für das Programm, da 3Com zusammen mit ZDI von Hewlett-Packard gekauft und später als Teil von Hewlett Packard Enterprise abgespalten wurde. Die Kernprinzipien des Programms damals sind jedoch nach wie vor dieselben wie heute:

  • Fördern der verantwortungsvollen Offenlegung von Zero-Day-Schwachstellen gegenüber den betroffenen Anbietern.
  • Gerechte Anrechnung und Vergütung der teilnehmenden Forscher, einschliesslich jährlicher Boni für Forscher, die innerhalb des Programms besonders produktiv sind.
  • Produktanbieter in die Verantwortung nehmen, indem sie eine angemessene Frist für die Behebung gemeldeter Schwachstellen erhalten.
  • Schutz der Kunden und des Ökosystems.

Mittlerweile war das ZDI gross genug, um einen Einfluss auf das gesamte Ökosystem zu haben. Zu dieser Zeit entwickelte sich die Initiative zum weltgrössten herstellerunabhängigen Bug-Bounty-Programm — sie ist es heute immer noch. 2011 kam es zur ersten öffentlichen Zero-Day-Offenlegung, als ein Anbieter die Patch-Frist nicht einhielt. Im Laufe der Zeit trug die Verpflichtung der Hersteller zur Behebung von Schwachstellen dazu bei, ihre Reaktionszeit von mehr als 180 Tagen auf weniger als 120 zu senken. Obwohl die ZDI die Zeitspanne für die Offenlegung verkürzt hat, ist die Rate der Zero Day-Offenlegung relativ konstant geblieben.

Eine weitere grosse Veränderung war die Zunahme der Forschungsarbeit der vom ZDI-Programm beschäftigten Schwachstellenforscher. Infolge einer Vergrösserung des Teams konnten Mitglieder des ZDI auch ihre eigenen Bugs melden. Sie veröffentlichten zunehmend die Ergebnisse ihrer Arbeit und hielten immer häufiger Vorträge auf hochkarätigen Konferenzen wie Black Hat und DEFCON.

Die Vergrösserung half auch, einige Trends in der bösartigen Ausnutzung zu erkennen. Auch gab es einen Anstieg bei den Reports von Java-Bugs. Nachdem die Browser Click-to-Play implementierten, wurde die praktische Ausnutzung schwieriger. Es gab auch viele Bugs, die Use-After-Free (UAF)-Bedingungen im Internet Explorer missbrauchten, bis Microsoft ohne Aufhebens Isolated Heap und MemGC-Mechanismen einführte. ZDI-Forscher fanden dennoch eine Möglichkeit, diese Mechanismen auszuhebeln und erhielten dafür 125.000 $ von Microsoft. Interessanterweise beschloss Microsoft, nicht alle gemeldeten Bugs zu fixen, sodass ein Teil des Reports als öffentlich gemachter Zero Day endete. Die Forscher spendeten das Geld an verschiedene STEM (Science, Technology, Engineering, Mathematics)-Wohltätigkeitsvereine.

Die Bug-Bounty-Landschaft normalisierte sich und weitete sich aus. Anbieter wie Microsoft und Google starteten ihre eigenen Bounty-Programme. Es entstanden Bug-Bounty-Plattformen, die es Firmen wie Starbucks und Uber ermöglichten, selbst Belohnungen anzubieten. Die Idee der Crowdsourcing-Forschung wurde zum Mainstream. Nicht jedes Programm war erfolgreich, da einige Anbieter plötzlich erkannten, dass das Angebot von Geld für Bug-Reports dazu führt, dass man Bug-Reports erhält. Dadurch hatten einige Unternehmen Mühe, nach dem Start ihres Programms  zu reagieren. Es war definitiv eine Zeit des Wachstums und des Lernens in der gesamten Branche.

2010 erlebte Pwn2Own den ersten erfolgreichen Mobilgerät-Angriff, durchgeführt von Ralf-Philipp Weinmann und Vincenzo Iozzo gegen Apple iPhone 3GS. Anbieter begannen umfangreiche Patches kurz vor dem Wettbewerb zu veröffentlichen. Da die Regeln für alle Angriffe die „neueste Version“ vorschreiben, wurden die Teilnehmer oft kurz vor dem Wettbewerb „aus-gepatcht“. Das bedeutete auch, dass die ZDI sich beeilen musste, um die Ziele mit den neuesten Patches auf den neuesten Stand zu bringen. I2012 kam ein zweiter Wettbewerb – Mobile Pwn2Own – hinzu, der sich auf Telefone und Tablets konzentrierte

2015 – bis heute

2015 kaufte Trend Micro das HP TippingPoint IPS zusammen mit dem ZDI-Programm. Dies eröffnete der ZDI neue Möglichkeiten, da die durch das ZDI-Programm gewonnenen Erkenntnisse über Schwachstellen nun nicht nur der Verbesserung des TippingPoint IPS zugute kamen, sondern auch für andere Produkte innerhalb der Sicherheitslösungen von Trend Micro genutzt werden konnten. Die Zusammenarbeit des ZDI mit Trend Micro führte auch zu einem massiven Anstieg des Interesses an Schwachstellen in den Trend Micro-Produkten selbst. Die Trend Micro-Produktteams scheuten nicht davor zurück, die von unabhängigen ZDI-Forschern eingereichten Fehler zu beheben, und ein gezieltes Targeted Initiative Program nur für ausgewählte Trend Micro-Produkte entstand.

Vor 2015 gab es nur selten eine Adobe Reader-Bug-Meldung ausserhalb von Pwn2Own. In dem Jahr aber waren es mehr als 100. Viele dieser Berichte stammten von ZDI-Forschern. Insgesamt machen interne Funde etwa 20% aller Fälle pro Jahr aus. Auch Deserialisierungs-Bugs und ICS/SCADA-Schwachstellen nahmen stark zu. Home-Router entwickelten sich zu einem beliebten Ziel, da sie massenhaft kompromittiert werden können, um in Botnets und DDoS-Angriffen verwendet zu werden. Infolgedessen passte sich die ZDI an und begann, hardwarebezogene Reports zu akzeptieren, insbesondere solche, die sich auf IoT-Geräte beziehen.

Die Einführung des Wassenaar-Arrangements brachte einige Herausforderungen mit sich – insbesondere beim Kauf von Bug Reports aus den Mitgliedsländern.

2016 wurde beim Pwn2Own die Kategorie Virtualisierung eingeführt. Zum 10. Geburtstag des Wettbewerbs 2017 konnte die ZDI während der drei Tage 51 Zero-Days erwerben. 2019 ging die ZDI eine Partnerschaft mit Tesla ein, sodass Forscher das Infotainment-System des Autos zum Ziel machen könnten. ZDI-Forscher zeigten auch ihren eigenen Einbruch ins Infotainment-System. Auch die Teilnehmer haben sich im Laufe der Jahre verändert. Anfangs nahmen hauptsächlich einzelne Forscher und nur wenige Teams teil. Später waren es in der Mehrheit Teams, die von ihren Arbeitgebern gesponsert wurden.  In den letzten paar Jahren ist dieser Trend wieder rückläufig.

2018 erreichte die ZDI ihren Höchststand von 1.450 veröffentlichten Advisories, und dieses Jahr werden noch mehr. Tatsächlich ist die ZDI seit 13 Jahren als weltweit führende Organisation für Schwachstellenforschung anerkannt. Laut Omdia war das ZDI 2019 für mehr als die Hälfte aller gemessenen Offenlegungen von Schwachstellen verantwortlich, das ist mehr als jeder andere Anbieter.