Wederom bedankt Erik!

Voor mij allemaal nieuw en veel geleerd

Thanks!

Kerberos is de default authenticatiemethode in Windows sinds Windows 2000. NTLM zou in het geheel niet meer gebruikt moeten worden. Dat ondersteuning ervoor na 23(!) jaar niet alleen nog aanwezig is voor wie het nog nodig heeft maar ook default actief is lijkt me een belangrijk onderdeel van het probleem.

Ik heb in de loop van de jaren meer dan eens berichten gezien die de indruk geven, of expliciet stellen, dat Microsoft zo sterk gericht is op het vermijden van wijzigingen die tot gevolg hebben dat een klant iets moet doen om het weer te laten werken dat allerlei ongewenste zaken eindeloos voort blijven woekeren. NTLM lijkt daar een voorbeeld van te zijn.

Ik kan me op zich prima voorstellen dat Microsoft geen zin heeft om nog werk te maken van het herstellen een ontwerpfout in de ondersteuning van een protocol dat niet meer gebruikt zou moeten worden. Alleen is de keuze om NTLM niet alleen nog te ondersteunen maar default actief te hebben wel door Microsoft zelf gemaakt, en dan ligt de verantwoordelijkheid voor de consequenties van die keuze ook bij hun. "Works as designed" is dan geen beste reactie.

Dank Erik voor al je onderbouwende en informatieve berichtgeving, wordt zeer gewaardeerd.
Intern bouwen we waar het niet anders kan RDP en soms VNC over ssh tunnels, nooit deze protocollen direct aan het internet.
Zonder veilige tunnel is het direct prijsschieten, altijd raak.

mvg

een fan

ja helemaal mee eens Erik.dit dit probleem bestaat all jaren ik find dit ook een groot probleem door schuld van Microsoft zelf
waarom word er niets aan gedaan ?..gelukkig heb ik in Windows 2000/xp/vista/Windows 10/11 eerst gestroomd voor dat ik het internet op ga instellingen Na loopen in Windows. ....het is jammer voor de leek aankoop stekker er in en rommelen maar ja zo werkt dat niet...veel mensen zou den ervaring op kunnen doen bij boeken van schoonepc....ook op www.veel info..succes

Het is niet dat MS niet wil vermijden maar klanten verwachten backwards compatibiliteit, dit is daarvan het gevolg.

Dat is onvolledig: Kerberos is de default binnen AD (Active Directory) omgevingen, maar niet daarbuiten (of zonder trust-relaties).

Je moet, te allen tijde, minstens de volgende eisen stellen voordat je op een server inlogt (en/of daar andere vertrouwelijke en/of noodzakelijkerwijs authentieke informatie mee uitwisselt):

1) Dat je jouw "client" (hard- en software) kunt vertrouwen;

2) Dat je zeker weet met welke server je communiceert;

3) Dat data uitgewisseld via die verbinding niet "onderweg" kan worden afgeluisterd en/of gewijzigd;

4) Dat je iedereen met (vooral beheer-) toegang tot die server kunt vertrouwen en die server geen kwetsbaarheden heeft.

Als dat het geval is heb je geen NTLMv2, NTLM, LM, andere hashes of andere mechanismes nodig: een plain-text wachtwoord (en vervolgens bijv. een plain-text session cookie of ander plain-text token) is dan prima.

De denkfout van Microsoft is dat je de punten 2 t/m 4 hierboven kunt oplossen met NTLM en Kerberos, maar dat is fout: meestal zijn dan replay- of relay-attacks (o.a. PtH, Pass the Hash) mogelijk. Zero Trust vereist veilige endpoints (1 en 4) met daartussen veilige verbindingen (2 en 3).

NTLMv2 is van latere datum en niet compleet waardeloos, maar wel als je een zwak wachtwoord gebruikt. Zo sluit ik niet uit dat het wachtwoord Welkom2020 ([6]) niet via brute-force is gevonden, maar een inlogger is gefopt door een AitM (Attacker in the Middle, GoSecure noemt dit op github [1] een -geslachtsloos- "Monster in the Middle" om MitM te kunnen blijven gebruiken).

[6] https://www.security.nl/posting/694947/Hof+van+Twente+raakte+door+zwak+wachtwoord+besmet+met+ransomware

Klopt, Windows is hopeloos verouderd en één grote lappendeken. Maar het m.i. grootste risico hier is dat je veel te eenvoudig op een nepserver kunt inloggen. Dit is gewoon een gigantische design error, want dit speelt ook op LAN's met één of meer gecompromitteerde devices. Het "Zero Trust" initiatief was nou juist bedoeld om dát probleem aan te pakken.

Klanten willen ook robuuste software zonder veiligheidsrisico's. Het gevolg van daarvoor kiezen is dat je af en toe tegen je klanten moet zeggen: "Sorry, maar hier moeten we echt van af en dat vergt ook wat inspanning van jou. We gaan alles doen om de overgang zo soepel mogelijk te maken." Dat zal Microsoft niet snel doen.

Ze zouden het echt wel voor elkaar kunnen krijgen als ze zouden willen. Microsoft is namelijk zeer bedreven in het beïnvloeden van bestaande en potentieel nieuwe klanten, het is net zo goed een marketingbedrijf als het een softwarebedrijf is.

Dus waarom doen ze het niet? Ik denk dat de marketingtak binnen Microsoft het niet wil omdat het marketinginspanning (want klanten beïnvloeden) vergt zonder dat daar nieuwe verkopen tegenover staan. Zeggen dat de klanten het niet willen zie ik als een smoesje. Wat klanten "willen" laat zich best vergaand sturen namelijk, en ze zijn bij Microsoft echt niet vies van dat soort gestuur als ze er iets mee kunnen verkopen.

De schuld van Microsoft? Kom op zeg! RDP staat standaard uit na een schone installatie en je router/firewall laat het ook niet standaard toe. Zet je het aan dan krijg je een waarschuwing voor je snufferd of je hier wel zeker van bent dat je dit wil? Het is en blijft de schuld van de gebruiker/beheerder, je moet gewoon geen verkeer openzetten naar het internet dat bedoeld is voor lokaal verkeer.

Routeren over SSH is niet veel veiliger, tenzij je er meer security technieken er tegen aangooit.

Beetje open deuren intrappen dit.

Nou ik denk dat dit gewoon voldoende verklaard wordt door de standaard triage die Microsoft doet bij IEDER voorstel
tot verbetering of wijziging van hun software: wat gaan WIJ hier meer door verdienen? Niets? Dan doen we het niet!

Daar loopt iedere ontwikkeling bij Microsoft op stuk. Men denkt alleen maar aan verkopen en aan zichzelf.
Daar staat dit ene specifieke dingetje helemaal niet apart in, dat geldt voor zovele "makkelijk op te lossen problemen
die de wereld veel geld en tijd kosten" maar die voor Microsoft kosten neutraal zijn.

Wat ik nog niet helemaal begrijp: volgens mij leg je uit dat je NOOIT met de Microsoft Terminal Server client een
server op internet moet connecten. Dat staat toch helemaal los van het feit of je die al dan niet zelf hebt?
Tuurlijk, als je die zelf hebt zul je wellicht ook vaker die client gebruiken, maar als bijvoorbeeld een leverancier
een RDP server draait die jij moet connecten met je client dan is dat toch precies hetzelfde probleem?

Het probleem zit niet bij de server maar bij de client. Om je te beschermen is het devies niet "zet geen RDP server
op internet" maar "zet poort 3389 uitgaand dicht". Of snap ik dat verkeerd?

Waarschijnlijk is het verstandig om "poort 3389 uitgaand dicht" te zetten, maar de gemiddelde Nederlander heeft geen idee wat wij daarmee bedoelen, laat staan dat ze weten hoe dat moet.

Maar zelfs als ze dat gedaan hebben: als hun werkgever (of, zoals je zelf schrijft, een leverancier) zegt dat, als zij thuis willen werken, zij maar op een RDP-systeem "van de baas" direct (zonder VPN) via Internet moeten inloggen, wat denk je dat er dan gebeurt met die dichtgezette poort?

Als mensen geen reden hebben om uitgaande verbindingen te maken naar servernaam:3389, dan boeit het niet dat jouw perimeter-firewall uitgaand verkeer naar poort 3389 niet blokkeert. De meeste mensen gaan sowieso niet allerlei poorten voor uitgaand verkeer dichtzetten (zoals 8080) - alleen omdat er brakke servers bestaan die zo'n poort gebruiken (dan weet ik nog wel meer poorten; dan kun je beter alles dichtzetten behalve 80/TCP, 443/TCP, 53/UDP, 53/TCP en 123/UDP - naast poorten voor een lokale e-mail client). En als je op LAN RDP-verbindingen maakt, ga je uitgaand-3389/TCP ook niet dichtzetten in de firewall op jouw PC.

Oftewel: als je een RDP-server direct aan Internet hangt, nodig je inloggers uit om onverstandige dingen te doen, en loop je uiteindelijk zelf een groot risico dat jouw hele organisatie wordt gehackt (zoals de gemeente Hof van Twente).

En het probleem zit hartstikke in de server, want pas ná inloggen een certificaatfoutmelding geven (met de -meestal theoretische- mogelijkheid voor inloggers om handmatig te checken of de public key nog hetzelfde is) is krankzinnig.

Ik zelf zorg dat ik via een tussenpagina op internet waarbij ik met .htaccess online moet inloggen en de RDP poort voor linux open zet voor 60 minuten in de firewall. Het is geen ideale oplossing, maar dan heeft alleen mijn ip adres toegang tot het rdp verbinding en geen anderen. Er zijn allerlei manieren om te bedenken hoe en waarom je poorten open zet. Ook ssh staat bij mij standaard dicht en wordt op deze manier voor 60 minuten open gezet.

Zo zijn er natuurlijk nog veel meer tips om de aanvalsvector op je bedrijf te minimaliseren: Bijvoorbeeld je web-server extern hosten. Onbegrijpelijk, dat organisaties RDP nog gebruiken. Tegenwoordig is het meestal Citrix met multi-factor authenticatie. Ook voor ssh zijn er nep-servers, die het wachtwoord afvangen en weergeven. Ook wordt er nog wel eens gebruik gemaakt van Teamviewer voor beheer....

Het gaat om inkomend verkeer om de RDP server connectie op te bouwen niet uitgaand. Inkomend staat dit standaard dicht op elke router/firewall die de fabriek komt uitrollen en staat de service uit in Windows (Server).

Actie nemen is dus niet nodig tenzij je service aangezet hebt en de firewall port geconfigureerd heb.

De laatste alinea klopt niet, het probleem zit hem niet harstikke in de server. Het zit hem in de gebruikers/beheerders die het aanzetten en dingen niet juist configureren. Als je het allemaal juist instelt kan je de service prima configureren via een GPO en deze voorzien wordt met een certificaat uit je eigen lokale CA.

Het FEIT blijft gewoon dat men het niet juist configureert en zich vaak niet houdt aan de best practises die worden geadviseerd door de leverancier (Microsoft). Daarom zie je in elk documentatie over RDP inschakelen vanuit Microsoft, staat er een waarschuwing zet dit alleen aan als je weet waar je mee bezig bent!!


Dit hele topic slaat nergens op, volg gewoon de aangegeven adviezen op die MS duidelijk aangeeft.

Maar Microsoft heeft zelf toch ook zo'n reverse proxy oplossing waarmee je RDP "achter" een https TLS host zet?
Gebruikt niemand dat dan? Ok, dat kun je niet simpel scannen natuurlijk want dat ziet er dan uit als een https website.

Ik blijf moeite hebben met dat vertalen van "door een probleem met de server kan mijn password hash lekken" naar
"dus moet je geen RDP server draaien". Dat gaat daar niet tegen helpen. Dat is net als "wanneer je telnet gebruikt
op internet zou het kunnen dat men je password mee kan lezen" vertalen naar "dus moet je geen telnet server op
internet zetten". Nee. Je moet niet op een telnet server op internet INLOGGEN als je wachtwoord geheim moet
blijven. Dat is wat anders.

Ervan uitgaande dat je een andere Anoniem bent: wat Anoniem van 13:49 lijkt te bedoelen is het voorkómen dat je, met jouw client, slachtoffer wordt van een AitM.

Zodat ook andere lezers het begrijpen: bij een TCP-"verbinding" is er geen echte verbinding, maar versturen zowel de client als de server netwerkpakketjes met, in elk pakketje, het afzender-IP-adres, het afzender-poortnummer, het ontvanger-IP-adres en het ontvanger-poortnummer. In een antwoordpakketje zijn beide paren (afzendergegevens en ontvangergegevens) van plaats verwisseld.

In onderstaand "plaatje" betekent, in C:random, dat C het IP-adres van de client is, en het poortnumner "random", min of meer willekeurig gekozen. Aan de linkerkant worden de pakketjes van Client naar Server uitgebeeld, en rechts de retour-pakketjes.


Als de firewall van de client uitgaand "verkeer" (pakketjes) naar uitsluitend poort 3389 blokkeert (aangegeven met X), kan die client geen verbindingen opzetten met RDP-servers (die gebruik maken van poort 3389, wel als deze van een andere poort gebruikmaakt).

Als de beheerder van de server niet wil dat er vanaf Internet met poort 3389 van de RDP-server kan worden gecommuniceerd, kan hij in zijn fiirewall inkomend verkeer voor poort 3389 blokkeren (aangegeven met +).

Voor de mensen die zich afvragen waarom de firewall van de client, pakketjes bestemd voor die client met random poortnummer doorlaat (bij # in het plaatje): daar maken firewalls een uitzondering voor, nl. zodra deze eerder (niet te lang geleden) een uitgaand pakketje met verwiselde gegevens heeft "gezien". Het gaat daarbij dus om 4 gegevens die moete kloppen; het is dus niet zo dat een aanvaller vanaf een ander IP-adres pakketjes, ongehinderd door de client-firewall, naar de client kan sturen.

Zodra de "verbinding" met de server netjes wordt gesloten (middels speciale pakketjes) zet de client-firewall de tijdelijke inkomende poort weer dicht. Dat gebeurt ook na een bepaalde periode van inactiviteit (internetstoring, server gecrashed etc).

Nb. bij NAT (Network Address Translation), meestal PNAT (P voor poort) kunnen firewalls (of firewalls in modems) het client-poortnummer en beide IP-adressen wijzigen; doordat ze dat op dezelfde manier voor in- als uitgaande pakketjes van één "verbinding" doen, merk je daar in de praktijk niks van (voorbeeld: als de client zelf pakketjes met afzender gegevens 10.0.0.1:1025 verstuurt, kan de client-firewall daar straffeloos 82.94.191.110:60000 van maken (d.w.z. deze gegevens aanpassen in uitgaande pakketjes). De server stuurt diens antwoorden dan naar 82.94.191.110:60000, waarna de client-firewall dat weer wijzigt in 10.0.0.1:1025 voordat het pakketje naar de client wordt gestuurd.

Als je een RDP-server direct op Internet wilt ontsluiten zul je inderdaad wat moeten doen. Probleem: veel te veel "beheerders" hebben dat gedaan.

Dat helpt onvoldoende. Sowieso zul je dan een extra CA-certificaat op je PC moeten hebben, wat lang niet altijd het geval is. Het volgende probleem is dat veel mensen certificaatwaarschuwingen van RDP-servers zó gewend zijn dat zij ze onmiddellijk wegklikken.

Maar zelfs dat is allemaal irrelevant: als je verbinding maakt met een AitM, stuurt mstsc jouw NetNTLMv2 "wachtwoord" naar die server vóórdat je een certificaatwaarschuwing hebt gezien.

Het is bullshit wat Microsoft adviseert, want dat helpt niet tegen AitM's.

In https://www.microsoft.com/en-us/security/business/zero-trust staat "Assume breach". Als er één of meer devices op jouw LAN gecompromitteerd zijn die zich kunnen voordoen als jouw RDP-server, en je opent daarmee een RDP verbinding, heeft de aanvaller jouw NetNTLMv2 credentials. Ongeacht wat voor certificaat je op jouw echte RDP-server zet, want die server speelt geen rol bij zo'n verbinding.

Ik vind het leuk om kennis te delen (in het topic de kennis opgedaan door GoSecure), maar als jij het beter weet vind ik dat ook helemaal prima. Fijne avond!

RD Web Acess heet dat inderdaad er zijn ook andere oplossingen. Tuurlijk wordt dat gebruik, zeker in grotere omgevingen zie je dit soort configuraties altijd. Daarom snap ik geen snars van Erik’s verhaal, tuurlijk kom je dit tegen maar niet in professionele omgevingen, de configuraties waar hij het over heeft zijn hobby boeren en doorgaans kleine bedrijven die alles willen en zo goedkoop mogelijk, zonder enige inkijk op de risico’s.

Zou je deze configuratie als IT architect voorstellen dan ben je direct je baan kwijt.

Ik heb dit issue een paar jaar terug ook aan Microsoft gemeld. Kreeg toen dezelfde by-design reactie terug. Met de opmerking: je moet rdp niet op internet gebruiken. Andere case in hun authenticatievoorziening (dat het uitloggen uit AAD-online een deel van de sessie niet verwijdert, waardoor er nog tokens zijn waarmee je hem na het uitloggen zonder wachtwoord weer kunt activeren): ook niet belangrijk. Over de ernst kun je altijd van mening verschillen, maar neem owasp/cwe issues tenminste serieus. Ik meld daar niet meer. Zonde van de tijd.

Ik heb dit topic bewust niet gepost in "Security Professionals", maar in "Computerbeveiliging".

Het is mooi als jij alles goed voor elkaar hebt, maar waarschijnlijk hangen er miljoenen onveilige RDP-servers direct aan Internet, waarvan meer dan 100.000 in Nederland (stand: okt. 2020 [7]).

Bovendien blijkt RDP een populaire achterdeur te zijn om ransomware uit te rollen en/of persoonsgegevens buit te maken. Vooral van dat laatste kan iedereen slachtoffer worden. Van mij mag de AP meteen een boete uitdelen aan elke organisatie, die digitaal persoonsgegevens verwerkt (welke niet tegenwoordig), die een RDP-server via Internet toegankelijk maakt voor meer dan een tiental IP-adressen.

[7] https://www.security.nl/posting/675570/Onderzoek%3A+100_000+Nederlandse+systemen+bereikbaar+via+RDP

Met ssh gebruik je geen wachtwoorden maar ssh-keys die niet over de lijn gaan!

Dank je wel voor deze bijdragen Erik,
Voor mij wel heel leerzaam en een duidelijk waarschuwing.

Noob

Additioneel;

De SSHD daemon dient AllowTCPForwarding aan te hebben staan.
De authenticatie gaat idealiter via SSH keys.
Op de client ziet een connectie er dan ongeveer zo uit:
ssh -L 3389:localhost:3389 remote.rdpserver.net

Je kunt je RDP verbinding dat opzetten tegen localhost:3389

Tevens is SSH per default al dusdanig dicht gespijkerd dat er niet direct extra configuratie nodig is.
Je zou hooguit password authenticatie kunnen disabelen of als je heel enthousiast bent een dedicated user aanmaken en interactieve shells kunnen disablen.


Overigens dat RDP zonder trusted cert over het internet een dom idee is lijkt me toch wel algemene kennis inmiddels.
Jaren terug al eens wat scriptjes gemaakt om een verbinding the MITMen , cert te injecten en keystrokes te loggen, leuk om mee te spelen.
En inderdaad klikt iedereen door de 'waarschuwing' heen, komt ook omdat veel admins lui zijn en niet veel begrijpen van certificaten, zeker wanneer ze niet automatisch 3x op next kunnen klikken.

Kom op ...

Dat _kan_ , en dat is _aan te raden_ , maar feit is natuurlijk wel dat ontzettend veel SSH logins gewoon password gebaseerd zijn.
En fors veel SSH gebruikers zijn helaas gewend aan wisselende host keys omdat zoveel admins bij een update/reinstall niet de hostkey behouden maar gewoon een verse laten installeren.

Dat is maar een van de mogelijkheden. Uit "man sshd_config":
Jij hebt het over de laatste, "publickey"; "password" laat je inloggen met usernaam en wachtwoord, wat dus wel degelijk ook kan; er er zijn dus meer mogelijkheden dan die twee. Dat de ssh-configuratie die jij kennelijk kent geen wachtwoorden accepteert betekent niet dat ssh in het algemeen er niet mee werkt.

De gemiddelde klant denkt daar niet over na, je kunt de gemiddelde klant niet vergelijken met de mensen op http://security.nl
Klanten kijken alleen of iets werkt of net, als een update er voor zorgt dat iets niet meer werkt updaten ze niet. Het risico bij niet meer updaten is groter.

Merk op dat het NTLMv2 authenticatieprotocol standaard geen server authenticatie doet (punt 3). Dat is de reden dat het protocol kwetsbaar is voor relay/intercepting aanvallen. Om dit te voorkomen moeten de "signing" instellingen zoals SMB signing, LDAP signing en HTTP EPA ingeschakeld worden. (Dit zijn overigens allemaal opt-in security fixes.)

Ik kom in diverse grote ondernemingen waar alleen public key is toegestaan voor linux servers maar rdp in mgt vlans overal open staat.

We hebben het over klanten die wel over backwards compatibility nadenken, je schreef dat klanten dat verwachten.

Of misschien vind je dat je kan stellen dat klanten backwards compatibiliteit verwachten als ze er pas over na gaan denken als ze geconfronteerd worden met het ontbreken ervan en de problemen die dat oplevert. Prima, maar dan kan je ook stellen dat klanten robuuste software zonder veiligheidsrisico's willen als ze er pas over na gaan denken als ze geconfronteerd worden met de gevolgen van het ontbreken ervan.

Had je zelf door dat je voor je eigen argumenten de lat anders legt dan voor de argumenten van een ander?

Ik twijfel er niet aan of dat klopt, maar het begon met deze uitspraak:
Dat is een uitspraak over ssh, niet over wat diverse grote ondernemingen doen en niet over wat verstandig is.

Vaak zie je natuurlijk dat dit soort later door Microsoft bedachte oplossingen alleen werken in een Windows monocultuur,
omdat de in de tussentijd ontwikkelde alternatieve oplossingen voor interworking met Windows servers dit dan niet
ondersteunen, of alleen in de allernieuwste versie die nog niet praktisch is om uit te rollen.
(of helemaal nooit beschikbaar gaat komen, bijvoorbeeld in embedded systemen of andere appliances)

Dit is vaak voldoende reden om er niet aan te beginnen. Want het moet wel blijven werken, natuurlijk.

Is het risico bij KDE gelijkwaardig vanaf een eventuele Android kant?

Als er verdiend moet worden, knijpt men heel wat security oogjes dicht, ook bij Big Tech.
Goed dat hier aandacht voor gevraagd wordt. Dank, Erik, goede heads-up!

Re: https://resources.infosecinstitute.com/topic/how-to-discover-open-rdp-ports-with-shodan/

luntrus