Honk: url mit /etc/passwd : Sicherheitslücke ?!

Hallo,

ich bin darauf aufmerksam gemacht worden, daß man bei einigen servern offensichtlich eine passwortdatei angezeigt bekommt, wenn man die domainmit folgender url aufruft:

http://www.xyz.de/etc/passwd

bei jemandem, den ich kenne, steht in der ausgabe etwa folgendes (verändert)

root::5:8:Superuser::
ftp::562:562:::
xyzde:x:52842:112:::

, wobei "xyzde" der benutzername für den ftp-zugang im klartext ist.

kennt sich jemand so damit aus, daß er/sie mir sagen kann, ob dies eine gravierende sicherheitslücke darstellt, und ob man daraus evtl. sogar das ftp-passwort entschlüsseln kann?

gruß henk

  1. Re-Hallo

    ich bin darauf aufmerksam gemacht worden, daß man bei einigen servern offensichtlich eine passwortdatei angezeigt bekommt, wenn man die domainmit folgender url aufruft:
    http://www.xyz.de/etc/passwd
    bei jemandem, den ich kenne, steht in der ausgabe etwa folgendes (verändert)

    root::5:8:Superuser::
    ftp::562:562:::
    xyzde:x:52842:112:::
    , wobei "xyzde" der benutzername für den ftp-zugang im klartext ist.
    kennt sich jemand so damit aus, daß er/sie mir sagen kann, ob dies eine gravierende sicherheitslücke darstellt, und ob man daraus evtl. sogar das ftp-passwort entschlüsseln kann?

    Das ist in der Tat bedenklich, da so immerhin Usernamen bekannt sind, und man es für eine Brute-Force-Attacke deutlich einfacher hat.
    Dennoch sollten so keine Passwörter ans Tageslicht kommen, die passwd ist immerhin auch so lokal für jeden lesbar. Das Passwort steht in der Regel Einweg-Verschlüsselt in der zweiten Spalte (siehe auch etwas weiter unten den Thread zur crypt-Verschlüsselung) und dürfte daraus nicht wiederherstellbar sein.
    Natürlich geht auch hier ein Brute-Force (oder auch mit dictionary) bis man es raushat.

    Praktisch stellt das aber kein Problem da, da hier (wie hoffentlich überall) Shadow-Passwörter verwendet werden. Erkennbar daran, daß in /etc/passwd in der 2. Spalte nichts oder nur müll ("x") steht. Die eigentlich Passwörter liegen sicher verwahrt in /etc/shadow und die kann nur root lesen.

    Henryk Plötz
    Grüße von der Ostsee

    1. Praktisch stellt das aber kein Problem da,...

      na dann bin ich ja einigermassen beruhigt.
      trotzdem peinlich, es ist nämlich auch einem grösseren provider passiert... (nicht strato, nicht puretec)

      gruß henk

      1. Hi

        na dann bin ich ja einigermassen beruhigt.
        trotzdem peinlich, es ist nämlich auch einem grösseren provider passiert... (nicht strato, nicht puretec)

        Na dann mach dich mal *lol*-bereit: http://www.teamone.de/etc/passwd
        Oder wars das, von der Reihenfolge sieht es fast so aus...

        Henryk Plötz
        Grüße von der Ostsee

        1. Na dann mach dich mal *lol*-bereit: http://www.teamone.de/etc/passwd
          Oder wars das, von der Reihenfolge sieht es fast so aus...

          *ggg* nee, das hatte ich noch nicht probiert...

          scheint sich wohl um einen weitverbreiteten konfigurationsfehler zu handeln.
          oder einen bug im apache-server?

          gruß henk

    2. Hi,

      root::5:8:Superuser::
      ftp::562:562:::
      xyzde:x:52842:112:::
      Das ist in der Tat bedenklich, da so immerhin Usernamen bekannt sind, und man es für eine Brute-Force-Attacke deutlich einfacher hat.

      hm - wenn ich einen solchen Rechner attackieren würde, dann würde ich gleich mit "root" anfangen, da brauche ich die /etc/passwd nicht.

      mfG - Michael

      P.S.: *Kein* Apache-Bug (bei meinem Sun-Server geht das nicht), also bewußte Konfiguration (aus welchem kühlen Grunde auch immer).

      1. P.S.: *Kein* Apache-Bug (bei meinem Sun-Server geht das nicht), also bewußte Konfiguration (aus welchem kühlen Grunde auch immer).

        Der Grund ist ganz einfach, die Datei wird in einer (FTP) chroot-Umgebung zur Aufloesung der numerischen Benutzer ID in den Benutzernamen gebraucht.

        Peter

        1. Hi!

          Der Grund ist ganz einfach, die Datei wird in einer (FTP) chroot-Umgebung zur Aufloesung der numerischen Benutzer ID in den Benutzernamen gebraucht.

          Das heisst also, das Problem tritt dann auf, wenn das http document root auch per ftp geservt wird. Nun, dann sollte man konsequenterweise den Webserver so konfigurieren, dass ./etc, ./bin usw. (vom doc root aus gesehen) nicht vom Webserver offeriert werden, ja nicht mal sichtbar sind. Sollte mit .htaccess kein Problem sein.

          So long

          1. Das heisst also, das Problem tritt dann auf, wenn das http document root auch per ftp geservt wird. Nun, dann sollte man konsequenterweise den Webserver so konfigurieren, dass ./etc, ./bin usw. (vom doc root aus gesehen) nicht vom Webserver offeriert werden, ja nicht mal sichtbar sind. Sollte mit .htaccess kein Problem sein.

            nicht ganz, das problem tritt dann auf wenn document root / ist also root des filesystems.

            und derjenige der das eingerichtet hat gehört geterrt gefedert und ans seinem pimmel aufgehängt :-)

            BTW. auch wenn / documentroot ist, gibt es vom apache her möglichkeiten alle "unerwünschten" verzeichnisse zu verschleiern. (ohne .htaccess in jedem verzeichniss,) geht aber leider nicht mit einzelnen files...

            lg
            Ludwig

            1. nicht ganz, das problem tritt dann auf wenn document root / ist also root des filesystems.

              und derjenige der das eingerichtet hat gehört geterrt gefedert und ans seinem pimmel aufgehängt :-)

              Du schnallst es nicht, denke ich. Die Datei, die per http zu erreichen ist, ist mitnichten die globale /etc/passwd. Es ist tatsaechlich ein Ausschnitt daraus, der im Documentroot des (virtuellen) Webservers liegt. Bei einem FTP-Login wird uns eine chroot-Umgebung fuer das Verzeichnis erstellt. Nur in dieser chroot-Umgebung ist die Datei /etc/passwd.

              Natuerlich kann man das Verzeichnis auch vor dem Zugriff ueber's Web schuetzen.

              Peter

      2. Hi

        hm - wenn ich einen solchen Rechner attackieren würde, dann würde ich gleich mit "root" anfangen, da brauche ich die /etc/passwd nicht.

        Ein Administrator, der ein root-Login über Netzwerk zuläßt gehört geteert und gefedert. Eigentlich sollte man schon einen Benutzernamen und das Passwort brauchen um auf eine Kommandozeile zu gelangen, wo man su benutzen kann. So müssen 2 Paßwörter erraten werden, die tunlichst unterschiedlich zu sein haben!

        Henryk Plötz
        Grüße von der Ostsee

        1. Hi,

          hm - wenn ich einen solchen Rechner attackieren würde, dann würde ich gleich mit "root" anfangen, da brauche ich die /etc/passwd nicht.
          Ein Administrator, der ein root-Login über Netzwerk zuläßt gehört geteert und gefedert.

          das gilt dann konsequenterweise auch für alle anderen vordefinierten Benuterkennungen? (z. B. daemon, bin, sys, adm, lp, uucp, nuucp, listen, nobody, ...)

          mfG - Michael

          1. Hi

            das gilt dann konsequenterweise auch für alle anderen vordefinierten Benuterkennungen? (z. B. daemon, bin, sys, adm, lp, uucp, nuucp, listen, nobody, ...)

            Für diese Benutzerkennungen sollte nicht mal ein Logon auf der Konsole möglich sein und ein Passwort brauchen sie demnach auch nicht. Das weiß sogar die SuSE-Standardinstallation.

            Henryk Plötz
            Grüße von der Ostsee

  2. Hallo Henk

    http://www.xyz.de/etc/passwd

    bei jemandem, den ich kenne, steht in der ausgabe etwa folgendes (verändert)

    root::5:8:Superuser::
    ftp::562:562:::
    xyzde:x:52842:112:::

    Ich habe da gewisse Zweifel.
    Damit ein Server bei dieser URL tatsächlich die _echte_ /etc/passwd
    liefert müßte dies (gar nicht mal so einfach) _absichtlich_ so konfiguriert worden sein. Aus Versehen oder DAUheit ist das nicht zu schaffen.

    Dies erscheint mir mehr als unglaubwürdig.

    Gib doch mal die URL an.

    mfg
      Fridolin

    1. Dies erscheint mir mehr als unglaubwürdig.

      Gib doch mal die URL an.

      z.B http://www.teamone.de/etc/passwd
      wie Henryk gerade herausgefunden hat.

      gruß henk

      1. Dies erscheint mir mehr als unglaubwürdig.

        Gib doch mal die URL an.

        z.B http://www.teamone.de/etc/passwd
        wie Henryk gerade herausgefunden hat.

        ROTFL

        Das ist eine  coole Idee,
        damit glaubt doch jeder zweite windozer er hätte eine dieser verhassten Maschinen gehackt ;-)

        Das könnte noch ausgebaut werden.
        Schwarzer (Voll)Bildschirm grüne Schrift riesen Buchstaben 80x24 Zeichen...

        Und dann noch Eingaben erlauben und munter irgendwelchen als GEHEIM und Passwort oder PIN bezeichneten Unsinn anzeigen...

        viel Spass
        Fridolin

        1. Hi

          ROTFL

          Das ist eine  coole Idee,
          damit glaubt doch jeder zweite windozer er hätte eine dieser verhassten Maschinen gehackt ;-)
          Und dann noch Eingaben erlauben und munter irgendwelchen als GEHEIM und Passwort oder PIN bezeichneten Unsinn anzeigen...

          Ich lache mal mit: http://fuzzy.homeip.net/etc/passwd
          Sorry, aber Animation und Eingaben habe ich mir jetzt nicht geleistet, aber wer weiß.

          Henryk Plötz
          Grüße von der Ostsee

  3. Hallo miteinander,

    ich nehm mir mal das Recht raus, zusammenzufassen ;-)

    Die /etc/passwd die auf der Webserverroot liegt, ist die fuer
    eine chown- Umgebung. D.h. alle Passwoerter, die in der zugehoerigen
    shadow sind, waeren nur fuer die chown-Umgebung gueltig. Also
    koennte man sich mit dem user Passwort (auf diesem Server also
    "teamone") dank chroot nur Zugang zu eben dieser passwd-Datei
    besorgen (was ja dann leicht sinnlos ist). Was der liebe
    Administrator noch machen koennte, waehre entweder ein
    uebergeordnetes Verzeichnis fuer die chroot machen (also ausserhalb
    der Webserverroot, wo aber sonst nix drin liegt), oder zumindest
    das /etc ueber http sperren. Aber eigentlich sind das nur
    Schoenheitsfehler und keine echten Sicherheitsluecken.

    Gruss, Gero