ABAKUS

Schwer zu sagen was genau das Ding bezweckt, denn die URL ist nicht erreichbar.

Die Nameserver stehen beim Registrar der Domain Domaincontext.com in Russland der komplett anonyme Bezahlung erlaubt, gut oder vertrauenserweckend sieht das nicht aus. Gehört definitiv nicht in den Code.

Mach ne saubere Installation etc pp. Einfach nur den Code rausnehmen reicht nicht, wie üblich bei PHP-Anwendungen hast Du irgendwo eine Sicherheitslücke, durch die Du immer erneut infiziert werden kannst.

Danke für die Infos. Die Installation ist gerade erst auf den neuesten Stand gebracht worden, daher wundert es mich, dass es da eine Lücke gibt, zumal bei meiner Seite die Userregistrierung komplett abgeschaltet ist und auch für Kommentare max. HTML zulässig ist.

Kann ich das Einfallstor irgendwie identifizieren?

Naja, Benutzerregistrierung muss nicht aktiv sein, um Lücken auszunutzen. Möglicherweise ist es wieder mal irgendeine durchdachte Eigenschaft von PHP, die vom User übergebene Variablen direkt in Systembefehle umsetzt, oder ein SQL-Injection-Exploit mit dem sich die Angreifer Admin-Rechte geholt haben und dann die Upload-Funktionalitäten deines CMS genutzt haben.
Die Lücke zu identifizieren ist sicher nicht ganz so einfach. Wenn Du es zeitlich einschränken kannst, guck dir alle verdächtigen Requests an. Was in einem 404 mündet ist, wenn deine Seite sauber gebaut ist, selten normal. Guck dir an, was die Clients, die 404 ausgelöst haben, sonst noch aufriefen. Oft sind das Scripts, die einfach verschiedene Exploits abklopfen und nicht unbedingt beim ersten fündig werden. Guck das Errorlog durch, ab und an gibt PHP bei manchen Exploits ne Warning aus. Je nach Zugriffsmengen: guck, wer sich ins Admin-System eingeloggt hat und check die IPs. Generell: Guck dir die Zugriffe aus dem Ausland an, die nicht bekannte Bots wie Google oder Bing sind. Guck dir besonders Zugriffe aus dem Ostblock und Asien an, da sind die meisten gehackten Server, die dann wiederum scannen. Je nachdem, wie deine Seite aufgebaut ist, kann auch ein POST-Request schon ungewöhnlich sein und eignet sich als Filter-Kriterium.

Und guck bei Drupal nach, ob vielleicht schon neue Lücken bekannt sind.

So, auch wenn ich mich hier schreibenderweise ja eigentlich verabschiedet hatte, aber bei meinem "Lieblingswort" muss ich mich dann doch mal kurz einklinken, zumal die Angaben so undifferenziert sind, dass Ursachenforschung da nicht grad einfach ist.

1. Meinst du mit der index.php die Startseite oder die Core-Datei index.php? Letzere beinhaltet ja selbst gar keinen HTML-Code und ist äußerst minimalistisch, also vermutlich ersteres. Also nur auf der Startseite? Oder meinst Du doch die nicht gerewriteten URLs mit Parameter?

2. Sollten wir erstmal klären, ob der Schadcode FTP-seitig oder datenbankseitig eingeschleust wurde. FTP-seitig wäre nämlich auch sowas hier möglich https://drupal.org/node/509208 und hätte dann gar nichts mit Drupal an sich zu tun, sondern mit Deinem Rechner. Wenn ja FTP-seitig, wo steht er? In einer Template-Datei, wird er von einem Modul (eher unwahrscheinlich, da gucken auf drupal.org doch zu viele Leute drauf, wenn's kein gar zu exotisches mit 5 Installationen ist) generiert?

3. Wenn datenbankseitig, wo? Kann man ja in einem DB-Dump finden, so eine Stelle. In einem Block, Node, Kommentar? An Blocks hat normalerweise nur der Admin was verloren, es sei denn, die Berechtigungen sind anderes gesetzt, die wären dann aber zumindest per default auf allen Seiten zu finden. Unabhängig von der Berechtigung, die ein schreibender User hat, ist das Input-Format in der Tabelle node_revisions festgehalten im Feld format festgehalten, zur richtigen Zahl siehe Tabelle filter_formats, aber normalerweise ist Filtered HTML 1. Nur was darin steht, zählt letztlich beim Output, auch wenn im Textfeld nicht zugelassene Elemente drinstehen, die werden vor der Ausgabe gefiltert, nicht vor dem Eintragen in die Datenbank.
SQL-Injections sind bei Drupal recht unwahrscheinlich (außer man hat ein furchtbar unsauber gecodetes Modul), dafür wird zu viel geprüft und ohnehin werden die DB-Abfragen in einer Drupal-eigenen Abstraktionsschicht eingekapselt.

4. D6 oder D7?

5. Sollte es denn wirklich an einer Lücke in Drupal liegen, werden die Leutchen auf drupal.org sich sicherlich über einen Report freuen.

Oft werden auch Javascripts eingeschleusst, evtl solltest du das auch kontrollieren. meist erkennt man die infizierten Dateien, das diese ein anderes Änderungsadtum haben, als der Rest.

PapaRatzi hat geschrieben:Oft werden auch Javascripts eingeschleusst, evtl solltest du das auch kontrollieren. meist erkennt man die infizierten Dateien, das diese ein anderes Änderungsadtum haben, als der Rest.

Das ist richtig: man sollte alles untersuchen. Aber: man sollte nicht anfangen, zu reinigen.
Die einzig richtige Reinigung bei einem kompromitierten System ist ein Flammenwerfer. Alles platt machen und aus vertrauten Quellen und Backups wieder herstellen. Wenn man den Aufwand nicht scheut, geht man den Inhalt seit dem letzten Backup durch und fügt ihn wieder ein.
Die Symptome bereinigen reicht nicht aus. Man weiß nie, ob nicht doch irgendwas zurückgeblieben ist. Und die Änderungsdaten der Dateien lassen sich übrigens auch einfach manipulieren.

Die infizierten Dateien waren die index.php (Startseite) und die page.tpl.php. Nach Euren Tipps habe ich einen kompletten Virenscan gemacht und MacAfee hat zwei Trojaner auf meinem Laptop gefunden und eliminiert. Beide hatte mir McAfee beim Auftauchen in den letzten Wochen schon als eliminiert gemeldet.

Danach bin ich alle meine Seiten durchgegangen und habe zwei weitere mit dem Schadcode gefunden. Die zweite Seite ist keine Standardlösung, sondern eine komplette selbstgeschriebene (nicht von mir) Seite und ein dazu gehöriger WP-Blog. Es ist also wirklich kein Drupal-Problem sondern eins mit meinem Rechner, das jetzt hoffentlich gelöst ist.

Kann ich davon ausgehen, dass der Trojaner dann auf eins meiner FTP-Programme (Filezilla und Notepadd++) abgerichtet ist?

Danke schon mal für Eure Unterstützung bis hierher!