Blackhole Exploit nistet sich in der Website ein
lima-city → Forum → Die eigene Homepage → Sicherheit im Internet
ausgabe
benutzerdaten
bestehen
code
datei
datenbank
datum
eingabe
filtern
formular
parameter
post
programm
register
system
umzug
url
vergessen
verwenden
webseite
-
Liebe Forianer;
seid einiger Zeit werden einige der Websites, welche von mir betreut werden, des öfteren mit einem Blackhole Exploit infiziert.
Dieser klinkt sich ausschliesslich in PHP-Dateien ein.
CHMOD fast aller Dateien 644 sofern nicht anders vorgegeben um eine Funktion des CMS zu gewährleisten.
Der Exploit nistet sich mit folgendem Code ein : echo(gzinflate(base64_decode(
Folgende Massnahmen wurde von mir ergriffen :
1. Ersetzen des kompletten Unterbaus bis auf die CONFIG durch originale Dateien
2. Änderung des FTP-Passwortes
Meine Frage ist nun, ob dies ausreicht und wenn nicht, was ich noch machen kann?
best wishes
Ralf -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Ich weiß jetzt nicht, was mit "Blackhole Exploid" gemeint ist, aber wenn sich Code in deine Webseite einnistet, dann wird irgendwo entweder eine XSS-Lücke bestehen oder über Parameter eingeschläust.
Wichtig ist immer(!):
- Register globals off (da sonst Variablen zB per GET geändert werden können)
- safe_mode immer auf on
- Daten (COOKIE, GET, POST, REQUEST) immer schon bei der Eingabe nach Schadcode filtern
- Ausgabe (zB aus Datenbank) immer filtern (damit durch SQL-Injections eingefügter Code nicht ausgeführt werden kann)
- Niemals $_SERVER['PHP_SELF']; verwenden (wird gerne bei Formularen gemacht), da das vom Browser gesetzt wird und somit XSS ermöglicht
-
trueweb schrieb:
Ich weiß jetzt nicht, was mit "Blackhole Exploid" gemeint ist, aber wenn sich Code in deine Webseite einnistet, dann wird irgendwo entweder eine XSS-Lücke bestehen oder über Parameter eingeschläust.
Wichtig ist immer(!):
- Register globals off (da sonst Variablen zB per GET geändert werden können)
- safe_mode immer auf on
- Daten (COOKIE, GET, POST, REQUEST) immer schon bei der Eingabe nach Schadcode filtern
- Ausgabe (zB aus Datenbank) immer filtern (damit durch SQL-Injections eingefügter Code nicht ausgeführt werden kann)
- Niemals $_SERVER['PHP_SELF']; verwenden (wird gerne bei Formularen gemacht), da das vom Browser gesetzt wird und somit XSS ermöglicht
Danke für die fixe Antwort.
Register globals stehen auf OFF
safe_mode .... wo ändere ich dies, oder muss das der Webspaceanbieter aktivieren?
Daten (COOKIE, GET, POST, REQUEST) <<< es handelt sich um CMS-Systeme....
Ausgabe (zB aus Datenbank) immer filtern (damit durch SQL-Injections eingefügter Code nicht ausgeführt werden kann) <<< Wie kann ich das machen oder besser wie muss ich da vorgehen?
Niemals $_SERVER['PHP_SELF'] verwenden <<<< Wie gesagt ist nicht selbst programmiert, sondern sind CMS-Systeme
Wie kann ich da vorgehen?
Bei PHPFusion kann ich da eventuell was machen, aber nicht bei Joomla oder Drupal, denn da reichen meine Kenntnisse im internen Aufbau nicht aus.
best wishes
Ralf -
Wenn du ein (oder in dem Fall mehrere) CMS-Systeme verwendest, kannst du eigentlich nicht viel machen, außer ständig auf aktuellem Stand zu halten, also Updates zu installieren. Natürlich solltest du da ein relativ sicheres CMS verwenden, bei dem die Community aufgetretene Sicherheitslöcher schnell schließt und Updates herausbringt.
-
trueweb schrieb:
Dann mal aufklären:
Ich weiß jetzt nicht, was mit "Blackhole Exploid" gemeint ist, aber wenn sich Code in deine Webseite einnistet, dann wird irgendwo entweder eine XSS-Lücke bestehen oder über Parameter eingeschläust.
Blackhole Exploit ist ein Framework das man sich kaufen kann und eine Sammlung an Exploiten beinhaltet. Wenn jemand auf eine infizierte Seite surft probiert der Blackhole Exploit eine Reihe von Exploiten aus um den Client ebenfalls zu infizieren und ihm einen Virus zu übertragen.
XSS? Der Fehler ist immerhin schwer genug, dass es von außen möglich ist PHP-Code auszuführen...
Verwendest du eval() auf deinen Seiten? Oder ist es sonst irgendwie möglich Dateien zu manipulieren? Du könntest ja mal den Namen des CMS nennen.
trueweb schrieb:
Damit hast du recht.
Wichtig ist immer(!):
- Register globals off (da sonst Variablen zB per GET geändert werden können)
- safe_mode immer auf on
- Daten (COOKIE, GET, POST, REQUEST) immer schon bei der Eingabe nach Schadcode filtern
trueweb schrieb:
jede dynamische Ausgabe (egal ob von PHP oder MySQL) solltest du entweder durch
Ich weiß jetzt nicht, was mit "Blackhole Exploid" gemeint ist, aber wenn sich Code in deine Webseite einnistet, dann wird irgendwo entweder eine XSS-Lücke bestehen oder über Parameter eingeschläust.
Wichtig ist immer(!):
- Ausgabe (zB aus Datenbank) immer filtern (damit durch SQL-Injections eingefügter Code nicht ausgeführt werden kann)
oderhtmlspecialchars()
laufen lassen, um XSS zu verhindern.htmlentities()
SQL-Injections solltest du auf jeden Fall verhindern, in dem du alle Userdaten bevor du sie in eine SQL-Anweisung einbaust durch
laufen lasst.mysql_real_escape_string()
trueweb schrieb:
Sollte nicht der Server wissen wie das Script heißt? Egal wie, wenn du hier ebenfalls
- Niemals $_SERVER['PHP_SELF']; verwenden (wird gerne bei Formularen gemacht), da das vom Browser gesetzt wird und somit XSS ermöglicht
oderhtmlentities()
verwendest bist du hier auch sicher.htmlspecialchars()
Was bis jetzt noch vergessen wurde:
- Niemals eval verwenden, schon gar nicht mit Benutzerdaten
- Niemals include oder require mit (ungefilterten) Benutzerdaten nutzen
- bei Dateiuploads extrem aufpassen, dass keine ausführbaren Dateien hochgeladen werden können (PHP, PL, CGI, ...)
- Das CMS immer auf dem neuesten Stand halten, um möglichst wenige Sicherheitslücken zu haben
ikariamx schrieb:
Obwohl du schneller warst:
safe_mode .... wo ändere ich dies, oder muss das der Webspaceanbieter aktivieren?
safe_mode musst du in der php.ini umstellen.
Und obwol noch wer schneller war... hier mein Beitrag -
Hier findest du Möglichkeiten den Safe-Mode umstellen zu können: http://sogoth.com/?p=293
Ansonsten kann ich mich nur den anderen anschließen. Da du natürlich nicht selbst entwickelte Software verwendest bist du an den Hersteller gebunden, du musst also darauf hoffen dass dieser die Lücken schleunigst schließt.
Wäre ein Umzug auf TYPO3 möglich? TYPO3 ist, meine ich, sicherer.
Gruß S.Brosch -
software-brosch schrieb:
Wäre ein Umzug auf TYPO3 möglich? TYPO3 ist, meine ich, sicherer.
Gruß S.Brosch
Wieso sollte Typo3 jetzt sicherer sein als Joomla beispielsweise, das CMS ist ja noch umfangreicher, da gibts sicherlich noch einige unentdeckte Lücken
Beitrag zuletzt geändert: 5.4.2012 11:42:00 von imho -
hackyourlife schrieb:
Was bis jetzt noch vergessen wurde:
- Niemals eval verwenden, schon gar nicht mit Benutzerdaten
Wenn ich es mir so anschaue, wird nur in einem einzigen PHP-Programm welches auf allen CMS-Systemen gleichermassen installiert ist eval-code genutzt. Dieser wurde von mir gerade in normalen PHP-Code umgewandelt. Danach wurde der Originalcode auskommentiert und gegen denumgewndelten Code ausgetauscht.
Das Programm ist weiterhin funktionsfähig.
Falls irgend jemand das Programm auch nutzen sollte :
Es handelt sich um die Wunschbox von Kintaro
Vielen Dank für alle Rückmeldungen.
best wishes
Ralf -
Ich hab leider noch nicht ganz raus, welches CMS es nun ist, aber ich denke etwas allgemeines kann ich schon dazu sagen:
Wenn du befürchtest, du weißt, wo eine Sicherheitslücke ist, melde sie. Und wenn du entwickeln kannst, kannst du sie auch vllt schließen. Es kann aber auch so großes Misstrauen sein, dass du sagst "ich möchte zusätzliche sicherheit". Du könntest in die Index Datei auch eine eigene einbinden, welche die globalen Variablen bereits vordurchsucht. Hier kannst du zb einen XSS Filter implementieren, welcher allerdings sehr gut durchgetestet werden muss.
Ich persönlich habe auch gerne eine Statik in der Seite. Mein Blog (siehe Signatur) ist eigentlich Wordpress, nur kommst du, egal welche Sicherheitslücke du versuchen würdest, nicht rein. Mein Blog ist vor jedem Exploit gesichert, da ich mein eigenes Plugin "Brutal Cache" im BrutalMode nutze, und so das komplette CMS außen vor lasse. Diesen Ansatz kann man sich auch durch den Kopf gehen lassen, wenn man ein Sicherheitstool schreibt.
Da es sich um eine Wunschbox handelt ist es zu empfehlen. eval zu entfernen, und, wenn du Richtext zulassen willst, dich mal mit dem HTMLPurifier auseinander zu setzen. Dieser ist ein recht zuverlässiges Werkzeug, um Richtext zu analysieren.
Meine persönliche Bitte wäre hier, diese Lücke auch an den Codeschreiber zu melden, und den Fix, welchen du vorgenommen hast, gleich mit zu senden. Damit kannst du allen Usern dieser Wunschbox helfen.
Liebe Grüße -
Sorry..... hab ich vergessen.....
Es handelt sich bei den CMS-Systemen um PHPFusion v7.02.04, Joomla v1.6 und Drupal.
Beim zuletzt genannten kenn ich die aktuelle Version nicht.
Ich hoffe das hilft weiter,
Kintaro wurde informiert und ich hab ihm den Lösungsansatz beriets zukommen lassen.
Hab nur bislang keine Zeit gefunden auch ins Forum zuschreiben und die gefixte Version anzuhängen.
Bin grade im Umzug und muss mal wieder grade einfach zuviele Dinge gleichzeitig erledigen.
ggamee schrieb
Mein Blog ist vor jedem Exploit gesichert, da ich mein eigenes Plugin "Brutal Cache" im BrutalMode nutze, und so das komplette CMS außen vor lasse. Diesen Ansatz kann man sich auch durch den Kopf gehen lassen, wenn man ein Sicherheitstool schreibt.
Könntest du mir in der Richtung weiter helfen? Hört sich gut an....
best wishes
Ralf -
Joomla solltest du aktualisieren, 1.6 ist ja schon älter aktuell ist 2.5.4
Wenn aber das Exploit auf allen drei Seiten ist, wird sich denke ich derjenige schon an dem auf allen drei Seiten installierten Script zu schaffen gemacht haben
Beitrag zuletzt geändert: 5.4.2012 14:19:05 von imho -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
