Gepubliceerd: Maandag 18 mei 2009
Een white hat hacker heeft een lek ontdekt in Internet Information Services (IIS) 6.0, de versie van Microsofts webserver die draait op machines met Windows Server 2003.
Toon volledig artikel
Even reactie aangepast met aanvullende info:
* Webdav staat default niet aan op IIS webservers
* Op W2k8, Vista en Win7 staat IIS 7.0 en die is inderdaad niet kwetsbaar
* Je kunt niet alleen files downloaden maar ook files uploaden maar dan naar webdav mappen.
Zie ook:
http://blog.zoller.lu/2009/05/iis-6-webdac-auth-bypass-and-data.html
Ik begrijp wanneer sharepoint services draaien niet. Of is dat een fout in dit artikel?
----------------------
(ook de reactie aangepast)
Fijn dat je je reactie aanggepast hebt om meer informatie te geven. Je herhaalt wat informatie uit het artikel, heel goed!
Maar nog steeds heb je mijn vraag niet beantwoord.
Wil je dat aub alsnog doen? Dank
(goede link trouwens. overigens maakt de schrijver in die link een vorbehoud in jouw punt 3 (hij zet er "as far as I know" bij, jij laat dat weg. Kun je dat ook verklaren? Ook hiervoor dank.
Een aantal functies van Sharepoint maken gebruik van WebDAV, met name het feit dat je "document stores" kunt benaderen alsof het shares zijn. SharePoint zet deze features standaard aan. Als het waar is wat men beweerd, dan ligt een SharePoint site dus momenteel open-en-bloot.
dan ligt een SharePoint site dus momenteel open-en-bloot.
Dan lag die site dus altijd al open en bloot en is het momenteel publiek bekend.
Tja, beetje spijkers op laag water zoeken misschien ;)
Maar dat geldt dan in principe voor alle systemen, ook voor degenen waar nog geen exploits voor bekend zijn, maar in de toekomst waarschijnlijk nog gaan volgen...
Zodra een 'evil hacker' een lek in IIS constateert gaat deze echt niet meteen Microsoft inlichten om vervolgens braaf af te wachten totdat Microsoft dit lek openbaar maakt voordat hij gebruik gaat maken van dit lek. Sterker nog, deze hacker heeft er vooral verschrikkelijk veel belang bij dit lek niet openbaar te maken zodat hij er nog jaren plezier van kan hebben.
In dit soort artikelen wordt vaak gedaan alsof een lek pas bestaat op het moment dat het openbaar is; dat is gewoon een verkeerde voorstelling van zaken. Ik vind dat geen spijkers op laag water zoeken maar een tamelijk essentieel punt.
Leuk dat het een "tamelijk essentieel punt" is, maar als normale gebruiker kun je je nooit volledig wapenen tegen dit soort zaken, of je zet gewoon je IP verbinding uit. (Ben benieuwd wat de baas van dat plan vindt.)
Het is dus een risico waarmee je zult moeten leven, je kunt het alleen minimaliseren door attent te blijven op mogelijke beveiligingsproblemen binnen je infrastructuur.
Zodra er een lek gedicht wordt is het waarschijnlijk al tijden kwetsbaar geweest. Het enige wat je kunt doen is een audit om te zien of het misschien ooit is misbruikt, als je weet waarnaar je moet zoeken. (In dit geval naar "verdachte WebDAV requests").
zodra een evil hacker ( dus gewoon een hacker, die black and white hat is voor de toeristen) een lek vindt zal hij nooit zomaar iemand inlichten. Ongeacht het OS ( denk aan de gevonden gaten in OSX op de recente hackwedstrijd) je punt is dus correct maar vooral academisch van aard.
Opmerking van Alon is zo'n beetje als de stelling:
"Een probleem is alleen een probleem als er een oplossing voor bestaat"
Het maakt in principe niet uit over wat voor OS'en je het hebt, als er gemeld wordt aan de 'gebruikers' dat er een patch is voor een ernstig lek, dan is voor de gebruikers vaak pas op dat moment bekend dat er een lek was.
Of hackers, crackers of andere beesten de betreffende lek al uitgebuit hebben, is iets waar alleen maar naar geraden kan worden.
Een kwestie van hopen. In ieder geval zou je de stelling van hierboven verder aan kunnen vullen als:
"Een probleem is alleen een probleem als er een oplossing voor bestaat. Als er geen oplossing is voor een probleem, dan is er geen sprake van een probleem, maar van een gegeven.
Aangezien er voor ieder probleem een oplossing bestaat, bestaan er in principe geen (langdurige) problemen"
Ik begrijp wanneer sharepoint services draaien niet. Of is dat een fout in dit artikel?
Door jouw gewijzigde reactie is deze vraag een beetje vreemd geworden.
Mijn vraag is: Staat WebDAV aan indien sharepointservices draaien? Dit omdat jij aangaf dat het default uit staat.
Of het waar is weet ik niet, maar lees deze link:
WebDAV, IIS, and SharePoint
Many people are under the misconception that SharePoint uses the WebDAV functionality provided by IIS 6.0. Actually, SharePoint provides its own WebDAV implementation using the Stsfilt.dll ISAPI filter that is installed with both Windows SharePoint Services and SharePoint Portal Server. Enabling or disabling the WebDAV extension in IIS 6.0 has no effect on SharePoint functionality.
Het antwoord zou dus zijn: nee.
Maar wel in Small Business Server 2003. Sterker nog, ik heb 2 klanten die al slachtoffer geweest zijn van deze hack, is ook al langer bekend, kennelijk probeert er een een wit voetje te halen door dit nu als nieuws naar buiten te brengen.
ik heb 2 klanten die al slachtoffer geweest zijn van deze hack, is ook al langer bekend
Is dat echt zo ? Toon ons eens een bron
Als een dergelijk issue al langer bekend is dan zal er zeker ook al langer een CVE code aan toegekend zijn.
Als het lek al actief geexploiteerd zou worden zou er zelfs als een security rating aan topegekend geweest moeten zijn.
Is dat echt zo ? Toon ons eens een bron
Jij hebt voor je klanten geen geheimhoudingsverklaring hoeven te tekenen? Als een white hat het nu naar buiten brengt, dan ik het zeker niet ondenkbaar dat een black hat het al een poosje wist. Ik gok dat dit gat al een poosje in de interne bugtracker van MS staat, maar helaas is dat niet te controleren.
Het gaat er niet om dat een hacker het nu naar buiten brengt maar juist dat er iemand hier op WW beweert dat dit lek al langer actief geexploiteerd wordt en zelfs zo actief dat hij claimt daar al bij meerdere klanten van blijkt te weten dat het zich heeft voorgedaan.
Een lek dat zo actief misbruikt zou worden zou zeker bekend zijn in de security wereld en lekken die reeds actief misbruikt worden ook niet geheim gehouden.
Ik kan me voorstellen dat een gat van deze omvang dat zo eenvoudig te exploiten is, zo lang mogelijk onder de pet gehouden wordt.
Als een white hatter info naar buiten brengt, dan kan je er donder op zeggen dat het al langer bekend is. De standaard werkwijze is dat info wordt gestuurd naar degene die het kan repareren, en dan pas na enige tijd wordt de info aan de rest van de wereld vrij gegeven.
Het feit dat de white hatter komt met zijn info voor de patch er is, duidt er juist op dat ze er achter gekomen zijn dat het gat gebruikt wordt. Dit is dus gewoon damage control.
WebDAV uit om erger te voorkomen en wachten tot Microsoft de tijd vindt om een pleister te plakken.
Ps. Gerke kan ook gewoon het 'geluk' hebben dat hij bij de eerst misbruikte groep zit.
Als een white hatter info naar buiten brengt, dan kan je er donder op zeggen dat het al langer bekend is.
Het is natuurlijk puur toeval wanneer een gat door een white hatter het eerst wordt ontdekt. Maar het kan wel. Echter zul je dat nooit zeker weten en moet je altijd van het ergste uitgaan.
Volgens Albert is het pas bekend als er een CVE is. =P En criminelen kunnen het zeker niet eerder misbruiken.
Je draait het om.
Iemand stelt dat het een bekend issue is dat je in het wild al op verschillende plaatsen kan tegenkomen. Dan verwacht ik zeker dat het een bekend issue is bij de security research community en dus al een CVE heeft.
Iemand stelt dat het een bekend issue is ...
Nee, iemand stelt dat hij het issue al is tegen gekomen. Hij kan horen bij de 'lucky' few. Je kan niet jouw conclusies trekken uit de gebrekkige info.
Als ergens een gat wordt misbruikt hoeft er niet automatisch een CVE te zijn. Ik denk zelfs dat er veel gaten eerste worden misbruikt voor de CVE vermelding er is. Zeker voor de gaten die door black hatters worden gevonden.
In dit geval denk ik dat er een overlap is geweest. In beide kampen is het gat gevonden, alleen brengt het witte kamp info naar buiten, waar het zwarte kamp is begonnen met misbruiken. Vandaar dat de white hatter zijn info naar buiten brengt voordat de patch er is. Lijkt me geen rocket science om dat uit te knobbelen.
Dat is zelfs per definitie zo. CVE reageert op gevonden gaten, en is dus altijd alert na dat een gat wordt gevonden.
Wat wel kan is dat een deel van de gaten door white hatters wordt gevonden en direct bij CVE zijn aangemeld. maar zelfs in dat geval is de kans redelijk aanwezig dat een black hatter het simultaan (of eerder) ook al had gevonden.
De stelling van dosprompt is dus buitengewoon naïef.
Klopt, het is alleen de vraag aan welke zijde de f[***]k up ligt. Albert baseert zich tenslotte net zo hard op aannames.
Het feit dat info naar buiten wordt gebracht over het gat, voor de oplossing beschikbaar is, doet mij vermoeden dat het gat al misbruikt wordt. Anders had Microsoft het zeker nog buiten de pers willen houden. En dat zijn ook meestal de afspraken met white hatters. Eerst de pleister, dan de pers.
Als een dergelijk issue al langer bekend is dan zal er zeker ook al langer een CVE code aan toegekend zijn.
Als het lek al actief geexploiteerd zou worden zou er zelfs als een security rating aan topegekend geweest moeten zijn.
Wat wil je nu precies beweren? Dat je een lek niet actief kunt exploiteren voordat er een CVE code en security rating aan toegekend zijn?
Hoe moet ik me dat precies voorstellen? Dat als ik een lek zonder CVE code en/of security rating actief probeer te exploiteren ik een venstertje in scherm krijgt met de tekst 'Unable to inject shellcode, missing CVE code and/or security rating'?
Dat je een lek niet actief kunt exploiteren voordat er een CVE code en security rating aan toegekend zijn?
Misschien wel als je het in het geheim weet te exploiteren. Als exploits echter al enige tijd in het wild opduiken en herkenbaar zijn als veroorzaakt door een bepaald lek dan heeft dat lek zeker een CVE nummer.
CVE nummers worden zelfs al uitgedeeld voordat het lek bevestigt als zijnde een lek.
Er ziin honderden, zo niet duizenden security researchers bezig met het opsporen en kwalificeren van dergelijke issues. Als iemand hier op WW aangeeft dat het een bekend issue is bij meerdere klanten dan zullen die security mensen dat zeker al weten en dan zal er ook zeker al een melding in de security database van NIST voorkomen met bijbehorende CVE code.
Ik heb bij 2 klanten exact de zelfde problemen geconstateerd. Ondanks dat alles dicht stond in ISA, alleen het hoognodige enabled, zijn deze servers gehacked, uit de loggingen valt weinig te halen, behalve dat de hacks gedaan zijn vanuit China. Beide servers zijn ook gelijk ingezet voor aansturing van Botnets, en dankzij juiste acties van providers die de boel direct hebben dichtgezet en gemeld is verder schade voorkomen. Dat de hack middels IIS is gedaan is duidelijk, en ik ben er ook redelijk van overtuigd, dat Webdav inderdaad de boosdoener is geweest.
Beide servers zijn ook gelijk ingezet voor aansturing van Botnets,
Dat is vreemd want dit lek lijkt bepaald geen evidente kandidaat voor het installeren van botnet software. Er is geen melding/rapport dat er controle over de w2k3 server software kan worden verkregen.
Tenzij iemand de servers "Opstarten" directory moedwillig als Webdav directory heeft opengezet zodat je daar execuable software in kan plaatsen maar dan is het systeembeheer wel erg losjes...
Dank edjez, maar als ik de link lees, en ik ga verder dan wordt de verwarring weer groter. Dan staat er:
You only need to enable WebDAV on IIS if you want to use the Web Sharing feature.
Correct. Sharepoint does not requied webdav at all, however if you want to use advance features of widnows explorer with sharepoint you need webdav enabled.
Ik geloof dat zelfs de experts in die discussie het niet goed zeker weten, of er in elk geval niet in slagen om er een eenduidig en helder verhaal van te maken.
Voor zover ik weet mis je de nodige functionaliteit, maar werkt het wel en kan Sharepoint Services (of Server, geldt voor beiden) dus zonder. Je zou met redelijk goed fatsoen dus kunnen besluiten om Webdav in IIS uit te zetten.
Dus, kort gezegd: In IIS heb je Webdav niet persé nodig om WSS/MOSS te kunnen gebruiken. Maar of je zonder Webdav blij moet zijn betwijfel ik.
Hier de MS security advisory melding:
blogs.technet.c...ory-971492.aspx
En hier een vrij duidelijke uitleg van MS wanneer je kwetsbaar zou kunnen zijn:
blogs.technet.c...ion-bypass.aspx
Als ik deze beide berichten zo lees zijn de claims van iemand die beweerde dat dit lek al wordt geexploiteerd en bij klanten was gebruikt om hun servers als botnet in te zetten gewoon duidelijk onjuist.
Het aansturen van een botnet is iets heel anders dan het inzetten als botnet. Ik kan me prima voorstellen dat dit gat misbruikt zou kunnen worden voor het verspreiden van spam templates. Aansturing dus.
Het feit dat jij het probeert af te doen als "duidelijk onjuist" kan alleen betekenen dat je de reacties van Gerke niet kan of wil begrijpen.
An IIS server that hosts web applications using only forms-based authentication is probably safe
Does this mean: "we don't know?". How can this be helpful for a customer? Would some explantion help?
misschien als je het hele stuk leest.;)
We are still investigating different attack ideas possible using this vulnerability but the original report claimed files could be uploaded and modified. However, what we have found is that the IIS installer applies an NTFS access control entry to explicitly deny write access to the anonymous account (IUSR_[MachineName]) in wwwroot and subdirectories that inherit wwwroot’s ACL. So in the default case, this vulnerability will not allow a malicious attacker to upload or modify webpages.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
