Announcement: there is an English version of this forum on Suche einen sehr simplen USB-Tester, der nur Datenbewegungungen anzeigen soll. Ein kleines Gerät, das nur in serie dazwischen geschaltet wird und anzeigt, dass Daten IN/OUT übertragen werden. Ich habe öfters das Problem, dass beim Updaten irgendwelcher Geräte ich nicht erkennen kann, ob der Ladevorgang gesperrt ist (z.B. firewall), noch läuft oder sich die SW aufgehängt hat. Grüße
:
Bearbeitet durch User
Benutze einen Logic Analyser (LA) mit Protokolldekoder. Bei USB findet immer (1x pro ms) eine Übertragung des SOF (Start-Of-Frame) statt, und bei USB2.0 High Speed kann man nicht mehr so einfach was dazu klemmen ohne sich HF Probleme einzufangen.
Jim M. schrieb: > Benutze einen Logic Analyser (LA) mit Protokolldekoder. > > Bei USB findet immer (1x pro ms) eine Übertragung des SOF > (Start-Of-Frame) statt, und bei USB2.0 High Speed kann man nicht mehr so > einfach was dazu klemmen ohne sich HF Probleme einzufangen. Danke! Werde so verfahren.
Vielleicht habe ich das Problem falsch verstanden. Aber Wireshark kann doch USB mitloggen. Reicht das nicht?
Hans-Uwe F. schrieb: > ob der Ladevorgang gesperrt ist (z.B. firewall) Welche Firewall blockiert spontan USB-Übertragungen (nachdem selbige schon gestartet wurde)?
Niklas G. schrieb: > Hans-Uwe F. schrieb: >> ob der Ladevorgang gesperrt ist (z.B. firewall) > > Welche Firewall blockiert spontan USB-Übertragungen (nachdem selbige > schon gestartet wurde)? Welche Firewall interessiert sich überhaupt für USB-Traffic? Die Antwort ist natürlich: keine. Das Problem ist, dass Vollhonks solche Sachen wie "Endpoint-Protection" mit Firewall gleichsetzen. Ja klar, eine Firewall kann Bestandteil so einer "Endpoint-Protection"-Software sein. Aber nur ein kleiner. Und eben insbesondere keiner, der sich irgendwie um USB-Traffic kümmert. Der Vollhonk muss also die Karten auf den Tisch legen: Welche "Endpoint-Protection" wird da verwendet. Und warum spricht die an? Das wird vermutlich einen guten Grund haben... Und: den Angreifer möglichst nicht erkennen zu lassen, dass er aufgelaufen ist, ist "state of the art" solcher Lösungen. Die sind nämlich gerade dazu gedacht, es Angreifern möglichst schwer zu machen. Dazu gehört auch, die Erkennung des Erfolgs oder Nichterfolgs eines Angriffs über den Angreifer-Kanal möglichst schwierig zu gestalten. Denn das ist eine Information, die der nutzen könnte, um seine Angriffs-Strategie zu verbessern...
Eine Möglichkeit zur geistigen Hygiene: PCs, auf denen irgendein Schlangenöl installiert ist, ignorieren. Die sind für andere Leute mit anderen Mindsets.
Ob S. schrieb: > Und: den Angreifer möglichst nicht erkennen zu lassen, dass er > aufgelaufen ist, ist "state of the art" solcher Lösungen Gibt es denn überhaupt Angriffe bei denen eine Custom-Software über ein Custom-Protokoll auf ein Custom-Gerät zugreift? Dazu müsste der Angreifer ja sowieso schon nahezu Vollzugriff auf das System haben. Macht es Sinn davor zu schützen? Also dass die "Endpoint-Protection" die ersten paar Transfers (zur Initialisierung) durchlässt und dann keine mehr? Wie kann so eine Software überhaupt so ein Custom-Gerät simulieren - die werden ja wohl kaum jedes einzelne exotische Gerät simulieren können. Das könnte ich mir höchstens bei Geräten vorstellen, welche MSC oder CDC für ihre Firmware-Upgrades nutzen.
Niklas G. schrieb: > Gibt es denn überhaupt Angriffe bei denen eine Custom-Software über ein > Custom-Protokoll auf ein Custom-Gerät zugreift? Der primäre Angriffsvektor bei USB-Geräten wird über HID (Mäuse & Tastaturen) gehen, und wenn die zum Nachladen von Code dann Eigenleben entwickeln (und z.B. sich als weiteres Gerät ausgeben), dann kann so etwas gegeben sein. Möglich ist halt alles, aber das ist nicht der Punkt. Das Schlangenöl soll Sicherheit und Schutz vorgaukeln, und fummelt deshalb überall an allen möglichen Stellen im System herum. Daß prinzipiell in kritischen Umgebungen nicht einfach jeder dahergelaufene Depp irgendwelche USB-Geräte anschließen darf, das ist eine nachvollziehbare Überlegung. Und das betrifft auch HID-Geräte; es darf an einem kritischen PC eben auch nicht einfach eine andere Tastatur oder eine andere Maus auftauchen. Wären die Hard- und Softwarehersteller hier an tatsächlicher Sicherheit interessiert, würden sie HID-Geräte konstruieren, die einen zusätzlichen USB-Deskriptor mit einer kryptographisch gesicherten eindeutigen Seriennummer haben. Üblicherweise hat Trivialkram wie HID-Geräte gar keine Seriennummer, so daß ein Tausch kaum oder gar nicht erkannt werden kann. Aber das ist ein anderes Thema; ich bleibe dabei: Um PCs mit irgendeinem Schlangenöl drauf macht man einen Bogen.
Harald K. schrieb: > Der primäre Angriffsvektor bei USB-Geräten wird über HID (Mäuse & > Tastaturen) gehen Kann so eine normale Windows-Software überhaupt direkt auf die zugreifen?! Harald K. schrieb: > Und das betrifft auch HID-Geräte; es > darf an einem kritischen PC eben auch nicht einfach eine andere Tastatur > oder eine andere Maus auftauchen. Ja aber das ist ein ganz anderer Fall. Harald K. schrieb: > Aber das ist ein anderes Thema; ich bleibe dabei: Um PCs mit irgendeinem > Schlangenöl drauf macht man einen Bogen. Die Wahl hat nicht jeder. Wenn es um Firmen-PCs (vom Kunden) geht...
Niklas G. schrieb: > Kann so eine normale Windows-Software überhaupt direkt auf die > zugreifen?! Drück' mal auf Deiner Tastatur eine Taste. Was passiert?
Niklas G. schrieb: > Kann so eine normale Windows-Software überhaupt direkt auf die > zugreifen?! Frag einfach andersrum: Welche Windows-Software reagiert nicht auf Maus-/Tastatureingaben? Das widerspricht der Idee eines GUI.
Harald K. schrieb: > Drück' mal auf Deiner Tastatur eine Taste. Was passiert? Das Event geht zum USB-Subsystem im Kernel, dann zum HID-Subsystem ebenfalls im Kernel, dann zur Event-Behandlung, dann eventuell zur Anwendung oder sonst so wo hin. Darüber kann man kaum Informationen an das Gerät schicken und exfiltrieren. Keylogger gibt es natürlich, aber das ist ne ganz andere Ebene und von USB unabhängig.
Niklas G. schrieb: > Darüber kann man kaum Informationen an > das Gerät schicken und exfiltrieren. Du kennst WinUSB? Das macht ähnliches wie libusb ...
Harald K. schrieb: > Du kennst WinUSB? Das macht ähnliches wie libusb ... Natürlich. Damit kann man nicht so ohne Weiteres auf USB-Geräte zugreifen. Dazu muss man dem Gerät den Treiber zuweisen wofür man Admin-Rechte braucht. Und ob das bei Geräten der Standardklassen (HID) geht weiß ich nicht
Niklas G. schrieb: > Harald K. schrieb: >> Du kennst WinUSB? Das macht ähnliches wie libusb ... > > Natürlich. Damit kann man nicht so ohne Weiteres auf USB-Geräte > zugreifen. Dazu muss man dem Gerät den Treiber zuweisen wofür man > Admin-Rechte braucht. Und ob das bei Geräten der Standardklassen (HID) > geht weiß ich nicht Treiber braucht's gar nicht. Malicious ARM HW-Stack als HID device registrieren/ausgeben, in USB port einstecken; rapid Keystrokes generieren das Umschreiben/Umleiten von URL's in Brower Bookmarks, aufrufen von Webseiten / Services, sammeln von Passwörtern aus dem User-Space und das Ganze via T/FTP hochladen, etc... gazillion of Möglichkeiten.
Andreas B. schrieb: > Treiber braucht's gar nicht. Malicious ARM HW-Stack als HID device > registrieren/ausgeben Das ist eine völlig andere Art von Angriffsszenario. Eine Software die unbekannte HID-Geräte blockiert wird wohl kaum das Problem des TO auslösen.
Niklas G. schrieb: > Eine Software die > unbekannte HID-Geräte blockiert wird wohl kaum das Problem des TO > auslösen. Eine Software, die irgendwie im USB-Stack rumpfuscht, was eine Eigenschaft von "Endpoint Protection"- oder ähnlichem Schlangenöl ist, kann natürlich irgendwas bewirken. Und wenn sie dann auch noch eine formschöne Meldung anzeigt, "Unser Superschlangenöl hat sie soeben vor 13.2 Sicherheitsrisiken der Marke W32.Total-User.Integration.Insecure.Trojan/Virus/Crapware und drölfzig Attacken aus dem Internet geschützt" anzeigt, dann ist doch alles super.
Harald K. schrieb: > Eine Software, die irgendwie im USB-Stack rumpfuscht, was eine > Eigenschaft von "Endpoint Protection"- oder ähnlichem Schlangenöl ist, > kann natürlich irgendwas bewirken. Ja, genau das ist der Zweck. Und was das "Schlangenöl" betrifft: Derartige aufgepfropfte Einschränkungen sind "state of the art". Auch bei Linux z.B. Dort muss man sie nur oft nicht extra kaufen. Dafür sind sie dann dort auch nur unkomfortabel und nicht dezentral konfigurierbar. > Und wenn sie dann auch noch eine > formschöne Meldung anzeigt, "Unser Superschlangenöl hat sie soeben vor > 13.2 Sicherheitsrisiken der Marke > W32.Total-User.Integration.Insecure.Trojan/Virus/Crapware und drölfzig > Attacken aus dem Internet geschützt" anzeigt, dann ist doch alles super. Naja. Der Benutzer vor Ort bekommt natürlich garnichts angezeigt. Der Administrator des "Schlangenöls" aber sehr wohl: Nämlich: dass ein USB-Gerät (mit ausführlicher Auflistung aller zum Zeitpunkt des Blockens verfügbarer Informationen darüber) stillgelegt wurde, weil es verdächtige Operationen ausgeführt hat oder auch: einem bereits bekannten Schadmuster entsprach. Im ersteren Fall wiederum mit vielen Details, im zweiten Fall mit einem Link zum Hersteller, in dem die Details gelistet werden. Und natürlich hat der Admin die Macht, den Block aufzuheben. Nur für den konkreten Zielrechner oder global für die gesamten verwalteten Rechner-Pool. Hätte es sowas damals(tm) auch schon gegeben, wäre z.B. Stuxnet schon in der ersten Stufe des Angriffs gescheitert. So sieht das aus. Da kann man von "Schlangenöl" rumheulen, wie man will. Das tuen nur die Idioten, die nicht kapieren, was das leistet und sich in gnadenloser Selbstüberschätzung zutrauen, ähnlichen Sicherheitsgewinn durch händische Konfiguration zu erreichen.
Ich bin vermutlich dem Problem auf der Spur. Der Hersteller des USB-Devices ( 3D FormLabs, Form Cure) warnt beim downloaden vor Benutzung einer Daisy Chain- Verkettung. Ich habe den Cure leider nicht direkt an die Windows11-Work-Station angeschlossen, sondern via Mehrfach-Hub. BTW: Um Servicezeiten möglichst klein zu halten, haben wir seinerzeit an den D+/D- Anschlüssen hochohmige LED-treiber angeschlossen. Meistens mit aufs PCB designed.
Ob S. schrieb: > Das tuen nur die Idioten, die nicht kapieren, was das leistet und sich > in gnadenloser Selbstüberschätzung zutrauen, ähnlichen Sicherheitsgewinn > durch händische Konfiguration zu erreichen. Damit hast Du Dich selbst ins Aus katapultiert. Nicht nur von Programmiersprachen hast Du keine Ahnung (wir erinnern uns an Dein früheres Pseudonym hier), sondern von PC-Sicherheit auch nicht. Da fällst Du auf Schlangenölbeteuerungen rein und bist selbst der an Selbstüberschätzung leidende Idiot. Naja, 's passt ja auch irgendwie ins Bild; Du bist halt im keine-Ahnung haben breit aufgestellt.
Harald K. schrieb: > Damit hast Du Dich selbst ins Aus katapultiert. Nicht nur von > Programmiersprachen hast Du keine Ahnung (wir erinnern uns an Dein > früheres Pseudonym hier) Du hast nie begriffen, dass man eine Programmiersprache wirklich beherrschen muss, um ihre Schwächen so weit zu erkennen, dass man die Sprache wirklich hassen kann. Sprich: du beherschst C nicht! Es ist wohl nur das einzige, was du wenigstens so halbwegs kannst. Weswegen dir jeder Vergleich fehlt, um wieviel besser eine Sprache sein kann... Das ist eben der Unterschied zu mir. > sondern von PC-Sicherheit auch nicht. Davon habe ich mit Sicherheit als seit Jahrzehnten aktiver und verantwortlicher Admin sehr viel mehr Ahnung als du. Witzig: ich habe dabei z.B. sogar gelernt, dass ein ganz erheblicher Anteil der Sicherheitslücken von Betriebssystem und Anwendungen gerade aus den Schwächen von C resultiert, die jede neue Programmierergeneration enthusiastisch erneut benutzt. Weil halt die Sprache konzeptionelle Voll-Scheiße ist und geradezu dazu einlädt, diese Fehler zu machen. Trotz aller zwischenzeitlicher Verbesserungen immer noch kaum mehr als ein bombastisch aufgedonnerter Macro-Assembler.
Ach ja, "C-Hater", das hast Du jetzt schön formuliert, und Dir Deine eigenen Unzulänglichkeiten schöngesoffen. Bist also nur Admin. Das ist sowas wie Sachbearbeiter. Im Amt, ganz unten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.