Exchange als Spamschleuder missbraucht
Es gibt so Tage, an denen man die Wände hoch gehen möchte. Beispielweise der, an dem ein Exchange-Server beim Kunden aus heiterem Himmel massiv Spam-Mails versendete. Variierende Absender alerts@XXXbank.de und Ziele in aller Welt. Dabei hat man schon Probleme, wenn der Kunde mal im Outlook oder Webmailer seine private Adresse als Absender verwenden will. Was war also passiert?
Daten sammeln
Zuerst einmal ist festzustellen, ob überhaupt gespammt wurde. Schließlich kann es ja sein, dass die auslösende Beschwerde eine Fehlinterpretation darstellt. In dem konkreten Fall sagen die relevanten Received-Zeilen zwar ganz koscher aus, aber man weiß ja nie.
Also zuerst mal ins Logverzeichnis des Mailserver, also der Komponente, die die E-Mails tatsächlich entgegen nimmt und dann verschickt.
C:\> cd C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
Dort finden sich Dateien der Form RECVyyyymmdd-ss.LOG. In denen steht, wie die Mailserver zu seinen E-Mails gekommen ist. Findet sich dort nichts auffälliges, schaut man nebenan im SmtpSend Folder nach, ob überhaupt vom Exchange gesendet wurde.
In diesem Fall stehen aber Einträge im Empfangsprotokoll:
...,[exchange-ip]:465,[exchange-ip]:38115,... <,EHLO exch.local, *,None,Set Session Permissions >,250-exch.local Hello [2a01:...], >,250-PIPELINING, >,250-DSN, >,250-ENHANCEDSTATUSCODES, >,250-AUTH GSSAPI NTLM LOGIN, >,250-X-EXPS EXCHANGEAUTH GSSAPI NTLM, >,250-X-EXCHANGEAUTH SHA256, >,250-8BITMIME, >,250-BINARYMIME, >,250-CHUNKING, >,250-XEXCH50, >,250-XRDST, >,250-XSHADOWREQUEST, >,250-XPROXY, >,250-XPROXYFROM, >,250-X-MESSAGECONTEXT ADRC-2.1.0.0 EPROP-1.2.0.0, >,250-XSYSPROBE, >,250 XORIGFROM, <,X-EXPS EXCHANGEAUTH, *,NT AUTHORITY\SYSTEM,authenticated >,235 <authentication response>, <,XPROXY SID=08D3C19C6F595AB4 IP=80.a.b.c PORT=51066 DOMAIN=xxx CAPABILITIES=0 SECID=Uy0xLTUtMjEtMDEyMzQ1Njc4OS0wMTIzNDU2Nzg5LTAxMjM0NTY3ODktMTIzNA+3D+3D, *,SMTPSubmit SMTPSubmitForMLS SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPSendEXCH50 SMTPAcceptEXCH50 AcceptRoutingHeaders AcceptForestHeaders AcceptOrganizationHeaders SendRoutingHeaders SendForestHeaders SendOrganizationHeaders SendAs SMTPSendXShadow SMTPAcceptXShadow SMTPAcceptXProxyFrom SMTPAcceptXSessionParams SMTPAcceptXMessageContextADRecipientCache SMTPAcceptXMessageContextExtendedProperties SMTPAcceptXMessageContextFastIndex SMTPAcceptXAttr SMTPAcceptXSysProbe,Set Session Permissions >,250 XProxy accepted and authenticated, <,MAIL FROM:<alerts@1k8JzXXXbank.com>, <,RCPT TO:<dest@ination.net>, >,250 2.1.0 Sender OK, >,250 2.1.5 Recipient OK, <,BDAT 8192, *,,receiving message with InternetMessageId <random@ination.net> >,"250 2.6.0 CHUNK received OK, 8192 octets", <,BDAT 8192, >,"250 2.6.0 CHUNK received OK, 8192 octets", <,BDAT 8192, >,"250 2.6.0 CHUNK received OK, 8192 octets", <,BDAT 5082 LAST, >,"250 2.6.0 <random@ination.net> [InternalId=7013681596317, Hostname=exch.local] Queued mail for delivery",
Der überraschende Punkt ist, dass es tatsächlich ein Mailversand von einer fremden Adresse an eine fremde Adresse gibt. Und dafür hat sich der Client die Berechtigungen SMTPAcceptAnyRecipient, SMTPAcceptAnySender, BypassAntiSpam, BypassMessageSizeLimit gegeben.
Richtig heftig ist aber, dass die Mail von der lokalen Maschine kommt und dort mit Systemrechten authentisiert ist. Ganz offenbar versteckt sich da irgendwo im XPROXY eine nachträgliche Authenisierung, die die angegeben Rechte frei schaltet.
Verursacher finden
Schaut man sich die vielen XPROXY Zeilen an, variiert alles, bis auf die IP und SECID.
Die IP ist ganz offensichtlich die originäre Quelle der Einlieferung. Wie auch immer die Mail durch Outlook Web Access, POP, IMAP oder Submission Ports durchgelaufen ist, externe IP und externer Port sind bekannt. Das ist viel wert!
Die SECID dagegen schaut sehr nach BASE64 aus. Also mal dekodieren.
$ echo Uy0xLTUtMjEtMDEyMzQ1Njc4OS0wMTIzNDU2Nzg5LTAxMjM0NTY3ODktMTIzNA== | base64 -d S-1-5-21-0123456789-0123456789-0123456789-1234
Oh, eine Security-ID von Windows. Das könnte ein Hinweis auf den realen Nutzer sein. Mal schauen:
PS C:\> $objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-21-0123456789-0123456789-0123456789-1234")
PS C:\> $objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
PS C:\> $objUser.value
KUNDE\backupHuch? Ein gültiger Nutzername aus dem AD? Gleich mal beim Kunden anrufen.
Es stellt sich heraus, dass bei dem Namen das Passwort sehr leicht zu erraten war. Viel zu leicht. Angelegt hatte den Nutzer der Kunde selbst, um damit USB-Backup-Platten im Netz einbinden zu können. Und damit jeder damit arbeiten kann, hatte der Nutzer auch viel zu viele Rechte.
Der Nutzer wurde deaktiviert und sämtliche Passworte sind zu ändern. Es gibt auch verpflichtende Passwort-Richtlinien, die nun auch als Admin nicht mehr zu umgehen sind.
Aufräumen
Nachdem die Ursache des Spamversands gefunden, bleibt nun noch das Wegräumen der Spammails, die noch nicht versendet wurden. Erst dann kann die Blockade des Mailversands aufgehoben werden.
Erstmal die Mails raus suchen:
[PS] C:\>Get-Message -Filter {FromAddress -like "alerts@*"}
Identity FromAddress Status Queue Subject
-------- ----------- ------ ----- -------
exch\50755\69... alerts@QIsnlXXXXbank... Active exch\50755 Important Account In...
exch\155681\7... alerts@HyThUXXXXbank... Active exch\155681 Important Account In...
...Und dann weg löschen:
[PS] C:\>Remove-Message -Filter {FromAddress -like "alerts@*"} -WithNDR $false
Bestätigung
Möchten Sie diese Aktion wirklich ausführen?
Die Nachrichten, die dem Filter 'FromAddress -like "alerts@*"' entsprechen, werden entfernt.
[J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [?] Hilfe (Standard ist "J"):Das ganze Spiel wiederholt sich solange, bis die Mailwarteschlange nur noch legitime E-Mails enthält.
Und dann kann man den Exchange wieder in die Freiheit entlassen.
Prävention
Im Nachgang sollte man überlegen, ob man solche Situationen nicht schneller erkennen kann.
Kann man: Symptomatisch für hohes Mailaufkommen ist die Anzahl der in einem kurzen Intervall versendeten E-Mails. Und genau dafür gibt es einen Leistungsindikator. Den trägt man mit einem sinnvollen Grenzwert im SystemCenter ein und bekommt einen Alarm, wenn der Grenzwert gerissen wird.
Interessant dass man sich per SMTP die Rechte wünschen kann für beliebige Absender, ob man das auch hinbekommt wenn man es will? ,)
Total 2 comments