http://www.swr3.de/info/nachrichten/Unkontrollierbare-Sicherheitsluecken-durch-USB-Sticks/-/id=47428/did=2837526/bekwpx/
USB-Sticks scheinen eine unkontrollierbare Sicherheitslücken zu sein.
Darüber berichtet das ARD-Magazin „Monitor“ in seiner heutigen Ausgabe.
Das Magazin zeigt, wie IT-Experten mithilfe infizierte USB-Sticks ganze
Rechner ferngesteuert werden können – ohne dass Antivirenprogramme auch
nur eine Chance haben, die Schadsoftware zu erkennen.
Da bin ich aber gespannt auf die Monitor-Sendung.
Ich gehe davon aus, dass man die USB-Sticks vorher säubern kann,
und somit das Thema mich nicht betrifft
Nürnberger schrieb:> Ich gehe davon aus, dass man die USB-Sticks vorher säubern kann,> und somit das Thema mich nicht betrifftdd if=/dev/zero of=/dev/sdb
falsch.
Es geht um die Firmware von den Sticks. Diese kannst du nicht so einfach
überschreiben.
Der Trick besteht ja darin, die Firmware so zu ändern das der Stick sich
als Tastatur ausgibt und für dich einfach ein paar eingaben macht.
Wtf ?
Natürlich kann ein Usb Gerät sich als was anderes ausgeben als es
wirklich ist. Aber ist das eine Reale Gefahr? Wenn ich am Pc sitze und
sich mal eben irgendwas von aleine öffnet würde ich vermutlich recht
schnell denken das irgendwas nicht stimmt mit dem Pc. Ob ich gleich mein
usb gerät verdächtigt hätte denke ich eher nicht aber ich hätte
sicherlich irgendwas unternommen.
Zumal weiß der Stick ja nicht an was für einem Betriebsystem er gerade
steckt.
Kann man unter Windows mit Tastenkombi ein Terminal öffnen? Ich dachte
das gibts seit windows xp garnichtmehr.
Unter Linux geht das aber idealerweise ist man selten als Root unterwegs
und ohne Passwort geht dann garnix.
Und worin liegt die Gefahr wenn sich eine vIrtuelle Netzwerkkarte
erstellt?
Helfer schrieb:> Hi,> wenn es sich um die gleiche Lücke wie hier [1] handelt (was ich> annehme),> so wird deine Säuberung nicht viel ausrichten ;)>> [1]:> http://www.golem.de/news/security-angriffe-mit-usb-geraeten-1407-108252.html
Richtig. Eine "Reinigung" hilft dagegen absolut nicht.
Was mich allerdings bei diesen Meldungen ankotzt, ist, dass das als
Neuigkeit verkauft wird. Das ist ein absolut alter Hut.
1. Die USB-Spezifikation sah schon immer vor, dass ein Gerät mehrere
Funktionen bspw. MSD (Speicher) und HID (Tastatur/Maus/etc.) beinhalten
kann/dazwischen umschalten kann (Device Firmware Upgrade Class und bspw.
was anderes ist häufig anzutreffen)
2. Das Umprogrammieren von Controllern/der Firmware ist auch nichts
neues
3. Das Verstecken von Malware in Firmware z.B. in Grafikkarten, im BIOS,
in Netzwerkkarten usw. usf. ist ebenso seit Ewigkeiten bekannt
Das ist aber ein Problem eines jeden USB Gerätes. Jedes Geräten dessen
USB Controller in irgend einer Form als HID verwendet werden kann (also
jedes USB Gerät) kann für sowas missbraucht werden.
Ottzi schrieb:> Kann man unter Windows mit Tastenkombi ein Terminal öffnen? Ich dachte> das gibts seit windows xp garnichtmehr.
Der Autostart geht seit XP nicht mehr aber einen USB Stick als HID
Tastatur anmelden und WIN + R cmd [Enter] eingeben zu lassen ist
einfach.
Ottzi schrieb:> Kann man unter Windows mit Tastenkombi ein Terminal öffnen?
ja, WIN+R -> CMD [ENTER]
> Ich dachte das gibts seit windows xp garnichtmehr.
scheinbar doch
> Unter Linux geht das aber idealerweise ist man selten als Root unterwegs> und ohne Passwort geht dann garnix.
bei dem meisten reicht ein sudo davor. Und warum sollte Viren immer Root
rechte brauchen - zum lesen und löschen von deine eigenen Dokumente
braucht man sie nicht.
> Und worin liegt die Gefahr wenn sich eine vIrtuelle Netzwerkkarte> erstellt?
Man umgeht die externe Firewall und kommt auf alle dienste drauf. Man
ist damit also schon mal im "Intranet". Eventuell kann man damit sogar
den Standardgateway neu setzen und damit den gesamten Traffic mitlesen.
> Zumal weiß der Stick ja nicht an was für einem Betriebsystem er gerade> steckt.
mit etwas aufwand wird es wohl erkennen können, und wenn es nur die
Reihenfolge der Initialisierung ist.
Ottzi schrieb:> Zumal weiß der Stick ja nicht an was für einem Betriebsystem er gerade> steckt.
Wie das geht wurde sogar patentiert...
http://www.google.com/patents/US20120054372> Kann man unter Windows mit Tastenkombi ein Terminal öffnen? Ich dachte> das gibts seit windows xp garnichtmehr.
Die Kommandozeile gibt's schon: Startbar z.B. mit Win+R dann cmd und
Enter...
> Unter Linux geht das aber idealerweise ist man selten als Root unterwegs> und ohne Passwort geht dann garnix.
Na... welche Linux-Distri kennt denn keinen Recovery-Modus in den
gebootet werden kann um bspw. das root-Password zu löschen/neu zu
setzen...
> Und worin liegt die Gefahr wenn sich eine vIrtuelle Netzwerkkarte> erstellt?
Ebenso wie bei einer realen Netzwerkkarte: Sobald dort Daten drüber
laufen, könnte sich die böse (virtuelle) Karte dazwischenhängen und
beliebig Pakete verändern, umleiten etc. pp.
Peter II schrieb:> Und warum sollte Viren immer Root> rechte brauchen - zum lesen und löschen von deine eigenen Dokumente> braucht man sie nicht.
Für einen Keylogger braucht man auch kein Root. Und dann ist Root
wahrscheinlich eine Frage der Geduld.
Wie immer haben die Journalisten 20% falsch verstanden und 79%
weggelassen. Viel interessanter als das altbekannte¹ "Oh mein Gott, ein
von bösen Hackern handgefertigter USB-Stick kann Tastatur spielen" fand
ich:
1
Very widely spread USB controller chips, including those in thumb drives, have no protection from such reprogramming.
2
[...]
3
A device can emulate a keyboard and issue commands on behalf of the logged-
4
in user, for example to [...] install malware. Such malware,
5
in turn, can infect the controller chips of other USB devices connected to
6
the computer.
¹gab es vor zig Jahren nicht schon Scherzartikel im USB-Stick-Format,
die man dem Kollegen heimlich hinten in den Rechner steckte und die dann
alle paar Minuten Caps-Lock drückten oder ähnlichen Unfug trieben?
> Very widely spread USB controller chips, including those in thumb
2
> drives, have no protection from such reprogramming.
3
> [...]
4
> A device can emulate a keyboard and issue commands on behalf of the
5
> logged-
6
> in user, for example to [...] install malware. Such malware,
7
> in turn, can infect the controller chips of other USB devices connected
8
> to
9
> the computer.
10
>
>>> ¹gab es vor zig Jahren nicht schon Scherzartikel im USB-Stick-Format,> die man dem Kollegen heimlich hinten in den Rechner steckte und die dann> alle paar Minuten Caps-Lock drückten oder ähnlichen Unfug trieben?http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices
(die Präsentation ist von 2011)
Diese "“Plug and Root,” the USB Key to the Kingdom"
https://www.blackhat.com/presentations/bh-usa-05/BH_US_05-Barrall-Dewey.pdf
von 2005 beschreibt auch schon vieles, was heute als Neuigkeit verkauft
wird "ISP: Allows an attacker to “re-flash” the device with his own
information" etc. pp.
In Linux gibt es ja zum Glück die udev rules, wo man verhindern kann,
das keine anderen, als die registrierten USB-Devices mit ebenfalls zum
Device zugeordneten Funktionen ins System eingebunden werden.
Nachteil: man kann nicht mal eben schnell Stick eines Kunden mounten.
Aber dafür gibt es ja virtuelle Maschinen als Virenfänger, die man immer
wieder rücksetzen kann. ;)
Detlef Kunz schrieb:> Aber dafür gibt es ja virtuelle Maschinen als Virenfänger, die man immer> wieder rücksetzen kann. ;)
USB hängt aber am VM-Host - man muss dort nur eine Lücke ausnutzen,
schon hat man alles VMs unter Kontrolle.
Peter II schrieb:> Detlef Kunz schrieb:>> Aber dafür gibt es ja virtuelle Maschinen als Virenfänger, die man immer>> wieder rücksetzen kann. ;)>> USB hängt aber am VM-Host - man muss dort nur eine Lücke ausnutzen,> schon hat man alles VMs unter Kontrolle.
Was für eine Lücke?
Welcher Virus bricht aus welcher VM aus?
Werd mal etwas genauer.
Detlef Kunz schrieb:> Was für eine Lücke?
ich kenne keine konkrete
> Welcher Virus bricht aus welcher VM aus?
wieso muss er ausbrechen. USB hängt am Physikalischen Rechner und nicht
an der VM. Sie wird von der Software (die fehler haben kann) in die VM
reingereicht.
Schönes Beispiel firewire, dort durften Geräte per DMA dem Ram auslesen
und schreiben, damit ist man im Host und nicht nur in der VM.
USB 3.0 hat doch auch DMA wieder mit drin, eventuell wurde ja die
gleichen Fehler wieder gemacht.
Arc Net schrieb:> Na... welche Linux-Distri kennt denn keinen Recovery-Modus in den> gebootet werden kann um bspw. das root-Password zu löschen/neu zu> setzen...
Aber ich als Benutzer merke doch wenn mein system neustartet und so
sachen macht?
Sicher ist ohnehin nur der Pc der niemals mit der welt verbunden wird.
Und ich gestehe ich bin dann wohl auch ein böser Hacker... Ich habe vor
vielen jahren versucht meinem Vater klaarzumachen das er sich einen
neuen Pc kaufen sollte weil ich seinen haben wollte. Geholfen hat ein
pic an einer Usb Tastatur Platine. Alle zufalls stunden hat das ding auf
sleep gedrückt. Verdammt warum hab ich das nicht Patentiren lassen....
Peter II schrieb:> Schönes Beispiel firewire, dort durften Geräte per DMA dem Ram auslesen> und schreiben, damit ist man im Host und nicht nur in der VM.
1. Welche VM kann Firewire?
2. Der Stick wird vom Linux über meine dev-Rules nicht eingebunden.
Er erhält keine Möglichkeit zur Kommunikation mit dem Linux-System.
Selbstständig kann er keine Kommunikation durchführen, da USB ein
Master-Slave-Bus ist.
3. USB hängt nicht am physikalichen Speicher. USB ist ein Protokoll, und
wenn ich nicht mit dem Gerät sprechen will, dann kann das Gerät garnix
dagegen tun.
4. DMA hängt überall mit drin. Wenn Firewire das zugelassen hat, warum
sollten es andere machen? Firewire ist nich USB.
Also muss der Virus ausbrechen. :P
Detlef Kunz schrieb:> 2. Der Stick wird vom Linux über meine dev-Rules nicht eingebunden.
und wer wertet du dev-Rules aus? Der Kernel + UDEV. Also muss man dort
nur ein Problem finden ( mit eine nicht USB-Konformen Bezeichner eine
Buffer Overlflow erzeugen).
Es finde ja schon lange eine Datenaustausch für dem USB-Gerät statt
bevor überhaupt UDEV eine rolle spielt.
1. Welche VM kann Fireware?
sie muss es gar nicht können, es reicht wenn der Host Firewire hat.
als Alternative SD-Karten mit "geprüftem" Card-Reader verwenden.
Sicher wird hier über USB diskutiert. Aber ist denn der PC sonst auch
dicht? Das BIOS ist angeblich Hintertüren-frei, beim UEFI geht die
Paranoia um, daß welche eingebaut sind. Dann eben die
open-source-Version davon flashen. Die gibt es aber nicht für alle
Motherboards.
Bis XP wäre noch ok, darüber gibt es auch wieder Gerüchte über
Hintertüren.
Linux hat einzig den Vorteil, daß ich mir bei kritischen Recherchen oder
Banking ein Live-System starte, und auch sonst mehrere -für mich
zweckgebundene- Installationen vorhalte. Im W. Lizenzmodell ist sowas
nur schwer möglich.
Peter II schrieb:> Detlef Kunz schrieb:>> 2. Der Stick wird vom Linux über meine dev-Rules nicht eingebunden.>> und wer wertet du dev-Rules aus? Der Kernel + UDEV. Also muss man dort> nur ein Problem finden ( mit eine nicht USB-Konformen Bezeichner eine> Buffer Overlflow erzeugen).
Das ist aber ein Totschlag"argument". Mit dem Argument "man muss nur
eine Lücke finden" kannst Du jede Sicherheitsschranke kleinreden.
Tatsache ist, dass man per udev nach aktuellem Stand der Dinge in der
Tat solche Angriffe verhindern kann - um den Preis einer geringeren
Flexibilität.
> Es finde ja schon lange eine Datenaustausch für dem USB-Gerät statt> bevor überhaupt UDEV eine rolle spielt.
Was ja erstmal nichts Schlimmes ist, solange es keine Lücke im
USB-Protokoll der Kernels gibt. udev sorgt dann dafür, dass der Stick
nicht ins System eingebunden wird.
Chris D. schrieb:> Das ist aber ein Totschlag"argument". Mit dem Argument "man muss nur> eine Lücke finden" kannst Du jede Sicherheitsschranke kleinreden.>> Tatsache ist, dass man per udev nach aktuellem Stand der Dinge in der> Tat solche Angriffe verhindern kann - um den Preis einer geringeren> Flexibilität.
seit wann wurde udev als Sicherheitsschranke entwickelt?
Das man es eventuell dafür nutzen kann mag ja sein, aber dann muss man
sich nicht wundern wenn es diesen zwecke nicht erfüllt, für den es nicht
gemacht wurden ist.
Peter II schrieb:> seit wann wurde udev als Sicherheitsschranke entwickelt?
Schon immer. Es wurde damals ja gerade entwickelt, um mit erkannter
Hardware sauber und sicher umgehen zu können: eine bestimmte Festplatte
sollte auch genau dort wieder eingebunden werden usw.
> Das man es eventuell dafür nutzen kann mag ja sein, aber dann muss man> sich nicht wundern wenn es diesen zwecke nicht erfüllt, für den es nicht> gemacht wurden ist.
Es tut dabei genau das, wofür es gemacht worden ist: über entsprechende
Regeln den vom Kernel erkannten Geräten entsprechende Devices zuzuweisen
oder sonstige Aktionen durchzuführen - oder wie in diesem Fall eben
nicht und sie damit auszusperren.
Chris D. schrieb:> Peter II schrieb:>>> seit wann wurde udev als Sicherheitsschranke entwickelt?>> Schon immer.
wo steht das?
> Es tut dabei genau das, wofür es gemacht worden ist: über entsprechende> Regeln den vom Kernel erkannten Geräten entsprechende Devices zuzuweisen> oder sonstige Aktionen durchzuführen - oder wie in diesem Fall eben> nicht und sie damit auszusperren.
nur weil ein link nicht vorhanden ist, ist das doch kein aussperren.
Hast du wirklich udev schon mal so konfiguriert, das nur bekannte Geräte
einen Device eintrag bekommen?
Chris D. schrieb:>> seit wann wurde udev als Sicherheitsschranke entwickelt?>> Schon immer. Es wurde damals ja gerade entwickelt, um mit erkannter> Hardware sauber und sicher umgehen zu können: eine bestimmte Festplatte> sollte auch genau dort wieder eingebunden werden usw.
richtig, aber nicht als Sicherheitsschranke. Nur um nach dem Booten
nicht feststellen zu müssen das eth0 und eth1 sich getauscht haben.
Peter II schrieb:> Chris D. schrieb:>> Peter II schrieb:>>>>> seit wann wurde udev als Sicherheitsschranke entwickelt?>>>> Schon immer.>> wo steht das?
Das ergibt sich aus seinem Verwendungszweck.
>> Es tut dabei genau das, wofür es gemacht worden ist: über entsprechende>> Regeln den vom Kernel erkannten Geräten entsprechende Devices zuzuweisen>> oder sonstige Aktionen durchzuführen - oder wie in diesem Fall eben>> nicht und sie damit auszusperren.>> nur weil ein link nicht vorhanden ist, ist das doch kein aussperren.
Doch, denn dann greift das System nicht auf das Gerät zu und ein nicht
eingebundenes USB-Gerät kann auch keine Aktionen ausführen bzw.
mitschneiden.
> Hast du wirklich udev schon mal so konfiguriert, das nur bekannte Geräte> einen Device eintrag bekommen?
Nein - hier steckt ja niemand einen fremden USB-Stick an. Und wenn mal
einer von außen angesteckt wird, dann geschieht das schon seit Jahren
nur in einer VM. Dass USB-Sticks gefährlich sind, ist ja nicht erst seit
gestern bekannt.
Aber Du musst ja auch nicht wirklich alle Geräte aussperren. Es geht bei
dieser Bedrohung ja nur um Geräte, die Aktionen ausführen können
(Tastauren, Mäuse etc.)
Wer natürlich ganz sicher sein will, bastelt sich für jedes seiner
Geräte eine Regel und sperrt den Rest aus. Sich eine passende Regel
dafür zu basteln ist nicht wirklich schwer.
> richtig, aber nicht als Sicherheitsschranke. Nur um nach dem Booten> nicht feststellen zu müssen das eth0 und eth1 sich getauscht haben.
Oder dass eben eine USB-Tastatur nicht eingebunden wurde, weil man dies
verbietet.
Chris D. schrieb:> Tatsache ist, dass man per udev nach aktuellem Stand der Dinge in der> Tat solche Angriffe verhindern kann - um den Preis einer geringeren> Flexibilität.
Wie verhindert das, dass ein böses Gerät vorgibt bspw. eine normale
Tastatur mit passender VID/PID und allem drum und dran zu sein?
Mit deutlich mehr Aufwand wäre es z.B. auch möglich, dass ein MSD-Gerät
das Datei-System analysiert und bei Bedarf dann "gepatche"
Programmstücke liefert...
Chris D. schrieb:> Aber Du musst ja auch nicht wirklich alle Geräte aussperren. Es geht bei> dieser Bedrohung ja nur um Geräte, die Aktionen ausführen können> (Tastauren, Mäuse etc.)
und diese kennst du alle?
Auch Scanner können Aktionen auslösen. Zeichentablets fallen mir spontan
auch ein.
Auch eine USV kann eine Aktion auslösen.
Es lässt sich bestimmt etwas finden was du vergessen hast zu sperren.
Daran sollte man merken, das man hier mit eine Backlist nicht weiter
kommt.
Peter II schrieb:> Auch Scanner können Aktionen auslösen. Zeichentablets fallen mir spontan> auch ein.>> Auch eine USV kann eine Aktion auslösen.
Diese Geräte sind aber meist genau so implementiert wie die "Bösen"
USB-Sticks: Zusätzliches HID-Interface.
So eines haben auch viele USB-Festplatten, wegen "One Button Backup".
d.H. ein Filter für "MSD + HID" Kombigeräte greift einerseits zu weit,
andereseits nicht weit genug...
Übrigens geht das dann auch unter Windows, und zwar mit
Gruppenrichtlinien. Nicht, dass wieder einer denkt, nur unter Linux
könnte man die USB-Geräte mit udev bändigen. Sowas machen die Admins bei
uns auf Arbeit immer mal, zum Beispiel um jeden normalen Nutzer den
Treiber für unsere selbst entwickelte USB Hardware installieren zu
lassen...
Peter II schrieb:> Es lässt sich bestimmt etwas finden was du vergessen hast zu sperren.> Daran sollte man merken, das man hier mit eine Backlist nicht weiter> kommt.
Wenn Du Dir anschaust wie die USB-Device-Nodes aufgebaut sind, kannst Du
die udev-Regeln übrigens auch auf die einzelnen USB-Ports aufbauen. Also
Du identifizierst den Port am Mainboard, in dem immer Deine Tastatur
steckt, und whitelistest nur den für Tastatur-HIDs. An allen anderen
Ports werden Tastaturen dann ignoriert. usw.
Genauso kannst Du einen Port für unbekannte Geräte definieren und dort
wird dann nie automatisch ein Treiber zugewiesen.
Der Trick warum ich hier udev wirklich als Sicherheitskomponente sehen
würde ist, daß der Kernel jetzt mit udev selbständig keinerlei
Treiberzuweisung mehr macht. Er erkennt ein neues Device und teilt das
an udev mit. Mehr macht er von sich aus nicht mehr. Wenn udev dann der
Meinung ist dieses Device mit einem Treiber verknüpfen zu wollen, muss
es von sich aus aktiv werden und die nötigen Befehle dazu geben. Wenn Du
in udev die entsprechenden Automatiken rausnimmst passiert da in die
Richtung nix mehr.
Eigentlich bringt das re-programming doch "nur", dass der Angreifer sich
zusätzlich noch Admin-Rechte erschleichen könnte (indem er z.B. UAC per
HID-Keyboard/-Maus "wegklickt", oder als Keyboard-Logger benötigte
Passwörter (sudo, etc.) mitloggt und später nutzt.)
Damit er ein USB-Gerät re-programmen kann, muss der Angreifer ja schon
Zugriff auf die Kiste ergattert haben.
Oder sehe ich das falsch?
bluppdidupp schrieb:> Damit er ein USB-Gerät re-programmen kann, muss der Angreifer ja schon> Zugriff auf die Kiste ergattert haben.> Oder sehe ich das falsch?
klar.
Der Angriff erfolgt, in dem man dem Benutzer einen harmlos aussehenden
USB-Stick gibt und ihn dazu bringt den in den Rechner zu stecken.
Das neue ist jetzt nur, daß man dem Gerät nicht mehr so einfach von
außen ansehen kann ob es bösartig oder nicht ist. Bisher dachte man daß
man dafür einen programmierbaren µC bräuchte und wenn man das Gehäuse
des Sticks aufmacht und da nix in diese Richtung findet, wäre der Stick
harmlos.
Genauso neu ist, daß ein Virus sich in einen im Rechner eingesteckten
Speicherstick übertragen kann. Dort kann er dann alle
Desinfektionsversuche auf dem PC überdauern und den PC später wieder
übernehmen. Doch das wäre z.B. mit dem BIOS oder der Firmware der HDD
auch schon vorher möglich gewesen.
Aber letztlich war auch früher schon klar, daß wenn man USB-Sticks aus
unbekannter Quelle in den Rechner einsteckt, seine Sicherheit riskiert.
Gerd E. schrieb:> Aber letztlich war auch früher schon klar, daß wenn man USB-Sticks aus> unbekannter Quelle in den Rechner einsteckt, seine Sicherheit riskiert.
Nicht nur das, mit physischem Zugriff zum Rechner hat man in den
allermeisten Fällen sowieso verloren, egal welches OS oder welcher
Virenscanner da drauf ist. Noch "schlimmer" sind ja FireWire und
ThunderBolt, die haben (über Busmaster DMA) sogar direkten Zugriff auf
den RAM und können mit ein bisschen Intelligenz dort machen was sie
wollen. Das geht bei USB zumindest nicht, EHCI und XHCI Host Controller
haben zwar auch DMA, aber nur zwischen Controller und Speicher, ein USB
Gerät kann von sich aus keinerlei Transfers starten. Auch USB 3.0 ist
noch streng Master-Slave. Mit der steigenden Verbreitung von Thunderbolt
Festplatten usw. wirds da sicher auch interessante Tierchen geben, die
dann meist die sich immer auf der Insel der virenfreien Glückseligkeit
wähnenden Apple-Nutzer treffen könnten.
Christian R. schrieb:> Noch "schlimmer" sind ja FireWire und> ThunderBolt, die haben (über Busmaster DMA) sogar direkten Zugriff auf> den RAM und können mit ein bisschen Intelligenz dort machen was sie> wollen.
Bei Firewire ist das ja schon lange bekannt und wird auch in der Praxis
genutzt: die Polizei hat fertige Forensik-Geräte mit Firewire. Die
steckt ein normaler Polizist (also nix IT-Spezialist) bei der
Hausdurchsuchung in den laufenden aber gesperrten Rechner und drückt ein
Knöpfchen. Dann wird vollautomatisch der gesamte RAM-Inhalt auf die
beiliegenden Platten kopiert.
Firewire kann in dieser Hinsicht nicht gefixt werden, da das im
Protokoll zwingend so vorgesehen ist und nicht geändert werden kann ohne
das Protokoll fundamental umzustellen.
Doch wie ist das wirklich mit Thunderbolt? Hat Intel da tatsächlich den
selben Fehler gemacht? Ich hab mich das immer gefragt und in die
Richtung leider noch nirgends etwas belastbares gelesen. Evtl. haben die
den DMA nämlich z.B. durch die IOMMU auf vorher durch den entsprechenden
Treiber freigegebene RAM-Bereiche beschränkt.
Gerd E. schrieb:> Doch wie ist das wirklich mit Thunderbolt? Hat Intel da tatsächlich den> selben Fehler gemacht?
Was heißt Fehler? Thunderbolt ist im wesentlichen PCI Express und
Display Port, und wie jedes PCI kann das PCIe Interface da natürlich
auch BusMaster DMA. Wir haben mal eine Karte für PCI Express external
Cabling gebaut, die konnte auch auf den gesamten RAM zugreifen. Und der
PC hat sogar bei falscher Programmierung des PLX Chips versucht, von der
Karte zu Booten.
Nachtrag:
http://en.wikipedia.org/wiki/DMA_attack
Google Suche: thunderbolt dma attack
USB-Sticks als Tastatur für einen Angriff zu verwenden ist aber ein
ziemlich alter Hut. Welcher unfähige Journalist hat diese alte
Geschichte ausgegraben? Klar dass jetzt alle auf die Geschichte
aufspringen um eine Story für den DAU zu haben.
Paul M. schrieb:> USB-Sticks als Tastatur für einen Angriff zu verwenden ist aber ein> ziemlich alter Hut.
Was neu ist, ist nur dass jetzt das
Bootloader/Firmware-Upgrade-Protokoll der meistverwendeten
USB-Stick-Controller gecrackt wurde, und deshalb nun solche Angriffe
auch "ohne Lötkolben" möglich sind.
Und "von jedermann" durchführbar sind.
"Privilegierte" haben sich vorher einfach das Datenblatt/Appnotes der
Hersteller per NDA oder court order geholt, und konnten das wohl schon
immer.
Was ähnliches gabs vor einigen Jahren schonmal, als demonstriert wurde
wie man den Controller in Apple-Tastaturen "bösartig macht".
Nur haben halt Tastaturen wesentlich weniger Infektionspotential als
USB-Sticks, die werden ja nicht ständig durch die Gegend getragen...
Naja man kann es sicher alles übertreiben. Eine gewisse Vorsicht ist
sicher nicht verkehrt, aber wenn man es übertreibt, dann wird jede
Arbeit / Benutzung zur Qual.
Was ist denn überhaupt noch sicher könnte man jetzt fragen, wenn man
sich seinen Rechner anschaut, mit zig tausenden an Dateien, davon könnte
jede potentiell gefährlich sein oder?
Geht es nicht da los, in dem man sich mal überlegt, ob man dieses oder
jenes Programm wirklich braucht, wo es herkommt usw?
Jahre lang galt die Lehrmeinung geswitchte Netze seinen sicher, was so
auch nicht stimmt.
Der sicherste Rechner ist wohl immernoch der, der keine Verbindung nach
außen hat, was sich aber oft kaum vermeiden lässt
Und es ist wohl wie im richtigen Leben, man muss nicht alles überall
reinstecken, nur weils reinpasst :-)
... vielleicht liest das noch jemand: Weiss jemand etwas von einem
USB-Stick, der sich nach der Produktion nicht mehr (oder nur mit
mechanischen Eingriff) umprogrammieren lässt. So könnte ich wenigstens
verhindern, dass ich den Trojaner auf meinem privaten Stick auf meinen
heimischen PC trage.
Thx
Thomas
DEN Stick wirst Du wahrscheinlich nicht finden, weil schon der
übermorgen gekaufte von selben Typ schlicht einen ganz anderen
Controller eingebaut haben könnte.
Du brauchst doch nur in den Gruppenrichtlinien die automatische
Treiberinstallation deaktivieren.
Dann gehen nur noch die USB-Geräte, die Du davor installiert hast.
Und natürlich auf allen USB-Sticks die Verzeichnisse "$Recycle.Bin" und
"System Volume Information" durch gleichnamige Dateien ersetzen
(Textdatei anlegen und umbenennen).
Da diese vor dem User geschützt sind, lagern sich da besonders gerne
Viren ein.
Auch verhindert das, daß da jedesmal drin rumgeschrieben wird, wenn man
den Stick einsteckt.
Diese beiden Verzeichnisse dienen nur der Systemwiederherstellung. Sie
sind also völlig unnütz, wenn man nicht von dem Stick booten will,
sondern nur Daten überspielen.
Peter Dannegger schrieb:> Du brauchst doch nur in den Gruppenrichtlinien die automatische> Treiberinstallation deaktivieren.> Dann gehen nur noch die USB-Geräte, die Du davor installiert hast.
Klappt das auch für HID Geräte? d.H. wenn ich eine neue/andere Tastatur
einstecke, oder die Tastatur in einen anderen USB-Port, kann ich dann
nicht mehr tippen?
Εrnst B✶ schrieb:> Peter Dannegger schrieb:>> Du brauchst doch nur in den Gruppenrichtlinien die automatische>> Treiberinstallation deaktivieren.>> Dann gehen nur noch die USB-Geräte, die Du davor installiert hast.>> Klappt das auch für HID Geräte? d.H. wenn ich eine neue/andere Tastatur> einstecke, oder die Tastatur in einen anderen USB-Port, kann ich dann> nicht mehr tippen?
Kommt darauf an ob die USB Tastatur eine Seriennummer hat oder nicht.
Mit Seriennummer kannst du sie beliebig umstecken, aber nicht gegen eine
andere ersetzen.
Ohne Seriennummer kannst du nicht umstecken, aber eine defekte gegen
eine identische ersetzen. (VID/PID und gleiche HID Descriptoren)
>DEN Stick wirst Du wahrscheinlich nicht finden, weil schon der>übermorgen gekaufte von selben Typ schlicht einen ganz anderen>Controller eingebaut haben könnte.
Hallo,
wenn ich das richtig gelesen habe, soll es in Bezug auf das
Umprogrammieren wohl nur ein paar wenige zu implementierende
Controller-Familien geben. Deswegen soll diese Schwachstelle auch so
gefährlich sein, weil man eben davon ausgehen muss, dass der eigene
USB-Stick unabhängig von Fabrikat und Größe unbemerkt zum Wirt
umprogrammiert wird. In dem Video über den Angriff wurden auch zufällige
Delays bis zum Start der HID-Vortäuschung erwähnt, was ein Entdecken des
Angriffs noch weiter erschwert. Ich habe ehrlich gesagt kein gutes
Gefühl mehr, wenn ich meinen Trekstor-USB-Stick mit
Schreibschutz-Schalter an vielen unterschiedlichen PCs anschließe, da
der Schreibschutz hier vermutlich keinen Schutz bietet.
Von daher finde ich die Frage von Thomas mit die Wichtigste hier im
Thread:
Gibt es einen Stick, wo der Hersteller bereits reagiert und diese Art
des Angriffs unterbunden hat?
Dieter
Thread beobachten
Seitenaufteilung abschalten