[Diskussion] Dynamische Malware infiziert Webseiten

[blob]

@ #19:Mass host hack bigger than first thought, hits 10,000 sites

@ #20: configure - Configure the source tree - Apache HTTP Server Hier steht aber unter optional features > general syntax das mit =static . Eigentlich sollte das default sein; komischerweise sind aber gerade diejenigen Module nicht da, #httpd -l , bei denen ich static explizit angebe ... daher fürchte ich, daß static aus irgendwelchen Gründen nicht geht und die anderen Module alle dynamisch geladen werden. Dafür spricht auch, falls static default, wäre auch meine Konfigurierung schon vorher static gewesen, jedoch hatte ich vorher LoadModule = ... im httpd.conf -file und wurde beim Ablauf nicht bemängelt daß das schon static da wäre

 

[charli]

Hallo,

Wie kommst du darauf?

Webserver verteilt Viren

Hallo Gemeinde, ich habe seit 5 Tagen ein Problem, Freund eund Bekannte rufen mich an das Sie wenn Sie meine Seite ansurfen, die Meldung bekommen das ein Virus gefunden wurde. Die Meldung die Sie erhalten ist folgende: In der Datei 'C:\Dokumente und Einstellungen\carola\Lokale...

serversupportforum.de

ich schließe mich der Meinung von LinuxAdmin an.

 

[Huschi]

@ #19:Mass host hack bigger than first thought, hits 10,000 sites

Von diesen Artikeln hab ich nun einige gelesen. Aber neues steht nirgends und von PHP ist schon gar nicht die Rede.
Die Sache mit den DSO scheint auch nur ein Gerücht zu sein. Bestätigungen bleiben aus. Im Gegenteil: Es gibt Anzeichen dafür, daß es ein Holzweg ist.

ich schließe mich der Meinung von LinuxAdmin an.

Klar, aber das sind keine wirklich neuen Erkenntnisse und haben ebenfalls eigene Gefahren und Nachteile.

Letztendlich weiß anscheinend noch niemand wirklich genaues über diese Attacke. Und hier wird in 3 Threads und über 20 Beiträgen Panik geschürt und angebliche Lösungen versprochen.
Mmmmmh...

@Blob
Bitte versteh mal das Thema eines Thread's und begreife, daß Dein Apache-Compiler-Problem hier nicht rein gehört!
Sehe dies als Moderationsbeitrag.

huschi.

 

[blob]

Einverstanden. Aber was ist denn dann momentan das beste, was man tun kann ? Anders als ich mich bisher nie um Sicherheitsfragen geschert habe, habe ich immerhin das Problem nicht ignoriert, und alle Ratschläge befolgt die hier bestmöglichst gegeben wurden. Momentan läuft mein site nur halb, insbesondere nichts was mit php zu tun hat. Ist das sinnvoll, oder nutzlos ??

 

[Janny82]

Hi,
einer meiner Server (Apache 1.3.29, PHP4, MySQL 4.1) ist Opfer dieser Attacke geworden.
Ein IPB-Forum hat bei Aufruf den Virenscanner zum Alarm gebracht.
Dieses Forum habe ich nun umgezogen, bzw. auf eine neuen Server und eine Forensoftware portiert.
Da auf dem Webserver ansonsten nur noch eine Website (Joomla) liegt und diese keinerlei Auffälligkeiten aufweist, sehe ich von einem Neuaufsetzen vorläufig ab.

Gibt es derweil eigentlich keinen Fix für die Attacke?

Gruss Janny.

 

[Firewire2002]

Janny82, da du die einzigste bist, die es nachvollziehen kann.
Wie wärs wenn du die Lücke mal analysierst und uns mitteilst, was die eigentliche Schwachstelle nun wirklich ist.

 

[Janny82]

Janny82, da du die einzigste bist, die es nachvollziehen kann.
Wie wärs wenn du die Lücke mal analysierst und uns mitteilst, was die eigentliche Schwachstelle nun wirklich ist.

Schon probiert und nichts gefunden. Wenn das Teil rootkitartig sich versteckt, wird das auch eher schwierig werden.

 

[charli]

Hallo,

hier wird in 3 Threads und über 20 Beiträgen Panik geschürt

falls mein Beitrag #5 dazu beigetragen haben sollte ist das ein totales Mißverständnis, ich hatte gedacht, mein letzter Satz

Ich sehe keinen Grund völlig neue Ursachen zu suchen, wenn die Angelegenheit mit den bekannten Ursachen erklärbar ist.

sei deutlich genug.
Um nichts anderes ging es mir als aufzuzeigen, daß die aus der Vergangenheit bekannten Angriffswege ausreichen um das aktuell diskutierte Problem zu erklären. Und solange das der Fall ist gehe ich davon aus, daß es sich nicht um neuen Zauber handelt sondern alten Wein in neuen Schläuchen.

Deshalb sehe ich auch keinen Grund zur Panik, wohl aber zur sorgfältigen Systempflege.

@Janny82: selbe Fragen wie hier:

Webserver verteilt Viren

Hallo Gemeinde, ich habe seit 5 Tagen ein Problem, Freund eund Bekannte rufen mich an das Sie wenn Sie meine Seite ansurfen, die Meldung bekommen das ein Virus gefunden wurde. Die Meldung die Sie erhalten ist folgende: In der Datei 'C:\Dokumente und Einstellungen\carola\Lokale...

serversupportforum.de

 

[blob]

Zu #18: die Übersetzung wie da gemacht war doch OK und alles statisch ... nur ist bei httpd standardmäßig kein php5 -Modul, auch kein security2 -Modul dabei, damit das statisch übersetzt und eingebunden wird, muß man den source-code davon woanders her bekommen und dazutun .... Momentan warte ich mal ab, was die Spezialisten sagen was die neue malware wirklich ist ...

 

[Ricko]

Da die Diskussion ja hier weitergeht, möchte ich noch ein Paar zusätzliche Informationen anbieten, welche doch noch interessant sein dürften.
Das Kind hat vorerst auch einen Namen:
'Random JS toolkit'

Vorerst würde ich, sofern nicht schon geschehen, jedem Betreiber raten sich in Sicherheitsnewsletter einzuschreiben und die zu lesen bzw. filtern zu lassen nach seinem System. Sehr gute ist z.B. der SecurityFocus.com Letter, hab den seit einigen Jahren.

Scheinbare 'Lösung' eines Serverbetreibers:
Comment - Legitimate sites serving up stealthy attacks
One way to check if the server is compromised further is try to
mkdir 123
if you get an error you are compromised backup your data and put it up on a new server.

The compromised sites host the malicious code -- foregoing the iframe redirect that has increasingly been used by attackers -- and serves up the attack to each visitor only once using a random file name each time. The two techniques, along with more traditional code obfuscation, makes the attack difficult to find, said Yuval Ben-Itzhak

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. Last week, several security researchers warned users of an attack in which infected Web sites would be injected with a snippet of Javascript code encapsulated in an iframe which would then redirect visitors to at least two domains, uc8010.com and ucmal.com, hosting malicious code.

Quelle: Legitimate sites serving up stealthy attacks

Was noch interessant ist:

A client-side honeypot -- or honeymonkey, as Microsoft calls them -- could detect the Random JS attack from a specific Web site, but if a second machine using the same Internet address returns to the site, it would not receive the malicious code. The sites infected by the Random JS toolkit include pages at the University of California, Berkeley's Web site and Teagames.com, according to Finjan.

Der Maliceous Page of the month - Paper/Report besagt das etwa 13 verschiedene Arten verwendet werden und zeigt eine allgemeine Übersicht über das Vorgehen.
(kann unter Finjan Thank You gegen Registration downgeloadet werden)

Anfänglicher Artikel
SQL attack continues to infect Web sites

 

[traced]

In some cases however it is advisable to get your backups and transfer the data to some other server.As i am not sure but this exploit might be providing root access and thats how they patch the kernel and once that is done you have no choice then to move everything to a new place.

Sehe ich das richtig dass ich auf meinem vServer "relativ" sicher bin? Der Kernel kann ja nicht gepatcht werden. Oder liege ich falsch?

lg
Basti

 

[Thorsten]

Hallo!
Also irgendwie fehlen mir bisher wirklich greifbare, technisch belegbare Hintergründe dazu. Oder habe ich etwas übersehen? Was passiert denn wirklich?

mfG
Thorsten

 

[charli]

Hallo,

Sehe ich das richtig dass ich auf meinem vServer "relativ" sicher bin? Der Kernel kann ja nicht gepatcht werden.

unabhängig von dem in diesem Thread diskutierten Problem:

Bei einem Vserver ist es (zumindest bei den meisten Varianten) nicht möglich einen eigenen Kernel oder Kernelmodule zu installieren. Allerdings könnte der Hacker den Hauptzugang des Providers knacken oder aus einem Vserver heraus in das Hauptsystem einbrechen. Auf den Vserversystemen kann der Kernel nicht so aktuell gehalten werden, weil der erst mit dem Virtualisierungssystem geprüft oder gar dafür angepaßt werden muß.

Ein Dedicated mit stets aktuell gehaltenem und korrekt konfiguriertem Kernel bietet bzgl. Kernellöchern also größere Sicherheit als ein Vserver. Allerdings hat man mit den Kernelupdates auch einige Arbeit.

Wenn Du weitere Fragen zu diesem Thema hast mach bitte einen eigenen Thread auf.

 

[blob]

Allerdings hat man mit den Kernelupdates auch einige Arbeit.

Man braucht doch nur in /etc/rc.d/rc.local am Schluß oder/unc in rc.d eine Anweisung reinzuschreiben: upgradepkg --install-new --reinstall linux*.tgz und das Paket mit dem Kernel in /etc/rc.d zu kopieren, dann wird jedesmal beim Starten, oder/und beim Anhalten, der Kernel überkopiert. Oder das in einen cronjob tun, sodaß das alle 5 Min. gemacht wird. Bei rpm geht das mit #rpm -Uhv --replacepkgs --replacefiles --nodeps kernel*.rpm (gegen Korruptionen reicht es, dieselbe Kernel-Version nehmen die man schon installiert hat)

 

[elias5000]

Hallo,

ich habe das Thema mit Kollegen besprochen und recherchiert und das Folgende ist, was ich gerade so an Gedankenwolke noch davon im Kopf habe (nicht unbedingt vollständig oder korrekt) :

- Einfallstor ist offenbar eine Lücke in cpanel
- Dadurch wird eine ptrace-Attacke möglich, mit der ein Apache lodable module nachgeladen wird
- Das Modul schleust die Client-Attacken in den Output-Stream

Klingt nach weniger Magie als in den (IMHO wirklich dünnen) Security Bulletins.
Dem original-Bulletin nach (von der Security-Firma, die es entdeckt hat) ist die Verbreitung eher gering.

Im Blogeintrag der Sicherheitsexpertin (dieser Firma), die das ganze Untersucht hat, zufolge wird der Exploit verhindert, wenn der Apache als root gestartet wurde.
Beim Nachladen des Apache wird die UID des Prozesses mit der originalen UID verglichen - weicht die UID ab, wird das Laden des Moduls verweigert.
Startet der Apache als root, führt er einen Privilegien-Drop aus (setiud).
Danach kann das Modul nicht mehr geladen werden.

Wieso sie das Starten des Apache als root als "bad habit" bezeichnet und den unprivilegierten Start als "best practice", entzieht sich aber meinem Verständnis.'
Der Apache startet in allen, mir bekannten Installationen, als root um die privilegierten Ports binden zu können und droppt dann seine Privilegien.

Da dies bei den gängigen Distributionen der Fall sein dürfte, halte ich das Risiko (zumindest was die aktuelle Meldung angeht) für eher gering.

Berichtigt mich, wenn ich was Falsches in der Zusammenfassung drin habe.

Grüße,
elias5000

 

[charli]

Hallo,

- Einfallstor ist offenbar eine Lücke in cpanel

es gibt hier im Forum zwei Betroffene (die von ihrem Problem geschrieben haben), wäre nett wenn die mitteilen ob sie cpanel einsetzen.

 

[blob]

Ich benutze zwar meinen ganzen Rechner immer als root -- aber ausgerechnet httpd läuft unter daemon (=id 2). Ist das OK ? Muß httpd als root starten und hinterher unter root weiterlaufen ? Werden alle DSO geladen wenn httpd startet, oder erst wenn sie zur Laufzeit gebraucht werden (zBsp das php5-Modul erst wenn ein Benutzer das php-Forum aufruft) ? Stimmt die Angabe, daß man infiziert ist, wenn mkdir 123 eine Fehlermeldung gibt ?

 

[elias5000]

Ich benutze zwar meinen ganzen Rechner immer als root -- aber ausgerechnet httpd läuft unter daemon (=id 2). Ist das OK ?

Nein. Ist es nicht. Man benutzt Rechner als unprivilegierter Benutzer. Und die Daemons starten i.d.R. als root (wenn sie privilegierte Ports (<1024) binden müssen) und droppen dann die Privilegien indem sie zu einem unprivilegierten User welchseln. Das sollte je Daemon ein eigener sein.
Braucht ein Daemon keine root-Rechte um an irgendwas ranzukommen, dann startet man ihn gleich unprivilegiert.

Muß httpd als root starten und hinterher unter root weiterlaufen ?

Nein. Wie kommst du darauf?

 

[Ricko]

Stimmt die Angabe, daß man infiziert ist, wenn mkdir 123 eine Fehlermeldung gibt ?

Das muss uns einer der beiden 'infizierten' aus dem Forum sagen.
Bzw. die Person die den anderen Thread gestartet hat.

 

[Janny82]

Hallo,
als Betroffener kann ich dazu sagen:
- kein cpanel installiert, sondern Confixx 3.31
- Apache 1.3 rennt als www-data
- "mkdir 123" funktioniert problemlos.
- Kernel ist 2.6.16

Virenverbreitung tritt nicht bei allen Sites auf, allerdings lagen zu dem Zeitpunkt auch nur noch 2 Sites auf dem Server. Eines war infiziert, das andere nicht.
Änderung in den Dateien der infizierten Site gab es nicht. Virus muss also woanders herkommen.
Bin ratlos!

Gruss Janny!