Citrix wijst beheerders op kritieke PuTTY-kwetsbaarheid in XenCenter
Citrix heeft systeembeheerders op een kritieke kwetsbaarheid in PuTTY gewezen waardoor een aanvaller in een guest virtual machine (VM) de ssh private key van een XenCenter-beheerder kan achterhalen. PuTTY is een populaire ssh-client. Vorige maand verscheen er een beveiligingsupdate voor een kwetsbaarheid in de software, aangeduid als CVE-2024-31497. Via het beveiligingslek is het mogelijk om bepaalde ssh private keys te stelen.
In een beveiligingsbulletin laat Citrix weten dat versies van XenCenter for Citrix Hypervisor 8.2 CU1 LTSR gebruikmaken van PuTTY voor het opzetten van ssh-verbindingen van XenCenter naar guest VM's. Via XenCenter is het mogelijk om virtual machines uit te rollen, beheren en monitoren. Vanaf XenCenter versie 8.2.6 is PuTTY niet meer in de software aanwezig.
In de versies waar PuTTY nog wel in aanwezig is kan een aanvaller de kwetsbaarheid gebruiken om de private key van de XenCenter-beheerder te achterhalen als die op de guest virtual machine inlogt. Citrix stelt dat organisaties er nu voor kunnen kiezen om PuTTY volledig te verwijderen als ze geen gebruikmaken van de 'Open SSH Console' feature. Beheerders die PuTTY wel willen behouden zullen zelf een nieuwe versie van de ssh-client moeten installeren.
Ik gebruik putty al 25 jaar, heb dankzij putty heel veel geld mogen verdienen, er komt geen reclame op, ze pikken mijn privegegevens niet en ik denk dat ik maximaal één keer per jaar kijk of er misschien een update is. Want zelfs daar krijg je nooit een popup over.
Putty spreek je met U aan, je mag pas wat zeggen als je wat gevraagd wordt, en je gaat achteraf de trap af. Ik heb bijvoorbeeld nu niet eens zin om op te zoeken wat citrix is. Zal wel zo een zakje van unilever zijn om snel kip met curry te maken met citroensmaak.
Ik gebruik putty al 25 jaar, heb dankzij putty heel veel geld mogen verdienen, er komt geen reclame op, ze pikken mijn privegegevens niet en ik denk dat ik maximaal één keer per jaar kijk of er misschien een update is. Want zelfs daar krijg je nooit een popup over.
Putty spreek je met U aan, je mag pas wat zeggen als je wat gevraagd wordt, en je gaat achteraf de trap af. Ik heb bijvoorbeeld nu niet eens zin om op te zoeken wat citrix is. Zal wel zo een zakje van unilever zijn om snel kip met curry te maken met citroensmaak.
Je zou de rest van het artikel kunnen lezen, daar staat duidelijk genoeg bij wat voor product Xen is .
Serieus - "25 jaar putty gebruiken en daar goed je brood mee verdienen" , en dan én geen idee hebben wat Xen/Citrix is (het is echt geen obscuur bedrijf/product" , én het zelfs niet lezen uit de tweede of derde alinea van het artikel waar je op reageert.
Hoofdschuddend.
Zo'n beetje de eerste noodzakelijke skillset in de IT is lezen , of het nu foutmeldingen zijn of man pages...
Dat zijn heel veel dubbele negaties . Bedoel je nou dat ze "allemaal" hun private key op de server zetten, of juist dat niemand dat deed.
Anyway :
Het hangt van je omgeving af, en welke key/credential gebruikt wordt.
Waarom vind je het zo'n goed idee om allerlei infrastructuur acces credentials op de persoonlijke devices van medewerkers te zetten ?
(* het aantal medewerkers in een team dat er bij moet kunnen ).
De access credentials die vcenter gebruikt om de vsphere hosts te managen bijvoorbeeld staan echt op de vcenter server.
(vcenter is de centrale applicatie waarmee je een grootschale vmware omgeving beheers. (vm's aanmaakt, toewijst aan de fysieke servers waarop de hypervisor draait, storage toewijst etc ).
Als je 'mooi' alles vanuit ansible beheert - waar staan de key/credentials waarmee ansible op de beheerde machines toegang krijgt ?
Typisch op de ansible server - er zijn best goede redenen waarom die dingen niet als account 'jan de beheerder' draaien.
Dat beheerder jan de private key van 'jan' op eigen client device (of liefst in een hw token) heeft is vrij gebruikelijk.
Maar het is niet altijd het geval (of altijd handig) dat het account 'jan' ook overal alle rechten heeft (of neemt met sudo) en als 'jan' alle acties doet.
Dat zijn heel veel dubbele negaties . Bedoel je nou dat ze "allemaal" hun private key op de server zetten, of juist dat niemand dat deed.
Anyway :
Het hangt van je omgeving af, en welke key/credential gebruikt wordt.
Waarom vind je het zo'n goed idee om allerlei infrastructuur acces credentials op de persoonlijke devices van medewerkers te zetten ?
(* het aantal medewerkers in een team dat er bij moet kunnen ).
De access credentials die vcenter gebruikt om de vsphere hosts te managen bijvoorbeeld staan echt op de vcenter server.
(vcenter is de centrale applicatie waarmee je een grootschale vmware omgeving beheers. (vm's aanmaakt, toewijst aan de fysieke servers waarop de hypervisor draait, storage toewijst etc ).
Als je 'mooi' alles vanuit ansible beheert - waar staan de key/credentials waarmee ansible op de beheerde machines toegang krijgt ?
Typisch op de ansible server - er zijn best goede redenen waarom die dingen niet als account 'jan de beheerder' draaien.
Dat beheerder jan de private key van 'jan' op eigen client device (of liefst in een hw token) heeft is vrij gebruikelijk.
Maar het is niet altijd het geval (of altijd handig) dat het account 'jan' ook overal alle rechten heeft (of neemt met sudo) en als 'jan' alle acties doet.
Dat vind ik ook oliedom. Je private key met passphrase hoort op je managed laptop (met encrypted disk) en het liefst via een HW token beschikbaar te zijn (windows servers worden vaak gehackt, kan vcenter over meepraten) . Zo gebruik ik ook github via een YubiKey. De gedeelde private key van de ansible user met sudo rechten plaats je zo wie zo niet op een windows werkplek. Is hier verboden.
Dat zijn heel veel dubbele negaties . Bedoel je nou dat ze "allemaal" hun private key op de server zetten, of juist dat niemand dat deed.
Anyway :
Het hangt van je omgeving af, en welke key/credential gebruikt wordt.
Waarom vind je het zo'n goed idee om allerlei infrastructuur acces credentials op de persoonlijke devices van medewerkers te zetten ?
(* het aantal medewerkers in een team dat er bij moet kunnen ).
De access credentials die vcenter gebruikt om de vsphere hosts te managen bijvoorbeeld staan echt op de vcenter server.
(vcenter is de centrale applicatie waarmee je een grootschale vmware omgeving beheers. (vm's aanmaakt, toewijst aan de fysieke servers waarop de hypervisor draait, storage toewijst etc ).
Als je 'mooi' alles vanuit ansible beheert - waar staan de key/credentials waarmee ansible op de beheerde machines toegang krijgt ?
Typisch op de ansible server - er zijn best goede redenen waarom die dingen niet als account 'jan de beheerder' draaien.
Dat beheerder jan de private key van 'jan' op eigen client device (of liefst in een hw token) heeft is vrij gebruikelijk.
Maar het is niet altijd het geval (of altijd handig) dat het account 'jan' ook overal alle rechten heeft (of neemt met sudo) en als 'jan' alle acties doet.
Dat vind ik ook oliedom. Je private key met passphrase hoort op je managed laptop (met encrypted disk) en het liefst via een HW token beschikbaar te zijn (windows servers worden vaak gehackt, kan vcenter over meepraten) . Zo gebruik ik ook github via een YubiKey. De gedeelde private key van de ansible user met sudo rechten plaats je zo wie zo niet op een windows werkplek. Is hier verboden.
Valt het kwartje dat je precies de omstandigheden noemt die ik ook noemde, waarin (beheer/infra) credentials _wel_ op "een" server staan (vcenter, ansible server) , en dat (hooguit) persoonlijke private keys van individuele beheerders op een - hopelijk erg veilige - werkplek staan ?
Met dat concept is niks mis - en ik heb het genoemd als kanttekening bij al die mensen die meteen in de stress gaan als ze lezen "private keys" "op een server" , en duidelijk geen ervaring hebben van de inrichting bij wat grootschaliger beheer situaties, want daarin zijn er vaak accounts (ik noem ze 'infrastructuur account') die het feitelijke werk doen op een beheerde machine, vanaf een dedicated beheer platform, en aangestuurt/afgetrapt worden door een beheerder
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
