Karl Heinz: wie Maleware auf Webseite identifizieren

Hallo,

ein Kunde von mir schaltet eine Google AdWords-Kampagne.

Google hat dummerweise die Webseite des Kunden gesperrt, weil die Webseite angeblich Maleware beinhaltet.

Könnt Ihr mir sagen wie man herausfinden kann, wo auf der Webseite die Maleware liegt bzw. um welche konkrete Malware es sich handelt?

Gibt es spezielle Virenscanner für das Scannen von Servern bzw. Webseiten?

  1. Hallo Karl Heinz,

    Könnt Ihr mir sagen wie man herausfinden kann, wo auf der Webseite die Maleware liegt bzw. um welche konkrete Malware es sich handelt?

    Google sollte können. In der Meldung steht doch sicher ein bisschen mehr als nur „Malware gefunden“?

    Gibt es spezielle Virenscanner für das Scannen von Servern bzw. Webseiten?

    Ich kenne http://www.urlvoid.com/

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    1. In der Meldung steht doch sicher ein bisschen mehr als nur „Malware gefunden“?

      Hier mal die Mail von Google:

      Lieber AdWords-Kunde,

      wir möchten Sie darauf hinweisen, dass eine Ihrer Websites gegen unsere Werberichtlinien verstößt. Daher werden Ihre Anzeigen, die mit dieser Website verknüpft sind, nicht mehr ausgeliefert. Zudem werden neue Anzeigen, die auf die Website verweisen, abgelehnt.

      So können Sie die Website korrigieren, damit Ihre Anzeigen wieder ausgeliefert werden:

      1. Nehmen Sie die erforderlichen Änderungen an der Website vor, die derzeit gegen unsere Richtlinien verstößt:

      Angezeigte URL: %%% Richtlinienverstoß: Malware und unerwünschte Software

      Details und Anleitungen:

      https://support.google.com/adwordspolicy/answer/6020954#311

      1. Reichen Sie Ihre Website zur erneuten Überprüfung ein. Folgen Sie dazu der Anleitung unter obigem Link. Wenn Ihre Website unsere Richtlinien befolgt, können wir die Anzeigen wieder freigeben. Wiederholte Sperrungen können dazu führen, dass Ihre Website dauerhaft von der Werbung mit Google ausgeschlossen wird. Wiederholte Verstöße gegen unsere Werberichtlinien können auch zur Sperrung Ihres AdWords-Kontos führen. Informieren Sie sich daher über unsere Richtlinien, um alle Probleme so schnell wie möglich beheben zu können. Weitere Informationen zu den AdWords-Richtlinien zur Kontosperrung finden Sie unter https://support.google.com/adwordspolicy/answer/164786?hl=de&utm_source=policy&utm_medium=email&utm_campaign=spsu.

      Mit freundlichen Grüßen Ihr Google AdWords-Team

      Gibt es spezielle Virenscanner für das Scannen von Servern bzw. Webseiten?

      Ich kenne http://www.urlvoid.com/

      Habe ich getestet, das Tool sagt die Webseite ist in Ordnung.

      Sonst noch Ideen?

      1. Sonst noch Ideen?

        Kann dein Kunde noch erfolgreich Mails an Empfänger, welche Telekom-Kunden sind, versenden?

  2. Tach!

    Könnt Ihr mir sagen wie man herausfinden kann, wo auf der Webseite die Maleware liegt bzw. um welche konkrete Malware es sich handelt?

    Umherschauen, wo überall Zeug drin ist, das man nicht selbst dahingetan hat. Das ist naturgemäß schwierig, wenn man fremde Softwareprodukte einsetzt. Das meiste erkennt man daran, dass es sich zu tarnen versucht, wohingegen die eigentliche Software mit lesbarem Code daherkommt. Auch gibt es da Tricks wie überlange Zeilen, mit vielen Leerzeichen vorndran, die man nicht als bösartig erkennt, wenn Wrap (Umbrechen von Zeilen) ausgeschaltet ist. Außerdem ist das recht mühsam, wenn die Software aus vielen Dateien besteht. Das trifft aber meist auch für die eigene Software zu.

    Besser ist es, im Vorfeld bereits Maßnahmen zu ergreifen, um ungeplante Änderungen feststellen zu können. Zum Beispiel kann man dazu Tools wie AIDE verwenden. Aber auch Versionskontrollsysteme, wie Git, können Änderungen aufspüren. Mit solchen kann man sogar den ursprünglichen Stand relativ leicht wiederherstellen, besonders wenn man ein unverfälschtes Repository oder eine Kopie davon an sicherem Ort hat.

    dedlfix.

    1. Der Kunde hat die Webseite komplett platt gemacht und neu auf den Server hochgeladen. Trotzdem meckert der Google Bot noch immer.

      1. Tach!

        Der Kunde hat die Webseite komplett platt gemacht und neu auf den Server hochgeladen. Trotzdem meckert der Google Bot noch immer.

        Der besucht die Seite ja auch nicht dauernd, sondern erst wenn er wieder Lust dazu hat. Solange bleibt die Information aktiv. Da hilft nur warten. Gegebenenfalls haben die Google-Webmaster-Tools etwas zum Beschleunigen.

        dedlfix.

      2. Hallo Karl Heinz,

        Der Kunde hat die Webseite komplett platt gemacht und neu auf den Server hochgeladen. Trotzdem meckert der Google Bot noch immer.

        Es sollten auch sämtliche Passwörter geändert werden, denn man kann ja davon ausgehen, dass dein Kunde die Malware nicht selbst hineingeschrieben hat.

        Bis demnächst
        Matthias

        --
        Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
        1. Hallo und guten Abend,

          Es sollten auch sämtliche Passwörter geändert werden, denn man kann ja davon ausgehen, dass dein Kunde die Malware nicht selbst hineingeschrieben hat.

          MMn sollte Karl Heinz uns erstmal offenbaren, was er noch alles von außen nachlädt. Vermutlich verwwendet die Seite auch eine jQuery-Bibliothek (oder mehrere). Die muss auch irgendwoher kommen. Und verwendet die Seite ein CMS? Dann stecken die Lücken vielleicht auch in dessen "Kernel"?

          Und wenn Datenbankinhalte in die Seite eingestanzt werden, können auch darin Lücken stecken. Die müssen gar nicht dauerhaft vorhanden sein, wenn das DBMS ein Leck hat.

          Grüße
          TS

          --
          es wachse der Freifunk
          http://freifunk-oberharz.de
      3. Der Kunde hat die Webseite komplett platt gemacht und neu auf den Server hochgeladen. Trotzdem meckert der Google Bot noch immer.

        Wenn es die selbe CMS-Version ist dann hat der neue Besitzer Deines Webservers auch in "Nullkommanix" wieder genau so Zugriff wie vorher und wird den von ihm gewünschten Zustand wieder herstellen.

    2. Umherschauen, wo überall Zeug drin ist, das man nicht selbst dahingetan hat.

      Es hat sich in meiner Praxis bei der Reparatur solcher, meist "eher so mittelmäßig betreuten" Webauftritte als gute Idee erwiesen mal nach dem Datum der Dateien und ins Access-Log zu schauen. Insbesondere POST-Requests sind sehr interessant. Für weitere Forschung ist dann grep hilfreich...

      1. Tach!

        Es hat sich in meiner Praxis bei der Reparatur solcher, meist "eher so mittelmäßig betreuten", Webauftritte als gute Idee erwiesen, mal nach dem Datum der Dateien [...] zu schauen.

        Einige sind aber auch clever und setzen das Modifikationsdatum der hinzugefügten oder geänderten Datei auf eins von einer anderen im Verzeichnis vorhandenen Datei. Man kann sie aber trotzdem entlarven, denn in dem Fall sind meist die Millisekunden auf 000 gestellt und nicht auf einen zufälligen Wert.

        Bei WordPress hilft auch, im upload-Verzeichnis das Zugreifen auf .php sperren. Der Upload ist eigentlich nur für Bilder vorgesehen.

        Options -Indexes
        <FilesMatch "\.(php|html)$">
          Order Deny,Allow
          Deny from all
        </FilesMatch>
        

        dedlfix.

        1. Bei WordPress hilft auch,

          • im upload-Verzeichnis das Zugreifen auf .php sperren.
          • den schreibenden Zugriff auf Dateien und fast alle Verzeichnisse zu unterbinden: chmod -R a-w ./ ; chmod o+w ./wp-upload
          • bei Zugriffen auf das wp-admin-Verzeichnis eine zusätzlichen HTTP-Authorisierung zu verlangen
          • ...
          1. Tach!

            Bei WordPress hilft auch,

            • den schreibenden Zugriff auf Dateien und fast alle Verzeichnisse zu unterbinden: chmod -R a-w ./ ; chmod o+w ./wp-upload

            Die Angreifer kommen in der Regel durch Lücken im Webauftritt, sind also Owner und können dann weiterhin schreiben.

            Unüberschreibbares dem root zu übereignen hilft auch nur bedingt, denn diese Dateien kann man weiterhin löschen, weil das eine Schreiboperation im Verzeichnis ist. Dem Benutzer kann man meist das Schreibrecht auf das Verzeichnis nicht entziehen. chattr +i hilft dann, die Datei unveränderlich (immutable) zu machen. Das ist aber recht ungewöhnlich und man muss sich das merken, dass das auf diese Weise gesperrt ist.

            • bei Zugriffen auf das wp-admin-Verzeichnis eine zusätzlichen HTTP-Authorisierung zu verlangen

            Ja, das kann man selbst mit einem erratbaren 0815-Passwort "sichern". Hier geht es hauptsächlich darum, dass die Bots beim Aufrufen scheitern.

            dedlfix.

            1. Tach!

              Bei WordPress hilft auch,

              • den schreibenden Zugriff auf Dateien und fast alle Verzeichnisse zu unterbinden: chmod -R a-w ./ ; chmod o+w ./wp-upload

              Die Angreifer kommen in der Regel durch Lücken im Webauftritt, sind also Owner und können dann weiterhin schreiben.

              nach chmod -R a-w ./ kann auch der Owner zunächst nicht scheiben (ich weiß: mit vi könnte er es erzwingen, dass dieses das Schreiben kurz erlaubt) und auch keine neuen Dateien anlegen. Er müsste die (meist in tausende neue und bestehende PHP-Skripte installierte) Webshell benutzen um sich das wieder zu erlauben. Sind die aber weg, dann hat er ein Problem.

              Zu Klarstellung: Ich meinte ZUSÄTZLICH. Denn klar ist ja, wenn in wp-uploads wieder PHP-Skripte landen können (der Fehler ist sowas von "asbach"...) dann dürfen die natürlich nicht ausgeführt werden.

              Natürlich kann man Wordpress auch als Linux-Paket installieren (landet in /usr/share/) und dann verlinken bzw. in der http-config Aliase setzen. Viele Hoster bieten das auch an, aber dann kann man natürlich nicht ohne weiteres jede shitty Erweiterung nutzen. Aber genau an den Dingern (oft in Templates beigepackt) liegt es auch, dass viele Wordpress- oder Joomla-Installationen nicht mit Updates gepflegt werden.

        2. Hallo und guten Abend,

          Bei WordPress hilft auch, im upload-Verzeichnis das Zugreifen auf .php sperren. Der Upload ist eigentlich nur für Bilder vorgesehen.

          1. Keine Uploads in durch http/s erreichbare Bereiche gestatten.
          2. Sämtliche Script-Ausführugnen in den durch http/s erreichbaren Upload-Verzeichnissen unterbinden!

          Grüße
          TS

          --
          es wachse der Freifunk
          http://freifunk-oberharz.de
          1. Tach!

            Bei WordPress hilft auch, im upload-Verzeichnis das Zugreifen auf .php sperren. Der Upload ist eigentlich nur für Bilder vorgesehen.

            1. Keine Uploads in durch http/s erreichbare Bereiche gestatten.

            Damit nimmst du WordPress die Funktionalität, Bilder hinzuzufügen. Wenn der Seitenbetreiber damit leben kann ...

            1. Sämtliche Script-Ausführugnen in den durch http/s erreichbaren Upload-Verzeichnissen unterbinden!

            Genau das ist das Ziel meines Vorschlags.

            dedlfix.

      2. Hallo und guten Abend,

        Es hat sich in meiner Praxis bei der Reparatur solcher, meist "eher so mittelmäßig betreuten" Webauftritte als gute Idee erwiesen mal nach dem Datum der Dateien und ins Access-Log zu schauen. Insbesondere POST-Requests sind sehr interessant. Für weitere Forschung ist dann grep hilfreich...

        Speziell die File-Upload-Module haben diverse Lücken. Da kann man die Server meistens mit wenigen Statements (Post-Requests) übernehmen, wenn die Applikation inzwischen keine fail2ban-Klasse für App-interne Authentification-Fehler hat...

        Das muss die Application selbstverständlich dann auch erstmal verlässlich loggen!

        Grüße
        TS

        --
        es wachse der Freifunk
        http://freifunk-oberharz.de