Sendmail mutiert zum offenen Relay
Gestern Abend hat sich ein Mailserver spontan dazu entschlossen, als offenes Relay eine besondere Willkommenskultur gegenüber Fremden an den Tag zu legen. Am nächsten Morgen fiel der Zustand zwar auf, konnte aber nicht mehr nachgestellt werden. Egal was man probierte, die Maschine lehnte gleichartige Versuche, den Spam einzuliefern einfach ab.
Es fanden sich über 4000 noch nicht zugestellte E-Mails im Spool, von den noch nicht zugestellten Rückläufern ganz zu schweigen. Aufräumen ist ja das eine, wichtiger ist die Ursache zu finden.
Ein Blick ins Logfile zeigt, daß ohne irgendwelche Authentisierung die E-Mail angenommen wurde:
19:05:03 xxx sm-mta[1930]: u0EI4iOC001930: from=clients@accounts1.com, size=38551, class=0, nrcpts=13, msgid=<22f19892829748b29072f669d147ed20@accounts1.com>, proto=ESMTP, daemon=MTA, relay=[120.24.4.184] 19:05:03 xxx sm-mta[1930]: u0EI4iOC001930: to=samoapim@gmail.com, delay=00:00:15, mailer=esmtp, pri=428551, dsn=4.4.3, stat=queued 19:05:03 xxx sm-mta[1930]: u0EI4iOC001930: to=samoawillovercome@hotmail.co.uk, delay=00:00:15, mailer=esmtp, pri=428551, dsn=4.4.3, stat=queued ...
Wie kann das sein?
Ein Test von einer externen Maschine aus gibt eine klare Ablehnung zurück:
$ telnet -4 xxx 25 Connected to xxx Escape character is '^]'. 220 xxx ESMTP Sendmail ... ehlo yyy 250-xxx Hello yyy, pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 100000000 250-DSN 250-ETRN 250-AUTH PLAIN LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP mail from: <clients@accounts1.com> 250 2.1.0 <clients@accounts1.com>... Sender ok rcpt to: <samoapim@gmail.com> 550 5.7.1 <samoapim@gmail.com>... Relaying denied. Proper authentication required. quit 221 2.0.0 xxx closing connection
Am gestrigen Abend war das aber offenbar nicht der Fall.
Ein Bug in einer Crypto-Lib, der des dem Angreifer gestattet, den Speicher des Sendmail zu überschreiben? Ach nein, es war ja kein TLS aktiv.
Eine besonders kreative DNS Antwort für die reverse Auflösung, die das Sendmail austrickst? Ja, kann sein. Es ist zwar nichts von einer erfolgreichen DNS Auflösung geloggt worden, aber vielleicht ist das auf den Trick auch reingefallen.
Also den Debugger anwerfen und spielen:
# sendmail -bt -d21.4
> .D{client_addr}120.24.4.184
> .D{client_name}
> .D{client_resolve}OK
> check_rcpt <samoapim@gmail.com>
...
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required." Das war's nicht, selbst wenn ich über die erfolgreiche Hin- und Rückauflösung lüge (das OK). Also nächster Versuch. Was könnte das DNS noch zurück geliefert haben?
> .D{client_name}localhost
> check_rcpt <samoapim@gmail.com>
...
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied. Proper authentication required." Es gibt da aber innen drin, einige sehr interessante Domain-Namen, die das Sendmail zusammenbaut. Wer da Glück hat, kann sicher einiges an Schutzmaßnahmen aushebeln. Aber nicht jetzt.
Nächster Versuch:
> .D{client_name}xxx
> check_rcpt <samoapim@gmail.com>
...
rewritten as: < ? > samoapim < @ gmail . com > $| OK
rewritten as: < ? > samoapim < @ gmail . com >
check_rcpt returns: < ? > samoapim < @ gmail . com >Oops! Wenn sich der Einlieferer als der einlieferende Host ausgibt, dann kann er – unabhängig von seiner tatsächlichen Adresse – problemlos einliefern.
Panik
Das Problem ist nur, daß Sendmail eine Vorwärtsauflösung zur Rückwärtsauflösung hinzufügt, und die muß wieder die einlieferende IP ergeben. Das ist natürlich nicht der Fall, oder kann man das DNS austricksen?
Normalerweise sollte das nicht klappen, aber wenn man den Resolver des Mailserver überreden könnte – dann hätte man eine ganze Weile Narrenfreiheit.
Zum Glück hat dieser Resolver DNSSEC-Validierung aktiv, wenn er auch zum fraglichen Zeitpunkt unter mächtigem Beschuß stand. Kann es sein, daß es also doch gelungen ist, da eine falsche Auflösung unterzujubeln?
Eine genauere Analyse der fraglichen DNS Resolver brachte keine Aufklärung. Kann sein, sollte nicht, wäre ungewöhnlich, kann ich mir nicht vorstellen. Oder doch?
Verzweifelte Suche
Je mehr man sucht, desto weniger wahrscheinlich wird das Phantom, dem man nachjagt. Also zurück auf Start.
Was tut sendmail eigentlich beim check_rcpt?
Beim Durchblättern des Debug-Outputs fällt eine Zeile auf, die siedend heiße Erinnerungen weckt.
Basic_check_rcpt input: < samoapim @ gmail . com >
rewrite: RHS $&{deliveryMode} => "i"
rewritten as: < i > < samoapim @ gmail . com >
rewritten as: < samoapim @ gmail . com >deliveryMode? Daran habe ich gestern Nachmittag herum gespielt. Wegen einer seltsamen Verzögerung bei der Mailannahme.
Mit dem Setzen von deliveryMode auf deferred werden DNS-Anfragen nicht sofort gestellt, sondern erst, wenn der Server explizit zur Mailauslieferung aufgefordert wird. Der Modus ist dafür gedacht, auf einer isolierten Maschine die Mailannahme zu ermöglichen.
Sollte das etwa? Ein Test:
> .D{deliveryMode}d
> check_rcpt <samoapim@gmail.com>
...
rewritten as: < ? > samoapim < @ gmail . com > $| deferred
rewritten as: < ? > samoapim < @ gmail . com >
check_rcpt returns: < ? > samoapim < @ gmail . com >Autsch! Ja, ich hatte die Konfig geändert, aber habe ich nach dem Test den Dienst auch neu gestartet?
Wirklich?
Ganz, ganz sicher?
Wollen wir ins Logfile schauen?
Occams razor
Was ist wahrscheinlicher: Das ein Spammer einen gezielten DNS Angriff gegen DNSSEC validierende Resolver erfolgreich mit einer Spamverteilung koordinierte (so das ein ganzes Botnetz für zig Minuten einliefern kann) oder das der Admin einen Fehler gemacht hat?
Ok, also nochmal den Modus umstellen und von extern testen:
$ telnet -4 xxx 25 Connected to xxx Escape character is '^]'. 220 xxx ESMTP Sendmail ... ehlo yyy 250-xxx Hello yyy, pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 100000000 250-DSN 250-ETRN 250-AUTH PLAIN LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP mail from: <clients@accounts1.com> 250 2.1.0 <clients@accounts1.com>... Sender ok rcpt to: <samoapim@gmail.com> 250 2.1.5 <samoa@gmail.com>... Recipient ok (will queue) quit 221 2.0.0 xxx closing connection
Autsch! Und wieder zurück.
$ telnet -4 xxx 25 Connected to xxx Escape character is '^]'. 220 xxx ESMTP Sendmail ... ehlo yyy 250-xxx Hello yyy, pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 100000000 250-DSN 250-ETRN 250-AUTH PLAIN LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP mail from: <clients@accounts1.com> 250 2.1.0 <clients@accounts1.com>... Sender ok rcpt to: <samoapim@gmail.com> 550 5.7.1 <samoapim@gmail.com>... Relaying denied. Proper authentication required. quit 221 2.0.0 xxx closing connection
*seufz* Was für ein Mist.