Na een beetje zoeken:

195.191.44.233 - - [01/Apr/2002:09:50:51 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 404 0 "-" "-"

195.191.44.233 - - [01/Apr/2002:09:51:22 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 404 0 "-" "-"

193.190.183.227 - - [07/Apr/2002:03:07:12 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 404 0 "-" "-"

Ik ~SNAP~ wel WAT het doet, wat me opvalt is dat juist ~DIT SOORT~ (m.a.w. de dubbele %255) requests pas sinds kort opduiken. En mijn vraag is dan ook;
duikt deze specifiecke request ook bij anderen op ? ( 1 bevestiging heb ik al)
En gaat het om een scantool ?

Ik wacht nog even de reactie af van een van de originating systems welke dezelfde fingerprint propageerde. Omdat dit ons en de andere bases onbekend is heb ik de vraag uiterst relaxed en geïnteresseerd gesteld zodat ze zich niet ongemakkelijk zouden hoeven voelen de informatie te verstrekken.

Aangezien ik geen frequentie heb kunnen bespeuren dat ik ergens aan vast kan knopen, vermoedt ik net als jij dat er mogelijk een tool achter zou zitten maar weet dat niet zeker.

Ik wacht even de reactie af en zal dat hier kenbaar maken zogauw ik deze heb ontvangen.

Voor de zekerheid stuur ik eveneens een rapportje door naar de NIPC zodat dit gelijk kan worden gedocumenteerd.

Met een zeer grote regelmaat, zojuist de apache logs er eens op nageslagen, 23 mei is er 117 keer getracht een dergelijke exploit te runnen, dat was wel het maximum, ik denk dat ik gemiddeld op dertig aanvallen per dag kom.

Ben wel met een nader onderzoek bezig naar wat het precies doet, die %255 is mij ook onbekend. Wellicht dat ik binnenkort voor een testcase een IIS inricht.

Dit zijn trouwens wel van die typische "leave something behind that can be traced back to you" gevallen.

Spreekt u hier specifiek over "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" pogingen? Of enkel over pogingen die daar op lijken? Dat is in dit geval een heel wezenlijk verschil.

Kunt u in uw logfiles terug gaan en aanschouwen wanneer deze poging voor de aller eerste keer aldaar is verschenen? Dat kan evenzeer buitengewoon waardevolle informatie inhouden.
Inmiddels is er contact met de States ten einde dit beestje te kunnen plaatsen.

Ik heb overigens naast deze pogingen verder geen gelieerde andere activiteiten bespeurd, niet bij de IDS en niet volgens de firewall.

Kan dit worden bevestigd, GrepMaster en/of AnonymousCoward?

Ja Virtal, het betreft hier echt "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir". Voor zover ik kan zien in mijn logs is er 28 april een eerste poging gedaan. Voor die tijd is alleen getracht via de ~normale~ unicode vulnerability binnen te komen. Wat mij trouwens wel is opgevallen is dat het aantal
%255 's niet constant is. Ene keer zijn het er twee andere keer zijn het er zes.

Het wordt toch tijd voor een testcase denk ik zodat ik precies weet wat het doet.

Ter informatie:

Ik vond op packetstorm het volgende Perl script, waarin het een en ander nogal in voorkomt. Voorzover ik weet, ook uit mijn verleden toen ik nog jong was en zo, is packetstorm toch wel de scriptkiddie site bij uitstek. Script ziet er trouwens wel erg goed uit. Publicatie datum van dit script is 01-05-2002 dus dat geefttoch te denken.

http://packetstormsecurity.nl/0105-exploits/cool2

Braziliaanse Scriptkiddie's, irritant, dat ze Nimda-achtige propageringen hanteren om "te achterhalen" of een site wel of niet IIS draait, terwijl dat gewoon in de HTTP-Header-respons staat af te lezen.

Interessant is het feit dat wij deze vermelding niet eerder dan 18 februari dit jaar tegenkomen in onze logfiles (van meerdere systemen op meerdere IP's), waardoor gerichte propagering door zo'n scriptkid uitgesloten lijkt.
Anderzijds kom ik deze regel absoluut niet zoveel tegen alsdat u aangeeft, ongeveer zo'n 16 keer maar dit jaar, per IP. Maar inderdaad zijn enkele, zoals u reeds constateerd, niet constant. Van een originator ontving ik er bijvoorbeeld 4 repeterend achter elkaar, van weer een ander slechts 1 en vervolgens nooit weer.

Misschien dat wij ook maar een kreupele IIS onbeveiligd online gooien en afwachten waarmee het wordt geïnfecteerd, dat in quarrantine kan worden gezet voor verdere studie. In de States weten ze nog steeds niet wat ze daar mee moeten, wat dit is.

Inmiddels hebben wij dus zo'n kreupele IIS online staan op onze gateway (dus absoluut geen productie-server, uiteraard) maar heeft deze tot nu toe enkel Nimda besmettingen opgelopen.

De laatste %255 variant die wij hebben opgevangen dateerd van 25 mei j.l., zo zeldzaam zijn deze alhier, voordat wij zo'n IIS webserver te luister hebben gezet.
Verder gebruiken wij een vrij eenvoudige methode:

1) installeer een schoon werkend systeem, met NT en IIS;
2) maak een image "master";
3) zet het systeem online;
4) wacht op een infectie;
5) bekijk de log of de gewenste propageringen hebben plaatsgehad;
6) zo nee, zet image "master" terug en ga naar punt 2;
7) zo ja, maak een image "gotcha";
8) vergelijk image "gotcha" met "master" (let op afwijkingingen);
9) betrek de afwijkende bestanden van image "gotcha" en plaats deze in quarrantine;
10) onderzoek het gevangen euvel en forward het naar bijvoorbeeld het CERT.

We moeten blijkbaar nog even geduld hebben voordat er weer zo'n %255 aan onze gateway wordt gericht.

Mogelijk heeft GrepMaster meer geluk, aangezien de hoeveelheid %255's bij hem veel frequenter voorkomen?

Excusimoi, punt 6) moest natuurlijk zijn:

6) zo nee, zet image "master" terug en ga naar punt 3;


Overigens is het CERT al op de hoogte gebracht van de %255's in de logfiles.

Ik was eigelijk niet van zins om een kreupele server on line te zetten. Doordat ik Apache heb draaien vang ik de propageringen toch wel af. Waar ik zeer benieuwd naar ben is:

- Wat kan iemand doen via deze exploit.
- Hoe kan ik het afvangen.
- Is het alleen en scantool, of is het daadwerkelijk mogelijk er een hack mee te zetten
- etc. etc.

We ga dus op het LAN een IIS inrichten waarop we de diverse mogelijkheden zullen gaan uitproberen. Door deze tests zijn we beter instaat onze klanten adviseren cq. te beschermen.

Mvg,

Michel van der Klei
Mitch ICT Solutions

Laatste hier is:
195.5.253.112 - - [25/May/2002:20:08:48 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 404 324 "-" "-"

Zoals wij in ons eerdere bericht hebben geschreven hebben wij een research-machine online gezet (= absoluut geen productie-machine), onbeveiligd en met IIS (dat beiden garant staat voor 'kreupelheid' en zwakte), dat als ideaal 'slachtoffer' staat te popelen om de eventuele gevolgen op te vangen en te registreren, zodat het feitelijk structureel onderzocht kan worden.
Hoe wilde u anders het eventuele gevolg onderzoeken? Ten einde te achterhalen -wat- precies de %255's genereerd, heeft u er niets aan dat enkel in een afgezonderde opstelling eigen genereerde HTTP Requests af te vuren. Het lijkt ons sterk dat je enkel daarmee voldoende informatie zou genereren waarmee je van advies zou kunnen dienen. Vandaar onze 'lokvogel': laat maar eens zien wat de bedoeling is van die %255's en wat het gevolg is wanneer zo'n IIS weerloos online staat. Buiten enkel een koppeling met het internet, staat hij verder uiteraard stand-alone.
Onze werkelijke webservers draaien uiteraard onder Linux met Apache maar gaat het daar hier niet over.
Wij zijn benieuwd wat voor effect de eerst volgende %255's propagering zal hebben op de lokvogel:

1) worden bestanden gemodificeerd?
2) worden bestanden gewist?
3) worden nieuwe (virus?) bestanden geplaatst?
4) zo ja, hoe gedraagt het systeem na dergelijke wijzigingen (gaat het dan zelf IP-ranges scannen?);
5) zo nee, dan is het blijkbaar gewoon een scantooltje, dat verder geen schade berokkend.Ofwel: wat is de oorzaak, wat is het gevolg en wat is de bedoeling daarvan.

Dank je AnonymousCoward. Toevallig was precies die vermelding ook de laatste die wij hebben opgevangen, met als enige verschil dat wij deze 5 minuten en 54 seconden later hebben ontvangen.
(tijd gesynchroniseerd met Nederlands enige stratum1 NTP server).

Hallo Virtal,

Ik ben het met je stelling wel eens, het zal natuurlijk ook niet alleen bij onze LAN test blijven. Naast dat we uit gaan zoeken wat het precies doet, wellicht op de manier die u voorstelt, gaan we op het LAN kijken wat er verder daadwerkelijk mee mogelijk is.


Is het mogelijk om er EOA mee up te loaden
Is het mogelijk root te krijgen
Kan je de SAM db eraf halen

etc etc.

Naast dit zullen we uiteraard ook online tests uitgaan voeren.

Ik denk alleen niet dat de buitenwacht er blij mee is als we zulke zaken op servers van derden gaan proberen.

Wij gaan niet over een nacht ijs, excuus als het een en ander zo overgekomen is.

Mvg,

Michel van der Klei
Mitch ICT Soluions

ps. Afgelopen zondag is hier voor het laatst een poging ondernomen.

Dan begrijpen elkaar in ieder geval niet verkeerd. In die zin dat het elkaar wel aanvult, dat zeker interessant is.

Maar dergelijke zaken moet je inderdaad niet op servers van derden gaan uitvoeren, ik kan alleen niet plaatsen met welke reden dat u dat daar zo expliciet vermeld. Wij gebruiken zowiezo enkel eigen systemen voor dergelijke onderzoeken, vandaar.

Het is verder wel erg opmerkelijk dat de %255-propageringen dan blijkbaar sinds afgelopen weekeind spontaan blijken te zijn opgehouden.

Het punt is dat ik niet weet wat dat perlscript van die Braziliaan precies doet. Het is vandaar dat we er eerst lokale tests mee uitgaan voeren voorddat we het een en ander "buiten" gaan proberen. Deze experimenten zijn best leuk, maar als het "verkeerd" afloopt zijn de gevolgen niet te overzien.

Stel je voor dat er in een keer automatisch in stealthmode een range gescand wordt, zonder dat je het zelf in de gaten hebt Lijkt me commercieel niet echt verantwoordt. Ik zal er in ieder geval niet mee lachen als het IP adres van mijn gateway hier en daar in de logs voorkomt. Ik zie het wijzende vingertje al weer helemaal voor me, he' dat zijn toch die lieden met dat Linux bedrijf......., het lijken wel scriptkiddies :D

Vandaar dus de keuze om het een en ander eerst lokaal te proberen.

Mvg,

Michel van der Klei
Mitch ICT Solutions

Uw humor is in deze zowel erg leuk als toepasselijk. Maar voor elk onderzoek geldt dat men goed op moet letten en men zekere voorzorgsmaatregelen moet treffen om eventuele risico's zoveel als mogelijk te onderdrukken.

U en ik beschikken zover ik heb begrepen niet over de luxe dat men eventueel kwalijke binaries in grote getalen aanleverd krijgt, zoals dat bij het CERT het geval is.

Bij het 'zelf vangen' van soort zaken, moet men goed op zijn hoede zijn en blijven. Daar zijn wij het zeker mee eens.

Hier niet, al wordt de frequentie wel lager,

64.0.147.81 - - [31/May/2002:08:51:42 +0200] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 362

212.38.44.137 - - [31/May/2002:10:07:09 +0200] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 362

212.38.44.137 - - [31/May/2002:10:07:09 +0200] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 362

Drie vandaag, en een variant:

212.38.44.137 - - [31/May/2002:10:07:15 +0200] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 345


Prettig weekend,

Michel van der Klei
Mitch ICT Solutions

De productie-server blijft er ongeveer 30 per etmaal krijgen, van de meest uiteenlopende hosts.

Ik heb behalve de %255c%255c nog geen varianten gevonden behalve Nimda zelf..

BingBong....

Op thuis-box ..

-----

xx 130.18.160.200 - - [28/May/2002:05:05:22 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 301 - "-" "-"
xx 217.34.115.81 - - [29/May/2002:05:52:39 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 301 - "-" "-"
xx 216.94.210.35 - - [29/May/2002:17:32:22 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 301 - "-" "-"
xx 159.178.235.160 - - [31/May/2002:16:02:25 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 301 - "-" "-"
xx 212.171.39.219 - - [01/Jun/2002:00:17:23 +0200] "GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir" 301 - "-" "-"

-----

Geen andere varianten nog steeds..

Ik heb een paar varianten op de scan gevonden die zeer wel van dit script af kunnen komen..

http://groups.google.com/groups?q=HEAD+/scripts/..%25255c..%25255cwinnt/system32/cmd.exe%3F/c%2Bdir%2Bc:%5C&hl=en&lr=&selm=a9a91541.0202191232.1eb0b43d%40posting.google.com&rnum=1


Vooral de lijst met 'bugs' is awesome, daar heeft iemand ~werk~ van gemaakt :-)

Zie ook datum in CopyLeft...


* beer is proof that gawd exists, and loves us *

Zijn gewoon servers die met code red geinfecteerd zij. Een server die geinfecteerd is probeert andere servers te infecteren door te scannen op IIS servers die niet gepatched zijn. Vandaar de meldingen in de logfile.

Ik heb ze zelf ook :

62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:54 +0100] "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 706
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 706
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.21.14 - - [02/Jun/2002:23:15:55 +0100] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 779
62.194.48.81 - - [02/Jun/2002:23:24:12 +0100] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 779

Al zal er een gedeeltelijke waarheid in zitten, ben ik het toch niet helemaal met je eens. Ik heb namelijk de laatste srie weken al diverse perl script op internet gevonden die precies het zelfde doen.

Het is al te gemakkelijk om dit af te doen als zijnde met code red geinfecteerde servers.

Voor de oplettende lezertjes:

Het gaat NIET om CODE RED of NIMDA besmettingen. Zie begin van thread...

En mijn logfiles heb ik obviously ~goed~ gelezen lijkt mij, als ik de volgende varianten tegenkom:

"GET scripts/.%252e/.%252e/winnt/system32/cmd.exe?/c+dir+c: HTTP/1.1" 404 336 "-" "-"

"HEAD /scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c: HTTP/1.1" 301 0 "-" "Mozilla/5.0"

"GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c: HTTP/1.1" 404 336 "-" "-"

Ik heb Code Red of Nimda nog nooit een HEAD request zien doen, dat is 1. Noch Nimda noch Code Red gebruiken een 'useragent' deze soms wel, dat is 2. De slash achter de dir+c: idem, dat is 3.

Maar anyway, mijn vraag is al beantwoord; het is een scan-toolie en geen nieuwe variant..