Shooting the messenger

Aus mehrfach aktuellem Anlass – und nachdem auch die Politik aktuell wieder heult, dass im letzten Jahr wieder massiv gecybert wurde.

Liebe Unternehmen: Bekommt eure Security und vor allem euer Verhalten gegenüber Sicherheitsforschenden endlich mal in den Griff.

Nachdem es bei Golem und Heise zu lesen war und es nicht der erste Fall von „Shooting the messenger“ dieses Jahr war und mir ehrlich gesagt mittlerweile der Kamm ein wenig schwillt, mal (m)eine Meinung und Erfahrung zum Thema Sicherheitsforschung und der Umgang von Unternehmen mit der Thematik.

Der Vollständigkeit halber (und nein, das soll keine Prahlerei sein): ja, auch ich habe schon Sicherheitslücken entdeckt und gemeldet. Details sind sind an der Stelle unwichtig, zur groben Einordnung, zwei Meldungen hatten IIRC einen CVSS-Score von 7,4 und 8,6.

Was ich in der Kommunikation mehrfach beobachten konnte waren folgende Reaktionen in dieser Reihenfolge:

  • „Kann gar nicht sein“
  • „Warum glauben Sie, dass es eine Sicherheitslücke gibt?“
  • „Oh.“
  • (vermutlich hektischer Griff zum Telefonhörer, keine Reaktion – nach längerem Warten und mehreren Rückfragen)
  • „Wir haben es gefixt, bitte prüfen“

Meine Gedanken dazu: Ok, ok, es kann ja jeder daherkommen und Dinge behaupten. Aber selbst mit einer groben Beschreibung was falsch läuft, sollte jemand der/die „security“ in der Mailadresse hat entweder seine Kompetenz nutzen oder entsprechende Ressourcen im eigenen Betrieb aktivieren.

Gleiches gilt für Punkt zwei. Muss man als unbezahlte(r) dritter wirklich immer einen proof of concept darlegen? War bei mir bis jetzt immer der Fall. Leute, es eure Sicherheit. Euer Kapital, eure Verantwortung. Muss man wirklich eure (bitte entschuldigt die Ausdrucksweise aber etwas milderes fällt mir dazu nicht ein) Nase in den Kackhaufen drücken, auch wenn man von weitem schon sieht, dass der einfach nicht auf den Parkettboden gehört?

Das darauf folgende „Oh.“ gibt zwar ein wenig Genugtuung – aber: man im Zweifel Stunden oder gar Tage für etwas aufgewendet, was eigentlich in der verdammten Verantwortung des „zerforschten“ liegt. Seis drum. Man hilft ja gerne.

Selten oder eigentlich eher so gut wie gar nicht habe ich Proaktive Kommunikation von der Gegenseite bekommen. Warum auch: man hat ihr unliebsame Arbeit beschert und nervt dann auch noch damit, wann endlich die ureigensten Probleme gelöst sind.

Und ja, auch der letzte Punkt ist nicht erfunden. „Will review for code and food“. Man muss sich echt wundern, mit welcher Erwartungshaltung manche Menschen durchs Leben gehen. Natürlich werde ich an einer Blackbox bestätigen, dass das Teil jetzt sicher ist, obwohl die Sicherheitslücke im Zweifel nur einen kleinen Schritt zur Seite gemacht hat – und zum Schluss noch „Haftung“ dafür zu übernehmen. Ja ne, is klar Kollege.

Eine andere Beobachtung (allerdings schon ein paar Jahre her): Es kann durchaus schwierig sein jemanden zu erreichen, der/die sich tatsächlich überhaupt verantwortlich für Sicherheit fühlt. Auf Anfragen über Kontaktformulare oder zentrale Mailverteiler wurde nicht reagiert und es war social engineering erforderlich, um einen Kontakt aufzubauen.

Was läuft falsch?

Die für mich markantesten Punkte sind:

  • Es ist erstaunlich schwierig, einen Kommunikationskanal aufzubauen
  • Man muss mehr beweisen als eigentlich nötig wäre
  • Probleme werden heruntergespielt oder die Tragweite verkannt
  • Um die Analogie „Daten sind das Öl des 21. Jahrhunderts“ auszuschlachten: Die Gewinne sind wichtig, aber für eine Tankerhavarie gibt es weder einen Notfallplan noch eine schnelle Eingreiftruppe. Zerstöre Ökosysteme: kann man nichts machen, das bringt der Fortschritt halt mit sich
  • Obwohl man hilft, bleibt man Bittsteller oder ein Störfaktor
  • Es gilt das Schubkarrenprinzip: Es bewegt sich nur was, wenn man schiebt

Grundsätzlich kann man es wie folgt zusammenfassen: Die Erwartungshaltung der beiden Parteien divergiert.

Zugegeben: ich habe den Eindruck, dass es (auch dank DSGVO und den damit verbundenen Strafen) etwas besser geworden ist und auch die Angst vor der Veröffentlichungen etwas größer geworden sind.

Dennoch ist die noch recht junge security.txt Stand Oktober 2021 leider noch nicht so richtig etabliert.

Liebe Unternehmen, bitte beachtet:

Sicherheitsforschende…

  • …machen das ggf. in deren Freizeit
    (nicht sie binden eure die Zeit, ihr macht das mit ihrer)
  • …sind nicht die Ursache eurer Probleme
  • …haben euch gegenüber keine keine Verpflichtung oder Bringschuld
  • …haben erst einmal keine persönlichen Vorteile, euch zu helfen
  • …haben kein Interesse, euch ans Bein zu pinkeln
    (sonst würden sie die Lücke gleich woanders verkaufen)
  • …sollten euch nicht erklären müssen, wie ihr es richtig macht
  • …sollten euch nicht den Hintern hinterher tragen müssen
  • …wollen sich nicht und lassen sich nicht gerne verarschen lassen

Herangehensweise

An der Stelle sei hervorgehoben: das sind keine verbindlichen Ratschläge, dafür habe ich weder die Expertise noch eine Autorität. Ein recht interessanten Artikel zum Thema bietet z. B. Heise Online.

Aus meinen bisherigen Erfahrungen halte ich für sinnvoll:

  • Diskretion bewahren
  • Wenn es nicht viel Aufwand ist, bereits ein proof-of-concept vorbereiten – die meisten Unternehmen werden euch nicht glauben. Je schnell man das „Oh“ erreicht, desto besser
  • So früh wie möglich Entdeckungen dokumentieren, auch wie man sich durchhangelt
    • Screenrecordings sind dank OBS mittlerweile sehr einfach zu erstellen und sicher auch schönes Futter, sollte man es beim Congress auf die Bühne schaffen 😉
    • Ist etwas physisches im Spiel: Video möglichst ohne Schnitte um zu zeigen, dass es keinen doppelten Boden gibt
  • Wenn Daten Dritter im Spiel sind: So viel wie nötig, so wenig wie möglich sehen/speichern, möglichst früh anonymisieren. Metainformationen reichen bereits oft für den „Aha-Effekt“
    • Wenn man nicht/schlecht anonymisieren kann: Kryptographie für die Dokumentation verwenden.
  • Zeitlich nachvollziehbar und nicht manipulierbar dokumentieren
    • Hashes von veröffentlichbaren Dokumenationen (Daten Dritter müssen irreversibel geschützt sein) auf nicht verfälschbaren Plattformen (z. B. Twitter) veröffentlichen, dadurch hat man einen Zeitstempel
    • Verschlüsselte Daten in ein öffentliches (z. B. Git) Repo packen
  • Noch vor der ersten Kontaktaufnahme prüfen
    • Wer ist steht einem gegenüber?
      • Gibt es eine Vulnerability-Kultur (Bug bounty-Programme, CVE)
      • Würde man für sie arbeiten wollen?
      • Sind sie schon durch Behandlung von Hackern in Erscheinung getreten?
  • Die erste Kontaktaufnahme gilt zum Aushandeln eines sicheren Kommunikationsweges, keine Details („Ich habe (vermutlich) eine Sicherheitslücke gefunden, bitte senden Sie mir eine verschlüsselte Mail mit Ihren Public Keys an …“)
  • Es kann sinnvoll sein, anonym oder unter Pseudonym an Firmen heranzutreten um Angriffsfläche zu verringern
  • Mit der ersten verschlüsselten Mail die „Spielregeln“ festlegen
    • Freundlich aber bestimmt bleiben („ich will euch nichts Böses, aber ihr müsst etwas machen“)
    • Auch wenn umstritten: CVSS-Score ermitteln und kommunizieren
    • Typ des Disclosures ansagen (Responsible oder Coordinated, siehe auch den oben verlinkten Heise-Artikel)
    • Durchführbaren aber festen Zeitrahmen/Meilensteine festlegen
      • Nicht vertrösten lassen, aber Verzug mit guter Begründung gewähren lassen
    • Konsequenzen beim Verstreichen von Fristen festlegen
      • Zero-Days sind nicht die beste Option
      • Zusammenarbeit mit Plattformen, Benachrichtigung von potenziell geschädigten Partnern/Kunden (nicht im Sinne von Endverbrauchern), Medien
    • Von vorne herein proaktive Rückmeldung des Gegenüber einfordern
    • Wenn es einem wichtig ist: Belohnung aushandeln
  • „Alles was Sie sagen, kann und wird gegen Sie verwendet werden“ gilt für beide Richtungen
  • Security Advisories vor der Veröffentlichung zum Gegenlesen verlangen (eigene Erfahrung: bei einer Stand ziemlich großer Unsinn und wurde trotz deutlichem Hinweis nicht korrigiert)
  • Wenn man zu Meetings eingeladen wird: jemanden im Hintergrund nach Pressemeldungen Ausschau halten lassen
  • Soweit wie sinnvoll möglich kooperieren – es geht um die Sache, nicht um Befindlichkeiten

Nachtrag, Januar 2022:

Die Hacker*innen von zerforschung hatten auf dem rc3 einen guten Talk zum Thema.

Auch wenn ich mich bei ihrem Argument „keine Druckmittel/Erpressung“ in Hinblick auf Konsequzenzen beim Verstreichen von fristen etwas ertappt fühlte, bleibe ich dabei: aufgrund bisheriger Erfahrungen ist ein Mittel, das man in Erwägung ziehen kann – wenn man nicht von vorne herein gemeinsam mit einer Vertrauensperson arbeitet, was je nach „Gewicht“ des Fundes und Breite des eigenen Rückens sehr sinnvoll sein kann.

Trusted Recursive Resolver

Aus der Kategorie: wir ersetzen etwas kaputtes durch etwas noch viel kaputteres:

DNS soll gegen DNS over HTTPS (kurz DoH, oder eher d’oh) ersetzt werden, so zumindest der Plan von Mozilla. Einmal Fefe, einmal Heise.

Symbolbild:

Ich hab übrigens seit mehreren Monaten einen Blogpost „on hold“, bei dem ich etwas Angst habe ihn zu veröffentlichen, da ich sonst als paranoid dastehen könnte. Titel: „Ein paar unangenehme Prognosen“. Eine davon war (leider zu dem Zeitpunkt nicht aufgeschrieben): „DNS-Anbieter loggen und verwerten Anfragen, verkaufen sie u.a. an die Werbebranche“.

Ein anderer Punkt: „Es kommt das Zeitalter der Tivial-Bugs –
Die root-Lücken in macOS letztes Jahr werden ein Witz dagegen sein. Kategorie: Encryption von Drahtlosnetzen (WiFi/5G/…) und Protokollen wird durch Bug mit dem Niveau eines Bitflips weitestgehend ausgehebelt.“

Ach, übrigens: WPA2 ist so gut wie tot. (ok, war kein Bitflip)