Peer Heinlein arbeitet schon seit 1994 mit SUSE und schätzt es als verlässliche Distribution, die bei Heinlein Support und auch bei unseren Kunden gern eingesetzt wird. Mit dem Sponsoring haben wir nun die Möglichkeit auch etwas zurückzugeben.

[ Zur offiziellen SUSE-Meldung. ]

Drupal-Accounts “veneamin1984″ und “hisopolko166″

Überall auf der Welt werden Benutzerregistrierungen für die Benutzernamen “veneamin1984″ und “hisopolko166″ verzeichnet [1]. Eine Suche auf Google nach einem der Benutzernamen listet unzählige Profile von den verschiedensten Drupal Webseiten auf [2][3], selbst wenn überhaupt keine offensichtliche Möglichkeit der Registrierung im Frontend angeboten wird. Die Löschung der Benutzerprofile im eigenen Drupal CMS führt nur zeitweise zum gewünschten Ergebnis, denn bereits nach wenigen Stunden sind die Profile wieder in der Datenbank zu finden. Die Drupal Community ist ratlos und auch der Drupal IRC Kanal antwortet auf dieses Thema nur mit ratlosem Schweigen.

Ein unerklärlich wiederkehrender Fehler in der MySQL Replikation unserer Shared-Hosting Infrastruktur lenkte unsere Aufmerksamkeit erstmals am 2. April 2012 auf das Phänomen. Ein Blick auf den Status des Slaves offenbarte einen “Duplicate Entry” Fehler:

Auszug der Ausgabe von:
mysql -Bse "SHOW SLAVE STATUS\G"
Last_Error: Error 'Duplicate entry '103' for key 1' on query.
Default database: 'drupal-7.12_database'.
Query: 'INSERT INTO users (name, mail, timezone, pass, init,
status, created) VALUES ('veneamin1984', 'veneamin1984@mail.ru',
7200, 'ddd640856db2fb81aa35554521b9352d', 'veneamin1984@mail.ru',
1, 1333270067)'

Bei dem Verursacher handelt es sich um einen Datensatz für ein Benutzerprofil innerhalb einer Drupal Kundendatenbank – der Name des Benutzers lautet “veneamin1984″.

Und die MySQL-Replikation stirbt

Unsere ersten Recherchen führten uns zu einer Diskussion auf Drupal.org, wo sich bereits andere Drupal Betreiber über die seltsamen Benutzerprofile erkundigten. Der allgemeine Konsens lautet, dass offenbar ein Crawler-Script weltweit auf allen gefundenen Drupal Webseiten fadenscheinige Benutzerprofile registriert. Unklar ist, ob es sich hierbei um Angriffe unter Ausnutzung eines Exploits handelt oder um schlichten Spam. Es werden scheinbar keine weiteren Manipulationen an der Datenbank durchgeführt, nachdem das Profil registriert wurde, allerdings sehen die MySQL Binary Logs von der Registrierung selbst bei genauerem Hinsehen verdächtig aus und lassen auf eine SQL-Injection schliessen.

Wer selbst von diesem Phänomen betroffen ist kann sich in seinen Logs ganz einfach einen eigenen Eindruck verschaffen:

# mysqlbinlog -d <database> /pfad/zu/mysql/binlogs | grep "veneamin1984

Unsere Entwickler beschäftigen sich bereits mit den ausgeführten SQL-Queries und überprüfen eine Verbindung zu CVE-2007-6752.

Unklar war (und ist es auch noch) warum das SQL auf dem MySQL-Master ausgeführt wird, auf dem MySQL-Slave jedoch zu einem “Duplicate Entry” Fehler führt und somit die Replikation zerstört. So ganz unglücklich sind wir über diesen Umstand im Nachhinein allerdings nicht, denn sonst wäre der Spuk wohl garnicht erst aufgefogen.

Hotfix:

Unser Studium über die Binary Logs brachte uns sehr schnell zu der Erkenntnis, dass alle Queries immer und auch bei bisher allen anderen Betroffenen von ein und der selben Source-IP ausgeführt wurden. Wer auch von diesem Phänomen betroffen ist und sich gerne gegen diesen Account-Spam schützen möchte, der kann sich somit ganz einfach einen vorläufigen Hotfix basteln:

# iptables -A INPUT -s 188.143.235.62 -j DROP

Das funktioniert selbstverständlich nur solange, bis unser Script-Kiddy sich entscheidet, seine Queries von einer anderen IP loszufeuern. Es bleibt bis auf Weiteres wohl nichts Anderes übrig, als regelmässig die Datenbanken nach verdächtigen Benutzerprofilen zu durchsuchen und gegebenenfalls die neue Source-IP aus den MySQL Binlogs zu grep’en und in den Netfilter-Stack zu werfen.

Dank und Gruss an Oli Sennhauser von FromDual.com, dessen Unterstützung uns in allen MySQL- und Drupal-Belangen massgeblich voran gebracht hat.

Nachtrag:

Unsere MySQL Binlogs lassen auf ein (möglicherweise) weiteres Script schliessen, welches versucht Passwörter von Drupal Benutzerprofilen mit den Namen “veneamin1984″ zu hacken.

Wie LPI in einer weltweiten E-Mail an alle LPI-Absolventen mitteilt, sollen die neuen LPIC-1-Fragen nun zum 2. Juli 2012, und die neuen LPIC-2-Fragen zum 1. September 2012 erscheinen. Angeblich wolle man den Kandidaten mehr Zeit zur Vorbereitung auf die neuen Themen einräumen, schreibt das LPI.

Eine etwas dürftige Begründung wenn man bedenkt, daß die neuen Fragen seit Monaten angekündigt wurden und es gewiß auch Kandidaten gibt, die sich bereits auf die neuen Objectives vorbereitet haben, nun aber plötzlich mit dem alten Fragenpool konfrontiert werden oder nun ihre Prüfung verschieben müssen.

Die Verschiebung der Fragen erfolgt extrem kurzfristig — erste Informationen dazu sickerten erst 48 Stunden vor dem eigentlichen Release-Termin durch, die LPI-Alumnis erhalten eine entsprechende Benachrichtigung dazu sogar erst nach dem Release-Termin.

In der Folge werden sich nun natürlich auch die Erscheinungstermine der neuen LPI-Bücher verschieben. Zumindest die Neuauflage meines LPIC-1-Buches wird sich natürlich ebenso nach hinten verschieben.

Nicht nur, daß Schwächen in den Zufallsgeneratoren und dem DECT-Schlüsselpairing erschreckend wenig verschiedene Schlüssel ermöglichen: Trotz vorgeblicher Schlüssellänge von 2^128, lassen sich bereits die Grundschlüssel in nur 2^22 Operationen knacken — und von diesem Grundschlüssel werden zu Lebzeiten von DECT-Telefon und Basisstation alle anderen Keys abgeleitet.

Auch verschiedene andere Designfehler im Protokoll machen es Angreifern leicht — so kann ein Angreifer eine Basisstation problemlos Daten senden lassen um Datentraffic zur Kryptoanalyse zu sammeln, ohne gleichzeitig selbst verschlüsselte Daten senden zu müssen (was der Angreifer zu diesem Zeitpunkt ja noch gar nicht könnte).

DECT abzuhören ist anscheinend relativ einfach möglich — und auch staatliche Stellen haben DECT-Cyrptoanalyse schon längst als Thema für sich erkannt. Erik verwies hier auf einen Bericht eines französischen Geheimdienstes aus dem Jahr 2004. Hardware um eigene Basisstationen zu Abhörzwecken zu programmieren sei auch für Normalbürger verfügbar.

Ein neuer DECT-Standard, der in den kommenden Wochen verabschiedet werden soll, verspricht Abhilfe in den wichtigsten Problemen — doch wird das nach Ansicht von Erik noch Ewigkeiten dauern, bis neue Telefone auf Basis dieses Standards auch im breiten Consumer-Markt angekommen sind — und dann werden bestehende Telefone auch kaum ersetzt.

Ein bißchen ist es bei der DECT-Telefonie wie mit dem Schnitzel auf dem Teller: Jeder weiß, daß man besser nicht nach den Hintergründen und Details fragen sollte, aber (fast) alle lieben es…

Wir sind uns sicher, dass wir Ihnen damit einen äußerst kompetenten Dozenten für diesen Kurs anbieten können und sind schon selbst ganz gespannt drauf.

Peer Heinlein war mit den beiden Vorträgen  “Rechtsfragen für IT-Administratoren” und “PHP-Security auf Shared Webservern” vertreten.

Vielleicht fühlt man sich auch einfach “gleicher als gleich” und meint, sich nicht an die ansonsten für alle Teilnehmer im Internet geltenden RFC-Spezifikationen halten zu müssen? Oder fehlt den Admins dort tatsächlich das Know-how? Man mag sichg überlegen, welche Antwort jetzt die bessere ist.

Banale und für jedermann gültige RFCs werden ignoriert

Ein konkretes Beispiel einer bei einem unserer Kunden geblocken Mails zeigt die ebenso einfachen, wie unnötigen Fehlkonfigurationen:

1. Die Mail kam von der IP 216.32.180.30, diese hat im DNS den Reverse-Lookup va3ehsobe010.messaging.microsoft.com. Im SMTP-Protokoll hat sie sich jedoch mit dem Namen VA3EHSOBE002.bigfish.com vorgestellt, also gelogen.
   Entweder grüßt das System im HELO mit dem, was im Reverse-Lookup gesetzt ist, oder man setzt den Reverse-Lookup auf den Namen, den das System seiner Meinung nach selbst hat und der für den HELO genutzt wird.
2. Das ganze wird auch nicht dadurch besser, daß die Namen noch nicht mal zur gleichen Domain gehören. Wenn wenigstens beide Namen microsoft ODER bigfish wären…
3. Microsoft MUSS nach RFC 2142 u.a. einen Postmaster-Mailaccount und auch einen Abuse-Mailaccount besitzen. Das ist keine Bitte, das ist Vorschrift. Microsoft ignoriert das geflissentlich, dabei müssten nur zwei simple Mailadressen eingerichtet werden.
   http://www.rfc-ignorant.org/tools/lookup.php?domain=microsoft.com
   [ Update: Microsoft hat reagiert und ist nun nicht mehr gelistet, siehe unten! ]

=> Die Kombination aus (1), (2) und (3) sorgt dann dafür, daß handelsübliche Anti-Spam-Systeme überall auf der Welt diese Mail (völlig zu recht) so verdächtig halten, daß diese Mails geblockt, getaggt oder sonst wie rausgefiltert werden.

Die Abhilfe wäre einfach und würde nur wenige Sekunden Zeit kosten

• HELO-Hostname und Reverse-Lookup müssen übereinstimmen, wie das bei Mailservern nunmal übereinstimmen muß. Also: Reverse-Lookup ändern. Easy.
• Micosoft muß eine Mailadresse postmaster@ und abuse@ einrichten, wie das nach RFC bei im Mailverkehr genutzten Domains nunmal vorgeschrieben ist. Also zwei Postfächer einrichten. Easy.

Doch das passiert nicht. Stattdessen wird zeitwaufwändig der Rest der Welt damit beschäftigt, mühsam die IP-Netze von Microsoft herauszufinden um diese manuell in den Spamfiltern der Welt zu whitelisten. Wenn man sich überlegt, was das die Provider, Partner , aber auch die (zahlenden!) Kunden von Microsoft betriebswirtschaftlich an Geld kostet…

Warum richten sich Beschwerden und Ursachenbehebung nicht an Microsoft?

Beschwerden über geblockte E-Mails sollten ausschließlich an den hausinternen IT-Support von Microsoft gehen. Stattdessen beschweren sich selbst Microsoft-Mitarbeiter bei deren unschuldigen Kunden darüber, daß angeblich geschäftskritische Microsoft-Mails nicht mehr versendet werden können — und die geben den Druck an die angeblich unverantwortlichen und schlampigen Anti-Spam-Dienstleister weiter. Dabei haben die gar keinen Fehler gemacht.

Doch wenn diese Mails so geschäftskritisch sind — warum versendet Microsoft diese dann nicht auch mit der für geschäftskritische Dinge notwendigen Sorgfalt?

Symptom und Whitelisting bei Postfix / policyd-weight

Bei Postfix schlägt der Dienst policyd-weight mit folgender Fehlermeldung zu:

Recipient address rejected: Mail appeared to be SPAM or forged. Ask
your Mail/DNS-Administrator to correct HELO and DNS MX settings or
to get removed from DNSBLs; in postmaster.rfc-ignorant.org;
in abuse.rfc-ignorant.org; from=<user@microsoft.com>
to=<user@example.com> proto=ESMTP helo=<AM1EHSOBE001.bigfish.com>

Update: Microsoft hat zwischenzeitlich noch einen draufgesetzt und betreibt nun auch Mailrelays, die gar keinen Reverse Lookup haben. Weiß der Geier, was die reitet — ich würde für so eine Schlamperei selbst den Azubi zum 4-Augen-Gespräch zitieren.

Wer die betroffene IP-Ranges von Microsoft whitelisten möchten oder müssen: Wir haben bislang betroffene drei Netzbereiche ausfindig gemacht. Diese können bei Postfix per check_client_access wie folgt gefahrlos gewhitelistet werden:

213.199.154.0/24        permit_auth_destination
65.55.88.0/24           permit_auth_destination
157.55.1.0/24           permit_auth_destination

Update 1:

Microsoft scheint aufgewacht zu sein und hat Postmaster- und Abuse-Accounts eingerichtet. Die Domain ist damit nicht mehr auf rfc-ignorant.org gelistet und Mails können wieder nromal zugestellt werden. Applaus und Glückwunsch — es geht doch!

Update 2:

Auch Google hat derzeit ein 1:1 vergleichbares Problem, daß zur Ablehnung der E-Mails führt: So melden sich einige (wenige) Mailrelays der Google-Maildienste mit einem völlig unpassenden HELO, ganz analog zu dem hier geschilderten Problem. So meldet sich der Host na3sys009aog137.obsmtp.com (IP: 74.125.149.18) mit dem HELO-Namen “psmtp.com”. Letzterer gehört zwar auch zu Google, zeigt aber auf die völlig unterschiedliche IP 64.18.0.253. Und da auch Google auf der RFC-Ignorant-Liste steht ist die Folge: Die Mails werden (völlig zu recht) abgelehnt.

Die Bürger von Karlsruhe wissen noch nicht, ob sie sich über dieses ungewöhnliche Phänomen freuen sollen (Touristenattraktion?) oder ärgern sollen (gefährlich!). In den Geschäften von Karlsruhe werden jedoch bereits deutliche Warnungen vor dem Rattenregen aufgehängt — so gesehen im Schaufenster eines E-Plus-Shops (pardon…: shop’s!) in der Karlsruher Innenstadt.

Ungeklärt jedoch ist noch, ob die Ratten bereits flach waren, als sie regneten, oder ob sie erst durch den unsanften Aufprall auf dem Karlsruher Kopfsteinpflaster flach wurden.

Dämonisierte Engines müssen sein

Das A und O eines performanten Anti-Viren-Filters auf einem Mailserver ist die Notwendigkeit, unbedingt einen dämonisierten Virenkiller einzusetzen. Leider bieten viele Hersteller jedoch keine eigenständig als Dämon laufenden Viren-Engines mehr an und möchten stattdessen gleich vollständige Komplettlösungen beim Kunden platzieren.

Unserer Ansicht nach kommen für eine enrsthafte Betrachung derzeit lediglich folgende Anbieter/Lösungen in Betracht:

• ClamAV
• Sophos
• Avira
• Kaspersky

Wobei Kaspersky anscheinend vom BSI eher ungerne für Behörden gesehen wird — Russland gehört nicht zur NATO und damit ist der Scanner wohl für die Verarbeitung von Dokumenten entsprechender Geheimhaltungsstufen nicht zugelassen.

Das SSSP-Protokoll ermöglicht den direkten Zugriff auf die Engine

Sophos bietet dankenswerterweise eine eigene Scan-Engine mit dokumentiertem Protokoll an: Über das SSSP-Protocol kann eine Drittsoftware die Scan-Engine performant und ohne Umwege über Hilfsprogramme ansprechen.

Für einen großen öffentlich-rechtlichen Kunden haben wir im Jahr 2009 zusammen mit Amavis-Autor Mark Martinec eine SSSP-Schnittstelle in Amavis gebracht. Seitdem kann Amavis mit der Scan-Engine von Sophos nativ und ohne Umwege über einen Unix-Socket oder einen TCP-Socket reden — genau wie Amavis das seit langem mit ClamAV bereits kann. Das macht den Einsatz von Sophos unter Amavis außerordentlich interessant — bei unseren Testaufbauten kamen wir damals auf phänomenale Durchsatzraten von 100 Mails pro Sekunde auf recht normaler Hardware.

Das Howto zu Installation

Ab Amavis 2.7.x ist die SSSP-Schnittstelle in Amavis enthalten.

Bei Sophos übernimmt die SSSP-Kommunikation der Dämon savdid — der ist nicht frei verfügbar, sondern nur für Systemintegratoren zu bekommen. im Normalen Download-Bereich wird man die notwendige Software (leider!) nicht finden können.

Notwendig sind die Pakete:

• Viren-Engine: linux.intel.libc6.tar.z (32 Bit), linux.amd64.glibc.2.3.tar.z (64 Bit)
• savdid: savdi-20-linux.tgz (32 Bit), savdi-20-linux-64bit.tgz (64 Bit)

Heinlein Support kann die Installationspakete dafür zur Verfügung stellen (=> Mail an support@heinlein-support.de). Und da wir aus den überzeugenden technischen Gründen bei vielen Kunden mittlerweile Sophos einsetzen, besorgen wir auf Wunsch die dafür passenden Lizenzen dazu…

Zunächst muß die eigentliche Viren-Engine installiert werden: tgz auspacken und Install-Script aufrufen. Anschließend finden sich unter /usr/local/sav die aktuellen Signature-Files und unter /usr/local/lib liegen die Dateien der libsavi.

Nun kann das Archiv vom savdid ausgepackt und das dortige Install-Script aufgerufen werden. Wenn das install_savdid.sh mit Verweis auf eine fehlende libsavi abbricht, so liegt das i.d.R. daran, daß unter 64 Bit eine 32-Bit-Version installiert worden ist (oder umgekehrt).

Am Ende muß nur noch der savdid-Dämon gestartet werden: Dessen Konfigurationsdatei liegt unter /usr/local/savdid/savdid.conf.  Dort kann einerseits eine unprivilegierte User-ID eingerichtet werden…

# User name and group for daemon to switch to for normal running
# savdi must be running as root for this to be useful
user: vscan
group: vscan

…andererseits muß dort noch ein spezielles Kommando freigeschaltet werden, mit dem Amavis Subdirectorys scannen lassen darf. Diese folgende Einstellung muß für den savdid vorgenommen werden:

    scanprotocol {
        type: SSSP

        # Do we allow the client to use SCANFILE?
        allowscanfile: SUBDIR

In der Amavis-Konfiguration sollte der Zugriff auf den savdid per TCP- statt per Unix-Socket vorgenommen werden, um Probleme mit Zugriffsrechten oder in chroot-Umgebungen zu vermeiden:

# ### http://www.sophos.com/
 ['Sophos-SSSP',
   \&ask_daemon, ["{}", 'sssp:[127.0.0.1]:4010'],
   qr/^DONE OK\b/m, qr/^VIRUS\b/m, qr/^VIRUS\s*(\S*)/m ],

Nach dem Start vermeldet Amavis bei log_level=3 auch den Fund des savdid auf Port 4010:

Jan  6 16:55:31 booster amavis[3629]: Using primary internal av scanner code for Sophos-SSSP

Und eine Test-Mail sollte problemlos versandt und gescannt werden.

Leider stellt Sophis hier keinen Client zur Verfügung, um Sigantur-Files zu aktualisieren . Diese müssen regelmäßig von http://www.sophos.com/downloads/ide/ geladen werden und damit der Inhalt von /usr/local/sav ersetzt werden. Ein laufender savdid muß reloaded werden (“kill -HUP” läßt grüßen).