HackeD By UyuSsman

M

Michael Künzle

Mitglied
Hallo zusammen

Letzte Woche erhielt ich einen Anruf einer Kundin. Sie musste feststellen, dass Ihre Website "gehackt" wurde. Ich konnte es kaum glauben und guckte mir das mal an. Da hat doch tatsächlich jemand die index.php im root überschrieben. Ergebnis im Browser ist eine Seite mit schwarzem Hintergrund, weissem Text a la "HackeD By UyuSsman" etc. und türkischer Hintergrund-Musik. Ein angezeigtes "Logo" wird von http://uyussmanx.sitemynet.com/uyzzzzzz.jpg geladen.

Die restlichen Dateien waren unverändert und somit konnte ich einfach mal kurz das Backup der index.php zurückschreiben und das CMS funktionierte wieder. Alle Passwörter geändert, soweit so gut. Nun wollte ich wissen, wie so was passieren konnte.

Mein Webhoster meinte das liegt an einer veralteten CMS-Version; also auf jeden Fall meinte er, dass die Schuld bei mir liegt. Ich denke aber, dass jemand direkten Dateizugriff benötigt (z.B. über FTP) um eine index.php komplett überschreiben zu können. Immerhin hat der Besitzer der index.php gewechselt. Ich hatte keine Rechte die Datei zu löschen oder editieren. Umbenennen war das einzige, dass ich machen konnte.

Was meint Ihr dazu? Kann es Sicherheitslöcher in einem CMS geben die das überschreiben einer index.php ermöglichen?

Vielen Dank für eure Antworten.

gruss michi
 
Hallo
tja da heißt es Logfiles durchforsten. Kann man den auf ner CMS Oberfläche ins Dateisystem und Daten ändern?

Wie gesagt viiiel Sucharbeit

Gruß Ronny
 
@ronnic

Sehr sehr unwahrschein, wenn das gehen würde, dann wären viele CMS eine sehr starke Sicherheitslücke. Ich denke mal, da wird sich wohl jemand das PW geholt haben. In den meisten fällen werden nur die Startseiten ausgetauscht, das ist schon Ärger genug, denn die meisten Hacker wollen nur auf Sicherheitslücken verweisen und sich danach auf die Brust klopfen was?se wieder für Dummfug gemacht haben.
 
Hallo,

ich wurde vor 2 Wochen von Xtech Inc. gehackt, bei mir war es aber wesentlich schlimmer.
Alle Datein waren im Eimer und alle index-Seiten waren überschrieben.

Die kamen laut Logs durch ein Script rein....

Also denke ich mal, dass meine Scripts einfach unsicher sind
huh.gif
 
Ich denke mal ein Grund bei alten CMS könnte vorallem ein aktiviertes Register Globals sein (wie es vielfach gewünscht wird)...
So braucht es nur einige Lücken und man kann die Dateien überschreiben oder?

Gruss Marc
 
Hallo,

es gibt immer wieder Sicherheitslöcher in bekannten Systemen. Sehr schlimm war es vor einigen Monaten mit phpBB, PHP-Nuke (und Ablegern) und Mambo (+ Ableger).

Ich selbst wurde vir etwa 1,5 Jahren ebenfalls 2x Opfer eines solches Scriptkiddies. Daraufhin habe ich konsequent das CMS nach Lücken durchforstet und unsichere Module abgeschaltet.

Lücken findet man meist bei Modulen, die nicht zum Core gehören.


Am einfachsten wäre es, wenn du uns kurz das eingesetzte CMS inkl. Version nennst.
 
Es handelt sich um ein sehr einfaches CMS Namens Websitebaker ;-) simpel - aber sehr leicht verständlich. Ja, ich gebe zu die Version ist ein wenig älter. Es handelt sich um den Release 2.4.1. Aktuellester Release ist 2.6.5. Es sind keine Zusatzmodule installiert, nur Core-Dateien wurden installiert.
 
Sorry für die harten Worte, aber wie Naiv bist du?
wink.gif
- Aber liegt wohl daran, dass du grad zum ersten mal gehackt wurdest...

QUOTE Die restlichen Dateien waren unverändert und somit konnte ich einfach mal kurz das Backup der index.php zurückschreiben und das CMS funktionierte wieder. Alle Passwörter geändert, soweit so gut. Nun wollte ich wissen, wie so was passieren konnte.

Natürlich immer die beste Lösung.. Woher weisst du dass die anderen Dateien unverändert waren? Führst du genaue md5-Hash Tabellen/Logs?
Die Frage sollte außerdem eher heissen: wie kann ich sowas verhindern!



QUOTE
Mein Webhoster meinte das liegt an einer veralteten CMS-Version; also auf jeden Fall meinte er, dass die Schuld bei mir liegt. Ich denke aber, dass jemand direkten Dateizugriff benötigt (z.B. über FTP) um eine index.php komplett überschreiben zu können. Immerhin hat der Besitzer der index.php gewechselt. Ich hatte keine Rechte die Datei zu löschen oder editieren. Umbenennen war das einzige, dass ich machen konnte.

Man kann sogar (häufig) über eine .php Datei komplett Root-Zugriff über einen Server erlangen - sofern dieser nicht ausreichend gesichert ist.
Es ist also durchaus möglich, dass er über eine andere Datei (nur weil die index.php verändert wurde, heisst es nicht dass die Lücke auch dort liegt!! - selten sogar!) die index.php bearbeiten konnte und anschließend gechmodded hat.

Und ja, veraltete CMS kann/wird der Grund sein. FTP Zugriff halte ich für unwahrscheinlich, da man (afaik) keine Datei Chmodden kann, die man nachher selber nicht mehr löschen kann.


Klapper am besten beide Seiten ab, und suche nach deinem CMS (+Version)

http://milw0rm.com
http://www.securityfocus.com/

Mit Glück, wirst du fündig und weisst dann was zu tun ist (sehr wahrscheinlich updaten).

PS: hat der "Hacker" eigentlich seine Email Adresse hinterlassen? Könntest ja eventuell Kontakt aufnehmen.
 
QUOTE (Michael Künzle @ Mo 26.2.2007, 12:46)Kann es Sicherheitslöcher in einem CMS geben die das überschreiben einer index.php ermöglichen?

Die kann es in beliebigem Umfang geben. Ein Passwort ist völlig unnötig - das wird der Hacker auch gar nicht kennen. Die Änderung des Passwortes ist da zwecklos.


QUOTE (Michael Künzle @ Mo 26.2.2007, 12:46)Ich denke aber, dass jemand direkten Dateizugriff benötigt (z.B. über FTP) um eine index.php komplett überschreiben zu können. Immerhin hat der Besitzer der index.php gewechselt. Ich hatte keine Rechte die Datei zu löschen oder editieren. Umbenennen war das einzige, dass ich machen konnte.


Das ist definitiv falsch. Ich bin zwar kein PHP-Experte, aber nach dem, was ich hier schon gelesen habe, sind PHP-Scripts teilweise (gerade bei unbekannten, kleinen CMS) so katastrophal, daß so ziemlich alles gehen dürfte.

Und solange diese Script-Lücken nicht geschlossen werden (etwa, weil es keinen Patch gibt, weil das CMS nicht mehr gepflegt wird), kann sich das jederzeit wiederholen. Ferner erscheint es mir etwas merkwürdig, daß Du Kunden hast, denen Du solche Dinge installierst - und daß Du gleichzeitig von solchen, doch schon sehr lange bekannten Sicherheitslücken nichts weißt.
 
Ich kann aus dem Blickwinkel der ColdFusion-Entwicklung sagen, dass mitunter die Scriptsprache selbst unglaubliche Features bereithält die kein "Hackrisko" sondern eine Hackgarantie" darstellen. Keine Details. (Wir wollen ja nicht irgendjemand auf komische Ideen bringen). Auf jedenfall reichte es, um mehrere Coldfusion-Provider in Schweißausbrüche zu versetzen. UIch denke mal, das PHP ähnliche Faetures bereithält.


Gruß Ronny

(Logfiles/IP suchen/ Strafantrag stellen)

 
QUOTE (ronnic @ Mo 26.2.2007, 15:45)Ich kann aus dem Blickwinkel der ColdFusion-Entwicklung sagen, dass mitunter die Scriptsprache selbst unglaubliche Features bereithält die kein "Hackrisko" sondern eine Hackgarantie" darstellen.

Genau solche Dinge meine ich.

Hier gab es einmal ein Beispiel, daß per Url


QUOTE http://www. meinedomain.de/index.php?file=/einedatei.inc


nachgeladen und ausgeführt wurde. Und das ganze dann noch womöglich so, daß auch eine fremde Url angenommen wird. Da muß ich mir um die Sicherheit keine Gedanken machen - so etwas ist offen.

Sprich: PHP enthält einige Features, die sich leicht zum Hacken verwenden lassen. Und jedes Script, das diese Features ohne eine massive interne Zusatzkontrolle nutzt, ist offen. Da nutzt auch eine gefundene IP oder eine Anzeige nichts - der nächste Hack kommt dann aus Australien, die Lücke muß zu.

Der 'alte Microsoft-Weg' ist da dagegen aufwendiger: Datenbank per Sql-Injektionen hacken, der SqlServer läuft auf einem Dienst mit zu hohen Rechten, darüber dann Betriebssystembefehle ausführen.
 
PHP, ist immer anfällig... ich lasse dies trotz Leistungseinbusen nun auf den Hostingservern mit mehr Rechten über suPHP laufen... dies sollte im Falle eines Problems dieses auf den Kundenaccount beschränken... aber es gibt denoch immer Lücken. Sei dies vom System her selbst oder in einem Modul oder einem sonstigen Script.. 100% Sicherheit gibt es nirgends, da es sehr viele Faktoren gibt, die Probleme machen können.

Was meiner Meinung auch ein grosses Problem ist, ich kenne einige Hoster (habe 5 Stück getestet um die Features anzuschauen), welche ohne etwas Hintergrundwissen, den Safemode, etc. (der fast immer als Mod läuft) ohne auch nur etwas zu tun... abschalten.

Gruss Marc

PS: Lade die Seite neu rauf... und fertig ist. Natürlich solltest du auch gleichzeitig die aktuelle Version einspielen. So hast du Gewissheit, dass keine anderen Dateien irgendwo noch ein Backdoor haben, die der Hacker erstellt hat.
 
@guwapo
QUOTE Natürlich immer die beste Lösung.. Woher weisst du dass die anderen Dateien unverändert waren? Führst du genaue md5-Hash Tabellen/Logs?


Nein, ich arbeite nicht mit md5. Wahr wohl ein wenig leichtsinnig von mir zu behaupten dass keine anderen Dateien verändert wurden. Ich habe lediglich das "modified" Datum angeguckt.


QUOTE Die Frage sollte außerdem eher heissen: wie kann ich sowas verhindern!


Aber zuvor sollte man doch besser die Ursache kennen.


QUOTE Und ja, veraltete CMS kann/wird der Grund sein.

Leider habe ich keine Informationen mit direktem Zusammenhang meines Falles auf den beiden Links gefunden. Ein Update des CMS ist sicher sinnvoll.

@jAuer

QUOTE Und solange diese Script-Lücken nicht geschlossen werden (etwa, weil es keinen Patch gibt, weil das CMS nicht mehr gepflegt wird), kann sich das jederzeit wiederholen. Ferner erscheint es mir etwas merkwürdig, daß Du Kunden hast, denen Du solche Dinge installierst - und daß Du gleichzeitig von solchen, doch schon sehr lange bekannten Sicherheitslücken nichts weißt.


Das CMS wird nach wie vor weiterentwickelt. Daher werden sicherlich bekannte Sicherheitslücken geschlossen. Das mir diese Risiken nicht bekannt waren stimmt teilweise. Sicherlich habe ich die Nachforschungen vernachlässigt, anderseits kann ich nicht ständig Updates aufspielen wenn der Kunde dafür nicht bezahlen will. Sicherlich fehlte es mir an Überzeugungskraft und einleuchtenden Argumenten für die Überzeugung des Kunden für ein Update. Das hat sich jetzt wohl ein wenig geändert.

Ich werde den Ratschlag von Marc befolgen und alle Dateien neu hochladen inkl. updaten.


Vielen Dank für eure Hilfe.

 
QUOTE (ms @ Mo 26.2.2007, 16:03) Was meiner Meinung auch ein grosses Problem ist, ich kenne einige Hoster (habe 5 Stück getestet um die Features anzuschauen), welche ohne etwas Hintergrundwissen, den Safemode, etc. (der fast immer als Mod läuft) ohne auch nur etwas zu tun... abschalten.


Interessant..

http://visualhype.de/programmierung/aender...n-in-php-6/371/
http://www.php.net/~derick/meeting-notes.html#safe-mode


Ein "guter" Hoster wird sowieso nicht auf "safemode" hoffen, darum ist diese Einstellung auch bei "guten" Hoster niemals "on" gewesen...

Kann man überhaupt als "Kunden" feststellen was der Hoster alles so für Sicherheitsvorkehrungen erschlossen hat? PHP.ini anschauen ist ja die eine Sache, aber ob der Kunde im jailed/chroot Umgebung ist kann man denk ich ohne weiteres nicht feststellen..

 
QUOTE guwapo // Text gelöscht.. habe deinen Text vorhin falsch gelesen!


Aber trotzdem...

Was haltet Ihr eigentlich von suPHP als "Benutzerrechte-Lösung"?
Ich habe es derzeit auf einem Server installiert, möchte es aber auch für die Zukunft auf weiteren Systemen einsetzen.

Gruss Marc
 
QUOTE (ms @ Mo 26.2.2007, 18:05) Was haltet Ihr eigentlich von suPHP als "Benutzerrechte-Lösung"?

Ist ein guter Ansatz, um PHP überhaupt im Safe-Mode vernünftig betreiben zu können. Dies alleine macht aber noch keine "sichere" PHP-Umgebung aus. Wenn du die open_basedir gut setzt, könntest du PHP zusmamen mit suPHP eigentlich auch ohne safe_mode einigermassen sicher betrieben. Ohne basedir immer mit Safe_Mode!

Extrem wichtig ist daher auch das open_basedir, sowie das safe_mode_exec_dir

Bei mir habe ich global folgende Funktionen mittels disable_functions gesperrt: exec, passthru, system, popen. Damit hat PHP "keine" möglichkeit mehr, direkt auf das System zuzugreiffen.

Bei mir können die Benutzer einige Funktionen, wie allow_url_fopen, allow_url_include, post_max_size etc per CP verwalten, bzw steuern. Gerade die allow_url_fopen und allow_url_include sind der ideale Weg um femden Code einzuschleusen. Daher sollten diese Funktionen natürlich gesperrt werden, wenn nicht zwingend benötigt (was wirklich selten der Fall ist).

Ausserdem kannst du per Mod_security (Apache) allgemein bekannte in gebräuchliche Attacken global sperren, wie beispielsweise das einschleusen weiterer E-Mailadressen per Formular, falsche Header etc.

Und Achtung, ältere Apache-Versionen sind nicht Thread-Safe!
 
Weiss gar nicht warum ihr euch alle so aufregt, das war ein "harmloses" Defacement, geschieht im Netz minütlich: http://www.zone-h.org/component/option,com...acks/Itemid,45/ ist teilweise schon ein richtiger Sport. Hatte das ganze auch schon, als mein Hoster ein wenig spät die PHP-Version wechselte. Die Leute nutzen meist schon lange bekannte Sicherheitslücken, tauschen die Index Seite und verschwinden wieder.

Tipp: Schau das überall die aktuellsten Versionen laufen und update sie rechtzeitig.

Grüße
 
suPHP ist denk ich mal nur eine Ergänzung, am sichersten ist es (afaik) mit einer jailed/chroot umgebung pro User, d.h. egal wo die Schwachstelle liegt, es kann maximal der eine User gehackt werden und nicht das ganze System / bzw. andere User.

Ansonsten stimme ich natürlich Alonso vollkommen zu.
 
Hallo,

das ist mir vor einem Jahr auch 2 mal passiert (Genau die Hacker die hier beschrieben wurden, gleiche Vorgehensweise). Ich nutzte ein CMS für Bilder-Hosting. Danach habe ich ein paar Sicherheits-Patches installiert die durch die Anbieter empfohlen waren, und seitdem läuft es stabil.

Kommt natürlich immer drauf an ob es Patches gibt, oder ob es selber gemacht werden muss. Also in meinem Fall scheint es eine Schwachstelle des CMS gewesen zu sein, und lag nicht unbedingt am Hoster.

Gruß,

Chris
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben