Onderzoekers vinden zero-daylek in remote desktop protocol

Beveiligingsonderzoekers hebben een zero-daylek ontdekt in het remote desktop protocol. Daarmee kan de beveiliging van Windows worden omzeild en kunnen aanvallers binnendringen op een getroffen systeem.

Onderzoekers van de Carnegie Mellon Universiteit hebben een exploit geschreven voor Metasploit waarmee het lek kan worden uitgebuit. Die is nog niet openbaar gemaakt vanwege de veiligheid. Er is op dit moment nog geen patch beschikbaar voor het lek; die komt op 11 juni uit tijdens Microsofts 'Patch Tuesday'. De kwetsbaarheid zit in Windows 10 vanaf versie 1803, en in Windows Server 2019.

De kwetsbaarheid, CVE-2019-9510, kan worden ingezet om de authenticatie van machines met Windows te omzeilen. Een aanvaller hoeft alleen maar via rdp verbinding maken met het systeem van een slachtoffer om authenticatie te krijgen en te houden voor de computer. Dat kan ook nadat de gebruiker het scherm heeft vergrendeld. Door het lek uit te buiten zou het zelfs mogelijk zijn bepaalde multifactorauthenticatiemethodes te omzeilen.

Het is niet direct duidelijk of de nieuwe kwetsbaarheid verband houdt met BlueKeep, de nieuwe remote desktop service-kwetsbaarheid die eerder dit jaar uitlekte. BlueKeep misbruikt kwetsbaarheden in het rdp-protocol en kan daardoor mogelijk ransomware-wormen verspreiden. Dat is een soortgelijke aanvalsmethode als bij WannaCry en (Not)Petya. Eerder deze week waarschuwde de NSA systeembeheerders nog dat zij hun netwerken moesten updaten. Er zijn nog steeds meer dan een miljoen computers met de rdp-kwetsbaarheid op internet aangesloten, ondanks het feit dat er al lang een patch voor beschikbaar is.

Update: in dit artikel stond aanvankelijk dat de exploit onderdeel is van BlueKeep en dat BlueKeep dezelfde kwetsbaarheden gebruikt als Wannacry en (Not)Petya. Dat is aangepast.

Reacties (112)

Dit is toch wel iets heel anders dan CVE-2019-0708
Voor CVE-2019-0708 heb je alleen netwerk toegang nodig tot het werkstation

Voor deze kwetsbaarheid moet je toegang tot het werkstation hebben waarop een gelockte sessie te vinden is. tja, als je dan al toegang hebt, installeer dan wat malware en neem de sessie over als de sessie unlocked is? Heb je geen vulnerability voor nodig.

Long story short: Niet echt een schokkende kwetsbaarheid. Disconnected RDP moet je sowieso mee uitkijken

Ik dacht dat dat wel zou worden afgevangen in Windows firewall. Maar nee, poort 3389 staat standaard gewoon open voor alle netwerkverbindingen.
Dus als ik bijvoorbeeld op Schiphol op de WiFi zit, kan "iedereen" er zomaar bij.
Min of meer onbelangrijke zaken als Windows Media Player service staan wel dicht voor "openbare netwerken".

Als je remote desktop enabled krijg je een mooie melding dag er een firewall rule is aangemaakt / enabled voor inkomend verkeer. Dit zou een trigger moeten zijn om hier whitelisting van "trusted" ip's in op te nemen lijkt mij.

Voor zover ik het begrijp moet er al een remote sessie zijn en dient die gelockt te zijn. Alleen dan kan dit werken. Weinig menden die even op schiphol gaan zitten met een gelockte rdp sessie naar hun laptop...

For example, consider the following steps:

User connects to remote Windows 10 1803 or Server 2019 or newer system using RDP.
User locks remote desktop session.
User leaves the physical vicinity of the system being used as an RDP client


At this point, an attacker can interrupt the network connectivity of the RDP client system. The RDP client software will automatically reconnect to the remote system once internet connectivity is restored. But because of this vulnerability, the reconnected RDP session is restored to a logged-in desktop rather than the login screen. This means that the remote system unlocks without requiring any credentials to be manually entered. Two-factor authentication systems that integrate with the Windows login screen, such as Duo Security MFA, are also bypassed using this mechanism.

[Reactie gewijzigd door Drucchi op 5 juni 2019 14:30]

Exact. Net even getest en het werkt inderdaad zo. Inloggen op RDP, RDP sessie locken, wifi disconnect > connect. RDP reconnect automatisch en is inderdaad niet op slot. Kinderlijk eenvoudig, maar dus niet iets wat je als aanvaller zomaar remote kan doen. Je moet echt toegang hebben tot een machine waar een gelockte RDP sessie draait en dan kan je die sessie dus op deze manier unlocken zonder het wachtwoord van de RDP bestemming te kennen).

Volgens mij zijn je Wifi instellingen beschikbaar vanaf het lock screen?

Dat kan, als ie aan het LAN hangt kan je ook stekker los en weer vast. Maar daarmee kan je nog niet bij de ontgrendelde RDP sessie natuurlijk, daarvoor zal je daadwerkelijk die PC zelf ook moeten unlocken.

Geldt dit dan eigenlijk ook voor MS HyperVisor-Hosts waar gelockte VM-sessies op open staan?
(kan dit zelf momenteel niet testen...)

Zegmaar uit de gedachte sysadmin die een RDP naar een HyperVisor-host heeft met daarop een aantal van de VM-sessies geopend had via het HyperVisor-overzicht en die allen gelocked. Ik geloof dat je daar onderhuids ook gewoon RDP voor gebruikt, niet?

[Reactie gewijzigd door Annihlator op 5 juni 2019 17:34]

Hyper-v VM console maakt alleen gebruik van RDP als je enhanced sessions gebruikt

Deze exploit werkt alleen als een aanvaller toegang kan krijgen tot jouw systeem. Hij moet dus je username en wachtwoord weten.

Blijkbaar niet echt. Toegang via het netwerk (connect op RDP poort), authenticatie is niet direct nodig.

[Reactie gewijzigd door tweaknico op 5 juni 2019 17:02]

Onjuist. Hier staat een duidelijke uitleg. Zoals onder het kopje "impact" staat:

By interrupting network connectivity of a system, an attacker with access to a system being used as a Windows RDP client can gain access to a connected remote system, regardless of whether or not the remote system was locked.

De aanvaller moet dus eerst toegang hebben tot de machine waar de RDP client op draait. Hij is vervolgens in staat voorbij het lock screen op de RDP server te komen zonder credentials te gebruiken.

En aangezien de remote user toch al credentials had om mee in te loggen, is het niet zo relevant dat hij het lockscreen kan omzeilen.

Nou ja, het impliceert dat je je RDP sessie niet veilig kunt locken en weg kunt lopen van de client PC, want iemand anders kan je sessie dan hervatten, dat is het punt.

Maar goed, persoonlijk sla ik wachtwoorden op voor veelgebruikte RDP servers dus dan is het sowieso een moot point

[Reactie gewijzigd door .oisyn op 5 juni 2019 17:05]

Besmette PC, aanval met RubberDucky , .. zijn ook zomaar wegen om langs de PC te komen zonder ww.

Er zijn meer manieren om bij de rdp client sessie te komen. Als je maar al toegang tot de client zelf hebt. Een voorbeeld is een user die denkt de client gelocked te hebben maar alleen de rdp client sessie locked heeft. Malware die de client al besmet heeft en de sessie kan overnemen is ook een mogelijkheid. Er zijn waarschijnlijk wel meer manieren. Maar op zich is deze fout inderdaad niet genoeg om de sessie ook over te kunnen nemen.

Zoals ik het verhaal van de onderzoekers lees moet een remote gebruiker eerst succesvol via RDP verbonden zijn met een machine. Dit lukt je niet zonder username en password. Daarna lockt de local user de machine en loopt weg. De remote user ziet ook het lockscreen. Hij of zij kan dan een korte verstoring van de verbinding veroorzaken en nadat RDP automatisch reconnect wordt de sessie unlocked weergegeven aan de remote user. Maar dan moest je dus wel eerst op legitieme wijze verbinding hebben gehad.

[Reactie gewijzigd door Haribo112 op 5 juni 2019 16:17]

Voor het tweede deel is geen username password nodig.
Voorwaarde is een bestaande sessie...

Ja, precies hetzelfde als ik zeg dus.

Hij moet dus je username en wachtwoord weten.

Nee hij moet op de een of andere manier toegang tot de client hebben, kan een besmette PC zijn...
of een USB Rubberducky .. (of soortgelijke aanval).
De aanvaller heeft niet username en ww op de server nodig.

Neen, net niet. Deze kwetsbaarheid authenticeert je zónder user/pass...

Euhm nee ...
Alleen als jij in de instellingen het vinkje aanzet "externe verbindingen"
Anders staat het gewoon standaard uit

Daarna moet je het in de router openen om extern door te zetten ( portforwarding )

* en het belangrijkste :
Waarom zit je op een vreemde wifi met lokale permissie ?
Die hou je toch gescheiden als openbaar netwerk ?
Daar zijn de firewall instellingen wat zwaarder.

Ik zat dus op mijn Windows 10 laptop te kijken, voordat ik het postte. Voor RDP zijn er maar 2 firewall rules in (TCP/UDP), die voor alle netwerken etc. gelden.
Voor Windows Media Sharing (of zoiets) en nog meerdere van dat soort in mijn ogen onbelangrijke services zijn er wel verschillende rules voor de diverse netwerken (privé, domein, openbaar). Alleen privé staat daar enabled.
Waarom dat zo is, weet ik dus niet. Ik gooi niet zomaar firewall rules weg, ik enable of disable ze. Ik kijk er overigens zelden naar (wel eens RDP naar 3390 gezet bijvoorbeeld, dan moet je daar zelf een rule voor aanmaken).
En uiteraard blokkeert de router verbindingen naar binnen. Maar punt was dat ik op een openbaar wifi netwerk blijkbaar de RDP (en andere) poorten standaard open heb staan, wat ik niet wenselijk vind.

Die poort staat alleen open als je toegang via RDP inschakelt. Gelukkig maar, anders zou het niet werken.

Inderdaad, in het "Public" firewall profiel staat rdp standaard dicht!

Een goed ingericht openbaar netwerk gebruikt client-isolation, wat will zeggen dat de verschillende clients niet met elkaar kunnen praten. Dus niet pingen, geen remote desktop, niks.

Jammer genoeg liggen openbare netwerken doorgaans buiten de invloedssfeer van de laptop eigenaar. En de gemiddelde Windows10 gebruiker zal niet bij machte zijn om dat "even te controleren". Tegelijkertijd zullen die gebruikers meestal RDP toegang ook niet op hun tablet/laptop aan hebben staan, dus dat valt dan ook weer mee.

Degenen die dat wel hebben zouden sowieso de RDP alleen open moeten hebben op een "Private Network" of "Domain Network" en nooit op "Public Network". Aangezien een systeem standaard in die laatste valt, kom je daar redelijk goed mee weg en heb je zelf vrij bewust een stomme keuze gemaakt als het anders loopt door én RDP te enabelen, én een netwerk als vertrouwd te markeren.

nee dat is niet waar! 3389 staat standaard dicht

Inderdaad, een windows installatie heeft RDP standaard niet ingeschakeld staan. De poort (3389) luistert dan ook niet en de Windows firewall zal deze tevens blokkeren. Alleen als de gebruiker (of beheerder in een zakelijke omgeving) Remote Desktop heeft ingeschakeld zal er ook automatisch een firewall regel voor het toestaan van TCP 3389 verkeer worden aangemaakt.

Dus netjes een outbound firewall notifier o.i.d. gebruiken, standaard windows firewall alles blocken zowel inbound en outbound, en uiteraard default bestaande rules verwijderen ;-)

Da's het hele idee van remote desktop, dat je er van buiten bij kan

@Sandor_Clegane

Jij vroeg je toch af waarom systeembeheerders als best practice RDP niet naar het internet openzetten? ;-)

Op zich een goed punt, maar voor deze kwetsbaarheid weinig relevant. Waar het om gaat is dat als je een RDP sessie hebt lopen, en die lockt. Dat na een netwerk hickup en automatische reconnect de lock weg is.

Dat is dus niet iets wat een aanvaller zomaar remote over het internet kan uitvoeren.

Het is wel weer een extra goede reden om een PC waar je op aan het werk bent niet onbeheerd onvergrendeld achter te laten.

Deze vulnerability biedt niet zomaar toegang tot sessies vanaf internet, dus het openzetten naar internet is geen factor in deze.

In dit geval wordt bij de exploit gebruik gemaakt van toegang tot een reeds open "bron" systeem om toegang te krijgen tot een gelockte RDP sessie naar een "remote" systeem die op dat moment al in gang was. Het enige dat je nu kan is het lockscreen omzeilen op het "remote" systeem.

In dit geval is er al zoveel gecompromitteerd dat je op het betreffende "bron" systeem ook gewoon een keylogger o.i.d. kan installeren om hetzelfde te bereiken. Het is niet zo dat elke RDP server op internet nu een open deur is geworden.

TL;DR: De enige situatie waar dit ge-exploiteerd kan worden is in de situatie dat iemand wegloopt bij zijn PC maar deze niet lockt, maar een remote sessie wel gelockt is, in dit geval kan je de remote sessie unlocken door de netwerkverbinding te onderbreken. Als je gewoon netjes je PC lockt als je wegloopt heb je dit al voorkomen dus.

Edit: @Orion84 had dit ook al opgemerkt, had de pagina te lang niet gerefresht sorry

[Reactie gewijzigd door GekkePrutser op 5 juni 2019 15:25]

Tja, als je nu een ongepatcht lek vind in SSH, zeg je hetzelfde?
Dat je RDP uitzet snap ik wel, maar om deze reden niet.

Is een behoorlijk groot verschil tussen een protocol dat van de grond af aan is ontwikkeld voor veiligheid en vele malen is ge-audit en een protocol dat is ontwikkeld om een desktop te delen waar later wat beveiliging aan is toegevoegd.

De correcte vergelijking zou zijn het direct aan Internet hangen van een X server zonder enige vorm van extra beveiliging.

RDP met SSH vergelijken is appels met peren vergelijken.

Mag hopen van wel, welke idioot zet er in productie in godsnaam SSH open naar de wereld? Daar zet je minstens een firewall voor met een whitelist, of enkel ontsluiten via VPN.

In het geval van VPN, is dat niet het verleggen van het probleem?

Want dan gaan botnets je VPN poorten proben.

Daarnaast heb je i.p.v. één gebruikersnaam en wachtwoord of key, nu 2 gebruikersnamen en wachtwoorden of keys die je moet beveiligen en voorzichtig mee moet omgaan.

Als je er iets van OpenVPN voor plakt, heb je:

1) Username+password VPN
2) Authy op je telefoon voor je MFA
3) Key al op je workstation

Je hoeft dus eenmalig een wachtwoord+MFA token in te tikken bij authenticatie, vervolgens kun je de hele dag vrolijk door. En botnets kunnen een VPN-poort gaan proben, dat maakt allemaal niets uit. Ookal wordt je VPN-doos somehow kapotgemaakt of geinfiltreerd, ze hebben geen werkende key om verder te komen. Je voegt een extra laag toe.

De bedoeling is dat je een VPN verbinding maakt naar het netwerk waarin je RDP server draait. Daarna verbind je via die verbinding met de RDP server. Je hoeft dan geen poort open te zetten naar de buitenwereld omdat het verkeer alleen op het lokale netwerk blijft.

Een eventuele aanvaller zou dan eerst toegang moeten krijgen tot je VPN netwerk en zou daarna pas de exploit toe kunnen passen. VPN vormt dus een extra beschermingslaag ten opzichte van een open RDP verbinding.

Toch moet je ergens een VPN server hebben staan om vanuit de buitenwereld met de RDP server praten. Dus moet je nog een machine onderhouden. Hoe ga je die beheren? Met RDP misschien?

Dat ligt eraan of het een Windows machine is. Maar zo ja, dan gewoon via VPN en RDP. En als je VPN uit de lucht moet vanwege het onderhoud dan doe je het onderhoud via het lokale netwerk zelf.

Of je zet er bruteforce detection op en staat alleen maar key-auth toe.... (port knocking is ook zo'n leuke)

Het "probleem" met SSH zit niet in het protocol en over het algemeen ook niet in de server maar wel in brute-force pogingen van allerlei botnets.

Ik heb SSH open naar de wereld, wel met public en private key..
dus ben ik nu idioot ?

SSH wordt vaak om precies dezelfde reden niet naar het internet open gezet

Wat word er dan wel volgens jou opengezet naar het internet, telnet?

VPN meestal. En daarvandaan heb je toegang tot het interne netwerk waarvandaan je SSH, RDP e.d. kan gebruiken.

Ik beheer meerdere servers tegelijk op verschillende netwerken.

Met SSH kan ik gewoon op alle machines tegelijk verbinden. Als het over vpn moet gaan enkel met de machines van dat netwerk.

Dat is het grote verschil. SSH verbind je met 1 machine, VPN met een netwerk. Tis maar wat je nodig hebt...

En wat als ze een lek vinden in het vpn protocol dat je gebruikt?

Gaan we dan met zijn alle geen gebruik meer maken van VPN?

Zo kun je door blijven gaan...

[Reactie gewijzigd door jordynegen11 op 5 juni 2019 14:42]

Daarvoor heb je dus meerdere schillen beveiliging en niet 1. Eerste schil is VPN, tweede schil is SSH of RDP.

Standaardconcept binnen informatiebeveiliging.

Daar heb je gelijk in. Maar als ze beide gevallen een lek vinden ben je alsnog de sjaak.

[Reactie gewijzigd door jordynegen11 op 5 juni 2019 14:41]

de kans dat er een lek gevonden wordt in beide binnen zo'n korte tijd dat je niet in staat bent om er 1 van beide te patchen is wel heeeel klein.
als je die dan allebei niet patcht dan ben je zelf een sjaak.

Ja en dat is juist het punt
Naar mate je meer schillen heb is de kans kleiner dat ze allemaal in 1 keer compromised zijn.

Klopt, dan zitten ze voordat je het weet in je NAS

Sjeumig dan maar geen internet meer. Veel te gevaarlijk allemaal

Als er een virus is met meerdere zero-day exploits. Ok. Maar als jij dat krijgt op je PC ben je een zeer hoge HIGH PROFILE target.

Een virus wat verschillende zero-day exploits bevatte is o.a. Stuxnet waar waarschijnlijk een zeer groot en competent team aan hebben gewerkt. En hierbij heeft het geen nut om grote schade aan te richten.
Een virus met meerdere zero-day exploits is meer een chirurgische tool om bepaalde speciaal geselecteerde doelen te elimineren of informatie te krijgen. Jij als gewone Hollander zal hier dus never nooit last van krijgen. Jij bent geen high profile target.

Eerste schil is VPN (bij voorkeur certificate-based in combinatie met een One-Time-Password)
Tweede schil is Just In Time Administration (dus toegangsrechten aanvragen vanaf het IP waar je op dat moment actief bent, voor de duur dat je verwacht dat de werkzaamheden duren)
Derde schil is Just Enough Administration (geen full-blown domain admin rechten, maar alleen de rechten die je nodig hebt)
Vierde schil is RDP authenticatie


Of sla ik nu door?

[Reactie gewijzigd door walteij op 5 juni 2019 15:09]

Alles achter een VPN is toch hard op zijn retour hoor. Zoek bijvoorbeeld maar eens op 'beyondcorp'.

Van mij hoeft helemaal niet alles achter een VPN, zeker niet voor de gewone werknemer. Voor die mensen is een toegang tot bestanden en applicaties via MFA een prima oplossing.

Accounts met meer rechten moeten echter wel beter afgeschermd worden. En dan kom je al een heel eind als je MFA&JIT&JEA gecombineerd gebruikt.

Probleem met al die schillen is dat als je een probleem hebt met een remote systeem en 1 van die schillen heeft een probleem dan kom je er al niet meer in. Stel je VPN connect niet, dan kom je er ook niet meer via SSH in om het probleem te fixen.

Dus als je geen "out of band" toegang hebt tot de console o.i.d. is het beter om SSH open te hebben als manier om er bij te kunnen, maar dan wel goed dichtgetimmerd en up to date.

En als je Windows login een 2FA gebruikt dan was dat dus al je tweede beschermingslaag. Zo zie je maar dat meerdere lagen ook niet altijd werken.

Ik begin altijd met het wijzigen van de poortnummers. Dat voorkomt de standaard poortscans en brengt het aantal aanvallen al aanzienlijk terug. Als iemand je dan nog aanvalt dan heeft hij het waarschijnlijk op je voorzien gezien de moeite die hij/zij er voor doet.

[Reactie gewijzigd door 3raser op 5 juni 2019 16:05]

Een tweede factor is iets anders dan een tweede laag.

Voordeur met twee sloten is anders dan twee deuren achter elkaar. Bij inbeuken merk je het verschil. Het kost je twee pogingen.

Het punt is hier dat er een bug in de deur zit. Kan je 30 sloten hebben maar die omzeil je juist. Bij twee deuren moet je twee keer omzeilen.

Zie "defense in depth"

[Reactie gewijzigd door Korvaag op 5 juni 2019 16:31]

Als er een lek in het VPN-protocol zit dan hebben ze met een beetje pech toegang tot de VPN-server, die een stuk beter te beheren, beveiligen en monitoren valt, dan iedere individuele node op zich voor intrusie.

Tenminste, in de omgevingen waar ik heb gewerkt was (beheer)toegang tot de VPN zelf extreem gelimiteerd en nogal dichtgetimmerd. Een security-device heeft nou eenmaal wat hogere eisen dan de doorsnee server in het park.

In een wat minder ernstig geval (VPN is vooral een netwerk-protocol en geeft toegang tot een netwerk en geeft zelf geen authorisatie af) dan heb je als het goed defense-in-depth doordat je vervolgens nog wel tegen alle servers waar je nu bij kan moet autoriseren.

[Reactie gewijzigd door Keypunchie op 5 juni 2019 14:49]

Over het algemeen verbind je met de VPN, waarna je door die VPN tunnel SSH gebruikt.

RDP voor Windows doe je op dezelfde manier, of via een Remote Gateway Server

Vpn met certificaten authenticatie. Beschermd door firewalls, fail2ban, accesslisten en evt zelfs een NAC. Mogelijk vanuit daar (vpn) zelfs alleen kunnen inloggen op een jumphost. Waar de jumphost alleen toegang heeft tot een management netwerk.

Dergelijk protocollen zoals SSH of rdp open zetten (zelfs op niet standaard poorten) is vragen om mensen die belletje gaan trekken.

SSH wordt vaak gelimiteerd op een aantal IP's. In mijn geval iig heb ik van al onze servers de IP's gelimiteerd tot onze zakelijke en mijn thuis IP's.

Klopt, maar daar ging het in deze context niet om.

reageerde op de verkeerde

[Reactie gewijzigd door Joenino op 5 juni 2019 14:37]

precies of ge gaat op dat niveau nog een assistent krijgen. Je mag blij wezen dat die job nog niet is vervangen door een robot. Die robot heeft natuurlijk wel onderhoud nodig door de vrachtwagenbandventieldopjesrobotonderhoudscrewmedewerker.

ontopic. Heeft er iemand de remote desktop open staan naar uitgaande netwerken? Binnen een bedrijfsnetwerk kan ik indenken dat de remote desktop open staat op het interne netwerk. Zeker bij een bedrijf met meerdere vestigingen, kan je besparen op IT-personeel via die remote desktop (denk aan een interne helpdesk). Maar zelfs dat is natuurlijk niet zonder gevaar, en dan denk ik vooral aan industriële spionage.

@Keypunchie Uhm nee, als je gelezen had wat ik geschreven heb, dan had je begrepen dat ik het raar vind dat je niet mag verwachten dat iets werkt zoals het hoort.

Maar lief dat je aan me denkt.

[Reactie gewijzigd door Sandor_Clegane op 5 juni 2019 14:07]

Dus Windows Server 2016 is niet vatbaar?

Klopt. Dit is er ingeslopen sinds Win10 1803. Sinds vorig jaar lente dus.

Waar is te vinden dat deze patch op 11 juni uit komt?

Ik vind deze commentaar van de onderzoeker:

Tammariello reported his findings to Microsoft, but the tech giant apparently does not plan on patching the vulnerability too soon.

“After investigating this scenario, we have determined that this behavior does not meet the Microsoft Security Servicing Criteria for Windows,” Microsoft said, according to CERT/CC vulnerability analyst Will Dormann.

Read aaaaalll about it! https://www.securityweek....n-remote-desktop-sessions

En dit is nu exact de reden waarom ik de laatste 6 maand nu zo'n beetje, telkens wanneer ik uit huis ga mijn UTP kabel uit mijn PC haal. Ik vond dat er de laatste paar maanden zo nu en dan maar vreemde dingen gebeuren namelijk, wanneer ik er op aan het werk was. Zoals spin-up's van HDD's die ik op dat moment helemaal niet aansprak, en dat terwijl indexering en dergelijke dingen allemaal uit geschakeld staan in mijn Windows 10 Pro installatie. En had daar om de hierboven genoemde redenen dan ook niet echt een fijn gevoel bij met wat er zoal gebeurd wanneer ik niet thuis ben, en om die reden voor de zekerheid dan ook maar elke keer de UTP kabel loskoppel wanneer ik uit huis ga.

Serieus ? En als je wel die kabel er uit trekt en niet het huis verlaat, starten allerlei dingen dan ook zomaar op ? En wat meldt een event-log ?

"starten allerlei dingen dan ook zomaar op ?"
Nope.
En nu zijn onverwachte spin-up's van HDD's nu ook niet meteen vreemd ofzo voor zover ik weet. Maar als ik soms met projecten bezig was, zij het in Adobe Pemiere of in After Effects, dan werdt mijn PC tijdens deze bezigheden soms op erg kromme momenten erg traag, en dat het gebruik van dit type software soms erg zwaar kan zijn voor een PC snap ik, alleen kwam het soms op de meest onlogische momenten tijdens deze bezigheden voor, en op een gegeven moment ook op momenten daarbuiten, waarna het mij toen maar verstandig leek om dan maar het zekere voor het onzekere te nemen, mocht het iets van "hacken" te maken hebben, of iets in deze richting. En kan dan ook melden dat hetgeen niet meer is voorgekomen zins mijn UTP kabel tijdens momenten dat ik uit huis ben, uit mijn PC verwijdert wordt.

Zou het kunnen dat de pc met internet software heeft (waaronder Windows en Adobe...) die wel eens updates uitvoeren?...
Ipv de kabel eruit te trekken zou het zoveel slimmer zijn om uit te zoeken wat het is en daarop te handelen, dit is symptoonbestrijding en dat lost niets op.

Aannames. Er draaien wanneer je PC draait allerlei programma's en taken op de achtergrond die dat soort zaken kunnen veroorzaken.

En dit is nu exact de reden waarom ik de laatste 6 maand nu zo'n beetje, telkens wanneer ik uit huis ga mijn UTP kabel uit mijn PC haal. Ik vond dat er de laatste paar maanden zo nu en dan maar vreemde dingen gebeuren namelijk, wanneer ik er op aan het werk was. Zoals spin-up's van HDD's die ik op dat moment helemaal niet aansprak, en dat terwijl indexering en dergelijke dingen allemaal uit geschakeld staan in mijn Windows 10 Pro installatie. En had daar om de hierboven genoemde redenen dan ook niet echt een fijn gevoel bij met wat er zoal gebeurd wanneer ik niet thuis ben, en om die reden voor de zekerheid dan ook maar elke keer de UTP kabel loskoppel wanneer ik uit huis ga.

Ja, want gekke dingen kunnen alleen gebeuren als je het huis verlaat en niet als je achter je PC aan het werk bent ...
Doe dan een shutdown, bespaar je ook nog energie.

"Ja, want gekke dingen kunnen alleen gebeuren als je het huis verlaat en niet als je achter je PC aan het werk bent ..." Nee dat zeg ik niet, ik zeg alleen dat het zo kan zijn. En tjah, mijn PC uitschakelen wanneer ik niet thuis ben/het huis uit ga, tuurlijk, dat gebeurt altijd netjes, alleen is er dan altijd nog de mogelijkheid om mijn PC te laten starten via een wake up on lan, en ik daarvoor in de BIOS geen optie heb om dit uit te schakelen. En om nu juist zoiets te voorkomen, wordt de UTP kabel er dus simpelweg volledig uit getrokken, wanneer ik mijn woning verlaat.

"Ja, want gekke dingen kunnen alleen gebeuren als je het huis verlaat en niet als je achter je PC aan het werk bent ..." Nee dat zeg ik niet, ik zeg alleen dat het zo kan zijn. En tjah, mijn PC uitschakelen wanneer ik niet thuis ben/het huis uit ga, tuurlijk, dat gebeurt altijd netjes, alleen is er dan altijd nog de mogelijkheid om mijn PC te laten starten via een wake up on lan, en ik daarvoor in de BIOS geen optie heb om dit uit te schakelen. En om nu juist zoiets te voorkomen, wordt de UTP kabel er dus simpelweg volledig uit getrokken, wanneer ik mijn woning verlaat.

Wol werkt niet vanaf het internet, wol wordt niet gerouteerd.

@ASS-Ware & @Immutable
Ik snap dat jullie mij beiden hiermee proberen helpen, en heb daar dan ook niets anders dan respect voor. Alleen ben ik niet echt een netwerk mannetje kan ik jullie melden, en heb daar dus maar bar weinig verstand om eerlijk te zijn. Dus ik handel dan ook alleen maar naar wat ik er wel vanaf weet, en dat luid, dat wanneer er geen netwerk kabel in mijn PC zit, deze simpelweg geen toegang heeft tot internet, just to be sure dus zeg maar, mocht het daarvan wegkomen. En dat er dingen op de achtergrond draaien wanneer een PC aan staat dat weet ik dan nog wel, en dat is in mijn geval een aanstuurt programma van mijn ESI geluidskaart, en nvidia video kaart, en een netwerk driver, ook wel handig, en wanneer er een USB-stick zit aangesloten, een aanstuur programma daarvoor, al loopt er op de achtergrond nog veel meer dan alleen dat natuurlijk, wanneer je eenmaal in taakbeheer gaat lopen kijken, maar goed, ik dwaal te veel af nu. Anyhow, dank aan beiden in elk geval, plus samen sta je sterker zeg ik altijd maar, dus wellicht dat ik jullie in de toekomst nog eens ergens mee kan helpen, who knows

[...]
Wol werkt niet vanaf het internet, wol wordt niet gerouteerd.

Het is wel degelijk mogelijk om Wake On Lan (ondanks de naam) via internet toe te passen.
WOL gebruikt UDP, en standaard is er helemaal geen poort voor een Magic Packet.
Het mág echter wel, en om WOL verkeer in complexere omgevingen (inclusief internet) mogelijk te maken wordt vaak poort 7 of 9 hiervoor misbruikt. (Officieel zijn deze poorten voor respectievelijk Echo en Discard).

Als je op basis van deze info je internetmodem/router configureert kun je wel degelijk wollen over internet.

[...]

Het is wel degelijk mogelijk om Wake On Lan (ondanks de naam) via internet toe te passen.
WOL gebruikt UDP, en standaard is er helemaal geen poort voor een Magic Packet.
Het mág echter wel, en om WOL verkeer in complexere omgevingen (inclusief internet) mogelijk te maken wordt vaak poort 7 of 9 hiervoor misbruikt. (Officieel zijn deze poorten voor respectievelijk Echo en Discard).

Als je op basis van deze info je internetmodem/router configureert kun je wel degelijk wollen over internet.

Het lukt nieteens over een vpn, alle poorten open ...

Ik probeer even te begrijpen wat de impact van een aanval van binnenuit is. Ik zie vaak dat (virtuele) servers in een netwerk vaak bereikbaar zijn voor interne clients en RDP wordt op die servers door admins vaak gebruikt als management tool. Ook heb ik vaak gezien dat admins niet altijd netjes uitloggen waardoor er vaak RDP sessies open blijven staan. Betekent dit dat het mogelijk is door interne clients om een sessie van een admin op een server over te nemen?

Een network hickup is vanaf de serverkant zeer onwaarschijnlijk. Vanaf de client kant echter wel.

[Reactie gewijzigd door Hoicks op 5 juni 2019 15:45]

Alleen als de aanvaller toegang tot het werkstation van die admin heeft. Je kan niet op afstand een sessie kapen of zo.

@RGAT Windows updates staat ingesteld op zelf bijhouden, en dus zo nu en dan als er tijd voor is zelf even naar gezocht dient te worden, op momenten dat mij dat schikt, één keer per week vaak. En wat de Adobe software betreft, ik werk nog met versie SC6 van dit pakket.

[Reactie gewijzigd door SSDtje op 5 juni 2019 16:36]