Automatische Aktualisierungsmail mit fremden Links

*PUSH

Bin ich wirklich der einzige, den derartige Probleme plagen?

Grade eben kam wieder eine schicke Mail vom Drupal, die diesmal den Link
http: //klik2you.com/de/admin/reports/updates
enthält :-(

Hi,

Diese Mail verstehe ich auch nicht ganz, sieht aus wie Werbung für Yahoo

Gruß Andi

Wenns nur das wäre...

da kommen teilweise auch Links zu irgendwelchen Seiten mit laszivem Inhalt ;-)

Ich kann mir nicht erklären, wo da das Problem liegt, ich würde es mal auf einen Bug in der Generierung dieser Mail schieben wollen. Das Problem sollte trotzdem abgestellt werden, da es sicher nicht nur mir unangenehme Bauchgefühle beschert.

Hmm, mit dem Upgrade auf 6.15 hat sich das wohl erledigt... bisher kein weiteres komisches Verhalten.

Hallo Community,

in unregelmäßigen Abständen tauchen wieder Mails mit fremden Links drin auf.

Zusätzlich ist bei der Teilnahme an einer Abstimmung bei Abgabe der Stimme per Mausklick ein User auf eine externe Seite weitergeleitet worden, was sich gegenwärtig nicht reproduzieren lässt, weil der externe Link nicht mehr da ist.

Die Core-Module haben den aktuellen Stand, ebenso wurde nicht manuell in Quelltexten der Module herumgebastelt, mit Ausnahme der selbstgeschriebenen Module natürlich.

Wo könnte man anfangen, sinnvoll nach dem Fehler zu suchen?

Böse Fragen, sorry. ;-)
Wer ist dein Hoster, Homepage und Email?
Wie werden die Emails verschickt, PHP(Drupal selbst) oder über Sendmail?
Hast du den vollständigen Header einer solche Email?

Falls du diese Fragen beantworten kannst, könnten dir hier sicherlich die ein oder anderen, eventuell weiter helfen.

Sieht so aus, als wenn dein Email-Account(oder Homepage) gehackt währe, oder dein Email-Provider( gerne von Freemail Diensten verwendet), baut solche Links ein.

Web.de, freenet.de, gmx.net, usw.

Grüße Uwe

Hoster sind wir selbst. Der Server ist unser Eigentum und wird von uns vollständig betrieben, steht demenstprechend auch in einem nur durch uns zugänglichen Raum.
Die Homepage: http://www.wh2.tu-dresden.de
Email-Dienste haben wir auch selbst inne, dort läuft afaik postfix als Mailserver.

Die Mails mit den fehlerhaften Links werden von Drupal selbst generiert (Standard-Aktualisierungsmails)

Einen Header hab ich auch für dich: :-)

Ganz unten, der offensichtlich eingespeiste (und von mir mit Leerzeichen getrennte) Link.

Ein Anfang waere auch mit einem Blick auf die selbst geschriebenen Module moeglich.

Eventuell hat das Ganze auch gar nichts mit Drupal zu tun. Kann es nicht auch sein das da Spammer am Werk sind die von der Existenz der Drupal-Website wissen und dies auf einfache Weise nutzen und damit auch auf einfache Weise erfolgreich Verwirrung stiften.

------------------------
Quiptime Group

Habt ihr die Logs von Postfix mal Kontrolliert, Sendedatum?

Sollte dann eigentlich, wenn SpamAssassin(Aktuell ist v3.3.0 vom 27.01.2010) fehlerfrei funktioniert, nicht passieren.
Was mir nicht gefällt, ist die verschlüsselte Ausgabe des Subjects, habe ich so noch nicht gesehen.

Was sagt der/die zuständigen Admin/s des Servers? Schon kontaktiert?

Grüße Uwe

Nachtrag

Nein, ist alles korrekt so!

Ich meine so etwas wie,

gehört normalerweise dazu.

Grüße Uwe

(Postfix, from userid 33)

Da fehlt ganz offensichtlich nichts, und ich würde darauf wetten, dass UID 33 genau die UID ist, unter der der Webserver läuft.

Dann würden die Mails aber sicherlich nicht von einem lokalem Benutzer versandt.

Ist aber schon eine ganze Weile Offizieller Standard. Vielleicht einfach noch nie damit beschäftigt? Oder ein buntes Mailprogramm was dir das immer brav automatisch dekodiert?

Koennte also ein lokaler Benutzer der Spammer sein?

------------------------
Quiptime Group

Möchte ich ausschließen... ca. 1500 Nutzer haben einen Login auf der Seite, aktiv nutzen ihn derzeit etwa 150 Leute. Der normale Nutzer hat keinerlei Rechte, bis auf das Forum, wo er Themen erstellen und Beiträge verfassen kann. Weder das Verfassen und Ausführen von PHP-Code, noch Full-HTML sind ihm gestattet.
Moderatoren und Administratoren entstammen alle dem Betreiberkreis ohne Ausnahme, da wäre das kontraproduktiv, seine eigene Seite abzuschießen.

Dann gehört entweder jemand geschlagen, weil er zweistellige UIDs an nicht-Systembenutzer vergibt, oder ein Systemdienst ist der Spammer, und da wäre das naheliegendste der Webserver. Jetzt ist zufällig auch noch 33 die UID, die die Debian Policy für www-data vorschreibt, und damit ist es schon sehr wahrscheinlich, dass das Drupal selbst der Spammer ist.

Ja, 33 ist die UID von www-data, die Mail stammt vom System und wird auch von dieser innerhalb des selben Systems ausgeliefert. Vermutlich spinnt da wirklich was in einem Drupal-Kernmodul herum, möglicherweise gibts irgendwo eine Lücke, wo diese Mail generiert wird.
Der relative Pfad der Mail bleibt ja immer gleich, aber die Variable, die immer und nur auf die eigene Seite zeigt wird irgendwoher ersetzt.

Dann stell ich mir allerdings noch die Frage, warum das nicht immer so ist, sondern von Mail zu Mail verschieden, eine ganze Zeit lang trat das Problem gar nicht auf (überwiegend im Dezember und zum Jahreswechsel).

Wir schauen uns mal die Serverlogs ein wenig näher an.

So, die Serverlogs offenbarten nichts auffälliges, auch die Mails kamen regelmäßig wie sonst auch. Auch waren immer Updates zu tun, wenn derartige Mails kamen.

Da sich immer nur die Base-URL ändert und der relative Pfad immer gleich bleibt schließe ich darauf, dass irgendwo schadhafter Code die Übergabe einer korrekten Base-URL manipuliert.

Ein Workaroung wäre sicherlich, diese Variable fest zu definieren. Das löst allerdings das Problem nicht, verhindert aber die Einspeisung.

Ich bin grad ein wenig ratlos... weil es sich nicht reproduzieren lässt und auch nicht regelmäßig auftritt, widerstrebt es mir, diesbezüglich einen Bug zu melden. Es ist auch so, dass alle Dienste unserer Server normal und korrekt laufen, so dass ich eine systemweite Lücke ausschließe (es läuft Debian stable). Was würdet ihr mir raten zu tun?

workaround: url()-Funktion fix gesetzt

Status: immer noch offen

Die einzige wirksame Maßnahme zur Verhinderung einer weiteren Ausnutzung ist die Seite abzuschalten bis die Lücke gefunden wurde. Alles Andere ist Augenwischerei.