Archiv der Kategorie: Sicherheit

Mail delivery failed: returning message to sender

Angriffsbeschreibung

Seit gestern bekomme ich mehrmals stündlich folgende E-Mails in mein Postfach:

This message was created automatically by mail delivery software.
Error
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  xyz@mail.ru
    SMTP error from remote mail server after end of data:
    host mxs.mail.ru [94.100.180.104]: 550 spam message rejected. Please visit http://help.mail.ru/notspam-support/id?c=WMigd_PLYuHmakzNLb3CXKQa0-GwN0i5g6somqCPuTsEAAAAuccBAC4KwyA~ or  report details to abuse@corp.mail.ru. Error code:
    77A0C858E162CBF3CD4C6AE65CC2BD2DE1D31AA4B94837B09A28AB833BB98FA0. ID:
    000000040001C7B920C30A2E.

------ This is a copy of the message's headers. ------

Return-path: <meine-email@it-freelancer-magazin.de>
Received: from vwp16331.webpack.hosteurope.de ([111.111.111.111] helo=www.it-freelancer-magazin.de); authenticated
	by vwp16331.webpack.hosteurope.de running ExIM with esmtpa
	id 1ewLyd-0001NJ-PT; Thu, 15 Mar 2018 07:02:59 +0100
Date: Thu, 15 Mar 2018 06:02:59 +0000
To: xyz@mail.ru
From: IT Freelancer Magazin <newsletter@it-freelancer-magazin.de>
Reply-To: meine-email@it-freelancer-magazin.de
Subject: =?UTF-8?Q?Bitte_best=C3=A4tigen_Sie_die_Registrierung_-_IT_Freelancer_Mag?=
 =?UTF-8?Q?azin_newsletter?=
Message-ID: <145763c7cfe0c93637c1de363c59e053@www.it-freelancer-magazin.de>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

Schaut man sich diese E-Mails genauer an, dann haben alle Adressaten russische Mail-Accounts. Außerdem weist der Subject darauf hin, dass jemand versucht, meine Newsletter-Anmeldung zu missbrauchen, um die Adressaten mit meiner Anmelde-Bestätigungs-Email vollzuspamen. Ein Blick in meinen WordPress-Newsletter Subscription-List zeigt, dass tatsächlich viele Pseudo-Anmeldungen auf russische Mail-Konten stattgefunden haben. Ein Blick in die Liste der Newsletter-Abonnenten, die not confirmed sind, offenbart, dass viel mehr Anmeldeversuche stattgefunden haben, als ich E-Mails bekommen habe. Dies deutet wiederum darauf hin, dass meine Anmeldeaufforderung tatsächlich in deren Mailboxes gelandet ist und nicht von deren Mailserver abgelehnt und an mich zurückgeschickt wurden. 

Zwei mal wurde ich bisher auf diese Weise angegriffen – das erste Mal war der Spuk nach ein paar Tagen von selbst wieder vorbei. Beim zweiten Mal musste ich mich stärker damit beschäftigen.

Mutmaßliche Angriffsgründe

Anfangs mutmaßte ich, dass durch diesen Angriff mein newsletter geblacklistet werden solle. Wahrscheinlich versuchen jedoch nur einige Bösewichte mit dem Spam Geld zu verdienen, denn als Vornamen wird z.B. folgendes eingetragen: dmunday28! Congratulations, You Have Won iPhone! – http://tofocovody.tk/b37106_prize2019_37106

Schäden

Es gibt drei Schäden, die bei dieser Art Angriff entstehen:

1.) Blacklistung der eigenen IP, Domain, usw.

2.) Man wird selbst mit E-Mails zugespamt (die der Mailserver zur Verteidigung schickt und man wird durch Karteileichen gestört, z.B. wird die Auswertung verfälscht, wieviele Prozent Newsletteranmelder auch tatsächlich die Bestätigungsemail schicken.

3.) Arme E-Mail-Nutzer auf der anderen Seite werden zugespamt und man leistet Betrügern ungewollt Unterstützung.

Verteidigung

Der erste Angriff war ja nach einiger Zeit vorbei. Den zweiten Angriff vollständig und nachhaltig abgewehrt hat aber erst das Einschalten von Akismet. Das war auch die einzige Maßnahme, die im Nachhinein betrachtet notwendig war. Also habe ich alle anderen Sicherheitsmechanismen wieder ausgeschaltet. Beim Ein- und Ausschalten kann es sein, dass irgendwas blöde verrutscht. Ich habe lange Zeit gar keine Newsletteranmeldungen bekommen, also weder Spam noch die echten. Also immer nach einer Umstellung der Sicherheitseinstellung testen, ob die Newsletteranmeldung noch sauber funktioniert.

Hier findet sich die entsprechende Doku.

Verteidigungsansatz: Adress-Blacklisting

Die meisten Anmeldungen gingen an russische E-Mail-Adressen, die mit hoher Wahrscheinlichkeit nicht zu meiner Zielgruppe zählen, daher schließe ich folgende Domains per Blacklist aus:

Dies reduziert zwar, aber blockiert die Angriffe nicht vollständig, da die Fake-Anmeldung auch an einige andere E-Mail-Adressen (z.B. yahoo und gmail) stattfinden.

Verteidigungsansatz: IP-Blacklisting

Die Angriffe finden bei mir über sehr unterschiedliche IP-Adressen statt, weshalb diese Verteidigungsstratgie bei mir keinen Sinn macht. Es gibt kaum doppelte IP-Adressen:

SELECT created, surname, name, email, ip, count(ip) FROM `wp_newsletter` WHERE status = "S" GROUP BY ip ORDER BY count(id) DESC

IP Verbindungen samt Dateipfad des Prozesses monitoren

TCPViewer

TCPViewer: Die eindeutig bessere Alternative zu netstat. Es ist übersichtlicher, enthält den Dateipfad zu den Prozessen, die zu einer Verbindung aufgebaut wurden und mit dem kleinen Bruder TCPVCon kann man die Daten als .csv abspeichern.

IP-Verbindungen leuchten von Zeit zu Zeit farbig auf, um die Aufmerksamkeit des Users zu erregen:

grün: Frisch geöffnete endpoints

blau: Gerade geschlossene endpoints

gelb: endpoints haben den Status gewechselt.

 

Process Monitor

Eigentlich hat dieses Tool den Schwerpunkt auf Prozesse, ist jedoch das perfekte Tool, um Events so weit einzuschränken, um die Datei zu finden, die verdächtige IP Connections aufbaut.

Den Filter muss man um folgende beiden Entries erweitern:

Operation contains TCP Include
Operation contains UDP Include

Nun filtert man nach und nach unverdächtige Prozesse raus (bsps.weise firefox.exe) bis die potenziellen Schadprozesse übersichtlicher sind.

Windows Firewall Logging

Beim gehijackten Server, kann man verdächtige Aktivitäten im Firewall-Log genauer analysieren. Dort wird jedoch leider nicht die Quelle der verdächtigen Aktivitäten (also der Prozess) protokolliert.

Das Firewall-Log wird per default in %systemroot%\system32\LogFiles\Firewall als pfirewall.log gespeichert und ist leer, muss also erst eingeschalten werden.

Das Menü zum Einschalten des Firewall-Loggings findet sich im Programm “Firewall mit erweiterter Sicherheit”: Aktion -> Eingenschaften. Dann für alle drei Profile (Domänenprofil, …) -> Anpassen -> dort die Protokollierung mit zweimal “Ja” einschalten.

Das Runterfahren von Windows war zumindest bei meinem letzten Einschalten vom Firewall-Log nicht notwendig. Wenn alles korrekt funktioniert, dann wird jeder(!) Aufruf einer Webseite in einem Browser zu zahlreichen Einträgen im Log führen.

Falls dies nicht der Fall ist, dann kann das möglicherweise daran liegen, dass der Windows-Firewalldienst keine Schreibberechtigungen für den Protokollordner hat:

Navigieren Sie zu dem Ordner, den Sie für die Protokolldatei angegeben haben, klicken Sie mit der rechten Maustaste darauf, und klicken Sie dann auf Eigenschaften.
Klicken Sie auf die Registerkarte Sicherheit, und klicken Sie dann auf Bearbeiten.
Klicken Sie auf Hinzufügen, geben Sie im Feld Geben Sie die zu verwendenden Objektnamen ein den Namen NT SERVICE\mpssvc ein, und klicken Sie dann auf OK.
Überprüfen Sie im Dialogfeld Berechtigungen, ob MpsSvc über Schreibzugriff verfügt, und klicken Sie dann auf OK.

Dann mit einem als Administrator gestarteten Editor die Log-Datei öffnen.

Interpretation des Firewall Logs

Nachdem die Analysephase vorbei ist, muss das Log wieder abgeschalten werden, damit durch die schnell anwachsenden Log-Files nicht irgendwann die Festplatte zu ist.