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.