Kategorie: Themen

Schematische Darstellung Decryption Oracle
Kryptographie

Von Decryption und Signing Oracles: Covert-Content-Angriffe auf E-Mail

Dieser Blog-Beitrag ist eine Zusammenfassung der Untersuchungen, welche von der Autorin im Rahmen einer Abschlussarbeit für den Studiengang Informatik/IT-Sicherheit durchgeführt wurden.

Mit der Entwicklung der Netzwerktechnologie ist die E-Mail zu einem unverzichtbaren Mittel für die tägliche Kommunikation geworden. Laut Untersuchungen der Radicati Group nutzten 2019 bereits über die Hälfte der Weltbevölkerung E-Mails. Viele sensible Informationen werden so ausgetauscht. Im geschäftlichen Kontext können das beispielsweise Liefervereinbarungen, Verträge verschiedenster Art oder vertrauliche Korrespondenz mit Kunden oder Geschäftspartnern sein. Im privaten Umfeld sind zum Beispiel personenbezogene Informationen, vertrauliche Korrespondenzen etc. nicht minder interessant für Internetkriminelle.

E-Mail-Sicherheit

E-Mail-Verschlüsselung und digitale E-Mail-Signatur schaffen im Idealfall Sicherheit für die Nutzer. So ist eine digitale E-Mail-Signatur mit einer Unterschrift im realen Leben vergleichbar. Durch das digitale Signieren einer E-Mail kann der Absender eindeutig identifiziert werden. Außerdem kann die Integrität der Nachricht sichergestellt werden. Das bedeutet, dass der Empfänger erkennen kann, ob die E-Mail unterwegs verändert wurde. Das Versenden einer E-Mail ist mit dem Verschicken einer Postkarte in der anlogen Welt vergleichbar. Die Postkarte wird in den Briefkasten geworfen, der Briefträger holt sie dort ab, und über verschiedene Stationen wird sie schließlich dem Empfänger zugestellt. Jeder, der an der Zustellung beteiligt ist, kann die Postkarte lesen. Beim Versand einer E-Mail ist es ähnlich. Standardmäßig werden E-Mails unverschlüsselt übertragen. Bis sie allerdings beim Empfänger zugestellt werden können, passieren sie viele verschiedene Mailserver und andere Netzwerksysteme. Jeder kann die unverschlüsselte E-Mail abfangen, zwischenspeichern oder mitlesen.

What’s up Johnny?

In 2019 stellten Müller et al. [1] in ihrer Veröffentlichung „Re: What’s up Johnny?“ die sogenannten Covert-Content-Angriffe auf E-Mail Verschlüsselungen und E-Mail Signaturen vor. Die Autoren zeigen, dass die Schutzziele Vertraulichkeit, Authentizität und Integrität einer E-Mail bei der Nutzung bestimmter E-Mail-Clients verletzt werden können.

Die Anfälligkeit der E-Mail Kommunikation in Bezug auf die Gewährleistung der Schutzziele wird durch die Angriffe belegt. Es sind verschiedene Angriffszenarien denkbar:

  1. Übertragung falscher Daten
    1. Impersonation
    2. Manipulation von Informationen
    3. Phishing
    4. Social Engineering
  2. Unbefugter Zugriff auf Daten
    1. Wirtschaftsspionage
    2. Verletzung der Privatsphäre

Die Covert-Content-Angriffe nutzen einerseits die Eigenschaften des MIME-Standards und andererseits HTML/CSS, um den Nutzer zu täuschen. Als Backchannel wird die Antwort-Funktion des E-Mail-Clients genutzt.

Es wird dabei zwischen zwei Angriffskategorien unterschieden: Decryption Oracle und Signing Oracle.

Decryption Oracle

Das Ziel des Angriffs im Sinne des Decryption Oracle ist es, den entschlüsselten Klartext über den Backchannel unbemerkt zu extrahieren. Müller et al. beschreiben, wie es einem Angreifer gelingt, (abgefangenen) Ciphertext in einer harmlosen E-Mail an das Opfer zu verstecken. Nutzt das Opfer die Antwort-Funktion des E-Mail-Clients wird es zum „Decryption Oracle“ und sendet unbewusst den versteckten, jedoch nun entschlüsselten Klartext an den Angreifer zurück.

Das Prinzip des Angriffs wird in Abbildung 1 dargestellt. Die Voraussetzung ist, dass der Angreifer Zugang zu der verschlüsselten Kommunikation zweier Parteien. Hierfür gibt es verschiedene Szenarien. Beispielsweise hat der Angreifer aufgrund eines schwachen, leicht zu erratenen Passworts, Zugang zu dem E-Mail-Konto auf dem E-Mail-Server. Eine weitere Möglichkeit ist, dass der Angreifer die verschlüsselte E-Mail mitliest und speichert, wenn der Nutzer diese über eine unverschlüsselte Verbindung vom Mail-Server abruft.

Abbildung 1: Covert-Content-Angriff gegen E-Mail-Verschlüsselung (Decryption Oracle)

Der Angreifer kann die verschlüsselten E-Mails jedoch nicht selbst entschlüsseln, denn er ist nicht im Besitz des privaten Schlüssels. Daher sendet er eine manipulierte E-Mail an einen der beiden Original-Kommunikationspartner. Dabei ist es unerheblich, ob es sich dabei um den ursprünglichen Sender oder Empfänger der E-Mail handelt. Denn die Verschlüsselung der E-Mail erfolgt beim Sender sowohl mit seinem eigenen öffentlichen Schlüssel als auch mit dem öffentlichen Schlüssel des Empfängers. Wie Abbildung 1 zeigt, besteht die manipulierte E-Mail aus zwei Teilen. Der erste Teil ist eine unverfängliche Nachricht, die das das Opfer zu einer direkten Antwort animieren soll. Um den Angriff erfolgreich durchführen zu können, ist der zweite Teil der Nachricht encω(m) für das Opfer unsichtbar. Antwortet das Opfer auf diese manipulierte E-Mail, dann wird der entschlüsselte Klartext m, als unsichtbarer Bestandteil der E-Mail zurück an den Angreifer gesendet.

Signing Oracle

Die zweite Angriffs-Kategorie verfolgt das Ziel, eine gültig signierte E-Mail durch den vom Opfer genutzten E-Mail-Client, welcher als Signing Oracle fungiert, zu erhalten. Abbildung 2 stellt das Prinzip des Covert-Content-Angriffs für das Signing Oracle dar. Die manipulierte E-Mail besteht hierbei wieder aus zwei Textteilen. Der erste, sichtbare und unverfängliche Teil, der zum Antworten animieren soll, und der zweite, versteckte Teil der Nachricht, der für weiterführende Angriffe genutzt werden soll. Im Kontext einer harmlos erscheinenden E-Mail an das Opfer wird dieser zweite Textteil mittels CSS-Conditional-Rules versteckt. So kann der Angreifer beeinflussen, dass die E-Mail je nach E-Mail-Client unterschiedlichen Text anzeigt. Da die digitale Signatur für die vollständige originale E-Mail gültig ist, kann die E-Mail durch den Angreifer für weitere Angriffe missbraucht werden. Beispielsweise kann der Angreifer sich per E-Mail als vertrauenswürdiges Mitglied des Unternehmens ausgeben, um dringende Überweisungen von ahnungslosen Mitarbeitern zu veranlassen.

Abbildung 2: Covert-Content-Angriff gegen E-Mail-Signatur (Signing Oracle)

Re-Evaluation

Seit der Durchführung der Tests sind mittlerweile ca. zwei Jahre vergangen. Daher wurden nun im Rahmen einer Re-Evaluation folgende Fragen beantwortet:

  1. Sind die Covert-Content-Angriffe auf die untersuchten Email-Clients weiterhin möglich?
  2. Falls nein, können die Gegenmaßnahmen durch Erweiterung der Angriffe umgangen werden?

Es wurden 22 E-Mail-Clients in die Untersuchung einbezogen. Davon unterstützen 19 Clients PGP-Verschlüsselung und -Signatur, 19 Clients S/MIME-Signatur und 18 Clients S/MIME-Verschlüsselung. Die Angriffe funktionieren bei vielen der getesteten E-Mail-Clients weiterhin. Die Re-Evaluation für die Signing Oracle-Schwachstelle ergab keine nennenswerte Veränderung im Vergleich zur Evaluation von Müller et al. [1]. Sämtliche Testcases der Evaluation als auch der Re-Evaluation sind auf Github veröffentlicht und können dort heruntergeladen werden [2].

Ergebnisse

Es sind 37% der S/MIME- und 32% der PGP-fähigen E-Mail-Clients als Signing Oracle angreifbar. Bei Müller et al. waren es 41% bzw. 32% der entsprechenden E-Mail-Clients. In Bezug auf die Decryption Oracle-Schwachstelle ist von Herstellerseite am meisten nachgebessert worden. Es existieren zwar nach wie vor E-Mail-Clients, bei denen es möglich ist, Klartext zu extrahieren, wenngleich deren Zahl um die Hälfte zurückgegangen ist. Insbesondere der Angriff für den Testcase 01-reply-mix-css.eml, der zum Ziel hat, den entschlüsselten Klartext vollständig zu verstecken, schlug bei allen E-Mail-Clients fehl. Die Hersteller haben teilweise die von Müller et al. vorgeschlagenen Gegenmaßnahmen gegen die Covert-Content-Angriffe umgesetzt. Die vollständige Ergebnisübersicht ist in der Tabelle 1 dargestellt.

Abschließend wurden verschiedene Modifikationen der Angriffe vorgenommen. War es im Rahmen der Re-Evaluation nicht mehr möglich, den Klartext vollständig zu verstecken, konnte dies durch eine Modifikation des Testcase 01-reply-mix-css.eml wieder realisiert werden. So ist es möglich, bei drei der S/MIME-fähigen und bei einem der PGP-fähigen Clients den entschlüsselten Klartext für den Nutzer unsichtbar zu gestalten. Dafür werden CSS-Regeln verwendet. HTML und CSS unterliegen einer ständigen Weiterentwicklung durch das World Wide Web Consortium (W3C). Es gibt immer noch E-Mail-Clients, die auch in der Antwort-E-Mail HTML/CSS unterstützen. Dies ist auch eine der Eigenschaften, die durch die reevaluierten Angriffe ausgenutzt wird. Daher ist es eine Frage der Zeit, bis neue Modifikationen, Schwachstellen in Bezug auf die Covert-Content-Angriffe aufzeigen.

Der Nutzer hat viele verschiedene Möglichkeiten, den Client nach seinen Wünschen und Bedürfnissen zu konfigurieren. Die E-Mail-Clients wurden in den Standard-Einstellungen getestet, aber die Re-Evaluation hat gezeigt, dass das Prinzip der Covert-Content-Angriffe, die Antwort-Funktion des E-Mail-Clients als Backchannel zu nutzen, nach wie vor funktioniert. Es entsteht der Eindruck, dass die Hersteller die Verantwortung für eine sichere E-Mail-Kommunikation auf den Nutzer abschieben. Und das ist nicht im Sinne der Sicherheit. Cranor und Buchler [3] stellten bereits fest, dass Benutzer nicht gewillt sind, aktiv die Einzelheiten der Sicherheitsmerkmale zu verwalten. Die Systemdesigner sind in der Pflicht, sich im Vorfeld über die Entscheidungsanforderungen Gedanken zu machen, welche an die Benutzer gestellt werden. Fast jeder Dritte der getesteten PGP-fähigen und gut jeder Fünfte der S/MIME-fähigen Clients ist als Decryption Oracle angreifbar. Sicherheit und Benutzerfreundlichkeit werden traditionell als Kompromiss betrachtet. Nach Schneier [4] führt genau dieses „Entweder-Oder“-Denken oft zu Systemen, die weder benutzbar noch sicher sind. Die Betrachtung, ob ein sicherer E-Mail-Client weniger funktional und ein flexibler und leistungsfähiger E-Mail-Client weniger sicher ist, lassen Raum für weitere Forschung.

Tabelle 1: Re-Evaluation Covert-Content-Angriffe

Quellen

[1] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Sebastian Schinzel, und Jörg Schwenk. Re:What’s Up Johnny?: Covert Content Attacks on Email End-to-End Encryption. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 11464 LNCS:24–42, 2019. ISSN 16113349.

[2] https://github.com/RUB-NDS/Covert-Content-Attacks

[3] Lorrie Faith Cranor und Norbou Buchler. Better Together: Usability and Security Go Hand in Hand. IEEE Security Privacy, 12(6):89–93, nov 2014. ISSN 1558-4046.

[4] Bruce Schneier. Stop Trying to Fix the User. IEEE Security & Privacy, 14(05):96, 2016. ISSN 1558-4046. URL https://doi.org/10.1109/MSP.2016.101.

Kritis

Umsetzung des § 8a BSIG in der Praxis

Hilfe für die Bevölkerung oder nur ein Papier-Tiger? Eine Reise zwischen Nachweiserbringungen, Zertifizierungen und dem wirklichen Leben.

Von Daniel Jedecke, Senior Expert, HiSolutions AG.

Kritische Infrastrukturen sind essentiell für unsere Gesellschaft. Daher sollte die Sicherheit der IT ein wichtiges Augenmerk sein. Durch das IT-Sicherheitsgesetz und den § 8a BSIG wurden hierfür die Weichen gestellt. Jedoch ist für viele Unternehmen das Thema IT-Sicherheit neu und die Umsetzung scheitert oft schon am Verständnis für die neuen Anforderungen. Hilft ein schnell eingeführtes ISMS wirklich oder sollte das Thema nachhaltiger angegangen werden?

Oft wurde uns gesagt: „Wir wissen natürlich, wie wir unsere Dienstleistung anbieten müssen, aber IT-Sicherheit? Das ist nicht unser Kernthema“. Das ist vollkommen klar; ein Bäcker wird auch nicht einfach anfangen, Kupplungen zu entwickeln und zu verkaufen.

Zunehmende Digitalisierung

In Zeiten der voranschreitenden Digitalisierung unserer Gesellschaft eröffnen sich auch immer weitere Angriffsflächen. Musste man vor Jahren noch Banken überfallen, um an Geld heranzukommen, so reicht heute der Überfall auf die IT, um sich das Geld bequem am Geldautomaten abzuheben. Dabei lässt sich dann ein sogenannter Cash-Out direkt mit einer manipulierten Chipkarte erzeugen.

Immer neue Cyber-Angriffe führen dazu, dass Angriffe auf Unternehmen nicht mehr als Ausnahme, sondern als Regel gesehen werden. So werden, je nach Studie, etwa 45% der Unternehmen regelmäßig angegriffen. „Von 2013 bis 2017 hat sich die Lage der Cybersicherheit dramatisch verschlechtert. Während die Durchdringung aller Lebensbereiche mit digitaler Technologie immer schneller voranschreitet, ist die Qualität der Technologie in der Fläche nicht besser geworden“[1].

Kritische Infrastrukturen sind essentiell für unsere Gesellschaft. So gibt es europaweite Bestrebungen, diese Infrastrukturen zu schützen. Die EU hat hierzu die Direktive 2008/114/EC herausgegeben, um in einem ersten Schritt die kritischen Infrastrukturen zu definieren und Schutzmaßnahmen einzufordern.

Beispiel Stromversorgung

Am Beispiel der Stromversorgung lässt sich gut feststellen, wie sich diese im Laufe der Zeit angepasst hat. Anfang des 19. Jahrhunderts war die Abwesenheit von Strom noch an der Tagesordnung. Selbst vor 40 Jahren noch gehörten kleinere Stromausfälle zum Alltag und waren von der Gesellschaft akzeptiert. Durch die zunehmende Industrialisierung und die Vernetzung von Systemen entstanden Kopplungen. Eine Kopplung bedeutet, „dass es zwischen zwei miteinander verbundenen Teilen kein Spiel, keine Pufferzone oder Elastizität gibt“[2]. War früher der Ausfall einer Telefonleitung noch vertretbar, so kann dies heutzutage zu einem kritischen Zustand führen, da wichtige Informationen nicht zwischen zwei Standorten übertragen werden können.

Die Bevölkerung verlernt mehr und mehr, den Ausfall von kritischen Infrastrukturen zu kompensieren. „Steigen die Auswirkungen, die durch Stromausfälle hervorgerufen werden, kann dies zweierlei bedeuten: zum einen eine wachsende Abhängigkeit vom Strom, zum anderen eine sich relational verringernde Kompensationskompetenz. Beides scheint in zunehmendem Maße gegeben.“[3]. Die beschriebene Kompensationskompetenz verringert sich durch die Digitalisierung immer weiter. Während bei älteren Bürgern in Deutschland durch die Nachkriegszeit noch Erfahrungen mit Mangelsituationen vorhanden sind, fehlen den meisten Menschen in Deutschland diese Kenntnisse, da sie selten oder nie mit Mangelsituationen infolge kriegerischer Auseinandersetzungen oder Katastrophen in Berührung gekommen sind. So können Jugendliche heutzutage kaum noch ohne ihr Smartphone auskommen. Ausfälle der Infrastruktur erleben sie somit als ernstzunehmende persönliche Bedrohung. Gerade die aktuelle Pandemie mit flächendeckenden Lockdowns zeigt deutlich auf, wie fragil die Gesellschaft in dieser Hinsicht geworden ist.

Angriffe gegen kritische Infrastrukturen

Angriffe gegen die kritischen Infrastrukturen nehmen immer weiter zu. So wurden 2015 weite Teile des ukrainischen Stromnetzes durch einen IT-Angriff abgeschaltet.

Seit 2016 ist ein starker Anstieg der Gefährdung durch Ransomware festzustellen. Weltweite Ransomware wie WannaCry hat 2017 dafür gesorgt, dass viele Unternehmen ihre Produkte und Dienstleistungen nicht mehr oder nur stark vermindert anbieten konnten. Betroffen waren hiervon viele namhafte Firmen wie beispielsweise die Deutsche Bahn, das Kammergericht Berlin, der DFB und die Fresenius. Ebenfalls sorgte ab 2017 eine weitere Malware für Aufsehen. NotPetya verbreitet sich anders als WannaCry nicht nur über Sicherheitslücken, sondern auch intern in Netzwerken. Zu den betroffenen Firmen zählen beispielsweise Maersk, Mondelez, SNCF und Merck. Die Angriffe zeigen deutlich, dass selbst bekannte Angriffswege, in diesem Fall bekannte Schwachstellen, nicht zeitnah innerhalb der Unternehmen behoben werden. Diese Wellen gehen mit den aktuellen Emotet-Kampagnen weiter.

Das BSI weist im Lagebericht 2019 genau 252 Meldungen seit der Einführung der Meldepflicht für kritische Infrastrukturen aus. Die Dunkelziffer dürfte hier weitaus höher sein.

Rechtliche Grundlagen

Da die Sicherheit der Infrastrukturen ein wichtiges Augenmerk sein sollte, wurden durch das IT-Sicherheitsgesetz und den § 8a BSIG hierfür die Weichen gestellt. Das IT-Sicherheitsgesetz ist hierbei die nationale Umsetzung der europäischen Richtlinie 2016/1148 („NIS-Richtlinie“). Durch das BSI Gesetz (BSIG) hat das BSI weitreichende Rechte wie auch Pflichten erhalten, um den Schutz von kritischen Infrastrukturen in Deutschland zu gewährleisten.

Im Rahmen der BSI-Kritisverordnung wurden zwei Körbe definiert, welchen die verschiedenen Sektoren zugeordnet worden sind. Zu den regulierten Sektoren zählen Energie, Telekommunikation, Transport und Verkehr, Gesundheit, Wasser, Ernährung, Finanz- und Versicherungswesen, Staat und Verwaltung sowie Medien und Kultur. Nicht alle Sektoren werden direkt durch das BSI überwacht. Der Bereich Energie wird durch die Bundesnetzagentur (BNetzA) betreut. Die Bereiche Staat und Verwaltung sowie Medien und Kultur fallen nicht direkt unter die KritisV und werden separat betreut.

Am 3. Mai 2016 ist der erste Teil der BSI-Kritisverordnung (§ 10 BSI-Gesetz) in Kraft getreten. Diese behandelt die Sektoren Energie, Wasser, Informationstechnik und Telekommunikation sowie Ernährung. Diese werden auch als „Korb 1“ bezeichnet. Durch die erste Verordnung zur Änderung der BSI-Kritisverordnung, die am 30.06.2017 in Kraft getreten ist, wurden die Sektoren Finanz- und Versicherungswesen, Gesundheit sowie Transport und Verkehr ergänzt. Diese werden auch „Korb 2“ genannt.

Anhand von Schwellwerten werden die betroffenen Unternehmen aus diesen Bereichen eingeteilt. Hierbei wird meist davon ausgegangen, dass eine Anlage 500.000 Bürger versorgt, um zu einer kritischen Dienstleistung zu zählen. Anhand von Berechnungsformeln werden die Schwellwerte berechnet. So ist der in der BSI-Kritisverordnung genannte Schwellwert für Strom unter Annahme eines Durchschnittsverbrauchs von 7.375 kWh pro versorgter Person pro Jahr definiert. Bei 500.000 Bürgern ergibt sich somit ein Schwellwert von 3.700 GWh pro Jahr ( 3.700 GWh/Jahr = 7.375 kWh/Jahr x 500.000).

Von Anfang an gab es jedoch auch Kritik an der Berechnung der Schwellwerte. So Ffllen beispielweise viele Krankenhäuser in einer Großstadt unter diese Regelung, obwohl es in der Stadt meist noch Alternativen gäbe, das kleine Kreiskrankenhaus, welches im Umkreis von 50km alle Patienten betreut, jedoch nicht.

Status-Quo des Umsetzungsstatus bei Unternehmen

Für viele KRITIS-Unternehmen ist das Thema IT-Sicherheit neu und die Umsetzung scheitert oft schon am Verständnis für die neuen Anforderungen. So haben viele Unternehmen mit der Umsetzung der gesetzlichen Anforderungen erst 2018 angefangen, obwohl das Gesetz schon seit zwei Jahren galt. Oft ist das begrenzte Budget Schuld an der mangelhaften Umsetzung neuer IT-Anforderungen.

Im Rahmen unserer beruflichen Tätigkeit als Prüfer, Ausbilder und Teilnehmer an Branchenarbeitskreisen von Betreibern, welche unter die KRITIS-Verordnung fallen, konnte ein breites Wissen darüber aufgebaut werden, inwiefern die Umsetzung der Anforderungen die Sicherheit in den Unternehmen nachhaltig verbessert hat, oder ob es nur das Ziel war, die gesetzlichen Anforderungen mit minimalen Aufwand zu erfüllen.

Hierbei stelle ich die These auf, dass Unternehmen, welche sich bisher noch nicht mit IT-Sicherheit beschäftigt haben, dies trotz des Gesetzes auch in Zukunft nur begrenzt tun werden.

Vielmehr werden diese Unternehmen den Minimalansatz wählen, um die nötigen Nachweise liefern zu können, ohne einen allgemeinen Prozess zur stetigen Verbesserung einzuführen.

Wir würden daher gerne anregen, die folgenden Forschungshypothesen, welche sich aus dem Wissen bei der Betrachtung der bisher durchgeführten Prüfungen wie auch Diskussionen im Rahmen der Branchenarbeitskreise ergeben haben, einmal genauer zu prüfen:

  • Hypothese 1: Die Umsetzung des BSIG führt zu einer besseren Akzeptanz der IT-Sicherheit in den Unternehmen.
  • Hypothese 2: Unternehmen, die sich bereits seit Einführung des Gesetzes mit dem Thema beschäftigen, messen der IT-Sicherheit einen höheren Stellenwert zu.
  • Hypothese 3: Eine (fälschlicherweise oft als Nachweis genutzte) Zertifizierung bringt nicht zwangsläufig Vorteile für den Bereich kritische Infrastrukturen, da gegebenenfalls die falsche Zielsetzung verfolgt wird.
  • Hypothese 4: Unternehmen, die bisher nicht viel für IT-Sicherheit getan haben, werden auch durch das aktuelle IT-Sicherheitsgesetz nicht ermuntert, in Zukunft viel dafür zu tun.

[1] https://www.esmt.org/sites/default/files/dsi_ipr_cybersicherheit_2018-2020_0.pdf

[2] Normale Katastrophen. Die unvermeidbaren Risiken der Großtechnik von Charles Perrow

[3] Kritische Infrastrukturen aus Sicht der Bevölkerung

SASE

Sassy Buzzword: Erobert SASE die Welt?

Ein neuer Trend macht aktuell in der IT(-Security) die Runde: SASE, wie die Marketinggötter sagen: „sassy“, oder in lang und verwirrend Secure Access Service Edge.

SASE ist ein neuer Ansatz in der Netzwerk-Architektur, in welchem WAN-Services (etwa eine Anbindung von Außenstellen) und Security-Funktionen (bisher bisweilen als CASP – Cloud-Access Security Provider – implementiert) in einer kombinierten Cloud-Lösung integriert werden. Die Sicherheitsfunktionen greifen hier am Rand (Edge) des Netzwerks und machen so bestimmte zentrale Sicherheitskonzepte wie vom Hauptquartier aufgespannte VPNs überflüssig. Zugriffe von Anwendern, Apps und Geräten werden dabei mit starken Identitäten und kontextbasierten Regeln gesteuert.

Die Platzierung des Begriffs an wenigen strategischen Template-Stellen in den Pressemitteilungen der Storage-Firmen und die Anzahl der um Bildschirm-Estate konkurrierenden Google-Ads zeigen allerdings schnell, worum es zunächst hierbei geht: Content Marketing und Search Engine Advertisement zur „neusten“ Sau, die Marktforscher wie Gartner, Forrester und Co. (natürlich auch zur Stärkung der eigenen Relevanz) durchs Dorf Internet treiben. Allein für die erotische Aussprache des Akronyms hat vermutlich eine Agentur einen schönen Batzen Geld kassiert.

Bei allem Hype ist aber vor allem der Trend hinter dem Trend interessant: Warum gerade diese Sau, gerade jetzt?

Zum einen geht es um Konvergenz: Die meisten großen Innovationen lassen sich entweder in „dasselbe mit weniger“ (Effizienz) oder „mehr mit demselben“ (Funktionalität) einordnen; nur wenige wahre „Disruptionen“ schaffen beides zugleich. Hier also dasselbe (nämlich VPN/„SD-WAN“ einerseits und CASP andererseits) mit weniger, d. h. nur einem Anbieter, der zukünftig beide Töpfe abgreifen möchte. Diejenigen, die eine Chance sehen, beides zugleich anzubieten, pushen den Hype, um diejenigen auszubooten, die nur eines von beiden können. Und selbstverständlich müssen dabei alle behaupten, sie machten das eh alles schon längst.

Zum anderen gibt es immer die Bewegung hin und her zwischen Zentralisierung und Dezentralisierung. Zum Beispiel: Mainframe -> Client-Server -> Cloud -> Edge -> … Diesmal rückt die zentrale Cloud, man hört es im „Edge“ am Ende von SASE, wieder ein Stück näher an die Kunden, um diese noch mehr einzubetten (und abzukassieren).

Bei allem Getrommel: Da das Konzept zu aktuellen Tendenzen und Bewegungen passt, kann ich mir vorstellen, dass es wirklich an Fahrt gewinnen wird – ob unter diesem künstlichen Buzzword oder unter dem nächsten.

Supply Chain

Die Ikarussen kommen? Flächensonnenbrand in IT-Land – SolarWinds #Sunburst Supply Chain Angriff

Dass Supply-Chain-Angriffe verheerend sein können, ist spätestens seit 2017 klar, als die im Update einer ukrainischen Steuersoftware versteckte Malware NotPetya IT-Infrastrukturen weltweit verkrüppelte und Schäden in Milliardenhöhe verursachte. Nun haben Angreifer – amerikanische Dienste verdächtigen den russischen Auslandsgeheimdienst – einen noch viel effektiveren Vektor in potenziell 300.000 für die Spionage (und evtl. auch Sabotage) äußerst wertvollen Unternehmen und Behörden gefunden: Ein manipuliertes Update der beliebten Netzwerkmonitoring-Lösung Orion hat bequeme Einstiegspunkte bei Kunden des Herstellers SolarWinds geöffnet, die in mehreren Fällen auch schon konkret ausgenutzt worden sind.
Aufgefallen war der Angriff, weil eines der Opfer der amerikanische Security-Spezialist FireEye ist. Experten dort hatten den Missbrauch von Microsoft-Authentifizierungstechniken durch die Angreifer bemerkt und eine Untersuchung gestartet, die zunächst die Spitze des Eisbergs sichtbar machte.
Inzwischen ist klar, dass nicht nur viele Fortune 500-Unternehmen, sondern auch kritische Infrastrukturen und der Verteidigungssektor betroffen sind – eine Goldgrube für die Angreifer.
„Sunburst“, wie der Angriff genannt wird, ist relativ leicht im Netzwerk zu detektieren und zu stoppen. Die Sisyphusarbeit liegt jedoch darin, Netzwerke, die möglicherweise durch die Lücke schon kompromittiert wurden, zu untersuchen und – in vielen Fällen der einzig wirklich sichere Weg – neu aufzusetzen. Die Aufräumarbeiten hierzu haben gerade erst begonnen.

SolarWinds #Sunburst Supply Chain Angriff
Cyberwar

Gestorben MIT, nicht AN Cyber

Im Fall der Patientin, die nach verschiedenen, auch internationalen Berichten wegen eines Cyberangriffs auf die Uniklinik Düsseldorf bedauerlicherweise verstorben war, müssten wir nun zurückrudern – wenn wir hier im Digest nicht schon im vergangenen September zur Vorsicht gemahnt hätten. Auch die Staatsanwaltschaft ist inzwischen zu dem Schluss gekommen, dass der Tod nicht ursächlich mit dem fehlgeleiteten Angriff zusammenhing, der eigentlich nur die Universität hätte treffen sollen.

Zukünftig müssen wir jedoch damit rechnen, dass Tod und Cyber immer häufiger aufeinandertreffen werden, einfach schon aufgrund der Statistik bei immer stärkerer Abhängigkeit von IT in allen Bereichen. Wie wollen wir als Gesellschaft damit umgehen?
Zwei Sichtweisen sind dabei nicht hilfreich: Zum einen das Verteufeln des Computers. Es ist richtig: Mit zunehmender Abhängigkeit von Rechnern und Netzen handeln wir uns zusätzliche Risiken ein. Sonst würden Sie diesen Digest übrigens gar nicht lesen, ich ihn vermutlich nicht schreiben. Und es ist sicher wichtig, jeden Todesfall zu analysieren und die allgemeine Entwicklung zu beobachten. Die Häufung von Todesfällen im Straßenverkehr seit den 50er Jahren hat zu Recht zu immer weiter verschärften Regeln beim Fahren geführt. Das ist jedoch nicht dasselbe, wie sensationslüstern auf die ersten Totgecyberten zu warten.

Auf der anderen Seite sollten wir der Versuchung widerstehen, das Thema kleinreden zu wollen. Das Beispiel Corona lehrt uns, dass es genug Menschen gibt, die ihre Ängste durch „Wegerklären“ zu verdrängen versuchen. Wenn innerhalb weniger Monate 150.000 US-Amerikanerinnen und Amerikaner zufälligerweise alle „mit“ Corona, aber „an“ Lungenentzündung sterben, dann ist dieses Ding möglicherweise doch nicht so „harmlos“ wie die im Übrigen auch nicht selten tödlich endende echte Grippe. Genauso muss uns eine Zunahme von Todes- und Unfällen und übrigens auch schon von near misses, bei denen der Computer zwar nicht „schuld“, aber beteiligt war, aufhorchen und die Risiken überdenken lassen. 

Haben wir also, sobald wir Corona überwunden haben, in den nächsten Jahren ein ruhiges, waches Auge auf das Sterben (an und) mit Cyber. Bitte bleiben Sie gesund!

Corona

Wo bleibt die Excel-ends-Initiative? MS Excel frisst Corona-Daten

Beim britischen Gesundheitssystem sind mehrere tausend Datensätze zu positiven Corona-Tests verloren gegangen, da das alte Excel-Dateiformat .xls nur eine begrenzte Anzahl von Zeilen speichern kann. Der Fehler fiel erst nach mehreren Tagen auf, sodass Betroffene teilweise erst sehr spät benachrichtigt werden konnten.

Das Problem unsicherer „Schatten-Softwareentwicklung“ durch Endnutzer in Office-Tools, insbesondere Excel, ist seit vielen Jahren bekannt und nicht leicht in den Griff zu bekommen.

https://t3n.de/news/excel-verursacht-corona-panne-1326375

Security-Kolumne „Spreadsheets töten“ in aktueller iX: https://www.heise.de/select/ix/2020/11/2026109274934915903

Ransomware

Totgecybert? Kollateralschäden von Ransomware

Ein eventuelles erstes Todesopfer eines Cyberangriffs in Deutschland hat die Debatte um Kritische Infrastrukturen und IT-Sicherheit in Krankenhäusern aufgeschreckt. Ein fehlgeleiteter Ransomware-Angriff auf das Uniklinikum Düsseldorf – es sollte eigentlich „nur“ die Universität treffen – hat zum Shutdown des Krankenhausbetriebs geführt. Obwohl die in Russland vermuteten Täter der Gruppe DoppelPaymer nach Mitteilung des Irrtums durch die Polizei umgehend die Schlüssel herausrückten, um das Krankenhaus wieder in Gang zu bringen, laufen nun Ermittlungen wegen des Verdachts der fahrlässigen Tötung einer Patientin, die statt in die nahe Uni-Klinik in ein weiter entferntes Krankenhaus gebracht worden und gestorben war. Ein eventuelles Gerichtverfahren wäre Neuland und ein möglicher Präzedenzfall für den Umgang mit Angriffen auf Kritische Infrastrukturen. Ähnlich wie bei anderen aktuellen Themen – etwa den Mordanklagen gegen Raser – bewegen sich hier nicht nur Ermittlungsbehörden, sondern auch Gerichte auf dünnem Eis. Gleichzeitig dürfte die Auseinandersetzung mit dem und über das Thema entscheidend mitgestaltend daran sein, wie wir als Gesellschaft Verantwortung und Rechenschaft im Internet sehen, leben und verfolgen wollen.

https://www.heise.de/news/Uniklinik-Duesseldorf-Ransomware-DoppelPaymer-soll-hinter-dem-Angriff-stecken-4908608.html

Netzwerk

Securing DNS Traffic: An Introduction to DoT & DoH

In recent times, operating systems including Windows and macOS have been adding support for encrypted DNS. But how do the involved protocols work? And what are their benefits?

To understand them, we first have to look at the Domain Name System (DNS) itself, which is one of the fundamental backbones of the Internet. However, DNS alone does not provide any encryption or authentication, which makes DNS communication vulnerable to eavesdropping and in-transit modifications. Adversaries can use DNS information in cache poisoning attacks to lure victims on phishing websites. On a larger scale, state-level agencies can use pervasive monitoring of DNS for surveillance purposes and therefore attack users‘ privacy. Other third parties can use DNS data for Open Source Intelligence (OSINT) purposes, which may harm users‘ security altogether.

Timeline of DNS history

Encrypted DNS protocols were first introduced in 2008 when Daniel J. Bernstein proposed DNSCurve. In the following years DNSCrypt followed but both protocols failed to gain noteworthy adoption. In hindsight of the Snowden revelations in 2013, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) were developed and standardized by the IETF. They aim to secure DNS by adding confidentiality, integrity and server authenticity.

But how do these protocols work? Let’s have a short look at each.

DNS-over-TLS

DoT, described in RFC 7858, is using the well-known Transport Layer Security (TLS) protocol and thus inherits all its security benefits. By default, DoT resolver listen on port 853 for incoming DNS queries that must be encrypted. This non-standard port was chosen to ease the differentiation between DoT and non-DoT connections. However, administrators deploying DoT can choose a different port, provided that both resolver and clients agree. A fallback to cleartext DNS messages within the protocol is not allowed, neither for the client nor the server.

DoT protocol

The protocol, as shown above, consists of two Round-Trip Times (RTT) on first contact. First, the DNS client performs the TCP handshake with the resolver it has chosen to connect to. Next, the DNS client performs the TLS handshake with the server. The client does not necessarily have to authenticate the server as this depends on the used profile. Therefore, self-signed certificates are also acceptable. After the successful completion of the handshake, both parties obtain a session key that is used for subsequent packets. In a third step, the DNS client sends its DNS queries through the established TLS channel. Multiple DNS queries may be pipelined to reduce bandwidth. Messages sent through this TLS channel are hidden from any intermediate party; therefore the DNS queries and answers stay confidential, with any Manipulation detectable.

Privacy Profiles

DoT supports two usage profiles that are defined in RFC 8310 and differ in the privacy they provide. Clients can choose which profile to follow and can thus match their DNS settings to their requirements. Administrators can also force the use of a usage profile.

  • Opportunistic: This profile does not guarantee privacy but tries to achieve as much as possible. Therefore, if connections to servers cannot be authenticated or encrypted they are still acceptable for the client. This profile consciously rates availability as a primary and privacy as a secondary goal and can thus result in insecure connections.
  • Strict: This is a privacy-oriented profile and does not allow establishment of connections to servers that cannot be encrypted or authenticated. It restricts availability but guarantees privacy of DNS messages. A fallback to insecure connections is prohibited.

Use of the strict privacy profile is recommended to establish adequate security in most settings.

DNS-over-HTTPS

DoH, as described in RFC 8484, is the most recent standard for encrypted DNS and uses HTTPS sessions to exchange DNS messages. This enables masking within other HTTPS traffic.
DoH uses URI templates to send DNS requests and can either use GET or POST methods. When using Cloudflare’s 1.1.1.1 resolver, the requests are structured as followed:

  • The GET request is sent to https://1.1.1.1/dns-query?dns, where the value of the DNS parameter contains the DNS message encoded in base64url.
  • The POST request is sent to https://1.1.1.1/dns-query within the message body. In addition, the header application/dns-message is specified.

It is interesting to note that the RFC does not specifiy the path dns-query. However, lists of public resolvers show that resolvers generally follow this format. Web browsers are able to conduct the requests on their own as they ship with an HTTP engine. An example GET request that recursively resolves the domain name www.hisolutions.com is shown below:

https://1.1.1.1/dns-query?dns=AAABAAABAAAAAAAAA3d3dwtoaXNvbHV0aW9ucwNjb20AAAEAAQ

The answer includes the corresponding IPv4 address of the resolved domain. For more information about the structure of DNS messages, refer to RFC 1035.

DoH protocol

Overall, the DoH protocol works similar to DoT. Their protocol messages include the same content, except for the additional wrapping of DoH messages. However, this wrapping in combination with operating on the same port as common web traffic yields additional privacy benefits that are discussed below.

Discussion

DoH offers the best privacy guarantees of the encrypted DNS protocols. The use of the common port 443 could help prevent censorship of DNS lookups, as third parties observing the traffic are not able to differentiate between regular web and DNS traffic. Therefore, they must block access to the full website to block DNS lookups. A blacklist only works partially as it can only block the access to well-known DoH resolvers. Another point includes the additional masquerading of DNS messages through the use of HTTP. This decreases the likelihood of successful fingerprinting through observing third parties. On the other side, DoT does not interfere with common web traffic by operating on a dedicated port. This enables adversaries to simply drop traffic on that port, such that clients must switch to an (insecure) alternative. However, in managed environments this may be done on purpose, e.g. to force the use of predefined resolvers.

Both protocols add a performance overhead compared to traditional DNS. Although researchers found higher response times for individual DoT/DoH queries, page load times performed similar to traditional DNS given stable network connections. When network conditions degraded, traditional DNS significantly outperformed DoT/DoH. However, this is critique on a high level and the elevated response time is rarely noticeable on the user side.

Usability of both protocols has increased over time, and further adoptions are already planned. As of now, DoT/DoH is already available in Firefox, Chrome and Opera, and therefore supported in the most common web browsers. When it comes to operating systems, both Windows and macOS have added DoH to their pre-release channels and are planning to release it anytime soon. On mobile, Android has been supporting DoT since Android 9. Overall, users are mostly able to enable encrypted DNS on their devices.

We performed some measurements on the Internet and found that, while the number of users of DoH has increased significantly over time, the number of DoH resolvers has not. This highlights a consolidation in the DNS resolver market, which can be problematic in case of untrustworthy resolvers. Even for trustworthy ones, it introduces a single point of failure that other systems rely on, as a recent Cloudflare outage showed. Therefore, the defined secondary resolver should not be of the same provider as the primary one. When using open resolvers we recommend the use of resolvers that have clear privacy directives, prove successful third party audits and have a clean compliance history.

In the future, other encrypted DNS protocols such as DNS-over-QUIC (DoQ) may be used as well. They will probably increase in adoption once HTTP/3 starts rolling out, but DoQ does not include additional privacy benefits as long as most web traffic is still conducted over HTTPS.

Advisories, Ransomware

Warnung: Aktuelle Ransomware-Angriffe als Folge von Shitrix

Monate nach dem Auftauchen der kritischen Sicherheitslücke im Citrix Application Delivery Controller (ADC) und NetScaler Gateway (CVE-2019-19781, auch als “Shitrix“ bekannt) werden nun immer mehr Fälle bekannt, in denen die Lücke früh ausgenutzt, jedoch erst sehr viel später lukrativ verwendet wurde bzw. aktuell wird.

Unsere Incident Responder stellten dabei fest, dass im kritischen Zeitraum Anfang 2020 in einigen Fällen Backdoors installiert worden sind, welche nun, 8 Monate später, durch Ransomware-Angriffe aktiv ausgenutzt werden.

Details im HiSolutions Advisory von Folker Schmidt und Daniel Jedecke.

Advisories, Ransomware

Warning: Current Ransomware Attacks As a Result of Shitrix

By Folker Schmidt and Daniel Jedecke

Months after the appearance of the critical vulnerability in Citrix Application Delivery Controller (ADC) and NetScaler Gateway (CVE-2019-19781, also known as „Shitrix“), more and more cases are now becoming known where the vulnerability was exploited very early on, but was not used for extortion until much later, and ongoing.

Our incident responders found that in a critical period in early 2020, backdoors were installed in some cases, which are actively exploited now, 8 months later, for ransomware attacks. In many cases, the attackers have not even bothered to adapt the known proofs-of-concept of the „Project Zero India“ group. In the cases known to us, the user „pwnpzi1337“ was created, which was used in the original PoC.

The subsequent steps of the attack are basically the same as they were before, network discovery, lateral movement within the network (for example using Dridex or Cobalt-Strike), data exfiltration, and later encryption of the data e.g. via DoppelPaymer.

However, there is a multitude of other conceivable malware variants on the market. Due to the current wave of attacks, every administrator and system administrator is strongly recommended to check their Citrix NetScaler systems in particular for possible new users or conspicuous network activity. A check of the folder /var/vpn/bookmark is definitely recommended, since the XML files smuggled in by the attacker can be found there. As a quick check for possible compromise, the instructions under http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781 have proved to be helpful.

If there is any doubt about the integrity of the system, our forensic experts recommend rebuilding the system, which is the standard procedure for ransomware attacks. We are happy to refer to the recommendations of the German BSI (Federal Cyber Security Agency). Back in January 2020, the BSI issued a Citrix vulnerability warning (see CSW No. 2020-172597-1531, Version 1.5, 30.01.2020 and https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2020/Citrix_Schwachstelle_160120.html), which contains, among other helpful bits, the following measures:

  • Disconnection from network of the compromised Citrix instance
  • Backup of the old Citrix instance (entire system, or at least the log files under /var/log/*)
  • Restart of Citrix instance with the latest build of the respective version branch and implementing the workaround (workaround recommendation when no patches were available yet)
  • Creation of new SSL/TLS certificates, recall of old SSL/TLS certificates
  • Resetting of all Windows Active Directory passwords if the Citrix user group cannot be restricted
  • Depending on the network connection, check the Windows domain for further compromises
  • If wildcard SSL certificates (*.example.com) were used on a compromised Citrix system, all other systems using the wildcard certificate must be taken into account in the certificate exchange mentioned above.

Citrix administrators should always subscribe to Citrix security bulletins with notices of new firmware versions to receive information about new firmware updates

The German Alliance for Cyber Security has recommended further action. These can be found at https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Ransomware/Ransomware_Massnahmenkatalog.html.

It is also important to note in this case that the attackers could potentially move around the network unnoticed for months, which could jeopardize the integrity of backups that have been made long ago. Special care must be taken here when restoring affected systems.

At the beginning of August 2020, still around 200 vulnerable Citrix systems in Germany were accessible from the Internet (https://twitter.com/certbund/status/1291017699351580675). The number of systems that are secured but have already implemented a backdoor cannot be quantified.