Gefährliche Sicherheitslücke in Froxlor

  • -------------------------------------------------------
    Update vom 30.07.2015 15:40:
    -------------------------------------------------------

    Sehr geehrte Kundinnen und Kunden,



    wir haben jetzt eigene Pakete für Debian Wheezy gebaut und in folgendem Repo veröffentlicht:


    http://froxlormirror.netcup.net/froxlor-nc


    Um unser Repo zu aktivieren, können Sie auf Debian Wheezy wie folgt vorgehen:


    ACHTUNG: Die Anwendung geschieht auf eigenes Risiko. Wir können keine Fehler ausschließen.


    Code
    echo "#Mirror for netcup builds if main mirror lack new release" >> /etc/apt/sources.list.d/froxlor.list
    echo "deb http://froxlormirror.netcup.net/froxlor-nc $(lsb_release -c -s) main" >> /etc/apt/sources.list.d/froxlor.list
    apt-key adv --fetch-keys http://froxlormirror.netcup.net/froxlor-nc/netcup-release-key.gpg


    Folgende Befehle aktivieren das Repo und spielen das Update ein:


    Code
    apt-get update
    apt-get dist-upgrade


    -------------------------------------------------------
    Ursprünglicher Beitrag (bitte auch lesen):
    -------------------------------------------------------


    Sehr geehrte Kundinnen und Kunden,



    wir wurden soeben über eine schwerwiegende Sicherheitslücke in Froxlor informiert. Über die Sicherheitslücke können Angreifer remote das Datenbankpasswort unter Umständen auslesen. Die Sicherheitslücke wird in Version 0.9.33.2 gefixt. Aktuell steht für Debian diese Version noch nicht zur Verfügung.


    Bis dahin empfehlen wir betroffene Server mit folgenden Befehlen zu schützen:


    Achtung: Das Anwenden dieser Empfehlung geschieht auf eigenes Risiko. Weitere Fehler können nicht ausgeschlossen werden.


    Code
    echo "Alias /froxlor/logs /dev/null" >> /etc/apache2/apache2.conf
    /etc/init.d/apache2 restart


    Das sorgt dafür, dass die kritische URL umgeleitet wird. Sobald die neue Version von Froxlor auch für Debian zur Verfügung steht, empfehlen wir diese per Paketverwaltung zu aktualisieren und anschließend die Zeile


    Code
    Alias /froxlor/logs /dev/null


    wieder aus der Datei /etc/apache2/apache2.conf zu entfernen.


    Folgend nun die genauen Details zur Sicherheitslücke:


    "Hello,


    I just want to inform you that froxlor version 0.9.33.1 and earlier has an


    information leak. (The database password is fully visible for unauthenticated


    remote attackers via the filepath /logs/sql-error.log)


    A CVE for this issue is requested and will be available/public soon.


    The vulnerability is fixed upstream in froxlor version 0.9.33.2.


    Please inform your customers. You can gain further informations on the


    oss-security mailinglist: oss-security@lists.openwall.com






    Greetings


    [persönliche Daten entfernt]




    Here is a technical description about this issue:




    Summary


    ========


    An unauthenticated remote attacker is able to get the database password via


    webaccess due to wrong file permissions of the /logs/ folder in froxlor version


    0.9.33.1 and earlier. The plain SQL password and username may be stored in the


    /logs/sql-error.log file. This directory is publicly reachable under the default


    configuration/setup.




    Notes


    =====


    Some default URLs are:


    - http://website.tld/froxlor/logs/sql-error.log


    - http://cp.website.tld/logs/sql-error.log


    - http://froxlor.website.tld/logs/sql-error.log




    The certain section looks like this:




    /var/www/froxlor/lib/classes/database/class.Database.php(279):


    PDO->__construct('mysql:host=127....', 'DATABASE_USER', 'PLAIN_DATABASE_PW',


    Array)




    Please note that the password in the logfile is truncated to 15 chars, therefore


    passwords longer than 15 chars are not fully visible to an attacker."


    Wir sind dabei alle Kunden die Froxlor einsetzen könnten zu informieren. Neuinstallationen von Froxlor über unsere Image-Verwaltung sind bereits mit dem oben genanntem Schutz versehen.


    Wir empfehlen auch zu prüfen, ob sich Dritte bereits Zugang zu Ihrem System verschaffen konnten.


    Fragen zu dem Thema bitte nicht beim Support stellen. Dafür ist z.B. Platz in diesem Beitrag. Der Support beantwortet keine Fragen zur individuell eingesetzten Software.



    Mit freundlichen Grüßen


    Felix Preuß

  • Danke für die schnelle Info :)


    Da ich jedoch mein Backend Panel von Froxlor über Lighttpd laufen lasse habe ich einfach mal die Berechtigungen zum Lesen der Datei entzogen. Sollte bis zum Patch auch funktionieren :)

    • Offizieller Beitrag

    Da ich jedoch mein Backend Panel von Froxlor über Lighttpd laufen lasse habe ich einfach mal die Berechtigungen zum Lesen der Datei entzogen. Sollte bis zum Patch auch funktionieren :)


    Unsere Tests haben gezeigt, dass Froxlor die Dateirechte eigenständig für alle Dateien im Logordner anpasst. Ein ändern der Dateiberechtigungen ist daher nicht ausreichend.

    Mit freundlichen Grüßen
    Kai Stenders
    netcup Team
    Operations

  • Was man auf jedenfall tun sollte (falls man das in den MySQL Standard-Einstellungen geändert hat) ist, dass man den Zugang auf den MySQL-Server nur von Localhost sprich 127.0.0.1 erlaubt. Dies sollte den größten Schaden vermeiden. Außerdem sollte man nach dem Update unbedingt das MySQL Passwort ändern.


    Wenn man sich die Patches bei Froxlor ansieht wird in der kommenden Version mit syslog geloggt anstatt in froxlor spezifische Files und das Passwort soll auch ersetzt werden.


    Grüße


    Christian Rebischke
    (ebenfalls netcup kunde ;) )


    PS: Kleines Lob. Ihr reagiert echt irre schnell und vorbildlich auf sowas.

  • Guten Abend,

    Zitat

    dass man den Zugang auf den MySQL-Server nur von Localhost sprich 127.0.0.1 erlaubt

    bitte aber zusätzlich bedenken, dass der Angreifer ggf. Zugriff auf den lokalen MySQL-Server hat, z.B. über PhpMyAdmin.



    Mit freundlichen Grüßen


    Felix Preuß

  • Zitat

    PS: Kleines Lob. Ihr reagiert echt irre schnell und vorbildlich auf sowas.

    Wir müssen uns für den schnellen Hinweis bei Ihnen bedanken! Ohne dem hätten wir nicht so schnell reagieren können.


    Vielen Dank!


    Mit freundlichen Grüßen


    Felix Preuß

  • Das muss natürlich mit einbezogen werden. Pardon. Ich denke euer Fix + Password Change sollte ausreichen bis das in den Repos ist.

  • Admins mit ausreichend langen Passwörtern sind hier aber mal wieder im Vorteil. In der Logdatei wird das Passwort auf 15 Zeichen verkürzt.
    Ist zwar immernoch kritisch aber zumindest wird so nicht der komplette Zugang kompromittiert.


    Aber vielen Dank an den Hinweisgeber und netcup für die schnelle Meldung.

  • Admins mit ausreichend langen Passwörtern sind hier aber mal wieder im Vorteil. In der Logdatei wird das Passwort auf 15 Zeichen verkürzt.
    Ist zwar immernoch kritisch aber zumindest wird so nicht der komplette Zugang kompromittiert.


    Aber vielen Dank an den Hinweisgeber und netcup für die schnelle Meldung.

    Für mich ist es komplett Verhältniss unmässig ob <16 Buchstabenpasswort selbst wenn es auf nur 15 gekürtzt ist und z.B. 'Sonnenblumenkerne' heißt kannst du es einfach rekonstruieren. Für mich ist es der Beleg für das was über Froxlor erzählt wird "die Sicherheitslücke im System", was zum Teufel hat ein Passwort im Klartext irgendwo verloren auf einem Server?


    >Besser gesagt warum kann man dadrauf überhaupt von aussen erst zugreifen?<

  • Hat halt irgendeiner den Murks zusammenprogrammiert und keiner hat es entdeckt bzw. ist draufgekommen. Bei Froxlor haben auch schon viele Hände gearbeitet - klar, dass da sowas mal passieren kann. Natürlich ist das mehr als ärgerlich, doch jetzt mit erhobenen Zeigefinder auf die Froxlor-Entwickler zu zeigen, die ihre Freizeit in das Projekt stecken, finde ich etwas zu übertrieben.


    Das Problem wurde rasch gefixed und sollte nun hiermit behoben sein.

  • Zitat von »mike87«




    Für mich ist es komplett Verhältniss unmässig ob <16 Buchstabenpasswort selbst wenn es auf nur 15 gekürtzt ist und z.B. 'Sonnenblumenkerne' heißt kannst du es einfach rekonstruieren. Für mich ist es der Beleg für das was über Froxlor erzählt wird "die Sicherheitslücke im System", was zum Teufel hat ein Passwort im Klartext irgendwo verloren auf einem Server?


    a) zufällig generierte Passwörter >>15 stellen sind damit geschwächt aber noch immer sicher.


    b) Es handelt sich hier um das froxloreigene DB-Passwort. Jede Software mit Datenbank muss wissen, wie sie darauf zugreifen kann.

  • Froxlor generiert eine .conf die mit 10_IP-Adresse anfängt. DORT folgendes eintragen und nicht in der default Datei..


    Unter root / von /froxlor, etc..


    dies eintragen:


    location ~ \.log {


    deny all;



    }


    extra: über port 80 froxlor myphpadmin sperren und nur über https url Zugriff erlauben, und diese auch umleiten, wenn man froxlor myphpadmin online nicht gerade braucht





    location ~ /froxlor {
    return 404;
    }


    location ~ /myphpadmin {
    return 404;
    }





    Zusatz: Was für ein lausiger Security breach...

    vServer Light NETCup Kunde mit Debian Squeeze 64Bit :)
    (Drupal CMS Fan.)

    2 Mal editiert, zuletzt von MegaBite ()

  • Was mir noch aufgefallen ist:


    Froxlor schlägt Konfigurationsdateien für Mail-, FTP- und andere Dienste vor, die zum Zugriff auf Froxlor-Tabellen den Froxlor-DB-User verwenden. Diese Dienste haben dadurch Vollzugriff auf die Froxlor-Datenbank, wodurch unter Umständen weitere Sicherheitslücken entstehen können. Besser wäre es, wenn man für jeden Dienst einen eigenen Datenbankbenutzer anlegen würde, der nur Lesezugriff auf nur die Tabelle(n) bekommt, die er benötigt.

  • Hallo, nach der informativen Meldung gestern kam eben noch eine Mail mit dem Betreff:
    "Wichtige Information zum Server mit IP x.x.x.x" in der steht, mein Produkt sei betroffen. Dass netcup sich die Arbeit macht, sogar Kunden einzeln zu warnen finde ich gut, allerdings habe ich wirklich kein froxlor installiert und die angebene Logdatei gibt es auf meinem System nicht. Kann es sein, dass das zum persönlichen Warnen verwendete Skript etwas großzügig reagiert, etwa sobald was anderes als Antwort 404 zu der zu testenden URL http://x.x.x.x/froxlor/logs/sql-error.log vom Server zurück kommt? Bei mir dürfte beim Check auf diesem Weg ein 3xx-Code antworten und aus Gründen auf eine Default-HTTPS-Seite weiterleiten.
    Trotzdem Danke für die Infos!

  • Es werden derzeit eMails an Kunden versendet, wenn ein vermutlich automatischer Vorgang "die Sicherheitslücke nachvollzieht". Sollten sich noch andere Kunden wundern, der Test scheint lediglich die Erreichbarkeit von

    Code
    http://ip/foxlor/logs/sql-error.log

    zu prüfen, nicht aber den tatsächlich dort ausgelieferten content. So werden u.U. auch andere Dienste auf Port 80 als betroffen identifiziert.

  • Guten Tag,



    nach unserem derzeitigen Stand wurden leider 9 Kunden fehlerhafter Weise informiert. Die Fehlinformation kam zustande, da der Server beim Aufruf der genannten URL einen Statuscode zurückgegeben hat, den auch Server zurück liefern, die von der Sicherheitslücke betroffen sind.


    Wir bitten für die Fehlinformation um Entschuldigung, sollte diese vorliegen.



    Mit freundlichen Grüßen


    Felix Preuß