Sicherheitsleck in PureFTPd?

[techblaster]

Hallo ihr lieben,

vor wenigen Monaten habe ich auf einem ESXi Server mehrere Debain-Squeeze Systeme aufgesetzt und ISPconfig gemäss bestehender Anleitungen eingebettet.
Die Systeme habe ich durch den Einsatz von bspw. Portknocking und fail2ban sowie wesentlichen Anpassungen in der iptables weiter ausgehärtet.
Bis zuletzt lief alles fehlerfrei und zur vollsten Zufriedenheit. Heute Morgen wurde ich durch einen Kunden darauf hingewiesen, daß sein Antivirus-Scanner beim Besuch seiner eigenen Homepage (durch uns gehostet) immer wieder anschlagen würde. Dies habe ich sofort geprüft und mit Schrecken festgestellt dass der gesamte Webhostingbereich verseucht ist. Weitere Recherchen ergaben, daß diese Malware bei Clamav noch gar nicht bekannt ist und bei Avira erst seit 03.06. auf dem Index steht.
Weitere Recherchen zeigen mir im pureFTPd plötzlich IP Adressen von USA, Russland und was weiss ich von wo sonst noch, die sich mit den verschiedenen Benutzerkonten authentifizieren und die schadhaften Daten hochladen bzw. manipulieren. Den Dienst habe ich nun zunächst vorsorglich gestoppt. Eine Datensicherung habe ich vom Webhostingbereich glücklicherweise auch. Doch, bevor ich das wieder einpflege würde ich natürlich schon gerne das eigentliche Sicherheitsleck stopfen wollen, damit sich das nicht wiederholt. Daher meine Frage, wo kann ich da am besten noch ansetzen? Gibt es Sicherheitslücken die das u.U. verursachen und dem Angreifer über Backdoors und Injections freien Weg bereiten?
Gern gebe ich Euch auf Anfrage genauere Infos und Auszüge aus den Konfigurationen.
Ich bin für jeden Ratschlag oder Gedanken dankbar

Gruß,
techblaster

 

[Brainfood]

poste bitte einfach mal die Logsfiles ... Kundenspezifische Werte kannst du ja abändern ...

Exploits Database by Offensive Security

pureftpd ist eigentlich relativ robust, die Frage ist eher was das Einfallstor war?

veraltete CMS, Foren etc. Versionen die einen Angriff ermöglichten?
simples sniffen von unverschlüsselten FTP Verbindungen der Kunden?
usw ...

 

[techblaster]

Hi!

Vielen Dank für Deine Antwort. Ja um das Einfallstor geht es mir natürlich speziell, leider sind die Logs nicht sonderlich aussagekräftig, dazu hätte man vorher mal den Debug Level erhöhen müssen...*hust /schäm*
Nun gut, hier sind die einzelnen Logs, von denen ich denke, die am wichtigsten und aussagekräftigsten sind:

Transfer.log:

74.220.23.6 - kalesseTAG [09/Jun/2013:21:19:47 +0200] "PUT /var/www/clients/client12/web38/web/cgi-bin/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:19:47 +0200] "PUT /var/www/clients/client11/web37/web/en/vrGkqJgF.gif" 200 0
4.78.164.34 - kuesterTAG2 [09/Jun/2013:21:19:48 +0200] "GET /var/www/clients/client8/web30/web/wp-config.php" 200 3945
74.220.23.6 - kalesseTAG [09/Jun/2013:21:19:50 +0200] "PUT /var/www/clients/client12/web38/web/daten/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:19:52 +0200] "PUT /var/www/clients/client11/web37/web/error/vrGkqJgF.gif" 200 0
74.220.23.6 - kalesseTAG [09/Jun/2013:21:19:53 +0200] "PUT /var/www/clients/client12/web38/web/error/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:19:55 +0200] "PUT /var/www/clients/client11/web37/web/i/vrGkqJgF.gif" 200 0
74.220.23.6 - kalesseTAG [09/Jun/2013:21:19:56 +0200] "PUT /var/www/clients/client12/web38/web/errors/bPv396xr.gif" 200 0
74.220.23.6 - kalesseTAG [09/Jun/2013:21:19:59 +0200] "PUT /var/www/clients/client12/web38/web/images/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:19:59 +0200] "PUT /var/www/clients/client11/web37/web/images/vrGkqJgF.gif" 200 0
168.143.236.150 - kuesterTAG3 [09/Jun/2013:21:19:59 +0200] "PUT /var/www/clients/client8/web32/web/Qkpny7dR.gif" 200 10
204.11.32.147 - eitnerTAG [09/Jun/2013:21:20:00 +0200] "GET /var/www/clients/client10/web36/web/wp-config.php" 200 3959
74.220.23.6 - kalesseTAG [09/Jun/2013:21:20:02 +0200] "PUT /var/www/clients/client12/web38/web/logs/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:20:03 +0200] "PUT /var/www/clients/client11/web37/web/stats/vrGkqJgF.gif" 200 0
168.143.236.150 - kuesterTAG3 [09/Jun/2013:21:20:03 +0200] "PUT /var/www/clients/client8/web32/web/error/Qkpny7dR.gif" 200 0
4.78.164.34 - kuesterTAG2 [09/Jun/2013:21:20:04 +0200] "PUT /var/www/clients/client8/web30/web/23wPrc8F.gif" 200 10
74.220.23.6 - kalesseTAG [09/Jun/2013:21:20:05 +0200] "PUT /var/www/clients/client12/web38/web/stats/bPv396xr.gif" 200 0
168.143.236.150 - kuesterTAG3 [09/Jun/2013:21:20:07 +0200] "PUT /var/www/clients/client8/web32/web/stats/Qkpny7dR.gif" 200 0
4.78.164.34 - kuesterTAG2 [09/Jun/2013:21:20:07 +0200] "PUT /var/www/clients/client8/web30/web/daten/23wPrc8F.gif" 200 0
74.220.23.6 - kalesseTAG [09/Jun/2013:21:20:07 +0200] "PUT /var/www/clients/client12/web38/web/wirtschafts-personalberatung_de/bPv396xr.gif" 200 0
168.143.236.150 - kuesterTAG4 [09/Jun/2013:21:20:08 +0200] "PUT /var/www/clients/client8/web33/web/KJgtf8rc.gif" 200 10
194.228.40.182 - dsvmbhTAG1 [09/Jun/2013:21:20:08 +0200] "PUT /var/www/clients/client7/web35/web/xt2BprMb.gif" 200 10
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:20:09 +0200] "GET /var/www/clients/client11/web37/web/animate.js" 200 14255
194.228.40.182 - dsvmbhTAG1 [09/Jun/2013:21:20:10 +0200] "PUT /var/www/clients/client7/web35/web/antiquariat/xt2BprMb.gif" 200 0
74.220.23.6 - kalesseTAG [09/Jun/2013:21:20:10 +0200] "PUT /var/www/clients/client12/web38/web/wp-admin/bPv396xr.gif" 200 0
4.78.164.34 - kuesterTAG2 [09/Jun/2013:21:20:10 +0200] "PUT /var/www/clients/client8/web30/web/error/23wPrc8F.gif" 200 0
168.143.236.150 - kuesterTAG3 [09/Jun/2013:21:20:11 +0200] "PUT /var/www/clients/client8/web32/web/webalizer/Qkpny7dR.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:20:11 +0200] "PUT /var/www/clients/client11/web37/web/animate.js" 200 18179
168.143.236.150 - kuesterTAG4 [09/Jun/2013:21:20:11 +0200] "PUT /var/www/clients/client8/web33/web/error/KJgtf8rc.gif" 200 0
194.228.40.182 - dsvmbhTAG1 [09/Jun/2013:21:20:12 +0200] "PUT /var/www/clients/client7/web35/web/artikel/xt2BprMb.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:20:12 +0200] "GET /var/www/clients/client11/web37/web/erfolge.html" 200 15642
74.220.23.6 - kalesseTAG [09/Jun/2013:21:20:13 +0200] "PUT /var/www/clients/client12/web38/web/wp-content/bPv396xr.gif" 200 0
168.143.236.150 - fritzscheTAG [09/Jun/2013:21:20:13 +0200] "PUT /var/www/clients/client11/web37/web/erfolge.html" 200 19859
4.78.164.34 - kuesterTAG2 [09/Jun/2013:21:20:14 +0200] "PUT /var/www/clients/client8/web30/web/ra/23wPrc8F.gif" 200 0

Welche Logs könnten ausserdem interessant sein? Rein von der Authentifizierung habe ich leider nicht viel finden können. auth.log bspw. sagt hierzu leider nichts aus.
Es ist mir ein echtes Rätsel, mittlerweile kann ich sicher sagen, dass ausschliesslich der Bereich für die Webpublikationen (var/WWW) verseucht ist. Die Hauptmaschine als solches ist nicht betroffen. Das untermauert die Aussage des Logs dass die Angreifer "nur" Zugriff mit den FTP Benutzerkonten hatten. Interessant hierbei auch und spricht eher gegen Deine Annahme die ich auch schon hatte, dass evtl. ein CMS oder andere Inhalte dort kompromitiert wurden, denn es wurde mit wirklich jedem FTP-Benutzerkonto auf den Webspace zugegriffen. Die Passwörter sind sehr individuell und recht solide gewählt.
Merkwürdig ist ja, dass die Angriffe simultan von ganz verschiedenen IP`s statt fanden, wie oben im Log-Auszug zu sehen ist.
Was könnte ich noch an Infos posten? Was würde hier entscheidend weiterhelfen?

Gruß,
techblaster

Bei dem Trojaner handelt es sich laut avast! um:

JS:Decode-AJU [Trj]

 

[Till]

Die Zugriffe erfolgen mit den "original" Passworten? Es ist also nicht so dass z.B. Beschwerden von Kunden vorliegen dass FTP Accounts auf einmal nicht mehr gingen da sie ein anderes Passwort haben?

Hast Di mal nachgesehen ob die pure-ftpd sql Konfigurationsdatei in Ordnung ist? Nicht dass ein Angreifer die SQL Query so geändert hat dass man ohne Passwort rein kommt.

 

[techblaster]

Hi Till,

vielen Dank für Deine Antwort.

Die Original-Passwörter sind nach wie vor gesetzt. Habe mir hierzu mal die Tabelle der dort hinterlegten Passwort-Hashes angesehen, sie sind alle unterschiedlich, es deutet jedenfalls nichts an dieser Stelle auf eine Änderung hin.

Ich habe herausgefunden, daß die Zugriffe abrupt enden, sobald ich den FTP-Dienst stoppe.
Lösen konnte ich das Problem im Moment nur mit einer 2 Schritt-Anmeldung. Kunden müssen zunächst auf eine von uns vorgegebenen mittels htaccess geschützten Seite sich mit einem Benutzer anmelden. Im nachfolgenden Schritt zieht sich ein dahinterliegendes Skript die IP des Benutzers und schaltet nur für diese den FTP Port in der iptables frei. Bei erreichen der nächsten vollen Stunde lasse ich die Einstellung mittels crontab wieder Reseten.
Nicht schön, aber zumindest die momentan effektivste Methode die Angriffe fern zu halten.
Es verunsichert mich etwas, daß es hierzu offenbar keine Erkenntnisse gibt, evtl. liegt die Schwachstelle, wie von Dir vermutet gar nicht im FTP-Bereich oder aber es handelt sich um eine neue Sicherheitslücke die noch nicht sehr bekannt ist.

Gruß,
techblaster

 

[Brainfood]

Die Passwörter der Kunden wurden also nicht geändert und trotzdem wird der FTP Zugriff missbraucht?

- Vielleicht benutzen einige Kunden ftp ohne ssl, ihr WLAN Zugang ist kompromittiert und jemand erlaubt sich ein Spaß mit den ersnifften Zugangsdaten?
- Vielleicht eine noch derzeit nicht sehr verbreitete PureFTPd Security-Lücke?
- SQL Injections über eine andere Schnittstelle? ISPConfig/PHPMyAdmin etc. ...

Warum schaltest du nicht FTP komplett ab, zwingst die Kunden vorübergehend Jailkit SSH zu benutzen und beobachtest das ganze weiterhin?

 

[Till]

- SQL Injections über eine andere Schnittstelle? ISPConfig/PHPMyAdmin etc. ...

Hatte ich auch erst daran gedacht, daher meine Frage nach geänderten Passworten denn das wäre meines Erachtens eine Voraussetzung dafür, denn das jemand crypt mit hash für alle User crackt ist recht unwahrscheinlich. Die Passworte werden von ISPConfig als hash gespeichert der im Arbeitsspeicher erzeugt wird (also per php crypt Funktion zur Laufzeit), somit sind sie nie im Klartext in der DB und man käme mit sql injection hier nicht weiter. Ich denke also es muss jemand entweder an die Passworte im Klartext rangekommen sein z.B. durch FTP traffic sniffing wenn kein tls eingesetzt wird oder pure-ftpd ist tatsächlich verwundbar.

Vielleicht hat aber auch jemand code in eines der ispconfig interface scripte auf Deinem Server eingeschleust (entweder php oder js) und greift somit die Passworte vor der Verschlüsselung ab. Du kannst ja mal versuchen alle Dateien von /usr/local/ispconfig/interface/ mit dem inteface/ Verzeichnis aus dem ispconfig tar.gz zu vergleichen und schau mal ins Verzeichnis /usr/local/ispconfig/interface/lib/plugins/ ob dort bei Dir mehr plugins drin liegen als im gleichen Verzeichnis des ispconfig tar.gz.

 

[Brainfood]

stimmt Till, PureFTPd läuft ja per TLS ... hatte ich ganz vergessen ...

@techblaster
Installiere dir ISPConfig in einer Testumgebung nach und vergleiche einfach mal komplett sämtliche Dateien per md5sum ...

Entweder ist dein OS verwundet, deine Dienste (PureFTPd) oder ein Konfig_Loch erlaubt unerwünschte Modifikationen ...