Don't Train Evil – Keynote bei den Machine Learning Essentials 2020

Ethik und Sicherheit im Machine Learning

Heidelberg, 17.-19. Februar 2020

Machine Learning gewinnt Einfluss auf immer größere Bereiche unseres täglichen Arbeits- und Privatlebens. Man muss nicht die Angst vor der bösartigen AGI oder der Singularität teilen, um angesichts zunehmender Überwachung und der Diskussion um autonome Waffensysteme zu erkennen: Ohne eine gewisse möglichst frühzeitig und grundsätzlich ins Design einbezogene Sicherheit droht KI mehr Schaden als Nutzen zu bringen. Die Keynote wirft die grundlegenden Fragen auf, mit denen sich alle beschäftigen sollten, die an der Revolution mitbauen, und zeichnet ein Modell, welche Bedingungen für ML Security und Safety notwendig sind.

David Fuhr ist Principal Berater bei der HiSolutions AG in Berlin. Als Forschungsleiter IT-Security beschäftigt er sich mit den grundlegenden Fragen von Sicherheit und Safety in unserer immer weiter digitalisierten Welt sowie den Grenzgebieten zwischen Mathematik, Technik, Ökonomie und Psychologie.

https://ml-essentials.de/lecture.php?id=10729

When #Shitrix hits the Fan

Massenhafte Hacks via NetScaler

Reihenweise Unternehmen und Behörden fallen aktuell einer Lücke zum Opfer, die den besonders „schönen“ Spitznamen #Shitrix (offiziell CVE 2019-19781) erhalten hat. Benannt ist dieser nach dem amerikanischen Netzwerk-Ausrüster Citrix, der das Debakel durch einen Schusselfehler im weitverbreiteten Enterprise-Gateway ADC (Application Delivery Controller) ausgelöst hat – vielen auch bekannt unter dem Namen NetScaler. Bereits seit der ersten Januarhälfte erreichen die HiSolutions-Hotline immer neue Fälle, da teilweise Administratoren noch nichts von der Lücke gehört haben.

Ein erfolgreicher Angriff hat neben der Übernahme des Gateways selbst weiterhin zur Folge, dass nicht nur die klassischen Zugangsdaten wie SSH-Keys oder Klartext-Passwörter in Konfigurationsdateien als kompromittiert gelten müssen, sondern auch verschlüsselte LDAP-Passwörter in der NetScaler-Konfiguration, wodurch weitere Angriffe ins Netzwerk hinein möglich werden.

Zunächst war kein offizieller Patch erschienen, lediglich Workarounds, die nicht ganz trivial sind, nicht immer voll effektiv und nicht für alle Versionen funktionieren.

Das größte Problem bei #Shitrix ist – wenn nicht offensichtlich Folgeschäden wie Ransomware entstehen –, dass zunächst nicht klar ist, wie weit der Angriff gegangen ist. Allein die Analysen nehmen Zeit und Ressourcen in Anspruch. Nicht selten fahren Betroffene in der Zeit Teile ihrer Infrastruktur herunter, wie zuletzt mehrere Kommunen in Brandenburg.

Derweil scheinen sogenannte „NOTROBIN“-Robin-Hood-Hacker die Lücke auszunutzen, um sie zu schließen – leider nicht ohne vorher noch eine Backdoor zu installieren.

Hier ist eine Liste mit bekannten IOCs zu finden.

Um Systeme lediglich auf die Schwachstelle zu scannen, existiert ein Nmap-Skript.

MEDIEN:

Unser Kollege Manuel Atug hat sich dazu auch im Beitrag mit dem SWR zum Vorfall geäußert.

Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern? Manual Atug bei AG KRITIS.

UPDATE:

Ein paar erste Patches (nur für bestimmte Versionen) sind bereits erschienen.

UPDATE 2 (2020-01-27):

Nun sind die „finalen“ Patches erschienen.

SHIFT LEFT – Linksruck im Neuland?

Linksruck in der IT? Was soll das bedeuten? Gewerkschaften bei Amazon? Google-style Walkouts bei SAP? Mindestlohn für Consultants bei Accenture und Co.? Keineswegs! Der aktuell „trendende“ Kampfruf „Shift Left“ spielt an auf die Bewegung nach links im Entwicklungszyklus von Software oder anderen IT-Produkten, also im SDLC (Software Development Life Cycle). Es mag merkwürdig anmuten, in Bezug auf einen Kreis(lauf) von „links“ und „rechts“ zu sprechen. Gemeint ist eine Bewegung hin zu den Tätigkeiten, die in der Entwicklung früh vorgenommen werden sollten.

Ein Penetrationstest setzt spät – „rechts“ – an und zieht dementsprechend große Aufwände nach sich, wenn grundsätzliche Dinge zu reparieren sind. Früher – „weiter links“ – wirkt sichere Softwareentwicklung. Und idealerweise wird die Security bereits „ganz links“, also in der Definition von Sicherheitsanforderungen, berücksichtigt.

Die Idee ist alles andere als neu. Doch scheint sie sich momentan aus ihrem Schattendasein als Elefant im Raum langsam in Richtung rosa Kaninchen auf der Tanzfläche zu bewegen. Immer mehr Organisationen umarmen das Konzept des „Linksrucks“ und greifen dafür in nicht unerheblichem Maße in althergebrachte Arbeitsweisen und Rollenverständnisse ein.

Der Hauptgrund dürfte – wie so oft bei der Umwälzung gesellschaftlicher oder technischer Verhältnisse – in der Veränderung der Produktionsbedingungen selbst liegen. Im Wasserfallmodell konnte man ans Ende der eh um 80 % überzogenen Entwicklungszeit und -budgets auch noch einen Penetrationstest „dranklatschen“, dessen Empfehlungen dann im Zweifel nicht umgesetzt wurden. In agilen Sprints mit DevOps-Prozessen und Hunderten von Microservices in Tausenden von Containern, die von Dutzenden Teams entwickelt und verantwortet werden, ist dies nicht mehr möglich. Wohl oder übel muss die Security ebenfalls agiler und mithin deutlich schneller werden – und das geht nur, indem sie früh im Entwicklungsmodell beginnt. Google etwa tanzt das aktuell mit dem Konzept BeyondProd (siehe Lesetipps) eindrucksvoll vor.

Bitte nicht falsch verstehen: Der klassische Penetrationstest hat weiterhin seine Daseinsberechtigung und ist in vielen Situationen (Legacy, Brownfield, Compliance …) das geeignete Mittel, um Schwachstellen zu identifizieren. Er muss allerdings zukünftig zu einem ganzheitlichen SDL (Security Development Lifecycle) ergänzt werden.

https://www.heise.de/developer/artikel/Shift-Left-Secure-by-Design-und-agile-Entwicklung-4613935.html

BlueKeep of Death – Kommt der nächste Wurm?

Aktuell werden wieder Wetten angenommen, wann wir mit der nächsten wirklich großen Infektionswelle rechnen können. „BlueKeep“ – so der umgangssprachliche Name für die Schwachstelle CVE-2019-0708 vom Typ „nicht authentifizierte Remote Code Execution“ unter Windows 7, Windows Server 2008 und Windows Server 2008 R2 – hat Microsoft bereits am 14. Mai gepatcht. Aber noch, das war nicht anders zu erwarten, sind viele Systeme weltweit verwundbar. In den letzten vier Wochen haben Angreifer nun mit der systematischen Ausnutzung begonnen. Bisher produzieren sie meist Abstürze (Blue Screen). Außerdem scheinen die Angriffe bislang noch größtenteils manuell, also per Clicki-Bunti-Oberfläche oder Metasploit-Modul, durchgeführt zu werden und sind dementsprechend langsam und an übliche Arbeitszeiten gebunden. Das könnte sich jedoch ändern, sobald stabilere Exploits entwickelt werden, welche automatisiert ausgeführt werden können.

Möglicherweise könnte dann der nächste große Wurm drohen, der ähnlich wie WannaCry innerhalb von Minuten Netzwerke auf der ganzen Welt befällt. Für BlueKeep kommen zwar nicht ganz so viele Ziele infrage – im Gegensatz zu WannaCry, welcher das verwundbare SMBv1-Protokoll auf einer großen Anzahl von Windows Server- und Clientsystemen ausnutzte, ist BlueKeep eine Lücke in den RDS (Remote Desktop Services), welche auf Clientbetriebssystemen standardmäßig deaktiviert sind. Allerdings stellen natürlich gerade die Server häufig Assets mit hohem Wert dar, zumal wenn sie intern mit vielen weiteren Systemen vernetzt sind. Die aktuellen Angriffe versuchen momentan nur, mittelmäßig schädliche Crypto-Miner unterzubringen. Aber auch das wird sich wohl ändern, sobald es sich von der Masse lohnt.

Das von den RDS verwendete RDP-Protokoll sollte niemals ungeschützt im Internet erreichbar sein. Scans des Internets, wie sie auch die Angreifer aktuell vornehmen, zeigen jedoch, dass dies an vielen Stellen trotzdem der Fall ist. Insbesondere bei Industrieanlagen wird RDP nicht selten zur Fernwartung eingesetzt.

Es mag sein, dass – anders als bei WannaCry – ein Wurm am Ende gar nicht notwendig ist. Vielleicht genügt es (aus Angreifersicht), mit einem stabilen Exploit das Internet zu scannen und alle verwundbaren Systeme direkt anzugreifen. Höchste Zeit also, nicht nur die Patches einzuspielen, sondern die eigene (RDP-)Exponierung im Internet zu überprüfen und zu reduzieren. Zumal mit DejaBlue im August schon die nächste RDP-Schwachstelle entdeckt wurde, die weitere, auch neuere Windows-Versionen betraf.

https://www.microsoft.com/security/blog/2019/11/07/the-new-cve-2019-0708-rdp-exploit-attacks-explained/

Sie sind unter uns – Cyber-Einheiten in der EU

Einige Beobachter haben es länger schon vermutet, nun ist es Gewissheit: Staatliche Akteure haben begonnen, dezentrale Cyber-Einheiten in Europa zu stationieren. Nun wurde bekannt, dass tschechische Sicherheitsbehörden bereits 2018 eine Gruppe ausgehoben haben, die unter dem Deckmantel des Handels mit IT über Jahre verdeckte Cyberoperationen auf dem Boden der Tschechischen Republik bzw. von diesem aus durchgeführt hatte. Wie die Analyse des renommierten OPSEC- und Cyberspionageexperten „The Gruc“ – kaum jemand kennt den Klarnamen des Südafrikaners – zeigt, wurden die russischstämmigen Personen, die teilweise über tschechische Pässe verfügten, quasi als „freie Mitarbeiter“ des russischen Inlandsgeheimdienstes FSB geführt, von diplomatischen Fahrzeugen aus mit Technik versorgt und vermutlich auch kontrolliert.

Das Rezept „People. Ideas. Hardware. In that order.“ des Militärstrategen John Boyd ist also bereits von der Russischen Föderation – und anzunehmenderweise weiteren Akteuren – auf eine neue Ebene gehoben worden. Zwar ist Geolokation für Cyberangriffe weniger relevant als für andere Waffengattungen, Staaten können jedoch auf diese Weise kostengünstig und risikoarm ihre Cyber-Zweitschlagskapazität hochfahren und geografisch verteilen.

Neu ist also: Akteure können auch „Auftragnehmer“ in anderen Ländern sein. TTPs (Tactics, Techniques and Procedures, anhand derer Angreifergruppen teilweise erkannt und ihre Aktionen u. U. vorausgesagt werden können) passen dann besonders schlecht zum üblichen Fußabdruck des Auftraggebers. Sie können sich in relativ kurzer Zeit frei bewegen und die logistischen Anforderungen sind extrem niedrig. Zeit für die Verteidiger, sich hierauf einzustellen.

https://gru.gq/2019/10/24/fsb-deploys-cyber-units-inside-europe-for-years/

Die Kehrseite der Monokultur? Zeroday-Inflation bei iOS

Tief sind die Gräben zwischen Apple-Fanboys/-girls und Android-Jüngern schon immer gewesen. Speziell in Bezug auf Security hatten jedoch die Geräte aus Cupertino bei der Mehrheit der Experten die Nase vorn. Klar, der „Walled Garden“ von Apple hat Nachteile, ebenso das Quasimonopol auf den Geräteverkauf, aber dafür ist das Ökosystem leichter „sauber“ zu halten als Googles Zoo von Versionen auf Geräten von zig Herstellern. Auch wenn die Android-Security in letzter Zeit deutlich aufgeholt hat: Sollte es besonders sicher sein (aber nicht allzu exotisch), waren für viele Organisationen iPhone und iPad die Smart Devices der Wahl – zumal beim Thema Datenschutz aufgrund der unterschiedlichen Geschäftsmodelle die Krake Google deutlich schlechter abschneidet – zumindest heute noch. iPhones galten vielen als kaum zu hacken, seltene Zeroday-Exploits waren Millionen wert.

Das Bild hat sich in den letzten Wochen etwas geändert. Nachdem ausgerechnet Google aufgefallen war, dass eine Reihe von Seiten, die besonders von der politisch unterdrückten Gruppe der Uiguren in China frequentiert werden, ungewöhnliche Malware enthielt, nahmen sich Mitglieder von Googles Project Zero diese einmal genauer vor – und wurden spektakulär fündig. Nicht ein hochwertiger Zeroday wurde da auf eine relativ kleine Gruppe von Dissidenten losgelassen, sondern gleich fünf verschiedene, meisterartig gemachte, die auf dem grauen Markt jeweils Millionenbeträge erzielt haben dürften.

Es scheint also ein Akteur am Werk, bei dem Geld eine geringe Rolle spielt. Und scheinbar sind auch beim Qualitätsprodukt iOS kritische Schwachstellen doch leichter zu finden als bisher gedacht. Das verändert das ganze ökonomische Denken über Bedrohungen – und lässt Google vergleichsweise etwas besser dastehen, obwohl später herauskam, dass Android-Exploits ebenfalls im Einsatz waren.

Den Preisen für iOS-Zerodays hat das Ganze übrigens keinen Abbruch getan. Allerdings haben führende Schwachstellenverkäufer ihre Einkaufspreise für Android-Zerodays angehoben, sodass diese inzwischen über den Preisen für iOS-Exploits liegen. Denn es ist schwieriger, einen Exploit zu finden bzw. zu bauen, der über eine große Bandbreite von Android-Versionen und Varianten verlässlich funktioniert. Apple wird sich überlegen müssen, wie die hier zum Vorschein kommende Kehrseite der leichter managebaren Monokultur eingehegt werden kann.

https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html

Proof of Does Not Work? E-Voting unsicher – „trotz“ Blockchain

Bei demnächst anstehenden Wahlen zum Moskauer Stadtparlament soll ein neues System zum Einsatz kommen, welches eine Wahlbeteiligung via Privatrechner und Smartphone erlaubt. Die Software, welche als erste ihrer Art produktiv eine Blockchain(!) einsetzt, um die Integrität der Daten zu sichern, wurde nun von Wissenschaftlern des französischen nationalen Forschungsinstituts für digitale Wissenschaften INRIA auseinandergenommen. Eine kritische Schwachstelle in der eingesetzten Kryptographie erlaubt es jedem, der an eine Kopie der verschlüsselten Daten gelangt, die Wahlentscheidungen aller teilnehmenden Bürger mit einem handelsüblichen Rechner innerhalb von 20 Minuten zu entschlüsseln. Schuld ist eine schlechte Parameterwahl – zu kurze Schlüssel – bei der verwendeten Variante des El-Gamal-Verschlüsselungsschemas.

Noch ist nicht klar, wie leicht es ist, ausreichend Daten aus der in Teilen genutzten öffentlichen Ethereum-Blockchain zu gewinnen oder aber aus Komponenten des Systems selbst zu stehlen. Die Forschung wirft jedoch grundlegende Fragen auf, die sich alle E-Voting-Systeme, wie sie auch im Westen immer wieder diskutiert werden, stellen lassen müssen:

Selbst wenn „nur“ das Wahlgeheimnis in Gefahr ist, also keine direkte Manipulation des Wahlergebnisses über Schwachstellen möglich wäre – was angesichts des eklatanten handwerklichen Fehlers sowie grundsätzlicher Überlegungen der Grenzen der Security unwahrscheinlich erscheint: Wie hoch ist das Interesse politischer Akteure, über die gewonnenen Informationen mindestens ihren Wahlkampf zu perfektionieren – oder aber sogar politischen Druck auszuüben?

Und vor allem: Wie schwer wiegt der Effizienz- und Coolheits-Gewinn elektronischer Wahlen gegenüber den Risiken? Digitale Wahlen sind noch viel schwerer zu beobachten und zu auditieren als solche auf Papier. Die Wahlbeteiligung ließe sich auch mit anderen Mitteln steigern, wenn dies ernsthaft gewünscht ist.

In einem gewissen Sinn lässt Moskau ein großes Experiment laufen, wenn am 8. September für 12 Stunden das Blockchain-Online-E-Voting freigeschaltet wird. Wir sollten es sehr genau studieren.

https://www.zdnet.com/article/moscows-blockchain-voting-system-cracked-a-month-before-election/

Alles ist verbunden – Multiple Single Points of Failure

Von großen – im Sinn von weitreichenden – Cloudausfällen war an dieser Stelle und in den Weiten des Internets in letzter Zeit häufig zu hören. Denn je mehr der Markt reift (sprich, je mehr Unternehmen relevante Teile ihrer Infrastruktur in die Wolke verlagern) und je mehr sich der Kuchen des Cloud-Geschäfts im Wesentlichen auf eine Handvoll großer Cloudanbieter und ein paar Dutzend Security-Services-Anbieter verteilt, desto größer kann der Impact eines einzelnen Zwischenfalls sein. Nun war Cloudflare an der Reihe, dies am eigenen Astralleib zu erfahren: Ein harmlos erscheinender regulärer Ausdruck, der weltweit bösartiges „Inline“-JavaScript herausfiltern sollte, brachte die Prozessorlast sämtlicher Filter auf 100 %, sodass bei den vielen Cloudflare-Kunden für eine halbe Stunde nichts mehr ging. Dann war das Problem erkannt und die Funktion gekillt – im Gegensatz zu Google im Mai konnte Cloudflare die Managementinterfaces nämlich ohne Probleme erreichen. Hatte der DDoS- und Websecurity-Spezialist aus Kalifornien schlampig gearbeitet? Ja und nein, die neue Funktion war zwar per Knopfdruck sofort weltweit, aber immerhin nur im Testmodus ausgespielt worden, der nichts hätte blocken sollen. <Ironie>Dass die Komplexitätstheorie bei den seit Jahrzehnten als mögliche Ressourcenmonster verrufenen RegExen einen Strich durch die Rechnung machen würde, konnte ja niemand ahnen … </Ironie>

In einer überraschenden Fügung des Schicksals hätte der Ausfall beinahe ein längst in eine dunkle Flasche verbanntes Monster wiederbelebt: 2017 hatte der junge Malware-Forscher Marcus “MalwareTech” Hutchins in einem heldenhaften Einsatz (siehe Lesetipps am Ende dieses Digests) per „Sinkhole“, also eine geistesgegenwärtig reservierte Domain, der Welt den größten Teil der ersten WannaCry-Angriffswelle erspart. Diese Sinkhole-Domain erhält bis heute riesige Mengen an Anfragen von schlummernden WannaCry-Infektionen, die nachfragen, wann sie denn nun endlich losschlagen sollen.Später wurde ebendiese pro bono (und natürlich für den Werbeeffekt) von Cloudflare übernommen – und war seither nie down. Um ein Haar hätte der Cloudflare-Ausfall also ein Heer von Schläfern erweckt, die Schäden von hunderten Millionen hätten verursachen können. Glücklicherweise genügte die immerhin noch ausgelieferte Fehlermeldung (HTTP-Code 502), um die Viren zu beruhigen. Sie schlummern also weiter auf unseren ungepatchten Systemen und laben sich an unseren technischen Altlasten …

Paging Münchhausen – Cloud braucht Cloud

Am 2. Juni standen weite Teile der Google Cloud für bis zu vier Stunden still. Dass Google damit die Jahres-SLAs gerissen hat, ist nur ein Teil des Problems, schließlich kamen und kommen Downtimes auch in selbstbetriebener IT immer wieder vor. Bedenklich ist vielmehr, dass es zu einem derart langen länderübergreifenden Ausfall kommen konnte, obwohl Google derart viel in Redundanz, Notfallplanung und Desaster Recovery investiert. Und zwar technisch wie konzeptionell. Nach ersterem Maßstab hat sich der Betreiber nicht viel vorzuwerfen, denn der Root-Cause war eine schwer vorauszusehende Interaktion drei verschiedener Bugs. Das Problem war schnell erkannt, verstanden und die Lösung schnell entworfen.

Allerdings gibt es zwei große Lessons Learned hier (für Google wie für die Kunden der großen Cloudanbieter): Erstens, die komplexen internen Abhängigkeiten der Gesamtsysteme, die Cloud-Dienste/-Rechenzentren/-Angebote darstellen, sind noch nicht ausreichend verstanden. Denn erst beim Incident-Handling fiel auf, dass man zur Behebung des Problems die, *tada*, Google Cloud benötigt, welche ja gerade nicht verfügbar war. Es fehlt also noch die Fähigkeit eines Baron Münchhausen, sich am eigenen Schopf aus dem Sumpf zu ziehen, sogenanntes Bootstrapping, im Energiesektor als Schwarzstartfähigkeit bekannt. Eine solche vorrätig zu halten, kostet Geld, was dem Kostendruck in der Cloud zuwiderläuft.

Das zweite Thema ist noch eine Ebene prinzipieller: Die großen Kosten- und Effizienzvorteile erzielt man im Cloud-Computing durch weitgehende Automatisierung – und die braucht als Basis Mono- oder zumindest Oligokulturen. Wie in der industriellen Landwirtschaft steigt mit der Effizienz hierbei auch das Risiko, dass ein einzelner Schädling/eine einzelne Schwachstelle/Bug/Fehlkonfiguration ganze Landstriche verwüsten und Hungersnöte auslösen kann. Meist wird man dies mittels viel Chemie unter Kontrolle halten können – was aber wieder nur das Risiko konzentriert und vertagt.

Sicher ist: Das dicke Ende kommt noch – und wir tun uns auf Dauer keinen Gefallen, wenn wir die Auseinandersetzung damit einfach nur in die Zukunft verschieben.

Zum Thema Cloud Security empfehle ich unseren aktuellen Webcast „Wege in die Cloud – aber sicher!“

Wild Thing, You Make My Heart Sing: 0days „in the wild“

Googles Project Zero (GP0) verfolgt seit der Gründung vor fünf Jahren intensiv die Entwicklungen und Entdeckungsprozesse im Bereich Schwachstellen. Das erklärte Ziel der Gruppe ist die Bekämpfung von „Zero Days“: Schwachstellen, die bekannt werden, ohne dass für sie bereits ein Patch besteht. Daher sind diejenigen Fälle von besonderem Interesse, bei denen Angreifer es geschafft haben, 0days „in the wild“, in freier Wildbahn tatsächlich auszunutzen. Diese Liste – quasi des eigenen „Scheiterns“ bzw. der eigenen Unvollkommenheit – hat GP0 nun veröffentlicht, mit allen „in the wild“ ausgenutzten 0days seit 2014. Soweit bekannt natürlich; die Dunkelziffer wäre hier zweifellos noch interessanter. Auffällig ist, dass die Anzahl der jährlichen Einträge seit 2015 kontinuierlich zurückgeht – bis auf 2019, wo wir mit 10 Einträgen schon jetzt fast auf dem Jahresniveau von 2018 sind. Die Kategorisierung der Schwachstellen wiederum deutet auf ein Versagen der IT-Branche insgesamt hin: Memory Corruption, die zusammen mit Use-after-Free den Löwenanteil der Exploits ermöglicht, sollte heutzutage nicht mehr vorkommen … eigentlich.

https://googleprojectzero.blogspot.com/p/0day.html