Ist es denn ausreichend, das Modul macina_banners auf Version 1.5.0 zu updaten?
Woran kann ich eindeutig erkennen, dass meine Installation bereits infiziert wurde?
Moeglicherweise liegt der Infekt ja vor, wurde jedoch einfach noch nicht genutzt.
Ich werde jetzt erst einmal die Passwoerter neu setzen.
danke,
Patrick
Hi all,
auf typo3.org gibt es inzwischen eine Zusammenfassung der Erkenntnisse des TYPO3 Security Teams zu diesen Angriffen, nämlich unter
http://buzz.typo3.org/teams/security/article/massive-web-server-hacks-iframe-attacks-now-extended-to-typo3/
(deutsch unter
http://www.naw.info/blogs/typo3security/2007/07/03/angriffswelle-gegen-webserver-iframe-attacken-nun-auch-typo3)
greets
/Ekki
__________________
Ekkehard Gümbel
naw.info net&works Internet Services GmbH, Hannover
http://www.naw.info
Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?
1. Alle macina_banners Ext. deinstallieren bzw. auf 1.4.1 zu updaten.
(mit find -type d macina_banners) findet man schnell raus aif welchen web´s die Ext. sind.
2. Alle Dateien nach den bekannten Strings, encodierte wie decodierte durchsuchen (grep -r etc.) und entfernen.
3. Alle temp_cached* Dateien löschen und neu generieren lassen.
Das ist was mir dazu einfällt. Was sollte man noch tun?
Sollte man alle Typo3 Admin Passwörter ändern? Oder besser gleich auch sämtliche Redakteurs Zugänge?
Ich würde auf Nummer sicher gehen und ein altes Backup einspielen...
nickno schriebIch würde auf Nummer sicher gehen und ein altes Backup einspielen...
Wenn man über 100 Web´s auf einem Server hat und Redakteure über viele Typo3 Installationen täglich munter Content produzieren, ist das nicht wirklich praktikabel. Die müssten ja dann alle wieder auf dem Stand vor z.B. 4 Wochen anfangen.
Besteht denn grundsätzlich die Möglichkeit, daß durch den SQL-Inject weitere Schadsoftware als "Hintertürchen" installiert wurde? Und wenn ja, ist da vielleicht was bekannt? 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.
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#
Über SQL-Injection kann man sich z.B. selbst als Admin in der Datenbank eintragen, da braucht man kein Passwort zu knacken.
Als Admin kann man z.B. beliebige (selbst geschriebene) Extensions installieren.
Wenn es irgendwie geht, sollte man versuchen festzustellen, über welchen Weg der Angreifer Zugriff auf den Server bekommen hat. Es muss nicht unbedingt oder nur macina_banners gewesen sein.
Ideal wäre eine genaue Analyse der Server Logfiles aus der Zeit vor dem Entdecken des Einbruchs.
In den meisten Fällen wurden auf den betroffenen Systemen mehrere Webshells installiert (und teilweise sehr gut getarnt). Wenn man nicht alle findet, hat der Angreifer nach wie vor Zugriff auf den Rechner.
Gerade wenn man über 100 Webs auf dem Server hat, muss man sich einige Zeit nehmen, um das System genau zu analysieren (und auch künftig zu überwachen).
Jochen Weiland
Twinstar schriebWie 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 schriebIn 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 schriebTwinstar schriebWie 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 schriebGibt 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 schriebTwinstar schriebGibt 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 schriebGut, 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 schriebTwinstar schriebGut, 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 schriebTwinstar schriebGut, 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 schriebAber 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 schriebMich 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 schriebAlso 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 schriebIch 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 schriebKann man sich hiervor eigentlich schützen?
Ja. Aber meiner Kenntnis nach nur durch manuelle Änderung der Benutzerrechte.
Twinstar schriebDenn 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 schriebJa, 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 schriebhepi schriebJa, 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 PingelAha, 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