Root-Passwort

[sun_starfire]

Halo,

wenn man sich ueber die secure shell per ssh auf das Openstage einloggt ist man ja der User admin, und nicht root. Sprich, man kann nicht alles. Leider ist es nicht so ganz trivial das root-Passwort herauszubekommen. Ich hab mich mal ein wenig damit auseinandergesetzt, und interessanterweise darf der user admin die /etc/group aendern, so dass man den user admin der root-Gruppe hinzufuegen kann, woraufhin der schon mal ein wenig mehr darf, aber bei Weitem noch nicht alles.

Ein su oder sudo geht ja nicht, und eine /etc/sudoers macht eher was kaputt und brickt unguenstigstenfalls das OS.

Ich habe jetzt mal mit ein wenig Herumprobieren das OS-Image der Software-Version R3V24 fuer das OS80 decoded, und mir in dem decodeten UNIX-Tree die /etc/shadow angeschaut, in der das root-Passwort verschluesselt steht. Wie die Unix-Gurus unter Euch vielleicht wissen, ist ein solches Passwort nicht decodierbar, weil es mit einem Hash oder Salt verschluesselt wird, zwei zufaelligen Chars die bei der Verschluesselung in das Passwort eingebunden werden. Um so etwas zu knacken braucht man eine sogenannte brute-force-attack, die einfach andersherum mit verschiedenen Salts verschiedene Passwoerter ausprobiert, diese verschluesselt und dann mit dem Hash-Wert in der shadow vergleicht.

Auf jeden Fall ist das mal ein Anfang, ich halte Euch auf dem Laufenden falls mir das Knacken gelingen sollte.

Ein anderer Weg waere ja auch noch, das Passwort in der /etc/shadow zu aendern, den Tree wieder in das img einzubauen und dann auf das Telefon zu spielen, welches dann Passwort-frei ist. Leider auch nicht ganz trivial, zumindest habe ich bisher kein Tool gefunden welches den Tree wieder einpackt

Toodles

s_s

 

[PeterPawn]

Ich habe kein entsprechendes Telefon und kann daher nicht selbst nachsehen ... aber Dir ist schon bewußt, daß eigentlich bei allen gängigen Verfahren zum Kodieren von Kennwörtern das "Salz" in der Suppe im Klartext Bestandteil der gespeicherten Zeichenfolge ist, oder?

Anders würde es auch echt kompliziert ... die Authentifizierung mit einem Kennwort gegen den gespeicherten Wert erfolgt ja so, daß das angegebene Kennwort samt Salt erneut mit dem verwendeten Algorithmus "kodiert" wird (üblicherweise eine Ein-Weg-Funktion wie eine Hash-Funktion, bei der aus dem Resultat nicht mehr auf die Eingangswerte geschlossen werden kann) und das Ergebnis dann mit dem "Hash"-Teil des gespeicherten Wertes verglichen wird. Deshalb auch "kodiert" und nicht "verschlüsselt", denn es kann (zumindest in der Theorie) nicht "entschlüsselt" werden.

Wenn man bei diesem Verfahren nicht bereits vorher den "salt" kennen würde, wäre das Hashen des "richtigen" Wertes ja nicht möglich. Bei einer Brute-Force-Attacke (ob nun mit oder ohne Wörterbuch, bei solchen "Standardaccounts" ist meist ein Wörterbuch vollkommen ausreichend, da braucht es keine kompletten Tables) reicht es also vollkommen aus, nur das Kennwort "auszuprobieren" (i.d.R. wird vorher ein Dictionary berechnet mit dem Salt) und es müssen (jedenfalls für ein einzelnes Konto) nicht mehrere Salts getestet werden.

Allerdings verwendet i.d.R. jedes Konto einen eigenen Salt-Wert, damit hat man mit dem einen Dictionary, das für einen definierten Salt berechnet wurde, nicht automatisch auch gleich die Chance, die Kennwörter anderer Konten zu brechen. Wenn man aber nur das Kennwort eines bestimmten Kontos wissen will, ist das "Salzen" nur ein kleines Hindernis für einen Brute-Force-Angriff.

Für diese Aufgaben gibt es auch Tools (z.B. John the Ripper), allerdings dien(t)en die ursprünglich mal dem Administrator eines Systems, um den Nutzern mit dem Kennwort "kennwort" (oder auch 123kennwort, wenn die Regeln eine Ziffer und einen Buchstaben erfordern) auf die Finger klopfen zu können.

Daher sollte die Kennwort-Datei eines *nix-Systems (gilt für andere Systeme aber ebenso) auch eines der besser gehüteten Geheimnisse sein, selbst wenn die Kennwörter dort nur in "kodierter" Form gespeichert sind. Kennt ein Angreifer das kodierte Kennwort für einen Account und den verwendeten Hash-Algorithmus, ist es nur noch eine Frage des Aufwands (der natürlich mit der Länge des verwendeten Kennworts exponentiell steigt, ein guter Grund für Kennwörter länger als 8 Zeichen), bis er das zugrunde liegende Klartext-Kennwort in den Händen hält.