Paßwort aus RAM lesbar per Firewire

[MacMark]

Wenn man Zugriff auf die Hardware hat, ist der Rechner eh Toast, es sei denn die Daten sind brauchbar verschlüsselt. Offenbar werden Paßworte und Keychain-Daten unverschlüsselt im RAM gehalten bei Mac OS X. Wie machen das andere Betriebssysteme? Sind dort Paßworte im RAM verschlüsselt?

Aktueller Hintergrund:

Passware (lostpassword.com) bietet ein Tool an, mit dem man in der neuesten Version auch am Mac Anmeldepaßworte und Keychain-Inhalte per Firewire auslesen kann aus dem Hauptspeicher:
http://www.lostpassword.com/pdf/pr-110726.pdf
http://www.lostpassword.com/kit-forensic.htm

Manche Newsseiten schreiben, es ginge nur mit aktivem Autologin, aber das ist nicht so laut Passware. Egal wie man angemeldet ist, sie können es auslesen.

 

[ImperatoR]

Hast du es schon ausprobieren können? Hat das Betriebssystem keine Kontrolle über das DMA des Firewire?

 

[MacMark]

Wollte das teure Tool nicht kaufen dafür Mir sind keine Beschränkungen für Firewire-DMA auf Mac OS X bekannt. Möglich wäre es wahrscheinlich, den DMA-Zugriff zu beschränken.

 

[ImperatoR]

Eigentlich muss ja jedes Gerät erstmal den Umweg über das Betriebssystem gehen, bevor es Zugriff via DMA zum Arbeitsspeicher erhält. Zudem weißt das Betriebssystem einen gesonderten Block zu, sonst könnte ja jedes Gerät beliebig den Speicherinhalt manipulieren (was sogar noch viel schlimmer meiner Meinung nach wäre als es nur zu lesen.)

Also ich weiß nicht wie viel Wahrheit in diesem Tool steckt!

 

[Rastafari]

Offenbar werden Paßworte und Keychain-Daten unverschlüsselt im RAM gehalten bei Mac OS X.

Passworte werden überhaupt nirgends gespeichert, und entschlüsselte Zertifikate werden nach Gebrauch überschrieben.

Wie machen das andere Betriebssysteme?

Ganz genauso. Geht auch nicht anders, schliesslich sollen sie irgendwie funktionieren.

bietet ein Tool an, mit dem man ... Inhalte per Firewire auslesen kann

Firmware-Kennwort aktiviert --> DMA-Filter auf FW gesetzt. Schluss mit lustig.

 

[MacMark]

Das heißt, Passware lügt?

The Mac OS vulnerability relates to user login passwords that are stored in the system memory even if the computer is locked or put into a sleep mode. Passware Kit Forensic v11 captures live Mac computer memory over FireWire and analyzes it, extracting these passwords. The process takes a few minutes, regardless of the password strength and use of a FileVault encryption. The vulnerability is present in all modern versions of Mac OS, including Mac OS X 10.6 Snow Leopard and the latest Mac OS X 10.7 Lion, released last week.

http://www.lostpassword.com/pdf/pr-110726.pdf

Wenn man das Firmware-Kennwort nutzt, wird ein DMA-Filter für Firewire gesetzt? Wie sieht der aus? Ist das irgendwo dokumentiert?

 

[Rastafari]

Das heißt, Passware lügt?

Nein, sie erzählen nur die halbe Wahrheit. Oder die Hälfte der Hälfte.
Sie lesen Hashes aus - die man anschliessend per Rainbow-Tables auf Kollisionen prüfen, oder eben einfach wieder woanders injizieren muss.
Und da das ganze auch via USB2/3 geht, auf nahezu ausnahmslos jedem PC...

 

[naich]

Sie lesen Hashes aus

So werden die doch eh auch auf der Platte gespeichert. (?)

Also man benutze einfach ein entsprechend kompliziertes Passwort...

Und da das ganze auch via USB2/3 geht, auf nahezu ausnahmslos jedem PC...

Mit USB 2 kann man ohne "Mitwirken" des Systems auf dem RAM oder Festplatte zugreifen? Das wäre mir neu, sollte sowas durch das Master-Slave-Verhalten des USB Protokolls nicht verhindert werden?

 

[Rastafari]

So werden die doch eh auch auf der Platte gespeichert.

Nicht ganz. Der interessante Wert im RAM ist durch eine weitere Iteration des Hashalgorithmus gelaufen, angereichert mit einem geheimen und maschinenspezifischen Saltwert. Nach dieser Prozedur ist der Hash "heiss", vorher ist er noch genauso vieldeutig wie auch das Kennwort, aus dem er erzeugt wurde.

Also man benutze einfach ein entsprechend kompliziertes Passwort...

Die Komplexität des Passworts verändert die Komplexität des Hashes nicht im geringsten. Der ist immer gleich komplex, auch bei einem leeren Kennwort.
Komplexe Passworte braucht man nur als Vorsorge gegen Brute-Force bzw. Lookup-Attacken. Das findet hier nicht statt, hier wird der fertige Datensatz einfach gestohlen und später 1:1 wiederverwendet.

Mit USB 2 kann man ohne "Mitwirken" des Systems auf dem RAM oder Festplatte zugreifen? Das wäre mir neu

Ein EHCI setzt immer auf einen parallel dazu existierenden OHCI auf.
Und das "OHCI" bei USB ist nun mal exakt das gleiche "OHCI" wie bei FireWire/IEEE1394. Selbe Adapterschnittstelle.
EHCI besitzen exakt die gleichen Busmastering/DMA Fähigkeiten, die auch OHCI für FW bieten. Zwar im Detail etwas anders gehandhabt, aber im wesentlichen gleich. Im Sinne der totalen Abwärtskompatibilität gilt das natürlich auch für USB 3 Controller.

sollte sowas durch das Master-Slave-Verhalten des USB Protokolls nicht verhindert werden?

Lässt sich von aussen aushebeln. (Ein dreifach Hoch den Stromsparfunktionen...)
Nach einer kleinen Spezialbehandlung mit einem geschickt modulierten 1,8 GHz Burst erwacht der PC als "Sklave" aus dem Ruhezustand und steht für beliebige Lese- und Schreiboperationen offen. Im Gegensatz zum FW-Hack bleiben hier auf Firmware- oder Treiberebene gesetzte Filter völlig wirkungslos.

 

[ImperatoR]

Und ein Firmwarepasswort hilft gegen die hier beschriebenen Angriffe? Oder bleibt nur noch die Option einen Kaugummi in entsprechende Ports zu stecken?

 

[Rastafari]

Und ein Firmwarepasswort hilft gegen die hier beschriebenen Angriffe?

Ja. Ein Kernel-Debugging via FireWire wird damit genauso verhindert wie der SU-Modus oder die Startvolumeauswahl.
(BTW: hat schon mal jemand bemerkt, dass das bei den Modellen ohne integriertes FW auch via Ethernet-Port funktioniert?)

 

[naich]

Nicht ganz. Der interessante Wert im RAM ist durch eine weitere Iteration des Hashalgorithmus gelaufen, angereichert mit einem geheimen und maschinenspezifischen Saltwert.

Verhindern gesalzene Hashes nicht die Benutzung einer vorberechneten Rainbow-Table?

Die Komplexität des Passworts verändert die Komplexität des Hashes nicht im geringsten. Der ist immer gleich komplex, auch bei einem leeren Kennwort.
Komplexe Passworte braucht man nur als Vorsorge gegen Brute-Force bzw. Lookup-Attacken. Das findet hier nicht statt, hier wird der fertige Datensatz einfach gestohlen und später 1:1 wiederverwendet.

Ich meinte damit, dass komplexere Passwörter auch größere Rainbow-Tabellen benötigen, um es knacken zu können. Aber wenn man allein den Hash-Wert zum "knacken" eines Systems verwenden kann (wie auch immer), dann ist die Komplexität natürlich egal.

Allerdings hat man dadurch immer noch nicht das Passwort im Klartext gewonnen!?

 

[Rastafari]

Verhindern gesalzene Hashes nicht die Benutzung einer vorberechneten Rainbow-Table?

De Facto - ja.
Sie können aber auch nicht verhindern, dass ein solcher entnommener Wert woanders einfach wieder injiziert wird.

Ich meinte damit, dass komplexere Passwörter auch größere Rainbow-Tabellen benötigen, um es knacken zu können.

Ja und Nein.
Du brauchst niemals DAS richtige Passwort herauszufinden - sondern für jeden möglichen Hashwert nur EINES, das noch kurz genug ist um verarbeitet werden zu können. (Und davon gibt es schier unendlich viele)
Ist die Tabelle erst mal lückenlos gefüllt, sind damit ALLE möglichen Kennworte geknackt, egal wie komplex sie waren.
Komplexe Passworte erschweren nur die Suche solange diese Tabelle noch sehr unvollständig ist, denn beim Aufbau geht man systematisch vor, von den simplen zu den komplexeren.

Allerdings hat man dadurch immer noch nicht das Passwort im Klartext gewonnen!?

Nein, und das ist auch völlig unerheblich. Keiner dieser professionellen Systemknacker hat es nötig, mit diesem Kennwort ausgestattet wieder "bei der Vordertür" reinzugehen. Man entriegelt das laufende System von innen heraus.
Bildlich gesprochen: Man öffnet keine Tür, man sprengt sie sich einfach komplett mitsamt Türstock aus dem Weg.

 

[naich]

Ja und Nein.
Du brauchst niemals DAS richtige Passwort herauszufinden - sondern für jeden möglichen Hashwert nur EINES, das noch kurz genug ist um verarbeitet werden zu können.

Klar, wenn du es hinbekommt, ne Tablle für alle möglichen Werte zu speichern...
Ich meine unkomprimiert das ja viel zu viel, ich weiß nicht wie gut Rainbow-Tables das runterbrechen können, sodass die Masse an Daten auch gespeichert werden kann.

 

[MacMark]

Nicht ganz. Der interessante Wert im RAM ist durch eine weitere Iteration des Hashalgorithmus gelaufen, angereichert mit einem geheimen und maschinenspezifischen Saltwert. Nach dieser Prozedur ist der Hash "heiss", vorher ist er noch genauso vieldeutig wie auch das Kennwort, aus dem er erzeugt wurde.
… hier wird der fertige Datensatz einfach gestohlen und später 1:1 wiederverwendet.

… Sie können aber auch nicht verhindern, dass ein solcher entnommener Wert woanders einfach wieder injiziert wird. …

Das heißt, dieser salted hash wird vom Betriebssystem selbst als eine Art "Paßwort" irgendwo verwendet?

 

[Rastafari]

Das heißt, dieser salted hash wird vom Betriebssystem selbst als eine Art "Paßwort" irgendwo verwendet?

Indirekt ja. Da zB Kerberos ständig neue Tickets ausstellen bzw verfallene erneuern muss, *muss* das entsprechende Credential zur gesamten Laufzeit gespeichert bleiben. Sog. "Single Sign On" Dienste wären sonst schlicht überhaupt nicht machbar.
Würdest du das nicht tun und stattdessen bei wirklich jedem Vorkommen einer notwendigen Authorisierungstransaktion den vollständigen Überprüfungslauf inklusive Kennwortabfrage fahren, hättest du nichts anderes mehr zu tun. Du könntest dein Kennwort gar nicht schnell genug eintippen, und schon wäre die nächste Anfrage da. Nicht sehr intelligent, oder?

 

[MacMark]

Passware sagte: "Clarification: Max OS X #Lion stores #passwords in memory after inital login even if "Automatic Login" is turned off. #passware"
https://twitter.com/passware/status/95967882923622400

Ich habe Passware deshalb direkt gefragt: "I guess you mean OS X stores salted hashes of passwords in memory not the passwords themselves."
https://twitter.com/macmark_de/status/98806503837937664

Passware antwortete: "The problem is OS X Lion keeps passwords in memory, not hashes."
https://twitter.com/passware/status/98986458790100992

Passware ist sich anscheinend sehr sicher. Kann man nicht irgendeine Form von grep auf das Kernel-Memory machen, um das zu testen mit einem bekannten Paßwort?

 

[Rastafari]

Kann man nicht irgendeine Form von grep auf das Kernel-Memory machen

Klar doch. Der Bootparameter "kmem=1" mappt das Device "/dev/kmem" in den BSD-Userspace.
Ich glaube nicht, dass ich dir (!) noch mehr dazu sagen muss, oder?


BTW
Nicht vergessen: *Physische* Adressräume. Sobald du lesend auf deine eigene I/O kommst, sage ich nur noch "Dr. Moebius" zu dir. Alles klar?

 

[MacMark]

Das /dev/kmem ist ja ein character special file. Wie liest man das am besten aus oder kopiert es. dd und cp ( scheiden anscheinend aus:

sudo dd if=/dev/kmem of=/root/kmem
dd: /dev/kmem: Bad address
0+0 records in
0+0 records out
0 bytes transferred in 0.000045 secs (0 bytes/sec)

Historic versions of the cp utility had a -r option. This implementation supports that option; however, its use
is strongly discouraged, as it does not correctly copy special files, symbolic links, or fifo's.

Alternativ: Wie stelle ich fest, an welchen Speicheradressen der Kernel liegt? Dann kann ich das hier nutzen: http://www.projectosx.com/forum/index.php?showtopic=1123

 

[Rastafari]

Das /dev/kmem ist ja ein character special file. Wie liest man das am besten aus

Mit "dd" - aber halt nur von Addressen, die auch gültig sind.

Alternativ: Wie stelle ich fest, an welchen Speicheradressen der Kernel liegt?

Der Debug-Kernel (im Debug-Modus) würde dir gleich zu Beginn eine komplette Map ins Kernel.log spucken.
Aber warum machst du dir das Leben so schwer, du bist doch sonst nicht so schwerfällig?

Installiere dir doch XXXXXX in VirtualBox, starte die VM im Debug-Modus, dann kannst du dir über Telnet (Port 5000) einen Live-Dump der gesamten VM ziehen... ...ohne Crashgefahr oder irgendwelche Mapping-Spielchen. Direkter gehts nicht mal mit echter Hardware.
Oder aber du sparst dir das - man hat dir Quatsch erzählt. Da findet sich gar nichts, in keiner möglichen Kodierung, keinem denkbaren Alignment, weder als BE noch als LE. Nada.
Längst abgegrast, schon anlässlich des angeblichen FileVault-Bugs - der auch nie real demonstriert werden konnte.