Mir ist die Tage - mal wie­der - eine kom­pro­mit­tier­te Ma­schi­ne unter die Fin­ger ge­kom­men - dies­mal eine Win­dows-Ma­schi­ne; ich hatte ja schon ein­mal bei so einem Vor­fall ein paar Infos auf­ge­schrie­ben, und da ich für den Ar­ti­kel viel po­si­ti­ves Feed­back be­kom­men habe, dach­te ich, ich mache das dies­mal wie­der :-) Al­ler­dings wird's dies­mal nicht so um­fang­reich, da ich die­ses mal quasi nur als Be­ra­ter hin­zu­ge­zo­gen wurde, das ei­gent­li­che Doing je­mand an­de­rem über­las­sen mußte.

Auf­ge­fal­len war die Sache, daß beim Ab­ru­fen der dar­auf ge­hos­te­ten Web­sei­ten plötz­lich Mel­dun­gen vom Vi­ren­scan­ner kamen. Das ganze sah nicht nach einem ge­ziel­ten Hack aus, son­dern eher nach der "Stan­dard-Ma­sche":

• Ein Skript sucht nach be­kann­ten Lü­cken.
• Diese wer­den au­to­ma­ti­siert ex­ploi­tet, um in den Rech­ner ein­zu­drin­gen.
• Auf dem Rech­ner wird nach html-Da­tei­en (und ähn­li­chem) ge­sucht und dort ent­spre­chen­der Schad­code in­te­griert.
• Op­tio­nal hin­ter­lä­ßt das Skript noch ein "Ku­ckucks­ei" auf dem Rech­ner, so daß die­ser sei­ner­seits be­ginnt, im Netz nach ver­wund­ba­ren Rech­nern zu su­chen.

Der Ja­va­Script-Code (na­tür­lich ob­fu­s­ca­ted) war schnell ge­fun­den; bei die­ser Ge­le­gen­heit habe ich zwei sehr hilf­rei­che Tools im Netz ge­fun­den, um sol­che Skrip­te zu ana­ly­sie­ren:

• Ein Con­ver­ter-Tool zum une­scapen der ob­li­ga­to­ri­schen Pro­zent-Ir­gend­was-En­co­dings
• Ein on­line Ja­va­Script Code Be­au­ti­fier (und Ent­pa­cker). Der hat mir er­folg­reich den hä­ß­lich in eine Zeile zu­sam­men­ge­zo­ge­nen JS-Code sehr hübsch for­ma­tiert; zu­nächst hatte ich vor, das ganze mit einem JS-De­bug­ger aus­zu­füh­ren, da wäre das sehr prak­tisch ge­we­sen...
• ...​der JSUN­PACK hat mir das aber fak­tisch ab­ge­nom­men :-) Hier habe ich auch be­reits eine fer­ti­ge Ana­ly­se des ge­fun­de­nen Schad­codes ge­fun­den - be­trof­fe­ne der Rech­ner war also kein Ein­zel­fall ;-)

Das Skript hat im End­ef­fekt eine URL zu­sam­men­ge­baut, um von die­ser den tat­säch­li­chen Brow­ser-Schad­code zu holen. Al­ler­dings war ich für einen Blick hier­auf zu spät 'dran - der DNS-Ein­trag der Do­mä­ne war be­reits ge­löscht.
All­ge­mein blieb die Frage, ob der Rech­ner tat­säch­lich frisch kom­pro­mit­tiert wurde - oder ob der Vor­fall ein­fach lange Zeit un­be­merkt blieb: Die ge­fun­de­ne Ana­ly­se da­tiert auf den April die­sen Jah­res...

Ers­ter Schritt war na­tür­lich, den Schad­code für den Mo­ment aus der Web­sei­te zu ent­fer­nen. Dabei er­leb­te der zu­stän­di­ge Admin die erste Über­ra­schung: Der Quell­text auf der Plat­te war un­mo­di­fi­ziert! Wo­mög­lich war der Fall doch span­nen­der ge­la­gert als zu­nächst an­ge­nom­men? Ein zwei­ter Blick of­fen­bar­te je­doch, daß ein Ver­zeich­nis mit blan­kem HTML nicht ge­prüft wurde; diese Da­tei­en wur­den an ver­schie­de­nen Stel­len in­klu­diert... und siehe da: Hier wur­den wir fün­dig. Ok, also doch eher klas­sich :-) Al­ter­na­ti­ve Mög­lich­kei­ten zum Ein­schleu­sen des Schad­codes wäre z.B. ein zu­sätz­li­ches Modul für den Web­ser­ver ge­we­sen; des­wei­te­ren gab es auch schon Schad­code, der sich nur im RAM ein­nis­te­te - da­durch würde er zwar einen Re­boot nicht über­le­ben, dafür war er durch Vi­ren­scan­ner, die le­dig­lich Da­tei­en durch­such­ten, nicht zu ent­de­cken.

Lo­gi­scher zwei­ter Schritt: Her­aus­fin­den, wie der An­grei­fer auf die Ma­schi­ne ge­kom­men ist - und dann die Lü­cken ab­dich­ten. Die Kiste lief noch unter Windws 2000 (für wel­ches Mi­cro­soft das "End of Life" für Juli 2010 an­ge­kün­digt hat)... also po­ten­ti­ell reich­lich Be­tä­ti­gungs­feld :-) Ein Port­scan of­fen­bar­te fol­gen­des:

Na prima. Min­des­tens einer der ver­meint­li­chen SMTP-Ser­ver mel­de­te sich zwar nach dem Auf­bau der Ver­bin­dung mit einem SMTP-Hel­lo, re­agier­te aber nicht auf wei­te­re SMTP-Kom­man­dos. Ein Lauf eines fri­schen Vi­ren­scan­ners auf dem in­fi­zier­ten Sys­tem (merke: Sol­che Scans sind mit gro­ßer Wahr­schein­lich­keit un­voll­stän­dig; zum einen hin­ken si­gna­tur­ba­sier­te Scans den ak­tu­el­len Ent­wick­lun­gen immer min­des­tens einen Schritt hin­ter­her, zum an­de­ren kann lau­fen­de Schad­soft­ware die Aus­füh­rung des Vi­ren­scan­ners sa­bo­tie­ren) of­fen­bar­te auch min­des­tens zwei Back­doors. Da sich diese nicht so ohne wei­te­res ent­fer­nen lie­ßen, und unser Admin nicht her­aus­fin­den konn­te, was die tat­säch­li­che Ein­falls­schnei­se ge­we­sen war, ent­schied man sich schlie­ß­lich für eine kom­plet­te Neu­in­stal­la­ti­on - dies­mal auf Basis von Soft­ware mit noch ak­ti­vem Sup­port ;-) Aus die­sem Grund ver­zich­te­te man auch auf tie­fer­ge­hen­de Ana­ly­sen - als Tools für wei­te­re Un­ter­su­chun­gen hät­ten sich die Sys­in­ter­nals Suite oder das Sleuth Kit an­ge­bo­ten.

Les­sons lear­ned:

• Up­dates, up­dates, up­dates. Und zwar zeit­nah. Ins­be­son­de­re, wenn es sich um eine Win­dows-Ma­schi­ne han­delt
• Wird der Sup­port für eine Soft­ware ein­ge­stellt, so ist zeit­nah auf eine an­de­re um­zu­zie­hen.
• Die Zahl der ex­po­nier­ten Diens­te so klein wie mög­lich hal­ten. Was nicht ge­braucht wird, soll­te nicht lau­fen... und wenn man­che Pro­gram­me lokal be­nö­tigt wer­den, der Port aber für die weite Welt offen ist, so muß man sich eben mit einem Pa­ket­fil­ter be­hel­fen.
• Der Job des Web­ser­vers ist es, die Da­tei­en der Web­sei­te zu lesen (ggf. zu in­ter­pre­tie­ren) und an­schlie­ßend aus­zu­lie­fern. Es be­steht kein Grund, dem Web­ser­ver Schreib­rech­te auf die Da­tei­en zu ge­wäh­ren. Ohne Schreib­rech­te hätte im vor­lie­gen­den Fall kein Schad­code so ein­fach in die Web­sei­ten ein­ge­fügt wer­den kön­nen (ich sage nicht, daß es un­mög­lich ist: Bei­spiels­wei­se könn­te der Web­ser­ver durch ein dy­na­misch da­zu­ge­la­de­nes Modul dazu ge­bracht wer­den, den Schad­code in jede aus­ge­lie­fer­te Seite zu pa­cken; aber das wäre schon ein gutes Stück kniff­li­ger als pri­mi­ti­ves Su­chen und Mo­di­fi­zie­ren von HTML-Da­tei­en).

Für Se­cu­ri­ty-Be­leck­te eher Bin­sen­weis­hei­ten - die in der Pra­xis doch allzu oft ver­nach­läs­sigt wer­den.