Twinstar schrieb
Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?
Hallo Twinstar,
ekki sagt doch eigentlich alles Wichtige in seinem Blog, ich zitiere mal:
"Sichergehen, dass alle Änderungen (in Datenbanken und Dateien) rückgängig gemacht sind und keine Hintertür das Hackers mehr offenbleibt. Um es offen zu sagen - dies ist SEHR schwer, genaugenommen müßte man sogar sagen: unmöglich.
Meine dringende Empfehlung ist daher, das System aus intakter Datensicherung komplett neu aufzusetzen!"
Er sagt auch, dass es beinahe unmöglich ist, das System wieder "keimfrei" zu bekommen. Will heißen: Es kann keine Anleitung geben, wie man vorgehen soll, sondern nur Hinweise, wonach man suchen soll. Aber die beste Vorgehensweise ist, selbst nach Ungewöhnlichem zu suchen. Du bist hier halt Dein eigener "Privatdetektiv".
Wir haben es hier nicht mit der Behebung von Softwarefehlern, sondern mit intelligentem Leben zu tun. Menschen versuchen, etwas vor anderen Menschen zu verstecken. Hier gibt es leider keine Pauschal-Rezepte.
Alles, was momentan bekannt und hilfreich ist, steht in Ekkis Blog.
Viele Grüße
Henning Pingel
jweiland schrieb
In den meisten Fällen wurden auf den betroffenen Systemen mehrere Webshells installiert (und teilweise sehr gut getarnt).
Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?
hepi schrieb
Twinstar schrieb
Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?
Aber die beste Vorgehensweise ist, selbst nach Ungewöhnlichem zu suchen. Du bist hier halt Dein eigener "Privatdetektiv".
Verstehe. Dann schnüffel ich mal weiter im Dateienwald. 😉
Twinstar schrieb
Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?
Ekki nennt in seinem Blog zwei Web Shells beim Namen - und auch einen speziellen User Agent String. Ekki serviert alles auf dem goldenen Tablett.
Gruß
Henning Pingel
hepi schrieb
Twinstar schrieb
Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?
Ekki nennt in seinem Blog zwei Web Shells beim Namen - und auch einen speziellen User Agent String. Ekki serviert alles auf dem goldenen Tablett.
Gruß
Henning Pingel
Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
Twinstar schrieb
Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
Für die Suche nach einer r57shell im Dateisystem bietet sich beispielsweise folgender Suchstring an:
"Use reverse (user -> resu) login for password"
Das ist aber auch nur ein Tipp, der WAHRSCHEINLICH hilft, mehr nicht. Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.
Gruß
Henning Pingel
hepi schrieb
Twinstar schrieb
Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.
Gruß
Henning Pingel
Bin dankbar für jeden Ansatz mit dem man weiter arbeiten kann.
hepi schrieb
Twinstar schrieb
Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
Für die Suche nach einer r57shell im Dateisystem bietet sich beispielsweise folgender Suchstring an:
"Use reverse (user -> resu) login for password"
Das ist aber auch nur ein Tipp, der WAHRSCHEINLICH hilft, mehr nicht. Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.
Gruß
Henning Pingel
Aber ein guter Tipp. Den den Schnipsel habe ich gerade in einem Gästebuch entdeckt. Bloss gut ... o.O
Twinstar schrieb
Aber ein guter Tipp. Den den Schnipsel habe ich gerade in einem Gästebuch entdeckt. Bloss gut ... o.O
Hi, sei bitte vorsichtig, was Du hier öffentlich postest. Wenn jemand anders gehackt worden ist, wird er jetzt wissen wollen: Was für ein Gästebuch ist gemeint? Ist das Gästebuch Schuld? Hat es eine Sicherheitslücke?
Aber hier ist das Problem: Das Gästebuch ist möglicherweise REIN GAR NICHT Schuld, sondern ein böser Hacker hat in dem Verzeichnis willkürlich sein Ei abgelegt, um es zu verstecken.
Deshalb ganz wichtig, ich kann mich nur wiederholen: Neue Erkenntnisse bitte an das TYPO3 Security Team melden.
Gruß
Henning Pingel
Twinstar schrieb
Mich würde auch interessieren wie man es schafft MD5 verschlüsselte Passörter zu knacken. Mit BruteForce sollten PW mit dem Format z.B. x4GH9nm! nicht so einfach zu hacken sein.
Das stimmt, ich dachte auch zuerst, man muesste das Passwort knacken, aber dem ist nicht so. Die MD5-Darstellung reicht. Mit dem MD5-Kennwort ausgeruestet kann man mittels POST-Datenmanipulation das TYPO3-Backend ueber das "normale" Login erreichen. Ich will hier nur keine detaillierte Anleitung geben, wie das funktioniert. Ist auch fuer den Sachverhalt, der hier geklaert werden soll nicht weiter wichtig. Wichtig ist nur zu wissen, dass das KEINE Sicherheitluecke in der TYPO3-Anmeldung ist.
Man muss sich einfach nur vor Augen halten, dass das MD5-Kennwort genauso wertvoll und schuetzenswert ist, wie ein Klartextpasswort. Der einzige Unterschied ist halt, dass man vom MD5-Hash nicht direkt auf den Klartext zurueckgreifen kann. Aber wer das MD5-Kennwort hat, kommt rein.
Twinstar schrieb
Also wenn ich die Aussage von Jan Radecker:
Die SQL-Injection-Schwachstelle ermöglichte es per Brute-Force und ein wenig SQL-Magie z.B. aus der Tabelle be_users einen Admin-User samt MD5-Passwort auszulesen.
richtig interpretiere. Hat der Angreifer "nur" den Admin Benutzernamen und den MD5 Hash des Passwortes ausgelesen und nicht das Passwort mittels Bruteforce geknackt. Oder?! In dem Fall kann der Angreifer bei Schliessen der macina_banners Lücke mit seinen Daten ja nichts mehr anfangen. #paralyzed#
Nein, das Passwort, das der Angreifer ausgelesen hat, wird ja nicht ungueltig, nur weil macina_banners jetzt das erneute Auslesen des Passworts verhindert. Also ist es unabdingbar ALLE Backend-Kennwoerter neu zu setzen.
Ich habe mal eine Frage bzgl. der Verzeichnissrechte von über das T3-Backend (Ext. Manager) installierten Module. Wenn diese installiert werden stehen die Rechte für die Verzeichnisse immer auf 755 wwwrun www. Dateien innerhalb der Ext. Verzeichnisse stehen auf 644 wwwrun www. Bedeutet das nicht automatisch, daß jeder der eine Webshell installieren kann in diese Verzeichnisse und Dateien lesen und schreiben kann wie er lustig ist? Bzw. jeder der in das Typo3 Admin Backend kommt?
Kann man sich hiervor eigentlich schützen?
Denn wenn ich die Rechte ändere in z.B. 644 EigentümerXY GruppeXY, kann man aus dem Ext. Manager nichts mehr deinstallieren bzw. löschen noch was neu installieren.
Der Witz dabei ist ja auch, daß selbst Monate alte Backups nicht mehr bringen. Denn da sind ja "WAHRSCHEINLICH" die Sicherheitslöcher wieder inklusive.
Twinstar schrieb
Ich habe mal eine Frage bzgl. der Verzeichnissrechte von über das T3-Backend (Ext. Manager) installierten Module. Wenn diese installiert werden stehen die Rechte für die Verzeichnisse immer auf 755 wwwrun www. Dateien innerhalb der Ext. Verzeichnisse stehen auf 644 wwwrun www. Bedeutet das nicht automatisch, daß jeder der eine Webshell installieren kann in diese Verzeichnisse und Dateien lesen und schreiben kann wie er lustig ist? Bzw. jeder der in das Typo3 Admin Backend kommt?
Genau. Das erleichtert die Arbeit des Hackers: Überall, wo man schreiben kann, kann versteckt werden.
Twinstar schrieb
Kann man sich hiervor eigentlich schützen?
Ja. Aber meiner Kenntnis nach nur durch manuelle Änderung der Benutzerrechte.
Twinstar schrieb
Denn wenn ich die Rechte ändere in z.B. 644 EigentümerXY GruppeXY, kann man aus dem Ext. Manager nichts mehr deinstallieren bzw. löschen noch was neu installieren.
Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.
Gruß
Henning Pingel
hepi schrieb
Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.
Gruß
Henning Pingel
Aha, gut. Damit kann ich was anfangen. Die Rechte manuell so zu ändern, daß man zum Ext. managen SSH braucht ist ja kein großer Akt. Mich wundert nur iregendwie, daß dieser Aspekt bisher so wenig in Typo3 Sicherheitsdiskussion kommuniziert ist.
Denn wenn das so ein elementar wichtiger Punkt ist, sollten das doch auch am besten alle so machen, oder?!
Wenn man mal betrachtet, was man für Typo3 benötigt, SAFE_MODE OFF, 777 und www wwwrun für viele Verzeichnisse, dann stellt sich mir die Frage an welcher Stelle kann man denn überhaupt für Sicherheit sorgen? Wo und wann eine SQL-Injection auftaucht kann kein "normaler" Typo3 Admin vorher wissen. Und wenn ein Hacker erstmal sowas gefunden hat und dann auch noch so tolle Schreibrechte vorfindet dann habe ich das Gefühl, daß man garnichts machen kann.
Twinstar schrieb
hepi schrieb
Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.
Gruß
Henning Pingel
Aha, gut. Damit kann ich was anfangen. Die Rechte manuell so zu ändern, daß man zum Ext. managen SSH braucht ist ja kein großer Akt. Mich wundert nur iregendwie, daß dieser Aspekt bisher so wenig in Typo3 Sicherheitsdiskussion kommuniziert ist.
Denn wenn das so ein elementar wichtiger Punkt ist, sollten das doch auch am besten alle so machen, oder?!
Es gibt das Security Cookbook des TYPO3 Security Teams und andere Versuche des Teams, TYPO3-Administratoren für das Thema Security zu sensibilisieren. Die Adminstratoren selbst müssen sich aber natürlich auch Gedanken zum Thema Security machen, am besten natürlich, bevor eingebrochen wird. TYPO3 war und ist immer ein Projekt, das mit Hilfe von Ideen und Initiativen aus der Community verbessert worden ist.
Viele Web-Applikationen brauchen Berechtigung zum Schreiben von Dateien im Webspace. TYPO3 könnte so, wie es ist, nicht existieren, ohne Schreibberechtigung in manchen Foldern. Redakteure könnten dann keine Bilder hochladen. Aber Du könntest als Admin halt überprüfen, was sich im Laufe der Zeit in den beschreibbaren Verzeichnissen ändert.
Übrigens: Wenn der Hacker Dein SSH-Passwort kennt, ist natürlich auch die Änderung der Benutzerrechte zwecklos.
Gruß
Henning Pingel
hepi schrieb
Es gibt das Security Cookbook des TYPO3 Security Teams und andere Versuche des Teams, TYPO3-Administratoren für das Thema Security zu sensibilisieren. Die Adminstratoren selbst müssen sich aber natürlich auch Gedanken zum Thema Security machen, am besten natürlich, bevor eingebrochen wird. TYPO3 war und ist immer ein Projekt, das mit Hilfe von Ideen und Initiativen aus der Community verbessert worden ist.
Gruß
Henning Pingel
In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?
Twinstar schrieb
In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?
Im TYPO3 Security Cookbook (0.0.5), verlinkt auf http://typo3.org/teams/security, steht unter anderem : "use safemode, or at least open basedir to prevent webs from accessing other directories or execute things, they mustn't – again: less is more."
Mehr werde ich zu der Frage nicht sagen, weil ich momentan keine gute Anwort geben kann und weil ich denke, dass das eben auch zur Verantwortung von Admins gehört, sich diese Frage selbst zu beantworten.
Das soll nicht arrogant klingen, ich will nur auf folgendes hinaus: Du hast da einen Server stehen und installierst einfach eines der besten freien WCMS, das Dich nichts kostet und darüber hinaus auch noch genial im Funktionsumfang ist. Nun musst Du Dich irgendwann auch mal fragen: Was macht diese Software eigentlich, die ich da benutze? Wie funktioniert das genau? Wo funktioniert es nicht? Wie kann ich die Software gegen Angriffe schützen?
Gruß
Henning Pingel
hepi schrieb
Wie kann ich die Software gegen Angriffe schützen?
Gruß
Henning Pingel
Du hast vollkommen Recht. Will jetzt auch garnicht mehr weiter öffetnlich auf diesem Thema rumreiten. Nervt ja auch irgendwann. Berate mich mal lieber mit Leuten aus meinem IT Dunstkreis. Trotzdem vielen Dank für die vielen nützlichen Informationen.
Twinstar schrieb
In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?
Das ist doch Schwachsinn oder?
Also ich weiss, dass wenn einer dann ich, bzw. der dummy vor dem PC und nicht typo3 der jenige ist, der vielleicht mit der Einstellung safe_mode = On nicht sehr weit kommt (bzw. kam) - mittlerweile betrifft mich das zumindest persönlich nicht mehr, da mein Server wunderbar mit safe_mode = On läuft!
Ich könnte mir einen public Server mit Safe_Mode Off nicht einmal vorstellen #giggle#
Grüße
Info
P.S.: Super Antworten & Fragen hier in diesem Post!!!! Hat mir einige nützliche Infos gegeben!!!!