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.

Zweiundvierzig

Jeder kennt sie, viele hassen sie – „Sicherheitsfragen“. Eine solche sollte ich heute beim Besuch des Kundencenters der Telekom einrichten.

Die Frage selbst kann man in aller Regel nicht frei wählen, die Antworten dieser Fragen lassen sich oft durch Social Engineering erarbeiten.

Aber die Telekom hat auch eine Frage im Katalog, deren Antwort eigentlich schon vor-ausgefüllt sein könnte:

Sicherheitsfrage „Wie lautet die Antwort auf die Frage aller Fragen?“

Ich frage mich tatsächlich und ehrlich, wie oft hier „Zweiundvierzig“ eingegeben wird (und ob die Eingabe zulässig ist). Liest hier jemand von der Telekom mit, der zugriff hat und mal eine Statistik rauslassen könnte?

Allgemein ist Passwortsicherheit ein Thema für sich. Viele IT-Abteilungen erfordern fordern z. B. einen sehr engen Wechselzyklus und Anforderungen wie Groß- & Kleinschreibung, Zahlen, Sonderzeichen, ein kyrillisches Zeichen, zwei Hiragana-Zeichen, eine persische Zahl und ein Emoji. Grund: weil es sicherer ist.

Ich bin eher der Meinung, dass es ziemlich großer Unsinn ist. Passwortüberprüfungen erfolgen nicht nach dem Prinzip des Spiels Mastermind. Es gibt entweder ein true oder ein false und nicht, ob und wie viele Zeichen richtig sind. Zudem lässt ein häufiger Passwortwechsel die Leute unkreativ werden. Dann gibt es Stammpasswörter mit einer Variablen wie das Datum des Passwortwechsels oder es steigt ganz einfach die Gefahr, dass das Passwort irgendwo notiert wird. An der Stelle möchte ich nicht wissen, von wie vielen das Passwort nicht nur unter der Tastatur klebt, sondern gleich Cherry oder Logitech verwendet wurde.

Auch habe ich schon viel zu oft gehört und gelesen, dass man als Passwort die ersten Buchstaben eines Satzes verwenden und noch eine Leetspeak-Zahl und ein Sonderzeichen reinnehmen soll. Beispiel: Das ist das Haus vom Nikolaus: DidHvN, mit Zahl dann D1dHvN. Mit dem erstbesten gefundenen Passwort-Crack-Estimater liegt das erste Passwort bei 6 Sekunden, das zweite bei 20 Sekunden. Würde man den kompletten Satz als Passwort nehmen, läge man bei 7,2*10^38 Jahren. Wie gesagt, unter der Annahme, dass die Passwortprüfung nur ein true/false zurückgibt. Ein kompletter Satz ist beim „Shouldersurfing“ vermutlich nicht ganz so gut, da man es in diesem Fall etwas einfacher als scheinbar zufällige Tastendrücke rekonstruieren kann – aber: das ist zusätzliche Information. Da der Aufwand bei Bruteforce-Attacken mit der Länge des Passworts exponentiell steigt, ist es von Nachteil, kurze, komplexe Passwörter zu verwenden.

Aber solche Angriffe sind mittlerweile eh langweilig – spätestens nach dem 10. Fehlversuch dürfte/sollte jedes Formular für eine Weile dicht machen. Kritischer ist heute nicht mehr das Passwort selbst, sondern die Person, die es eingibt.

Ein Passwort für alle Dienste, ungesichert gespeicherte Passwörter im Browser und ganz vorneweg: Zeug anklicken. Das Konto muss verifiziert werden? Klick. Unaufgeforderte Passwortwiederherstellung? Klick. Irgendwas gewonnen und man muss sich mit den Credentials der Seite einloggen, auf der die Werbung stand? Die Liste der Möglichkeiten ist lang.

Meine Strategie: Lallo-Passwörter liegen im (gesicherten) Passwortmanager, die wichtigeren (bei denen etwas bei einem Leak kaputt gehen könnte) existieren nur im Kopf. Dazu noch 2FA wo es möglich und sinnvoll ist. Zudem genau schauen, wo man denn nun sein Passwort eingibt.

Hier schlägt auch der Vorteil eines Passwortmanagers, der im Browser integriert ist, zu: Der schlägt den einzugebenden Login erst einmal nur auf den legitimen Domains vor, was schon sehr hilfreich sein kann.

Bei der Sicherheitsfrage von der Telekom habe ich übrigens einen zufällig generierten Text eingetragen, auch wenn DIE ANTWORT aller Fragen verlockend gewesen wäre. Wobei der Kenner weiß: Es ist nicht die Antwort, es ist die Frage.

USB 3.2 – Ist die Lösung schlimmer als das Problem?

Vor knapp zwei Wochen gab es in der c’t (4/2019) einen Artikel zu USB 3.2, das neben der doppelten Geschwindigkeit (20 GBit/s) auch ein älteres Problem des Systems beheben soll: BadUSB. Dabei kann z. B. ein USB-Stick mehr als Massenspeicher. Als beispielsweise Maus- und Tastatur-Simulator kann er Eingaben am Rechner durchführen, als RNDIS kann es ggf. sogar Netzwerkverkehr manipulieren. Hurra!

Mit USB 3.2 soll das alles besser werden. Mit Zerifikaten und Crypto. An der Stelle sei erwähnt, dass Apple mit im Gremium war. Wofür haben die nochmal Crypto in ihren Lightning-Steckern hinzugefügt? Um ihre Produkte sicherer zu machen oder um sich vor günstiger Nachbauware zu schützen? Ein Schelm, ….

So, jetzt stellt sich einer mal das hier vor: Ein USB-Device, sei es eine Maus, eine Tastatur, ein USB-Speicherstick, hat ein gültiges Zertifikat. Soweit, so gut. Was hindert die Maus oder Tastatur nun daran, böswillige Eingaben zu machen, von denen der User nix mitbekommt? Wenn man wollen würde, könnte man sogar hinter dem USB-Controller, also direkt an der Tastaturmatrix etwas böswilliges einbauen. Schützt einen das Zertifikat, das man wahrscheinlich für teuer Geld kaufen muss davor?

Andersrum: Wenn ein legitimer Chip mit diesem Angriffsvektor in einem dadurch illegitimen Produkt verbaut wird und dieses Zertifikat zurückgezogen oder für ungültig erklärt werden muss (wie läuft das überhaupt, muss man nun beim Einstecken eines USB-Geräts online sein?), sitzen dann die Nutzer des legitimen Produkts im Dunkeln? Was hält einen Hersteller davon ab, schlechte Firmware zu schreiben, dass man trotz Zertifikat Schadsoftware injizieren kann?

Oder noch viel einfacher: Wenn ein Angreifer eine Maus und Tastatur in einen USB-Stick (zusätzlich zum Speicher) unterjubeln will, dann kann er doch einfach einen legitimen USB-Hub vor den legitimen USB-Speicher hängen und nebendran noch eine legitime Tastatur anbasteln, die über einen weiteren µC (oder auf andere Wege) illegitime Befehle an den PC weitergibt. Zwar werden dadurch mehrere Geräte erkannt, aber welchen Unterschied macht’s?

Und wie schaut es mit alten USB-Geräten aus? Es ist ja schon ein riesiges Problem, bei USB-Type-C-Buchsen & -Steckern zu sagen, was sie denn überhaupt können. USB 2.0, USB 3.0, USB 3.1, USB 3.2, Tunderbolt, Display Port, Power Delivery mit 5 W, 10 W, 20 W, 100 W, Quelle, Senke oder beides. Kann sie Analog Audio, kann ich daran meinen Mixer anschließen?

Aber ich schweife ab: Wie sieht es mit Legacy-Devices aus? Sie von der Verwendung auszuschließen wäre Irrsinn, also müssen sie weiter funktionieren – und wen hält es ab, einen scheinbar modernen USB-Stick (z. B. mit USB Type C) einfach nur ein USB 2.0-Interface zu implementieren, das dann fleißig böse Dinge tut.

Ich muss zugeben, ich habe die Spec (noch) nicht gelesen, aber die die (ok, nicht exklusive) Apple’sche Zwangsneurose alles verdongeln zu müssen kotzt mich als User, Bastler und Entwickler einfach nur noch an.

Warum löst man das BadUSB-Problem nicht wie früher bei den Personal Firewalls: Ein Gerät meldet sich an, wird enumeriert, darf aber erst einmal nichts machen. Der Benutzer bekommt einen Popup mit dem neu erkannten Gerät (oder Gerätebaum) präsentiert und muss sich entscheiden, ob er die Verwendung zulassen oder verweigern möchte. Noch eine Checkbox dazu, ob man dies vorübergehend oder dauerhaft will und ob dies für alle USB-Buchsen der Fall sein soll und fertig.

Einen halbwegs eindeutigen Fingerabdruck (Vendor- & Product ID, Seriennummer, Descriptors) haben eigentlich alle Geräte und ja ich weiß, es ist nicht perfekt und hindert ein wenig die Usability. Aber es könnte jetzt sofort für alle USB-Generationen implementiert werden. Selbst bei Eingabegeräten (Maus/Tastatur), die man an einen jungfräulichen PC anschließt, dürfte die Kopplung funktionieren, indem man eine angezeigte, zufällige Tastenfolge, eingibt.

Ich befürchte nur, dass das Ganze eher wieder ein Mittel wird, um Firmeninteressen zu verfolgen und die Sicherheit der User nur eine gefühlte bleibt.

Wir brauchen mehr Cyber!

Was für ein Skandal. Kaum werden Daten von Politikern „gecybert“, „doxed“ und ins Netz geblasen, ist es ein Angriff auf die Demokratie und es müssen Gesetze gemacht, Behörden vergrößert und Qualitätssiegel eingeführt werden.

Was war bei den Datenskandalen zuvor, bei denen primär „normalsterbliche“ betroffen waren? Da hat es offenbar keinen gejuckt, weil einfach niemand von den „wichtigen“ betroffen war!?

Oder was war mit der mehrfach zerlegten Wahlmeldesoftware? War die lausige Security dort nicht viel mehr der Wegbereiter für Angriffe auf die Demokratie? Wo war Cyberhorst da, um Leute einzustellen, die es besser machen und auch noch ein Siegel draufkleben?

Aus dem aktuellen Fall sind nur wenige Details bekannt und werden es wahrscheinlich auch nicht viel mehr werden. Für mich hört es sich aber am ehesten danach an, als hätten viele der betroffenen ihren persönlichen Datenschutz nicht im Griff. Schlechte Passwörter, jeden Mist anklicken und empfindliche Daten auf den Computern anderer Leute (vulgo in der Cloud).

Was helfen uns Gesetze, wenn die Leute noch immer zu blöd sind, sichere und vor allem unterschiedliche Passwörter für unterschiedliche Dienste zu verwenden? Was bringt stärkere Behörden, wenn die Cracker unterm Radar fliegen (well, hackers gonna hack)? Was bringen uns irgendwelche teuren Qualitätssiegel, wenn diese nur Momentaufnahmen sind und man als User keine Chance hat, die Integrität und Unterschiede der untersuchten und präsentierten Software zu prüfen?

Für mich ist alles nur ein verdammtes Strohfeuer, das unser Politiker da gerade anzünden. Und Geldverschwendung obendrein.

Da wäre es vermutlich sinnvoller, einen Internetführerschein und Grundkurse in Sachen Internet- und Datensicherheit einzuführen.

Ich meine klar, jeden kann es mal erwischen – nur wenn man sieht, wie blind manche herumrennen, muss man Angst und Bange sein.

Hierzu eine kleine Anekdote aus meiner Hochschulzeit: eines Tages kam eine Mail vom Rechenzentrum, dass gerade Phishing-Attacken auf Mitglieder der Hochschule liefen, die durch eine fremde gekaperte WordPress-Installation durchgeführt wurde und man auf keinen Fall den Link klicken solle und sich schon gleich gar nicht dort einloggen solle. Auch war ein Muster einer solchen Mail angehängt. Soweit, so gut. Nur war das kein Bild, kein CopyPasta, sondern die Originalmail. Mit funktionierenden Links.

Auf freundlichen Hinweis hat der Admin die Mail dann zurückgezogen und erneut „sauber“ geschickt. Es ist nicht bekannt, wie viele zumindest auf den Link geklickt haben…

Um nun für User einen Unterschied zu machen: Wo es früher noch hieß, dass Passwörter oft geändert werden sollten und kryptisch sein müssen, zum Beispiel, indem man Sätze verendet und Leetspeak o. ä. appliziert – so wird aus dem Satz „Das ist das Haus vom Nikolaus“ das Passwort „DidHvN“ oder „D!d4vN“, hat einer der alt eingesessenen Passwortevangelisten (mir fällt der Name gerade nicht ein) seine damalige Empfehlung korrigiert. Wenn ich mich richtig erinnere ist es besser, einfach den kompletten Satz zu verwenden, „Das ist das Haus vom Nikolaus“. Denn: So ein Passwortcheck ist mein Mastermind, das sagt „Zeichen ist vorhanden aber an der falschen Stelle“, sondern einfach nur „true“ oder „false“. Klar, mit Wörterbuchattacken kann man immer noch arbeiten, aber auch die werden bei langen Passwörtern langsam schwierig; und ja, ein Beobachter hat es bei „korrigierbaren“ Passwörtern auch einfacher und kann sich den Sinn erschließen. Aber da gilt die Regel: Lass dir nicht über die Schulter schauen!

Das Problem an häufigen Passwortänderungen ist, dass sie dann entweder trivial oder unter die Tastatur geklebt werden. Lieber ein anständiges Passwort, das zwar nicht so oft geändert wird aber dafür auch nicht irgendwo notiert wird.

Zum Thema Cloud bin ich immer noch der Meinung: „(wenn überhaupt:) Traue nur einem Computer, den du aus dem Fenster werfen kannst“ und: „Es gibt keine Cloud, es gibt nur Computer anderer Leute“ (ok, war schon oben). Sprich: Man kann nur die Kontrolle über die Daten haben, die man bei sich hat. Seid Datensparsam, lagert Daten im öffentlichen Raum, die auch jeder sehen darf.

Auch müssen sich die Firmen – und da schweife ich mal in Richtung Hacking und Datenlecks ab – endlich mal ändern. Ich hatte es bis jetzt nicht nur einmal, dass auf eine Meldung einer Sicherheitslücke entweder gar nicht oder mit „kann gar nicht sein“ reagiert wurde. Teilweise wurde erst nach einem Proof of Concept Initiative ergriffen. Und dann nicht mit „ja, wir haben ein Problem, wir analysieren es“, sonder mit „wie haben Sie das gemacht??ß?sz?“. Denen hat also nicht der Hinweis „ihr habt da und da ein Problem“ gereicht, sondern brauchten auch noch eine Erklärung.

Das dreisteste, was ich dabei erlebt hatte war dann ein Admin, der mich nach der „Sicherheitsberatung“ und dem Schließen der Lücke durch deren Enwicklungsdienstleister bat, den Fix zu verifizieren. Anhand der Blackbox. Auf meine Antwort, dass das ohne Einblick in die Quellen sinnlos wäre und dass ich ihm keinen Code-Review schenken werde, kam nichts mehr zurück.

Liebe Firmen, nehmt bitte endlich Meldungen zu Bugs und Vulnerabilities ernst und schaut erst einmal selbst nach, wenn ihr Hinweise bekommt! Viele, die etwas entdecken, erwarten keine Gegenleistung, dafür dürft ihr aber nicht erwarten, den A… hinterhergetragen zu bekommen.

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)

Die meisten Daten haben überlebt

Noch ein kleines Update zum letzten Beitrag: Nach vielen On-Off-Zyklen der Festplatte war ddrescue bei 100 % aber doch nicht fertig.

ddrescueview zeigte folgendes:

416,24 GB wiederhergestellt, aber knapp 84 fehlen noch. Hm, das ist ungewöhnlich schlechte Ausbeute, vor allem weil so große Blöcke fehlen. Da muss ich etwas falsch gemacht haben.

Ich höre schon meine alte Ausbildungskollegin schreien „manpage, MANPAGE!!!“

ddrescue läuft mit den Parametern (Reihenfolge zu Dramaturgiezwecken geändert)

-f -r10 -v -n

-f: force overwrite of outfile, braucht man, wenn auf eine Partition geschrieben wird
-r10: Exit after the given number of retry passes
-v: Verbose mode
-n: Skip the scraping phase

Vielleicht sollte ich das letzte weglassen 😉

Gesagt, getan – und ddrescue läuft weiter. Im Schleichmodus werden die restlichen Daten zusammengekratzt. Um diese Schleichfahrt nicht zu blockieren, habe ich den Knockout meines Scripts auf 2 Stunden gesetzt. Nach ein paar weiteren Tagen sieht es wie folgt aus:

Das würde ich als Erfolg bezeichnen. Mit dem Hintergrund, dass die erste Partition der Platte eine versteckte EFI-Partition mit 200 MB ist, sollten die Userdaten vollständig lesbar sein.

Das Volume ließ sich dann auch wieder mounten. Um auf Nummer sicher zu gehen, habe ich aber trotzdem noch ein Image der Partition gezogen.

dd if=/dev/sdxy of=/media/foo/bar/image.bin bs=64K

macht den Job. Wichtig ist, die Blocksize anzugeben, da sonst gefühlt Byteweise kopiert wird und so der Durchsatz unterirdisch ist – ohne Parameter dümpelte der Kopiervorgang von USB 2.0 nach USB 2.0 mit 4 MB/s herum, mit 64K bei 38 MB/s. Mehr geht über die Schnittstelle fast nicht.

ddrescue. aggressiv.

„Nein“ wäre die richtige Antwort gewesen. „Nein“ zur Frage, ob ich eine Festplatte wiederherstellen kann, die vor meinen Augen nochmal fallen gelassen wurde.

„Macht der das was?“

JA, verdammt nochmal – Festplatten (also „klassische“ mit Magnetscheiben) sind mechanisch empfindliche Komponenten.

Naja. Eine zweite Platte für die Wiederherstellung hat er immerhin schon besorgt, also versuche ich mein Glück. Also ein Live-Linux in das olle Thinkpad geworfen und ddrescue gestartet.

Quelle: 500 GB 2,5 Zoll Western Digital Blue, Ziel: 1 TB 2,5 Zoll Seagate.

Zunächst ging es auch ordentlich schnell und ich dachte, der begrenzende Faktor wäre das USB 2.0 am Rechner. Doch auch mit der extra georderten USB 3.0 Expresscard ging es nach ein paar Klimmzügen (zusätzliche Versorgung der Festplatten) nicht wirklich schneller.

Nach den ersten paar Gigabyte sackte die Leserate aber auf mehrere 100 kByte/s ab. Nicht so schlimm, wäre da nicht folgendes Geräusch:

(das nach 10 Sekunden)

Wäre da nur das Geräusch, könnte man vielleicht noch damit leben, aber ddrescue macht nur noch eines: Fehler für Runde zwei melden. Das bringt einen nicht weiter. Also Platte weg und wieder ran. Die ersten paar Stunden mache ich das noch manuell, dementsprechend haben sich knapp 100 GByte Lesefehler und ein wenig Frustration angesammelt. Grmpf. Dabei fiel auf, dass die ersten 30 Sekunden die Übertragungsrate mit 15-30 MByte/s noch relativ hoch war, danach sank sie schlagartig ab und schwankte zwischen 65 und 300 kByte/s.

In einer Woche (Abends, musste in der Nähe sein) kamen so etwa 90 GByte von Platte A auf Platte B. 150 GByte wurden als nicht lesbar markiert.

Um nicht dauernd den USB-Stecker ein- und ausstecken zu müssen, habe kam eines meiner Schubladen-Projekte zum Einsatz, der (verbuggte) USB-Switch. Mit einem Mit einem TS3USB221 (sehr klein und bescheiden zu löten) und einem IRLML2244 lässt sich das angeschlossene Device mit dem PC verbinden und trennen. Die Verbindungsfolgen werden erwartungsgemäß nicht eingehalten und durch einen Denkfehler und zu wenig Koffein schaltete die aktuelle Version entweder die Versorgung oder USB durch. Fädeldraht hat es zumindest vorübergehend gerichtet. Mit einem Schalter ausgestattet bleiben nun die Stecker heile.

Aber zurück zur Datenrettung. Zwei Gedanken: Die Platte alle 30 Sekunden pauschal zu trennen erhöht zwar die Datenrate, aber auch die elektromechanischen Zyklen, was der Lebensdauer nicht wirklich zuträglich ist. Gleichzeitig kommt die Platte nach einem Aussetzer nicht mehr hoch. Sie muss neu gestartet werden. Das kann man überwachen, indem man die Größe der Logfile von ddrescue prüft. Wächst diese stark an, ist etwas im faul. Ferner beendet sich ddrescue automatisch, wenn die Platte sich komplett abwirft.

So viel zum Wissen, aber wie kommt diese Information zum USB-Switch? Am einfachsten wäre es ja, den USB-Port selbst aus- und wieder einzuschalten. Geht in manchen Systemen, aber eine mittelkurze Recherche zeigte: die Erfolgschancen sind eher gering.

Also doch irgendwie anders. Hm. Der Laptop ist zu jung für den Parallelport, einen Microcontroller dafür zu programmieren ist mir ehrlich gesagt auch zu blöd. Hm, DTR und RTS lassen sich doch üblicherweise durch Software schalten und einen USB<>UART-Wandler, bei dem zumindest RTS herausgeführt ist, liegt auch herum.

Unter Linux ist doch alles eine Datei, also sollte es doch ein Leichtes sein, das Flag zu setzen. Leider nicht ganz. ioctl macht zwar genau das, aber es ist nicht persistent. Sobald das Programm sich beendet, wird der Port geschlossen und RTS/DTR ist wieder low. über stty schafft man es zwar auch irgendwie, aber mein Shell-Script begann eh anfangen, ziemlich übel zu stinken.

Nachdem desinfec’t mit Python kommt – warum nicht damit? Mit pyserial kann ich zumindest unter Windows schon einmal alles machen, unter Linux klappt es auch auf Anhieb.

Mittlerweile sieht das Setup so aus:

Die Platte liegt (ich weiß, nicht ganz ideal) auf einer Schütte, der Lüfter hält sie kühl. Am Notebook hängt der USB-Stick mit Scripts und Log (wichtig, da im Notebook kein persistenter Speicher ist), daneben der USB-Switch, der mit dem RTS des USB<>UART-Wandler verbunden ist.

Das Python-Script macht aktuell folgendes:

Verbinden der Platte und warten, bis /dev/sdx (also die Platte) existiert. ddrescue mit den entsprechenden Parametern als subprocess starten. Während es läuft, also .poll() des Prozesses keinen Exitcode ausweist. Weiter wird geprüft ob die Logdatei anschwillt. Dank Caching ist das leider nicht ganz so zielführend, aber immerhin. Das dritte Kriterium ist die Laufzeit. Ist die Datenrettung länger als 10 Minuten aktiv, naja – ich bin nicht stolz drauf. Tritt eine der drei Bedingungen ein, wird die Platte getrennt und gewartet (falls nicht schon passiert), bis ddrescue fertig mit dem Schreiben der Logdatei ist. Nach einer weiteren Wartezeit geht das Spiel von vorne los:

rescue.zip (weil WordPress mir Python-Scripts verbietet)

Für Schäden, die das Script verursachen kann, übernehme ich keine Haftung.

In nicht ganz 24 Stunden sind so nun weitere 130 GByte in Richtung Ersatzplatte gewandert. „Nur“ 35 weitere Gbyte wurden als defekt markiert.

Ob die Aktion erfolgreich gewesen sein wird, kann ich erst in knapp 280 GByte sagen und hoffe, dass auch so viel davon gelesen werden kann.

Abschließend kann ich nur mal wieder sagen: Kein Backup? Kein Mitleid!

Sichere Verbindung

Ich hab mir schon länger überlegt, ein Zertifikat zuzulegen. Aber egal ob extern zugekauft oder selbst-signiert, es hätte monatlich auffallend gekostet, u. a. weil mein Hoster eine eigene IP zuweist. Schlussendlich hielt ich es dann doch für weniger notwendig, verschlüsselte Verbindungen anzubieten, da hier – vielleicht etwas naiv gesprochen – eher weniger schützenswerte Informationen gibt.

Nun hat Hetzner eine Partnerschaft mit einem bekannten Antiviren-Software-Hersteller abgeschlossen und bietet zumindest für ein Jahr kostenlose Verschlüsselung für jeden an. Nach der Antwort meiner Rückfrage nach versteckten Kosten habe ich gleich das Zertifikat beantragt. Zwar kam beim ersten Versuch eine Fehlermeldung, aber

Finde ich richtig klasse und hoffe, dass das Angebot in der Form beibehalten wird!

Jetzt müssen nur noch ein paar Links zwischen Blog und Wiki angepasst werden, damit man in der jeweiligen Variante bleibt.

BadUSB gone worse!?

Vor zwei Jahren präsentierte Karsten Nohl auf der Black Hat seinen Vortrag über BadUSB. Auf dem Chaos Communication Congress danach wurden, wenn ich mich richtig erinnere, USB-Sticks verteilt, deren Firmware sich einfach anpassen lässt. Von konkreten Angriffen habe ich bis jetzt von nichts gehört, trotzdem ist die „Bedrohung“ durchaus real.

USB macht seinem Namen alle Ehre – der Anschluss ist extrem universell und den Geräten sieht man nicht an, als was sie sich gegenüber dem PC anmelden. Dazu kommt, dass jedes Device nicht auf eine Funktion beschränkt ist, was grundsätzlich nichts böses ist und in manchen Fällen sogar zwingend erforderlich ist. Hier fängt aber auch das Problem an: Ein USB-Stick kann neben dem Massenspeicher auch noch ein einen Endpunkt haben, der z. B. eine Netzwerkkarte mimt. Diese kann dann den Datenverkehr belauschen und interessantes in einen unsichtbaren Bereich des Speichers ablegen. Hat der Angreifer keinen physischen Zugriff auf das Gerät, kann aber auch einfach nur der DNS umgebogen werden.

Einfacher und auf den ersten Blick weniger fatal wäre, wenn der USB-Stick auch eine Maus implementiert und den Cursor alle paar Minuten um einen Pixel verschiebt. Wären da nicht die User, die ihren PC nicht manuell sondern durch den Bildschirmschoner sperren lassen – und schon hat ein dritter zumindest Benutzerrechte. Genauso mit einer emulierten Tastatur. Wer tiefer gehen will, kann auch DMA nutzen und somit (mehr oder weniger) direkt auf den Speicher des PCs zugreifen.

Gegenmaßnahmen gab es bis jetzt keine praktikablen. Aber das USB-IF blieb nicht untätig, wie heise berichtet. Dennoch halte ich das für den falschen Weg. Wie bereits im dortigen Forum bemängelt wird, öffnet das Tür und Tor, USB bzw. Zubehör in Apple-Manier zu verdongeln – was aus Nutzersicht nur Nachteile bringt. Zudem muss wieder mal eine Crypto- und Zertifikatsinfrastruktur aufgebaut werden, die, wie wir alle gelernt haben, wahrscheinlich irgendwann geknackt wird und somit Angreifer wieder einen Vektor haben – denn ganz ehrlich: Wenn sich das Ziel sich lohnt, findet sich auch ein Weg. Ich verweise einfach mal auf die prominenten Beispiele DVD und HDCP.

Mein Vorschlag wäre deutlich pragmatischer: eine Firewall für den Host. Wird ein USB-Gerät (das erste Mal) eingesteckt, wird es zwar enumeriert aber nicht eingebunden. Der Benutzer bekommt angezeigt, welche Device-Klassen implementiert sind und wählt Zulassen oder Verweigern. Zur Unterstützung könnte das Betriebssystem auch anzeigen, ob die Funktionen plausibel wären – z. B. dass eine Maus mit RNDIS (Netzwerkinterface) dubios ist. Das schöne wäre, dass dies nicht nur für den USB-C-Type-Stecker, sondern für alle anderen USB-Versionen und komplett plattformunabhängig funktionieren könnte. Natürlich mit der Einschränkung, dass der Nutzer mit einer Meldung belämmert wird, die er unter Umständen nicht versteht. Vielleicht ist das mit den Zertifikaten doch nicht so schlecht. 😉

Keyless, bequem und weg.

Vor einer Weile hatte heise den Artikel „Keyless gone“ in der c’t. Neu war mir die Thematik zu dem Zeitpunkt nicht. Leider.

Vor einiger Zeit wurde der SUV unseres Nachbarn heimlich still und leise vom Hof gefahren. Gemerkt wurde es erst, als es zu spät war. Obwohl ich im Schlaf relativ geräuschempfindlich bin (und auch öfter vom Öffnen ihres Tores aufgewacht bin), war in der Nacht nichts. Der Großstadt-Panzer war weg und ward nie mehr gesehen.

Eine Weile später hatte ich leihweise ein nicht ganz schlecht ausgestattetes Fahrzeug übers Wochenende, eben auch mit diesem System. Leider war die Karre zu groß für die Garage, also blieb sie vor dem Haus stehen. Normalerweise ist Abends am Wochenende tote Hose in der Straße, doch genau an dem Abend hielt ein Fahrzeug direkt von unserem Haus, das mir durch Zufall aufgefallen ist. Nachdem es eine Weile dort stand, hab ich einfach mal rausgeschaut. Insassen: 2 Männer mittleren Alters, die abwechselnd und emsig zum Handy griffen. Das Kennzeichen konnte ich bis auf die ersten zwei Zeichen nicht richtig lesen, vom Schriftbild war es kein deutsches. Nachdem das Fahrzeug sehr langsam davon rollte, ging bei mir der Adrenalinpegel nach oben.

Die Polizei konnte aufgrund des fehlenden Tatbestandes (verständlicherweise) nichts machen, hat aber gesagt, dass sie patrouillieren (was sie dankenswerterweise auch gemacht haben) und ich versuchen sollte, es sicher unterzustellen. Wurde auch getan. So richtig wohl war mir trotzdem nicht.

Auch wenn es mich interessiert hätte, ob es einen weiteren Besuch auf Nimmerwiedersehen gegeben hat, war ich aufgrund einer Feier am Tag zuvor zu müde, um mich auf die Lauer zu legen.

Da ich in der Branche unterwegs bin, habe ich in der Arbeit mal gefragt, ob es seitens der Hersteller Interesse darin besteht, Diebe und deren Werkzeuge durch einen Honeypot dingfest zu machen, kam die Antwort: nein, kein Interesse.

Nachdem Mercedes Benz heute die neue E-Klasse vorgestellt hat, und der lokale Händler nur zwei Häuser von meinen Eltern ist, die ich besucht habe, bin ich kurz vorbei. Ohne den Transponder hat in dem Schiff (außer der Anzeige, dass der Schlüssel fehlt) nichts funktioniert – nicht einmal das Radio konnte man einschalten. Nachdem der Händler den Schlüssel brachte, habe ich ihn darauf angesprochen, ob sich bei der Sicherheit schon etwas getan hat. Seine Antwort war sinngemäß, dass er es für nahezu unmöglich hält. Zudem sei es ja illegal und mit großen kriminellen Energien verbunden, so ein System zu umgehen. Aber er sei kein Informatiker [sic] und kann deswegen auch nicht mehr sagen. Der offizielle Sprech ist aber, dass – sofern man beide Schlüssel aber kein Auto mehr hat – der Verlust von der Kasko abgedeckt ist.

Ehrlich gesagt: Unsinn. Alleine durch die Messung der Laufzeit könnte man die wohl am häufigsten angewendete Repeaterattacke (das passende Kuchenblechmafia-Video aus Frontal verlinke ich nicht) mit großer Sicherheit abwehren. Weitere Methoden (aber sicher nicht alle) sind auf Wikipedia zu finden.

Warum wurde das bis jetzt noch nicht gemacht? Ich denke: es funktioniert ja und eine Neu- bzw. Weiterentwicklung kostet Zeit und Geld. Ein gestohlenes Auto kostet dem Hersteller erst einmal nichts, sondern bringt eher Umsätze ein. Dazu kommt, dass momentan wohl noch kein Hersteller etwas sichereres hat. Folglich: kein Handlungsbedarf, solange es von keiner Stelle was auf den Deckel (siehe „Dieselgate“) gibt. Auch wenn aktuell schon an einem Nachfolgesystem gearbeitet wird, Automotive-Entwicklungen dauern. Vor allem das Überprüfen auf Tauglichkeit in der rauen Umgebung ist nicht zu unterschätzen.

Obwohl es sehr bequem wäre, habe ich mich bei meinem neuen Auto bewusst gegen diese Komfortfunktion entschieden. Wobei mein Fahrzeug für Diebe sowieso uninteressant wäre 😉