Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 92 reacties, 62.880 views •
Submitter: Metalrick

Microsoft waarschuwt voor twee kritieke beveiligingslekken in het remote desktop protocol in Windows. Het bedrijf verwacht dat binnen een maand exploits voor de lekken verschijnen en raadt dringend aan de patches te installeren.

Alleen Windows-systemen die remote desktop protocol hebben ingeschakeld zijn vatbaar voor misbruik. Standaard staat het protocol uit, maar in zakelijke omgevingen wordt het veel gebruikt en ook it-beheerders maken vaak gebruik van rdp, waarmee systemen op afstand zijn te beheren. Het wordt echter afgeraden om ze rechtstreeks aan het internet te hangen.

De kwetsbaarheden, die Microsoft CVE-2012-0002 heeft gedoopt, zijn te misbruiken met speciaal vervaardigde datapakketjes. Authenticatie is verder niet vereist, waarna het uitvoeren van kwaadaardige code op afstand mogelijk is. De verwachting is dan ook dat het verschijnen van nieuwe wormen die er misbruik van maken niet lang op zich laten wachten. Microsoft zegt echter geen aanwijzingen te hebben dat het lek nu al in de praktijk wordt misbruikt.

De rdp-kwetsbaarheden zitten in Windows XP, Windows Vista en Windows 7, terwijl ook Windows Server 2003 en 2008 kwetsbaar zijn. Microsoft raadt aan Security Bulletin MS12-020 te installeren om het lek te dichten, terwijl het ook een work-around voorstelt. Het is het enige kritieke lek van de zeven die Microsoft bij zijn patchronde van maart onder handen neemt.

Reacties (92)

Reactiefilter:-192088+158+211+30
Moderatie-faq Wijzig weergave
Wat ik apart hieraan vind is dat de exploit al in november 2011 bekend was?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0002
"This candidate has been reserved by an organization or individual that will use it when announcing a new security problem"

Kan het niet zijn dat MS vantevoren gewoon een aantal nummertjes claimt?
wat ik apart aan jouw comment vind is dat je het woord Phase vertaald met datum.
Het wordt echter afgeraden om ze rechtstreeks aan het internet te hangen.
Bron? Dat is niet meer van toepassing met Network Level Authentication waarbij eerst gevalideerd wordt of gebruiker bekend is voor verbinding opgezet wordt.
Encryptie is 128 bit RC4, maar dan moeten er natuurlijk geen kritieke gaten in vallen :)

Hmm dat is ook exact wat ze als work around stellen:
Enable Network Level Authentication on systems running supported editions of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2
Als het goed is doe je dat alsnog via een tunnel, isa server, security gateway, whatever.

Een server rechtstreeks vanaf het internet op de RDP poort kunnen benaderen is gewoon stompzinnig en vragen om problemen. NLA of niet, dat is gewoon niet handig.
Hartstikke handig, nooit problemen mee gehad :)
Goed wachtwoord(vergrendelings) beleid.
RDP kwetsbaarheden zijn ook zeldzaam.
Handig is het zeker.

Maar zonder helm en pak op de motor is ook super handig, veel sneller even naar de shop enzo. Toch doe je dat als je slim bent niet ;)

Bij me thuis heb ik het wel, maar op het werk gaat dat toch ff anders hoor.
Jouw argument geldt dan ook voor alle SSH-enabled servers die rechtstreeks vanaf internet benaderbaar zijn. Kan ook een vulnerability voor bekend worden immers.

Het toevoegen van een extra beveiligingsschil is net als een extra ketting om je fiets: het maakt het net iets lastiger, maar de ene ketting kan net zo goed doorgeslepen worden als de ander.

Zeggen dat RDP per definitie niet via een public netwerk / internet toegankelijk moet zijn vind ik dus te kort door de bocht.

[Reactie gewijzigd door Jochem_ op 14 maart 2012 12:17]

"Zeggen dat RDP per definitie niet via een public netwerk / internet toegankelijk moet zijn vind ik dus te kort door de bocht. "

Voor bedrijven vind ik toch echt niet kunnen. Dat je thuis RDP zo beschikbaar zet kan ik me nog inbeelden, maar als bedrijf kan dit echt niet.
Met de vele nieuwe Cloud server opties, ontkom je vaak niet aan een dergelijke opzet. Zelfs bij grote partijen als Amazon en Rackspace.

Natuurlijk kun je er vervoglens een IP-filter etc opzetten. Maar de machines die je opgeleverd krijgt, zijn wel zo uitgerust. Dus dan kun je er bijna op vertrouwen dat een flink percentage nog steeds zo ingesteld zal staan.
RDP, SSH, VNC of Telnet, geen van deze methoden wordt door mijn firewall naar binnen doorgestuurd. Je maakt maar een VPN, en die VPN maakt gebruik van SSTP en certificaten i.p.v. een wachtwoord / user id.
Er zijn meer dan genoeg servers met poort 3389 gewoon open voor de buitenwereld, denk hierbij aan hosters bijvoorbeeld.

Ik heb ook ergens gelezen dat je na het installeren van deze fix de server moet rebooten, iets waardoor het patchen van deze bug nog wel een lange tijd gaat duren en er waarschijnlijk binnenkort een nieuwe worm de top3 binnen komt.

Bij binaryninjas zijn ze bezig om de verschillen van voor/na de patch te bekijken, misschien wel interessant voor sommige tweakers: http://blog.binaryninjas.org/?p=58

Ik ben zeer benieuwd hoe dit gaat aflopen, er is een kans dat dit al een tijdje bekend was bij onze Russische/Chinese(blackhats) vrienden, maar nu weten ze het iig allemaal en word er ongetwijfeld al aan een exploit/worm gewerkt
Dat klopt, je moet inderdaad de server rebooten voor die fix.
Dat word dus even een avondje patches installeren op systemen.
Als je Network Level Authentication (NLA) aan hebt staan op je systemen is het probleem al veel minder ernstig.

Als je nog geen NLA hebt aanstaan op je systemen dan kan dat eenvouding met een fix:
Microsoft Fix it 50844
NLA zit standaard in vista,W7 en W2K8 in xp kan het worden gepatcht.
In W2K3 is NLA niet mogelijk.
Ik heb maar direct de updates op mijn servers ge´nstalleerd. Het is ook wel op te maken uit de MS12-020 pagina, maar misschien wel handig om "KB2621440" erbij te melden. Dit is het KB nummer van de update die je moet installeren.
Gelukkig moeten hacker in de meeste gevallen al toegang hebben tot het interne netwerk, direct of via VPN. Elke systeembeheerder die RDP toegankelijk maakt voor buitenaf zonder VPN moet direct ontslagen worden.
Denk dat er genoeg Tweakers zijn die een port-mapping hebben aangemaakt, zodat ze makkelijk op hun thuissysteem kunnen komen. Die hebben echt geen VPN of ingewikkelde firewall aangemaakt. Zelf heb ik dat vroeger wel zo gedaan, iig..

Hopelijk gebruiken ze dan nog wel een niet-standaard poort, maar dat is security through obscurity, dus niet echt effectief.

Daarnaast, zo moeilijk is het vaak ook weer niet om binnen een corporate netwerk te komen. De beveiliging van RDP is gewoon weer onderdeel van je defense-in-depth, dus hoort ook op orde te zijn.

[Reactie gewijzigd door Keypunchie op 14 maart 2012 11:16]

3389 direct doormappen op je router, als je dan gehackt wordt vraag je er echt zelf om.
Als er een lek in de VPN oplossing zit komen ze alsnog binnen dus het enige wat je doet is het probleem verschuiven, een ge´nfecteerde PC kan ook via de VPN de boel exploiten.

Je moet gewoon zorgen dat de beveiliging van de RDP servers zelf op orde is, o.a. door te patchen en traffic monitoring.
Je achter een firewall/VPN verschuilen en denken dat je klaar bent is pas dom.
Als er een lek in de VPN oplossing zit heb je waarschijnlijk grotere problemen dan deze.
Goede beveiliging is gebaseerd op meerdere lagen. Elk protocol heeft in potentie zwakheden. De beste manier om te voorkomen dat iemand binnen komt doordat er een zwakheid gevonden is die nog niet gepatcht is, is om een extra laag te hebben. In dit geval is RDP kwetsbaar. Mocht je een VPN hebben is RDP nog steeds kwetsbaar maar is de impact een stuk kleiner aangezien men eerst in het VPN moet komen. De kans op 2 0-day exploits (1 voor de RDP en 1 voor het VPN) is een stuk kleiner dan de kans op 1.

Meerdere lagen heeft dus als voordeel dat je minder kwetsbaar bent bij een 0-day exploit en dat je patches kan plannen in plaats van direct te moeten reageren op een issue.

Dit neemt niet weg dat je natuurlijk moet zorgen dat je patches uitvoert maar 1 enkele beveiligingslaag is in feite nauwelijks een beveiliging te noemen. Het opzetten van RDP (of SSH) toegang tot een server zonder VPN is voor productiesystemen dan ook redelijk riskant te noemen. Het gaat in de meeste gevallen vast goed, maar een systeem zonder patches en met een wachtwoord als 12345678 kan ook jaren draaien zonder gehackt te worden. In beide gevallen ben je echter kwetsbaar.
Ik heb mijn computers van buitenaf bereikbaar gemaakt maar wel op een andere poort dan standaard het geval is. Of is dit heel makkelijk te omzeilen?
Tuurlijk, Gewoon even de hack uitvoeren op die andere poort en hop, men is binnen. Security through obscurity is wat jij nu hebt, en zoals we allemaal weten is dat eigenlijk geen security.
Moet je natuurlijk wel eerst de poort weten...
Een beetje goeie router/firewall laat jou echt geen poortscans uitvoeren.
Maar die hebben mensen thuis natuurlijk niet; meeste thuis-routers laten prima portscans toe, zeker half-open stealth-scans. Maar daar heb je eventueel weer Port-knocking truukjes voor; dat wordt steeds beter ondersteunt en is een aardige 'extra beveiliging' (maar helaas niet zo transparent / gebruiksvriendelijk als een SSL/VPN tunnel) ...
Ik vind dat voor een thuissituatie wel makkelijk gezegd.
Natuurlijk is een andere poort pakken geen security, en natuurlijk kunt je als je die poort weet die hack uitvoeren. Maar zo'n andere poort draagt wel heel effectief bij aan het ontspringen van de ranges in portscans die standaard gebruikt worden.

Er zijn tig mensen die het zo geregeld hebben, zelfs bedrijven. En hoewel je van die laatste groep zou mogen verwachten dat ze een VPN opzetten, vind ik dat een thuisgebruiker toch wel een beetje mag vertrouwen op het authenticatiesysteem van RDP (toch in ieder geval met NLA), zonder een extra laag toe te hoeven voegen.

[Reactie gewijzigd door Jochem_ op 14 maart 2012 12:12]

Klopt maar dan heb je nog altijd mensen die prive een servertje draaien en niet VPN tunnels e.d. opzetten :) (O.a. omdat je ook lang niet altijd overall VPN kan opzetten) Als me servers plat gaan is het ook niet zo erg maar leuk is anders :)
Maar daar gebruik je toch iets als SSH voor en geen remote desktop?
Alsof er nooit security issues zijn geweest met SSH... Daarnaast zit Remote desktop netjes ge´ntegreerd in Windows en werkt het behoorlijk efficiŰnt.

[Reactie gewijzigd door Deem op 14 maart 2012 12:39]

Issues met openSSH doen zich 9 van de 10 keer voor in de vorm van denial of service. Voor zover ik terug kon vinden zelfs nog nooit in de vorm zoals het hier nu beschreven wordt.

Een denial of service is toch even iets anders dan de mogelijkheid om malicious code te kunnen runnen op de target machine. Andere schaal dus lijkt mij :)

[Reactie gewijzigd door EnigmA-X op 14 maart 2012 13:38]

Misschien moet je de Matrix Reloaded nog een keer kijken ? Daarin zit toch echt een bestaande OpenSSH hack met code-execution erin hoor. Zie hier voor de details (oldschool 2001 !).
Het was mijn taak niet, maar bij mijn vorige job was het wel gebruikelijk om het zo in te stellen bij klanten. Ik denk dat ze deden uit gemakzucht, en eerst inloggen via VPN is een stap te veel. 8)7
Waarom is een VPN veiliger dan een goed opgezette RDP ?
Met beide kan je encryptie gebruiken en heb je genoeg aan een programmaatje , een inlogcode en een wachtwoord om in te loggen.
Het is een andere manier van werken, of je op een computer inlogt of op een netwerk, maar qua veiligheid zie ik geen verschil. Of denken jullie er anders over ?
Het gaat om rdp via een vpn. Een extra beveiligingslaag dus, meer niet. Het idee is dat er dan 2 dingen gekraakt moeten worden voor het systeem gecompromiteerd is.
Ik draai thuis een VPN waar alleen mijn private key op werkt, op die key zit vervolgens ook nog eens een wachtwoord. Het gaat jou ten eerste heel wat moeite kosten om die key uberhaupt te krijgen, en daarnaast om ook het wachtwoord daarvan te achterhalen.

En mocht het je lukken, dan zie ik in de logs dat iemand heeft lopen kloten en verwijder ik de public key van mijn server. In dat geval heb je inderdaad wel dingen stuk kunnen maken, maar ik acht de kans klein dat het uberhaupt zo ver zal komen...
Elke systeembeheerder die RDP toegankelijk maakt voor buitenaf zonder VPN moet direct ontslagen worden.
Ben het 110% met je eens.

en voor de medetweakers, gebruik dan logmein of teamviewer, wordt vaak geupdate, werkt minimaal net zo goed en is een stuk veiliger op basis van encryptie tussen je twee end points. (en t is nog gratis ook).
Is niet gratis voor bedrijven alleen voor particulier gebruik. Team viewer werk helemaal niet goed met windows 7 met UAC. Kan misschien iets aangedaan worden maar heb ik niet achter gezocht.
Met de vele nieuwe Cloud server opties, ontkom je vaak niet aan een dergelijke opzet. Zelfs bij grote partijen als Amazon en Rackspace.
eh jah, daarom schakel ik al jaren het protocol uit bij wijze van tweaken.
Altijd services hebben draaien die niet gebruikt worden is onzin.

Aan de ene kant leuk van windows dat alles meedraait maar aan de andere kant is het systeembelastend en beveiliging compromitterend.

Ik geloof ook helemaal niet dat deze gatenkaas pas net ontdekt is want hij stinkt al heel lang ontzettend hard. Eerder dat white hat hackers vriendelijk hebben verzocht er iets aan te doen of anders...

Ik dacht dat het common knowledge was dat remote desktop een deur is.. en hoe groot het slot ook is met een ram kom je er wel doorheen.

Teamviewer anyone?

edit:toevoeging

[Reactie gewijzigd door swel op 14 maart 2012 12:08]

Haha, jij zegt teamviewer (of logmein)? DAT is pas slecht in een bedrijfsomgeving. Moet ik dat nog uitleggen?
Je geeft namelijk een 3de partij (teamviewer, logmein) volledig toegang tot je hosts. Dit bedrijf hoeft zich niet te houden aan regels die gelden in Nederland omdat ze gevestigd zijn in bv Amerika. En daar nemen ze het niet zo nauw met jou privacy.
Daarnaast zijn ze waarschijnlijk ook nog eens minder open omtrend security isseus.
Als systeembeheerder zijn er betere oplossingen voor dit soort systemen.

[Reactie gewijzigd door Deem op 14 maart 2012 12:50]

Logmein is sowieso slecht in een bedrijfsomgeving aangezien het de firewall compleet negeert. Wel erg handig voor toegang naar een thuis server maar in een bedrijf zie ik het liever niet.

Dat je een derde partij toegang geeft tot je hosts is echter wel een beetje overdreven natuurlijk. Je kan met hetzelfde gemak zeggen dat je geen Cisco routers moet gebruiken omdat die vast wel een achterdeurtje voor de NSA hebben. Of geen Huawei omdat die mogelijk de Chinezen toegang geven. Je kan ook doorschieten in je angst. Bedrijven als LogMeIn hebben te veel gebruikers om die allemaal te lopen bespioneren en te veel te verliezen (hun complete business) om daaraan te beginnen.
En Windows 2000? Ok, out of support maar wordt nog VEEL gebruikt...
Zoals je zegt: Out of Support.

Maar ga er maar gewoon vanuit dat deze bug er altijd in heeft gezeten.
Dus daarop RDP af zetten (voor van buitenaf in ieder geval) eb eeb andere oplossing vinden voor beheer op afstand.
Heeft dit gevolgen voor OSX gebruikers die via de RDC client van Microsoft verbinden met een externe desktop?
Nee, want dat is een client. De kwetsbaarheid zit hem in de RDP-serverzijde software.

Dus de externe desktop die je benadert is kwetsbaar tot je hem patcht. Je (Mac)-client is niet kwetsbaar voor deze exploit.

Pas als je op een computer de RDP-service aanzet dan ben je ook kwestbaar (Onder Windows 7 in het "System Control Panel" -> Remote settings en dan een firewall exception maken voor RDP).

[Reactie gewijzigd door Keypunchie op 14 maart 2012 11:26]

Hoei, ben ik even blij dat ik dit alleen via VPN of SSH doe... Gebruikers van de concurrent multi-user hack even opletten dus, het is goed mogelijk dat deze update de file termsrv.dll vervangt door een nieuwe versie waardoor je concurrent sessions dus niet mee werken.
Net getest: de termsrv.dll wordt niet vervangen en de concurrent multi-user hack blijft dus gewoon werken :)
Ik zie nergens iets staan over Windows Server 8 x64 beta. Is die soms gewoon nog niet gelist omdat die nog niet officieel gereleased is? Ergens ga ik er toch vanuit dat het gros van de code van nieuwere Windows-versies voor het grootste deel gecopy-paste wordt (ten dele terecht natuurlijk, want waarom code herschrijven die goed werkt? Blijft natuurlijk: die goed werkt, en remote desktop gaat hierbij kennelijk de mist in).
Win 8 consumer preview heeft er ook last van. Dan zal Server 8 er ook wel last van hebben.
Ik zag dat niet in de KB staan, en heb zover ik kon zien vanmorgen ook geen fix hiervoor ontvangen op de consumer preview.
The bug affects Windows XP and all versions of Windows released since, including the developer preview of Windows 8

Mijn fout het is de developer preview, maar ik neem aan dat de consumer er ook last van heeft.

Bron
Ik gebruik Microsoft als bron:

http://technet.microsoft....ecurity/bulletin/ms12-020

Daar reppen ze niet over Windows 8, ik heb nog even de updates van gisteren nagekeken, maar ik heb voor deze RDP vuln. geen fix gehad. Dat kan twee dingen betekenen of die RDP vuln. zit niet in de consumer preview versie, of Microsoft heeft nog geen fix voor de consumer preview, ik hoop zelf toch op het eerste.

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True