Die Web­sei­te ist die Au­ßen­dar­stel­lung von Fir­men und In­sti­tu­tio­nen - so­zu­sa­gen die vir­tu­el­le Emp­fangs­hal­le. Aus Kom­fort­grün­den dient sie häu­fig so­wohl für Be­su­cher als auch für Mit­ar­bei­ter als Platt­form; und auch die Ge­stal­ter und Re­dak­teu­re be­nö­ti­gen in ir­gend­ei­ner Form Zu­griff, um Ak­tua­li­sie­run­gen vor­neh­men zu kön­nen. Eine ent­spre­chen­de Kon­fi­gu­ra­ti­on ist leicht zu er­stel­len, doch bie­ten diese leicht­sam eine Ein­falls­schnei­se für un­ge­be­te­ne Be­su­cher; auf ei­ni­ge Pro­ble­me möch­te ich in die­sem Ar­ti­kel am Bei­spiel des Apa­che-Web­ser­vers hin­wei­sen.

All­ge­mei­ne Hin­wei­se

...möch­te ich hier nicht breit­tre­ten. Dinge wie das re­gel­mä­ßi­ge Ein­spie­len von Up­dates soll­ten selbst­ver­ständ­lich sein. Die An­griffs­flä­che soll­te prin­zi­pi­ell klein ge­hal­ten wer­den: Keine un­nö­ti­gen Diens­te auf dem Web­ser­ver, aber auch mög­lichst wenig In­for­ma­tio­nen über das Sys­tem preis­ge­ben. Un­glück­li­cher­wei­se sind dies­be­züg­lich viele Web­ser­ver sehr ge­sprä­chig und ver­sor­gen einen An­grei­fer in den HTTP-Hea­dern mit de­tail­lier­ten In­for­ma­tio­nen über die ver­wen­de­te Soft­ware, die Ver­si­on und mit­un­ter sogar die ver­wen­de­ten Mo­du­le (z.B. PHP-Hea­der) oder die ein­ge­setz­te Dis­tri­bu­ti­on (als Teil der Ver­si­ons­ken­nung). Beim Apa­che-Web­ser­ver kann dies bei­spiels­wei­se durch Ver­wen­dung von mo­d_hea­ders un­ter­bun­den wer­den.

Kom­pro­mit­tie­ren eines Web­ser­vers

Der ein­fachs­te Weg, der Zu­griff auf die In­ter­na eines Web­ser­vers er­laubt, ist ein Ex­ploit, der einen Shell­zu­gang zum Ser­ver er­mög­licht. Ein sol­cher An­griff er­for­dert das Ein­schleu­sen von Code, der dann vom Ser­ver (un­frei­wil­lig) aus­ge­führt wird und die Shell er­zeugt. Klas­si­sche Buf­fer-Over­run-Ex­ploits dürf­ten die be­kann­tes­ten Bei­spie­le hier­für sein.
Dank der Exis­tenz von Skript­spra­chen gibt es so­zu­sa­gen eine "Me­ta­ebe­ne" für An­grif­fe: Es ge­nügt, eine Mög­lich­keit zu fin­den, ein Skript auf dem Ser­ver aus­zu­füh­ren. Eine Mög­lich­keit ist es, in ein CGI-Ver­zeich­nis eine ei­ge­ne Datei ein­zu­schleu­sen. Ein­fa­cher ist je­doch die Ver­wen­dung von web-ty­pi­schen Skrip­ten wie z.B. PHP, bei denen der ent­spre­chen­de In­ter­pre­ter meist im Web­ser­ver selbst in­te­griert ist - hier fällt meist die Be­schrän­kung auf be­stimm­te Ver­zeich­nis­be­rei­che weg. Hier ge­nügt es, ent­we­der wie­der­um eine ge­eig­ne­te Datei ein­zu­schleu­sen, oder aber feh­ler­haf­te Skrip­te aus­zu­nut­zen, über wel­che es mög­lich ist, ei­ge­ne Skript­kom­man­dos aus­zu­füh­ren.
Letz­te­re Me­tho­de ist in den ver­gan­ge­nen Jah­ren äu­ßerst po­pu­lär ge­wor­den - man fin­det im Netz kom­for­ta­ble PHP Shells, wel­che wei­te­res Ar­bei­ten auf dem kom­pro­mit­tier­ten Sys­tem sehr be­quem ma­chen.

Rech­te-Pro­ble­me 1: Web­DAV & Co.

Um ein be­que­mes Be­ar­bei­ten einer Web­sei­te zu er­mög­li­chen, wird häu­fig Web­DAV ein­ge­setzt - die Pro­ble­ma­tik gilt aber prin­zi­pi­ell für alle Tech­ni­ken mit Schreib­zu­griff auf das Da­tei­sys­tem. Die Über­prü­fung der Be­nut­zer­rech­te (wer darf wo lesen und schrei­ben) er­folgt aus­schlie­ß­lich in­ner­halb des Web­DAV-Mo­duls; die Unix-ty­pi­schen Rech­te sind hier­bei außen vor, denn das Be­triebs­sys­tem "sieht" nur den Pro­zeß des Web­ser­vers. Dem­entspre­chend müs­sen alle Da­tei­en und Ver­zeich­nis­se, die via Web­in­ter­face (und dazu zählt auch Web­DAV) ver­än­der­bar sein sol­len, auch von die­sem Be­nut­zer be­schreib­bar sein. Um­ge­kehrt be­deu­tet das, daß ein An­grei­fer, der an nur einer Stel­le eine (Skript)shell er­zeugt hat, auf alle Daten, die der Web­ser­ver lesen kann Zu­griff er­langt und alle Daten, die der Ser­ver­pro­zess ver­än­dern kann nun auch ma­ni­pu­lie­ren kann.
Da eine ty­pi­sche Ein­stel­lung für Web­DAV-Zu­griff das Wur­zel­ver­zeich­nis der Web­site ist, ist in die­sem Fall das Er­geb­nis meist be­son­ders fatal.

Rech­te-Pro­ble­me 2: Shared Hos­ting

In der Aus­ga­be 18/07 der Zeit­schrift c't wur­den die Kon­fi­gu­ra­tio­nen ver­schie­de­ner Web­hos­ter ver­gli­chen. Dabei fiel auf, daß ei­ni­ge Web­hos­ter mo­d_­php ver­wen­den, ob­wohl ver­schie­de­ne Kun­den auf dem­sel­ben Rech­ner ge­hos­tet wer­den. Dies be­deu­tet, daß in­tern die Skrip­te ver­schie­de­ner Kun­den mit dem­sel­ben Ser­ver­pro­zeß und damit mit den sel­ben lo­ka­len Rech­ten aus­ge­führt wer­den. Selbst wenn die ei­ge­ne Web­sei­te si­cher ist, kann sie durch einen an­de­ren Kun­den mit­kom­pro­mit­tiert wer­den.
Sol­che wei­te­ren Do­mä­nen kön­nen so­zu­sa­gen einen Sei­ten­ein­gang für einen An­grei­fer bie­ten. Das nor­ma­le DNS-Sys­tem zeigt zwar längst nicht alle Web-Do­mä­nen (via re­ver­se dns) an, aber es gibt im Netz Such­diens­te (wie z.B. my­IPn­eigh­bors), mit denen man die "Mit­be­woh­ner" eines Ser­vers fin­den kann.

Quel­len für Log­in-In­for­ma­tio­nen

Um Zu­griff auf ge­schütz­te Be­rei­che zu er­lan­gen, ist (hof­fent­lich) ein Login mit Be­nut­zer­na­me und Paß­wort er­for­der­lich. Daß die Wahl guter Pass­wör­ter häu­fig ein Pro­blem dar­stellt, habe ich be­reits mehr­fach er­wähnt. Er­schre­ckend oft funk­tio­niert auch das ganz plat­te So­ci­al-En­gi­nee­ring mit einem ein­fa­chen Te­le­fon­an­ruf. Bei Be­nut­zern mit schlech­tem Paß­wort ist der Be­nut­zer­na­me die si­che­re­re Kom­po­nen­te der Au­then­ti­sie­rung (das Paß­wort läßt sich bei die­sen Leu­ten rasch mit Hilfe eines Wör­ter­buch­an­griffs her­aus­fin­den).
Um an Be­nut­zer­na­men zu ge­lan­gen, kann man na­tür­lich die Web­sei­te selbst durch­fors­ten. Häu­fig fin­det sich eine Rand­no­tiz oder ein Kom­men­tar im HTML-Quell­text, wel­cher das letz­te Än­de­rungs­da­tum und den Be­nut­zer­na­men ent­hält.
Sehr er­gie­big kön­nen aber auch die Me­tain­for­ma­tio­nen sein, die in Do­ku­men­ten ste­cken, wel­che auf der Web­sei­te zum Down­load an­ge­bo­ten wer­den. Das Tool Me­t­a­Goof­lil sucht au­to­ma­tisch nach sol­chen Do­ku­men­ten, läd diese her­un­ter und ex­tra­hiert die darin ent­hal­te­nen Me­tain­for­ma­tio­nen. Diese be­inhal­ten Pfad­an­ga­ben, Be­nut­zer­na­men und vie­les mehr - alles In­for­ma­tio­nen, die für einen An­grei­fer sehr wert­voll sein kön­nen. Um nicht als "Craw­ler" auf­zu­fal­len, nutzt Me­t­a­Goo­fil für die Suche die­ser Da­tei­en die Such­ma­schi­ne Goog­le

Fazit

Es gibt eine ganze Reihe von Mög­lich­kei­ten für einen An­grei­fer, auf einen Web­ser­ver ein­zu­drin­gen. Die obige (si­cher­lich nicht voll­stän­di­ge) Liste zeigt ei­ni­ge Bei­spie­le hier­für. All diese Pro­ble­me las­sen sich durch ge­eig­ne­te Kon­fi­gu­ra­ti­on um­ge­hen; un­glück­li­cher­wei­se er­kennt man die Schwie­rig­kei­ten erst, nach­dem man ein­mal "um die Ecke" ge­dacht hat - oder selbst Opfer eines ent­spre­chen­den An­griffs wurde.
Ich hoffe, daß die­ser Ar­ti­kel bei die­sem "um-die-Ecke-den­ken" hilft - bevor man selbst eine ent­spre­chend schmerz­li­che Er­fah­rung macht.