1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Korrektur: Den Gast zum Admin machen

Und wo ist jetzt der Unterschied zu

  1. Thema

Neues Thema Ansicht wechseln


  1. Und wo ist jetzt der Unterschied zu

    Autor: Felix_Keyway 19.10.18 - 01:38

    usermod -u 0 poeser.hacker

    unter Linux?

    Ich bin Spezialist der NSA mit dem Spezialgebiet Backdoors in den Linux-Kernel einzuschleusen ;) .

  2. Re: Und wo ist jetzt der Unterschied zu

    Autor: Tuxgamer12 19.10.18 - 10:04

    Felix_Keyway schrieb:
    --------------------------------------------------------------------------------
    > usermod -u 0 poeser.hacker

    Einziger Sinn und Zweck dieser Lücke ist Unauffälligkeit um unentdeckt zu bleiben..

    Wie in der verlinkten Beschreibung ganz am Anfang steht: Relevant ist diese Lücke, wenn man keine Nutzer erstellen / Nutzer in Gruppen schreiben kann, weil das überwacht wird und man damit sofort auffliegen würde.

    Dein Befehl sollte übrigens auf den meisten Befehlen Distributionen nicht funktionieren, weil usermod nach duplizierten uid gecheckt wird. Musst die /etc/passwd schon manuell bearbeiten ;).

    Was wiederum bedeutet: Du bearbeitest die /etc/passwd - und das ist ja wohl eines der auffälligsten Sachen, die du machen kannst. Auf exakt dem gleichen Level wie den Nutzer in verschiedene Gruppen eintragen - somit ist nicht wirklich etwas gewonnen.

    Die Windows Lücke dagegen bedeutet, dass du in der Registry einen Binärstring eines nicht nicht dokumentierten Eintrages bearbeitest - was blöderweise die Kopie der wichtigen Account-Informationen ist. Der eben Blöderweise beim Login ausgelesen wird und Windows es nicht bemerkt, dass die dortigen Daten nicht den richtigen Account-Informationen entsprechen.

    Und jetzt versuche einmal so etwas zu bemerken, bzw. aus dieser Änderung im undokumentierten Binärstring herauszufinden, dass der Gast-Nutzer gerade Admin-Rechte bekommen hat.

    Du hast ja nicht einmal die wirkliche Chance herauszufinden, dass der Gast als Admin läuft. Wer würde denn mit so etwas überhaupt rechnen? Linux dagegen re-viewst du die /etc/passwd oder machst ein id NUTZER und es ist völlig klar, was los ist. Noch dazu, weil in deinem Beispiel wohl zwangsweise entweder root als poeser.hacker oder poeser.hacker als root angezeigt wird - je nach Reihenfolge in der /etc/passwd ;).

    Oder kurz gesagt: Der Artikel beschreibt eine Windows-Sicherheitslücke; du beschreibst dokumentiertes Verhalten auf Linux ohne sicherheitskritische Auswirkungen.



    1 mal bearbeitet, zuletzt am 19.10.18 10:12 durch Tuxgamer12.

  3. Re: Und wo ist jetzt der Unterschied zu

    Autor: SkyBeam 19.10.18 - 10:37

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Einziger Sinn und Zweck dieser Lücke ist Unauffälligkeit um unentdeckt zu
    > bleiben..

    Einverstanden.


    > Die Windows Lücke dagegen bedeutet, dass du in der Registry einen
    > Binärstring eines nicht nicht dokumentierten Eintrages bearbeitest - was
    > blöderweise die Kopie der wichtigen Account-Informationen ist. Der eben
    > Blöderweise beim Login ausgelesen wird und Windows es nicht bemerkt, dass
    > die dortigen Daten nicht den richtigen Account-Informationen entsprechen.

    Die Registry Strukturen (HIVE) sind durchaus dokumentiert. Ich habe zu Studien-Zeiten sogar einen Registry-Editor in Java implementiert der beliebige Hives laden konnte.


    > Du hast ja nicht einmal die wirkliche Chance herauszufinden, dass der Gast
    > als Admin läuft. Wer würde denn mit so etwas überhaupt rechnen? Linux
    > dagegen re-viewst du die /etc/passwd oder machst ein id NUTZER und es ist
    > völlig klar, was los ist. Noch dazu, weil in deinem Beispiel wohl
    > zwangsweise entweder root als poeser.hacker oder poeser.hacker als root
    > angezeigt wird - je nach Reihenfolge in der /etc/passwd ;).

    Die Auswirkungen sind etwa die gleichen wie unter Linux. Nur behauptest du unter Linux würde es sofort auffliegen und unter Windows nicht. Du gehst bei deinen Annahmen aber davon aus, dass der Administrator unter Windows unfähig ist sich die SAM anzusehen und auch bei den Dateisystem-Berechtigungen dann zu sehen, dass die RID nicht mehr aufgelöst wird. Sprichst aber im gleichen Atemzug einem Linux Admin zu er würde sofort und ohne mit der Wimper zu zucken eine Inkonsistenz zwischen /etc/passwd, /etc/group und /etc/shadow erkennen und sofort beheben. Hier sollte man mit gleichen Massstäben vergleichen. Ein Windows-Admin hat ebenfalls die Möglichkeit solche Sachen zu erkennen.

    Ein System ist immer zunächst komplizierter für den, der es nicht täglich benutzt.

    Ein Windows-Admin hätte unter Linux genau so viel Mühe zu erkennen wo das Problem liegt wenn einem zweiten Benutzer die user-iD 0 zugewiesen wird.


    > Oder kurz gesagt: Der Artikel beschreibt eine Windows-Sicherheitslücke; du
    > beschreibst dokumentiertes Verhalten auf Linux ohne sicherheitskritische
    > Auswirkungen.

    Diesen Rückschluss halte ich nicht für korrekt. Beide Systeme verhalten sich so wie spezifiziert. Rechte werden anhand von Benutzer IDs vergeben (nicht deren Namen) und bei Duplikaten passiert genau das was man erwartet - mehrere Benutzer haben die gleichen Berechtigungen.

    Unter Windows könnte ggf. aber auch auffallen, dass ein so manipulierter Benutzer nicht mehr ohne weiteres auf seine Dokumente zugreifen kann (denn dort hat der Admin mit der geklauten RID keinen Zugriff). Unter Linux ist der Zugriff auf die Benutzerdaten mit UID 0 ohne Einschränkungen möglich.


    Ich halte das Ganze für einen Sturm im Wasserglas. Windows verhält sich hier nicht falsch oder unerwartet. Für die Modifizierung der Benutzerdatenbank sind Admin- oder SYSTEM Berechtigungen nötig. Und dann bleiben noch fast beliebig viele andere Methoden um sich Admin-Rechte zu verschaffen. Von Executor-Systemdiensten über versteckte Benutzerkonten über Task Scheduler-Einträge bis hin zu modifizierten Systemtreibern, Rootkits usw.


    Das einzige was ich sehe was Microsoft dagegen machen könnte wäre es beim Login auf duplizierte RID innerhalb der Benutzerdatenbank zu prüfen und einen Login zu verbieten wenn die RID mehrmals benutzt wird. Das würde dann sowohl den modifizierten Benutzer als auch den Administrator aussperren.

  4. Re: Und wo ist jetzt der Unterschied zu

    Autor: Tuxgamer12 19.10.18 - 11:28

    Alles vorausgesetzt, dass der Link im Artikel keinen Blödsinn erzählt:
    http://csl.com.co/rid-hijacking/

    SkyBeam schrieb:
    --------------------------------------------------------------------------------
    > Windows verhält sich hier nicht falsch oder unerwartet.

    Eben doch. Schau dir doch das Screenshot an:

    https://csl.com.co/wp-content/uploads/2016/03/5.png

    Hast den Key "Names". Darin Key für jeden Nutzer. Darin einen Eintrag, der die RID enthält. So weit so gut? Jetzt schaust du mal hier:

    https://csl.com.co/wp-content/uploads/2016/03/7.png

    Willst mir erst einmal nicht erklären, dass die Werte auch nur annähernd so gut lesbar sind wie die /etc/passwd - auch als Windows Admin.

    Problem: Im umrandeten Kästchen ist noch einmal die RID. Und wenn dort eine anderer RID steht, wird im Zweifelsfall die eigentlich konfigurierte RID im Key "Names" ignoriert. Und das ist die Sicherheitslücke.

    Vergleichbar wäre das, wenn bei Linux anstatt der /etc/passwd die /etc/.passwd gelesen werden würde - in der der Inhalt von /etc/passwd irgendwie Binär zusammengepampft ist und die in /etc/passwd zugewiesene uid ignoriert werden würde. Was wohl nicht der Fall ist ;).

  5. Re: Und wo ist jetzt der Unterschied zu

    Autor: SkyBeam 19.10.18 - 11:58

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Alles vorausgesetzt, dass der Link im Artikel keinen Blödsinn erzählt:
    > csl.com.co
    >
    > Willst mir erst einmal nicht erklären, dass die Werte auch nur annähernd so
    > gut lesbar sind wie die /etc/passwd - auch als Windows Admin.

    Der eine findet Tool X einfach, der andere Tool Y. Man könnte ja mal ein paar Windows Admins an einen vim mit geladenem /etc/shadow setzen und gucken wer da ohne Hilfe wieder heraus findet.


    > Problem: Im umrandeten Kästchen ist noch einmal die RID. Und wenn dort eine
    > anderer RID steht, wird im Zweifelsfall die eigentlich konfigurierte RID im
    > Key "Names" ignoriert. Und das ist die Sicherheitslücke.

    Danke für die Klarstellung. Dass der Wert mehrmals abgelegt wird und ggf. an einer Stelle ignoriert wird würde ich jetzt auch als Bug ansehen - oder zumindest unsauberes Design. Dass dadurch jetzt ein echtes Sicherheitsproblem resultiert sehe ich aber nach wie vor nicht. Aber den Bug könnte man durchaus beheben. Vermutlich ist das eher so ein "Historisch gewachsenes" Ding.

    Mal sehen ob Microsoft da noch was macht. Deswegen schlafe ich jetzt aber nicht unruhig.

  6. Re: Und wo ist jetzt der Unterschied zu

    Autor: Tuxgamer12 19.10.18 - 12:58

    SkyBeam schrieb:
    --------------------------------------------------------------------------------
    > Tuxgamer12 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Alles vorausgesetzt, dass der Link im Artikel keinen Blödsinn erzählt:
    > > csl.com.co
    > >
    > > Willst mir erst einmal nicht erklären, dass die Werte auch nur annähernd
    > so
    > > gut lesbar sind wie die /etc/passwd - auch als Windows Admin.
    >
    > Der eine findet Tool X einfach, der andere Tool Y.

    Die Windows Tools versagen ja gerade aufgrund des Buges - genauso wie natürlich auch Linux Tools Bugs haben können.
    Wichtig wird deshalb hier, wie das hinter den Kulissen vom System gespeichert wird.

    Und eine textuelle Darstellung ist grundsätzlich lesbarer als eine Binäre. Da gibt es erst einmal nichts zu rütteln.

    Wie die /etc/shadow aufgebaut ist - da machst einfach ein "man shadow" (wie für alles andere auch):
    https://linux.die.net/man/5/shadow
    Kann sich der Windows Admin durchlesen und versteht sehr schnell, was da Sache ist.

    Machen wir doch den Test: Zeig mir mal auf die schnelle, wo die F und V Registry Keys dokumentiert sind (also Aufbau, z.B. das RID bei 30h beginnt).

    > > Problem: Im umrandeten Kästchen ist noch einmal die RID. Und wenn dort
    > eine
    > > anderer RID steht, wird im Zweifelsfall die eigentlich konfigurierte RID
    > im
    > > Key "Names" ignoriert. Und das ist die Sicherheitslücke.
    >
    > Danke für die Klarstellung. Dass der Wert mehrmals abgelegt wird und ggf.
    > an einer Stelle ignoriert wird würde ich jetzt auch als Bug ansehen - oder
    > zumindest unsauberes Design.

    Sicherheitslücken sind grundsätzlich Bugs - und durchaus häufig auch unsauberes Design.

    Ein Bug, der einen Nutzer mehr Rechte gibt, als er eigentlich haben sollte, IST jedoch grundsätzlich sicherheitskritisch.

    Und dabei ist es völlig egal, ob die Lücke dich oder mich betrifft oder ob du ein Szenario kennst, wo man die Lücke ausnutzen kann.

    Aber natürlich ist diese Sicherheitslücke sehr weit weg von "kritisch" und der Golem-Artikel Mist. Genauso verständlich, wenn diese Lücke keine hohe Priorität hat.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. LÖWEN ENTERTAINMENT GmbH, Bingen am Rhein (Großraum Mainz)
  2. SENSIS GmbH, Viersen bei Mönchengladbach
  3. Merz Pharma GmbH & Co. KGaA, Frankfurt am Main
  4. Evangelische Kirche im Rheinland, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 31,99€
  2. 23,99€
  3. 16,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de