[Diskussion] Dynamische Malware infiziert Webseiten

[charli]

Hallo,

Wenn man in den httpd- und sendmail log-files das Wort 'hightstats' o.ä. nicht findet, kann man dann annehmen das man nicht betroffen ist ?

nö, warum sollte das in den Logfiles stehen?

Bzw was gibt es für einen einfachen Test ?

Eigene Homepages (Startseiten genügt hoffentlich) mit dem Firefox aufrufen (der ist gegen den "Virus" ziemlich sicher immun), im Firefox den Quelltext anzeigen lassen und nach "Iframe" suchen.

Wenn php-Dateien vom Virus geändert werden

Werden sie aber nicht nach den Berichten von Janny82.

 

[Huschi]

@Blob:
Du hast richtig Angst, daß jemand Deine DynDNS-Domains angreifen will, oder?

Laß uns mal mit beiden Füßen auf dem Boden bleiben (ich weiß, fällt Dir schwer...):
Von den bisher berichteten Vorfällen sind mal 3.000 mal 10.000 Domains befallen. In beiden Berichten, in denen Zahlen genannt sind wird jedesmal nur von "Hostern" geredet und nicht von "Servern". Einer davon hat seinen Apache neu gebaut und das Problem dennoch nicht beseitigt bekommen.

Ob Janny82 wirklich unter die selbe Attacke fällt, halte ich nicht für 100%ig gesichert. Meiner Ansicht nach hat Janny82 (bitte nicht persönlich nehmen) nicht ausreichend Erfahrung mit Linux und der ganzen Materie um den Vorfall wirklich zu analysieren.
Was dagegen spricht:
a) Der Test mit "mkdir 123" funktionierte.
b) In den bisherigen Berichten war nirgends etwas von Iframes zu lesen.
c) Eingebundene Iframes sind gang und gebe nach einer erfolgreichen Hack-Aktion.

Daher meine Bitte:
Geht mal mit ein weniger Panik an die Sache. (Außer Janny82! Denn Du mußt wirklich was daran tun.)

Was mich persönlich irritiert, ist, daß Heise bisher nicht darüber berichtet hat.
Oder ist mir eine News dazu entgangen?

huschi.

 

[blob]

(Früher habe ich mich nie um Sicherheit gekümmert, aber langsam fange ich damit an, das ist das gute an diesem Forum ... )

 

[Janny82]

Hallo,
habe die Seite nun wieder gesperrt und auch die letzte Site runtergenommen.

Habe immer noch keine Idee, wo genau sich der Schädling versteckt hält.

Danke für eure Bemühungen.

Gruss Janny.

 

[Ricko]

b) In den bisherigen Berichten war nirgends etwas von Iframes zu lesen.

The Random JS toolkit attack is the latest malicious code to use two stages: First, infecting a Web site with an infection kit or iframe tag and, second, attempting to exploit the systems of visitors to the compromised sites.

Was ich noch anmerken muss:

Einerseits, klar geht mit weniger Panik an die Sache.

Aber, beachtet bei euren Spekulationen und Überlegungen dass es sich zusätzlich um ein Rootkit handeln muss.

Sprich, wenn jmd. nichts findet usw. und der Server trotzdem 'streut' ist das nicht verwunderlich.

 

[Huschi]

@Ricko:
Danke, hab ich wohl überlesen. Also streichen wir b).


So langsam füllt sich Google zu dem Thema.
Dabei ist mir ein PDF mit einer kleine Abhandlung darüber aufgefallen:
(Aufgrund der Lizenz verlinke ich nur die Quelle. Gemeint ist die Januar-Ausgabe)
Finjan Malicious Page of the Month

Und Cpanel hat (aufgrund von Gerüchten) ebenfalls einen recht aufschlußreichen Artikel geschrieben:
cPanel - The Leading Control Panel
(Interessant: Auch hier wird der Vorschlag "mkdir 1" aufgegriffen.)

Dazu noch ein recht interessanter Lösungsansatz:
Shut down "Random JS Toolkit" exploit

huschi.

 

[charli]

Hallo,

dass es sich zusätzlich um ein Rootkit handeln muss.

warum?

Falls tatsächlich ein Rootkit vorliegt muß man natürlich im Rescue (ohne chroot!) analysieren, da ist das Rootkit wirkungslos. (Es sei denn das Rescue ist auch verseucht.)

 

[blob]

Demnach kann man das loswerden wenn man javascript abstellt, vermutlich im Server, nicht im browser; das suche ich momentan aber kann ich nicht finden .

 

[marneus]

JavaScript am Server abstellen?! Ja ne... ist klar! JS ist eine clientseitige Scriptsprache.

--marneus

 

[daseddy]

Demnach kann man das loswerden wenn man javascript abstellt, vermutlich im Server, nicht im browser...

Das ist jetzt nicht dein ernst, oder?

 

[Roger Wilco]

So falsch liegt blob doch gar nicht, auch wenn sicherlich nicht beabsichtigt.

-> Aptana Jaxer | Aptana

 

[blob]

Im letzten link von huschi steht, daß das Funktionieren des Virus davon abhängt, daß etwas auf Server-Seite von javascript geändert wird bevor es an den Klienten gesendet wird (wenn ich das richtig verstanden habe). Mindestens ein einziges Mal soll daher in den Protokollen ein js-Aufruf an den Server enthalten sein müssen. Und das Ding heißt ja Random JS Toolkit. js Habe ich gerade gefunden und abgestellt: rm /usr/bin/js Muß jetzt sehen, ob meine web-Seiten noch gehen, berichte dann.
Nachtrag: zumindest augenscheinlich geht mein site noch. Kann man denn am Anfang der eigenen home-page etwas einbauen was beim Aufruf js auch beim Klienten abschaltet ? Wenn ich das richtig verstanden habe, macht der Virus keine Änderung in den Dateien auf der Festplatte vom Server, deshalb sind Dateigrößen usw. unverändert, sondern im Speicher bevor es zum Klient gesendet wird. Wenn meine eigenen web-Seiten gar kein js benutzen (mit OpenOffice gemacht / benutzen nur html und php), wie kann man in httpd abstellen, daß js-Dateien ausgesendet werden ?

Was sich ferner noch aus og links von huschi herausfiltern läßt ist, daß sehr wahrscheinlich ein einmaliger Zugang über ssh nötig ist um root-Rechte zu bekommen; gut daß ssh bei mir sowieso nicht läuft, das braucht man sowieso nicht, also besser abstellen. Mir selbst ist aufgefallen, daß in den letzten Tagen öfters auf port 81 (glaub' ich) irgendein Programm lief was ich nicht kenne und nie vorher gesehen habe, keine Ahnung ob das irgendwas bedeutet.

It loads it's own httpd server in memory, yes, but from what I understand only to inject a Javascript include into your HTML after your Apache server has finished it's job and sent the file out. After the httpd-in-memory-server finishes up it's little edit, it pushes the page on through to the end user. Then the end-user compromise starts. The included Javascript file is requested from your host ... all the Javascript examples I have seen so far show that the path to the malicious Javascript is on your server, the root-compromised host.

 

[charli]

Hallo,

es ist schon erstaunlich was man an einem Homeserver alles rummurksen kann und der läuft immer noch. *SCNR*

 

[Ricko]

warum?

Falls tatsächlich ein Rootkit vorliegt muß man natürlich im Rescue (ohne chroot!) analysieren, da ist das Rootkit wirkungslos. (Es sei denn das Rescue ist auch verseucht.)

Na, weil die Tatsache dass ein (so wie es aussieht) infizierter keine Dateien auf seinem Server findet bzw. keine Anzeichen für das Teil.
Gut, klar, wenns codiert eingefügt wird ists ne andere Sache, aber auch dass findet man raus.
Ausser eben es ist (wie auch in den Quellen ersichtlich) ein Rootkit

Dabei ist mir ein PDF mit einer kleine Abhandlung darüber aufgefallen:
(Aufgrund der Lizenz verlinke ich nur die Quelle. Gemeint ist die Januar-Ausgabe)
Finjan Malicious Page of the Month

Auch die hab ich, wenn auch etwas unvorteilhaft, verlinkt
Aber schön hier Leute zu finden die sich auch bei nem Problem richtig 'reinknien' in die Sache!

 

[charli]

Hallo,

wenns codiert eingefügt wird ists ne andere Sache, aber auch dass findet man raus.

wenn man korrekt und vollständig sucht ja.

Ausser eben es ist (...) ein Rootkit

Wenn man korrekt und vollständig sucht findet man auch ein Rootkit.

Ein Rootkit funktioniert nicht mehr, wenn man von CD oder das Rescue bootet (versuchtes Rescue natürlich ausgenommen).

 

[Ricko]

Hallo,


wenn man korrekt und vollständig sucht ja.

Wenn man korrekt und vollständig sucht findet man auch ein Rootkit.

Ein Rootkit funktioniert nicht mehr, wenn man von CD oder das Rescue bootet (versuchtes Rescue natürlich ausgenommen).

Es war anfangs lediglich ein Hinweis dass man das bei Spekulationen mit einschließen muss

Das eben hattest du ja schon gepostet.

 

[blob]

Ich habe mir einmal alle links in obigen posts durchgelesen. Ich glaube, mit am praktischsten verwendbar, außer daß es von js abhängt, ist, daß korrumpiert würden: ifconfig, fsck, route, cat, mount, touch . Dann braucht man ja nur in rc.local und in einen cronjob zu schreiben, daß diese Programme alle 5 Min. überinstalliert / überkopiert werden. An einer Stelle stand ferner, daß das rootkit davon abhängt, kernel-Module zu korrumpieren. Ich kann mir vorstellen, daß das nicht fortwährend gemacht wird sondern nur beim Systemstart und daß auch hier anschließendes Überkopieren / -installieren hilft.

Aber in Wirklichkeit scheint niemand genau zu wissen, was passiert

 

[marneus]

Nein blob, das ist keine Lösung... Wenn die Ölpfanne Deines Autos ein Leck hat, dann ist andauernde Nachkippen von Öl nicht die Lösung des Problems.

--marneus

 

[Huschi]

Im letzten link von huschi steht

Warum hast Du den nicht wirklich gut gelesen?

js Habe ich gerade gefunden und abgestellt: rm /usr/bin/js

ROFL!!! Ne, ist klar. Und jede weitere auf dem Server abgelegte JS-Datei ist damit ebenfalls weg...

Und schon wieder weise ich Dich auf den hinlänglich bekannten IT-Dreisatz hin:
Lesen, VERSTEHEN, Handeln!

wie kann man in httpd abstellen, daß js-Dateien ausgesendet werden ?

Steht im o.g. Link: Mit mod_rewrite.
Allerdings kann man auch in PHP JS überliefern. Aber das ist hier ja nicht der Fall.

daß sehr wahrscheinlich ein einmaliger Zugang über ssh nötig ist

Falsch. Wenn, dann wurde das System per Exploid geknackt.

gut daß ssh bei mir sowieso nicht läuft, das braucht man sowieso nicht

Genau, wir steigen alle wieder um auf Telnet...

Mir selbst ist aufgefallen, daß in den letzten Tagen öfters auf port 81 (glaub' ich) irgendein Programm lief was ich nicht kenne und nie vorher gesehen habe, keine Ahnung ob das irgendwas bedeutet.

Das Bedeutet, daß Du Deinen Rechner nicht im Griff hast.

daß korrumpiert würden: ifconfig, fsck, route, cat, mount, touch .

Würde man mit kleinen sicheren Tricks wie z.B. Tripwire erkennen.

An einer Stelle stand ferner, daß das rootkit davon abhängt, kernel-Module zu korrumpieren.

Wo stand das? Evtl. dort wo auch vom Exploid die Rede war?
Es ist ein Unterschied, ob eine Kernel-Lücke ausgenutzt oder korrumpiert wurde. Das ist der wesentliche Teil von VERSTEHEN.

Aber in Wirklichkeit scheint niemand genau zu wissen, was passiert

Das ist wohl das einzige, was Du wirklich verstanden hast.


@Ricko:

Aber schön hier Leute zu finden die sich auch bei nem Problem richtig 'reinknien' in die Sache!

Dafür trage ich für zuviele Server die Verantwortung als daß ich mich hier nicht kundig mache.
Aber ich habe bisher noch keine Gegenmaßnahmen für nötig befunden.

huschi.

 

[Firewire2002]

Das Problem scheint noch aktuell zu sein.
Viren/Malware Warnung - OVH-Forum