Zeker 39 Nederlandse servers zijn geïnfecteerd via oud Citrix-lek ondanks patch

Zeker 25 Nederlandse bedrijven zijn geïnfecteerd via een lek in Citrix. Het gaat om een kwetsbaarheid van eerder dit jaar in de Citrix NetScaler en ADC. Ook bedrijven die het lek al gedicht hebben, zijn geïnfecteerd, stelt beveiligingsbedrijf Fox-IT.

Fox-IT onderzocht servers die kwetsbaar waren voor CVE-2019-19781. Die bug werd eind vorig jaar ontdekt in de Citrix Application Delivery Controller en Citrix Netscaler Gateway. Veel bedrijven en overheidsinstellingen gebruiken de Citrix-software om op afstand werken mogelijk te maken. Hoewel Citrix begin dit jaar een patch uitbracht, besloten veel van die organisaties de software uit voorzorg uit te zetten.

In de periode tussen de ontdekking van het lek en het moment dat organisaties die zijn gaan patchen, hebben aanvallers in veel gevallen misbruik gemaakt van de kwetsbaarheid. Ze hebben daarbij een achterdeur in software gezet waardoor ze nog steeds toegang tot de servers hebben. Dat is dus ook het geval als bedrijven de patch al hebben doorgevoerd. De aanvallers zetten in zo'n geval een webshell op de servers waarop ze op een later moment konden toeslaan. Vaak hebben die webshells geen authenticatie, waardoor ze ook konden worden gebruikt door andere aanvallers, mits die wisten van die shells. Na de infectie wisten de aanvallers de shells zo te verbergen dat het voor systeembeheerders na het installeren van de patch leek alsof er niets aan de hand was.

In sommige gevallen was het niet één crimineel of groep die zo'n achterdeur achterliet, maar verschillende. Fox-IT zag servers waarop wel vier of vijf backdoors stonden. De criminelen konden het lek uitvoeren door een http-request te doen naar een Perl-bestand dat bepaalde functies aanriep. Zo'n bestand moest op de servers staan, maar dat was vaak het geval als systeembeheerders die niet handmatig verwijderden. Vervolgens kon door een tweede http-request een xml-bestand op de machine worden gezet, waarmee code kon worden uitgevoerd op de machine. Met een remote code execution kunnen aanvallers bijvoorbeeld coinminers installeren, wat in het begin veel gebeurde. Later werd het lek ook misbruikt om ransomware te verspreiden.

Fox-IT vond in januari al verschillende exploits van de kwetsbaarheid. Het bedrijf zette honeypots op en ontdekte onder andere dat hackers daar webshells zonder authenticatie op zetten. Fox-IT ontdekte dat er in Nederland 39 servers staan die nog steeds geïnfecteerd zijn. Dat betekent niet dat er ook 39 bedrijven zijn getroffen; sommige bedrijven gebruiken bijvoorbeeld verscheidene servers. Volgens de Volkskrant gaat het om zeker 25 bedrijven, waaronder een farmaceutisch bedrijf en een organisatie voor gehandicaptenzorg. Wereldwijd zouden nog meer dan 3300 servers kwetsbaar zijn. De helft daarvan staat in de Verenigde Staten.

Reacties (84)

[Raymond Deen]

Hmmm, als ik het goed begrijp zijn die Citrix server direct verbonden met internet en staan ze niet achter een firewall die ongewenst verkeer tegen houdt.
Ik heb wel vaker met Citrix gewerkt, maar nog nooit zonder dat ik me had aangemeld op het eigen netwerk van de klant...

[bvdli]

Het gaat hier slechts om de Netscaler appliances, niet de servers waar Citrix XenApp of XenDesktop op draait . Deze Netscaler appliances draaien meestal in een DMZ om op een veilige manier te kunnen verbinden met je Citrix omgeving.

[Raymond Deen]

Van hun eigen site begrijp ik dat Citrix het volgende adviseert: internet <=> firewall <=> adc <=> firewall <=> lan
Dan zorg je ervoor dat er alleen toegestaan verkeer - mits goed ingericht natuurlijk - bij de adc terecht komt.
Tot nu toe heb ik omgevingen gewerkt die niet eens vanaf internet direct te benaderen waren en ze dus de buitenste firewall door een VPN vervangen hadden.
Met een voldoende krachtige VPN kun je behoorlijk wat desktops bedienen, want met een 5Mbps verbinding per cliënt geef je ze al best een redelijke ervaring.
Link: https://docs.citrix.com/e...firewall-environment.html

[Reactie gewijzigd door Raymond Deen op 23 juli 2024 08:08]

[Anoniem: 1322]

Het hele ding van het apparaat is juist dat je er geen omkijken naar hebt. Door een vpn voor de netscaler te plaatsen bouw je juist de ellende op die dit apparaat probeert op te lossen. Zaken zoals goede beheersbaarheid van datastromen worden weer complex en gebruikersgemak is problematisch met vpn clients.

[Raymond Deen]

Vpn != Firewall. Dat terzijde genomen lijkt me dat je met routering de data stromen goed in de hand houdt hoor. Een vpn is in feite gewoon een uitbreiding op je lan, op een apart segment.

[Anoniem: 1322]

Vpn != Firewall.
Er zijn veel manieren om datastromen te tunnelen naar een ander netwerk. Het bekendste voorbeeld is HTTPS. Je kunt argumenteren dat dit geen VPN is maar het principe is hetzelfde, het is niet zo dat je perse een firewall nodig hebt.

Dat terzijde genomen lijkt me dat je met routering de data stromen goed in de hand houdt hoor.
Dat is dus niet zo. Dat probleem zie je al met HTTPS verkeer. Je kunt daar niet inkijken dus kun je deze niet beheren. Hooguit kun je deze blokkeren.
Binnen het Citrix ICA protocol verloopt beeld, audio, randapparatuur en allerlij andere zaken. Een firewall, DPI of VPN apparaat kan hier niet 'in' kijken omdat dit versleuteld is. Je kunt dus deze datastromen niet beheren of zelfs monitoren zonder koppelingen met Citrix. Daarom schaft men een netscaler aan, deze maar deze datastromen beheersbaar.

[Raymond Deen]

Een firewall kan ook nog op andere zaken verkeer tegenhouden of doorlaten dan inhoud hoor, zoals bijvoorbeeld whitelisting van ip-adressen om maar wat te noemen.

Dan nog je argument dat je niet in data kan kijken; dat klopt alleen zolang de data in de tunnel zit. Zodra het niet in de tunnel zit, kun je er prima in kijken zoals je normaal bij DPI ook zou kunnen (dus bij HTTPS nog steeds niet) en kun je dus ook ingrijpen op bandbreedte en dergelijke van bepaalde streams voordat ze de tunnel in gaan. Je kunt het zelfs zo regelen dat bepaald verkeer niet door de tunnel gaat zodat je alleen intranet- en geen internet-verkeer door die tunnel gaat zitten proppen.

[Reactie gewijzigd door Raymond Deen op 23 juli 2024 08:08]

[Anoniem: 1322]

Noem mij eens 1 redelijke organisatie op die ip adressen whitelist? Dat is helemaal niet te doen.. en die mobile werkers onderweg? Die moeten maar even iedere dag bellen om te door te geven welk IP ze hebben? Sorry maar ik neem dit gesprek niet meer serieus. Het principe van ‘overal kunnen werken’ ontgaat je volgens mij.

Tuurlijk kun je allerlei man-in-the-middle oplossingen gaan maken maar dan ben je er nog niet. Noem mij eens 1 firewall op die Citrix data channels kan analyseren of beïnvloeden. En dan ga je weer, complexe oplossingen maken die helemaal niet werkbaar zijn. Een hele Citrix omgeving is al complex om te beheren en te onderhouden. Dan ga je er gewoon nog even een paar complexe apparaten voor zetten. Kost niets allemaal...

[Raymond Deen]

Jammer dat je zo boos wordt.

Ik noemde en voorbeeld maar ik had met zo goed cliënt certificaat kunnen noemen.

En ik kan trouwens echt overal online werken; heb dat zelfs gedaan in de rimboe van Borneo waar ik prima een VPN verbinding naar huis op kon zetten, vervolgens een rdp sessie startte naar een vm op mijn nas die weer een rdp kon opzetten naar een azure workstation machine vm die wat krachtiger was met meer geheugen om daar wat Sitecore solutions op te fixen.
Performde overigens prima op het i3 laptopje met 4GB geheugen

En hoe bedoel je data channels? Ik zie 1 virtual channel in de docs staan en daarvoor maakt een vpn tunnel volgens mij niet zoveel uit...

[Reactie gewijzigd door Raymond Deen op 23 juli 2024 08:08]

[SunnieNL]

Dan nog moet je poort 443 of 80 wel open hebben staan, naast citrix verkeer.
Als je het verhaal van fox-it leest, leer je al snel dat de meeste vulnerabilities de logon/logoff pagina aanpassen zodat de vulnerabilities blijven draaien. Dus degenen die binnenkomen gebruiken ook poort 443 of poort 80. Die extra firewall zou het dus niet tegenhouden in dit geval.

Daarnaast zou de ADC zelf ook als firewall moeten kunnen dienen. Die is ook ingebouwd en wordt meestal ook gebruikt.

[klakkie.57th]

Wel met dat verschil dat 443 misschien ook wel gebruikt wordt voor je VPN, maar wel een ander device is en dus niet vulnerable is voor exploits van je ADC en vice versa.. dat is wat anders dan de firewall die gewoon 443 door-routeert naar je ADC.

ze zeggen het verdorie zelf in hun documentatie.

"In a multiple-firewall environment, the NetScaler appliance is placed between two sets of firewalls, the external set connecting to the public Internet, and the internal set connecting to the internal private network"

Als je dan toch een firwall ervoor plaatst kun je net zo goed VPN activeren zodat enkel je werknemers met het juiste cert/VPN Profiel het ip van je netscaler appliance kunnen bereiken en alle andere traffic gewoon gedropt wordt nog voor ze je netscaler bereiken.
Overkill ? misschien, maar in tijden waar dataloss je een schadeclaim van vele miljoenen kan opleveren, kun je nooit zeker genoeg zijn.

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 08:08]

[Raymond Deen]

Een apparaat dat veel dingen doet ipv 1, doet die vele dingen vaak minder goed dan de losse apparatuur die maar 1 ding kunnen.
Ik ben ook gewoon van mening dat Citrix desktops niet "gewoon" aan het internet moeten hangen, want vaak kun je via die dingen dan weer makkelijk verder het netwerk in.

[SunnieNL]

De desktops hangen ook niet gewoon aan het internet.
Daar zit dus die ADC tussen. Die zorgt voor een secure channel richting die desktops.
Die handelt al het valse verkeer af en zorgt voor authenticatie.

Om niet verder in het netwerk te kunnen staat hij in de DMZ. Als die conpromised is, kom je niet zomaar op het interne netwerk, tenzij je het encrypte verkeer naar de citrix servers binnen weet te komen (of je dmz firewall niet goed ingesteld hebt)

[Reactie gewijzigd door SunnieNL op 23 juli 2024 08:08]

[Taghorn]

Performance/Security/Kosten baten keuze. Alle verkeer via de klant laten gaan via een VPN betekent dat je een flink grotere pijp nodig hebt bij de klant (thuis=>klant=>citrix, dus up&down) & de latency gaat omhoog. Rechtstreeks vanuit huis=>citrix scheelt weer een hop.
Zeker met een remote desktop voor veel medewerkers naar een fijn 4K scherm slurpt het best wel bandbreedte. Kun je weer dichttimmeren door alleen RDP rechtstreeks toe te staan en de rest via een VPN af te dwingen, maar dat is weer lastiger = €€€.

[Blokker_1999]

Een VPN voegt niet veel overhead toe, maar kan overkill en soms zelfs onwenselijk zijn. Waarom heel de PC in je eigen netwerk brengen met een VPN wanneer je enkel maar remote desktop wil mogelijk maken op die PC?

[klakkie.57th]

Security ?!

[Anoniem: 1322]

Een Remote Desktop oplossing zoals Citrix gebruikt dezelfde encryptie als je VPN tunnel (het is een soort van micro vpn) dus daar ga je geen terrein winnen. De nadelen van een VPN tunnel zijn echter groot, zo zijn de datastromen (beeld, audio en randapparatuur) niet meer zo eenvoudig te beheren wanneer het over een vpn tunnel verloopt (dat zul je dan allemaal via je firewall gaan regelen die niets van die datastromen snapt).

[klakkie.57th]

Maar je endpoint staat in het dat gevall wel op het internet , wanneer je eerst vpn moet opbouwen van op een trusted device is dat niet nodig. Als je VPN eeb full tunnel is is er toch niet meer beheer ?? ofwel snap ik je opmerking niet.

Het gaat hem ook niet over het type encryptie, wel over verschillende devices combineren om zo de attack-vector te verkleinen/divercifiëren.
zie ook deopmerking van @Raymond Deen hieronder

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 08:08]

[Anoniem: 1322]

Het is same, same gezien de netscaler gewoon een ssl (vpn) tunnel opbouwt van cliënt naar endpoint.
Alleen bij een netscaler (of gelijke oplossing) heb je geen omkijken naar al die vpn problemen met de cliënt.

Website benaderen -> inloggen -> aan het werk op de werkplek van de zaak.

[Reactie gewijzigd door Anoniem: 1322 op 23 juli 2024 08:08]

[klakkie.57th]

dan heb je enkel de ssl vervinding tussen je remote laptop en de netscaler? anders heb je eerst een vpn verbinding met device merk x (cisco, Palo Alto) en vervolgens een ssl verbinding met je netscaler.
Is je VPN vulnerable dan is je netscaler nog altijd safe en omgekeerd.


net zoals @Raymond Deen het hieronder beschrijft:
internet <=> firewall <=> adc <=> firewall <=> lan en dan beide firewalls nog van een verschillend merk..

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 08:08]

[Anoniem: 1322]

dan heb je enkel de ssl verbinding tussen je remote laptop en de netscaler?
Ja

Is je VPN vulnerable dan is je netscaler nog altijd safe en omgekeerd.
We gaan in rondjes, je koopt een netscaler om van al die VPN problemen en complexiteit af te zijn. 1 website voor toegang tot je werkplek.

Als je daarna er nog een VPN voor gaat zetten snap je het concept niet. De gebruiker ziet namelijk niets van al die complexe IT, men gaat naar een website, logt in en opent al zijn werkapps of werkplek. Meer is het niet en voor een gebruiker moet het ook niet anders zijn.

Dit is niet alleen Citrix die zo werkt, ook VMware en Microsoft's oplossingen werken hetzelfde. Als je meer apparaten ertussen gaat zetten dan komt een gebruiker er niet meer uit. Die moet eerst een VPN client installeren, daarna de VPN client configureren, daarna connectie maken, daarna naar een webinterface, nogmaals inloggen, verbinding maken met de werkplek en alles weer afsluiten als hij klaar is. En dat is nog maar de complexiteit voor de gebruiker, de beheerder en helpdesk krijgen het extreem complex.

[klakkie.57th]

welke complexiteit heeft een eingebruiker nu met vpn ?
Je start je laptop op en automatisch start de vpn ...vpn client installeren ...die staat standaard op je laptop van je bedrijf geinstalleerd en geconfigureerd door de helpdesk / IT afdeling
Het zijn niet bepaald particulieren die citrix gebruiken.


In het huidge klimaat wordt het dringend tijd dat security terug met stip op nr 1 komt.

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 08:08]

[Anoniem: 1322]

Je start je laptop op en automatisch start de vpn
Niet iedereen heeft een laptop (van de zaak). De meeste mensen werken vanuit huis vanaf een eigen PC waar niets op geïnstalleerd is.

die staat standaard op je laptop van je bedrijf geïnstalleerd en geconfigureerd door de helpdesk / IT afdeling
Dit kost tijd, geld en moeite van de helpdesk / IT afdeling. Citrix heeft dit niet nodig.

Het zijn niet bepaald particulieren die citrix gebruiken.
Het zijn mensen met 0 IT kennis die thuis moeten werken. Daarvoor schaf je dit apparaat aan.
Ik denk dat je eens mee moet kijken met iemand die het gebruikt, dan snap je het denk ik wel.

In het huidige klimaat wordt het dringend tijd dat security terug met stip op nr 1 komt.
UIteraard, maar zoals aangegeven is dit probleem voornamelijk gekomen door het gebrek aan actie bij Citrix. Als zij hun werk beter hadden gedaan en goed gereageerd hadden was dit geen nieuws geweest.

[Raymond Deen]

Deze pc is dan een door de organisatie beheerde machine tenzij het een bring your own device organisatie is en zit normaal ook op het netwerk, maar dan fysiek op kantoor.
Op die manier werken al je netwerk koppelingen en intranet precies hetzelfde, net als de Citrix omgeving waardoor de infra afdeling niet twee verschillende situaties hoeft in te richten.
Daarbij is een VPN verbinding in een vloek en een zucht geïnstalleerd en opgezet dus dat is ook geen reden om het niet te doen.

[mutsje]

Daar zijn deze gateways voor bedoeld om rechtstreeks op het internet te staan. De netscaler is tegenhanger van een Big IP F5. Die machines handelen het verkeer af en doen ssl ofloading etc. Het zijn ook geen servers zoals Tweakers aangeeft maar appliances.

[Mr.Monk]

Ik zou die bedrijven na een half jaar wel aan de schandpaal hangen. Ontwetende klanten van die bedrijven weten wellicht niet dat hun IT- boer compromised is, en moeten daar zo snel mogelijk weg.

[wildhagen]

Moet het bedrijf in kwestie wel weten dat ze gecompromitteerd zijn. Dit valt lang niet altijd op namelijk, zeker niet als er gebruik gemaakt wordt van rootkits etc, waardoor de malware verborgen is voor het systeem. Als zo'n hacker dan geen enorme hoeveelheden verkeer veroorzaakt, of hoge CPU-load etc, valt het lang niet meteen op.

Schandpaal lijkt me dus een beetje kort door de bocht.

Enige wat je ze eventueel (deels) zou kunnen verwijten is dat men destijds hun Netscalers wellicht niet snel genoeg uitgeschakeld hebben, of voorzien van de mitigation-stappen.

[F0nn3kke]

Ik vind ook niet dat je het (alleen) bij de "IT-Boer" mag leggen, kans is ook gewoon aanwezig dat de klant de opdracht geeft om iets wel of niet te doen. Met wat voor een slimme / onverstandige reden dan ook. Ik kan me voorstellen dat kosten of workload of bedrijfsbereikbaarheid hier ook een grote rol in spelen.

Enige wat je ze eventueel (deels) zou kunnen verwijten is dat men destijds hun Netscalers wellicht niet snel genoeg uitgeschakeld hebben, of voorzien van de mitigation-stappen.

Daar hebben wel veel partijen heel lang mee gewacht, en dat mag wel worden besproken vind ik. Maar ik vind aan een schandpaal knopen (Zoals jij zelf ook al aangeeft) wel kort door de bocht.

[Frituurman]

Daar zit wel wat in, maar in dit geval gaat het om het feit dat kwaadwillenden zelf een backdoor hebben aangemaakt. Dan kun je als IT-boer of klant wel denken dat je veilig bent, want alles is gepatched, maar dat is dus niet automagisch zo. Bij ons werd vrij rigoureus heel Citrix gewoon uitgezet. Er kon gewoon een aantal dagen niet worden gewerkt (behalve dan overleggen e.d.) totdat alles waar nodig was gepatched, vervangen, etc. Fox-IT heeft in elk geval bij de laatste controle geen bewijs gevonden van een infectie bij onze servers, dus er is bij ons wel tijdig gehandeld. Gelukkig maar, want sinds maart moet er eigenlijk onbeperkt thuisgewerkt worden.

[K-aroq]

De luxe dat je een systeem voor een paar dagen plat kunt leggen heb je niet altijd. Er zijn ook nog andere belangen waar een bedrijf mee te maken heeft. Stel je voor dat je aan een grote tender werkt en even aangeeft aan de potentiele klant "we zijn een week later met onze offerte, kan zeker wel". Dan lig je er in de meeste gevallen toch echt uit.

[rob12424]

Ligt eraan welke afwegingen je maakt. Ik weet dat bij ons Citrix een paar dagen niet gebruikt mocht worden. Dit heeft miljoenen gekost. Alle sequencing data enz. Konden niet naar supercomputers gestuurd worden en visa/versa of van de sequencers. Dit moest met harde schijven enz. Opgelost worden. Maar heb wel eens gehoord dat 1 simpele run 18 TB kon bevatten.

Maar uiteindelijk wat doe je? Lig je er langer uit. Je wordt gehacked voor ransom, of je data wordt gestolen. Dat kost zeker weten meer. (Even een disclaimer: een prijs hangen aan wetenschappelijke data is eigenlijk niet te doen)

[mkools24]

Zelf heb ik eerst de mitigatie uitgevoerd en toen de patch beschikbaar was de Netscalers volledig opnieuw geinstalleerd. Dat is de enige juiste manier om zeker te weten dat er geen achterdeurtje is.

[tERRiON]

Een puntje om dan niet te vergeten: Wachtwoorden aanpassen en certificaten revoken.

[DefaultError]

Volgens mij kun je gecompromitteerde remote desktop systemen ook weer achter een beveiligde muur plaatsen. Er zijn toch middelen legio om dit voor elkaar te maken.

[kodak]

Niet weten of je gecompromitteerd bent en dan de software maar (blijven) gebruiken klinkt niet verstandig. Het lijkt zo ernstig dat je dan wel heel zeker moet zijn dat het je niets ernstigs kan zijn overkomen, of liever risico loopt vergeleken met de situatie als het achteraf wel mis blijkt te zijn, of gewoon niet weet hoe ernstig het is en dus je beveiliging niet heel professioneel hebt ingericht.

Ik kan geen goede redenen bedenken om risico te nemen met enkel patchen van een bestaand systeem of helemaal niet patchen, anders dan geen belangrijke gegevens verwerken of dat het eigenlijk geen gecompromitteerd systeem is maar iets wat er op lijkt.

[tERRiON]

Na de infectie wisten de aanvallers de shells zo te verbergen dat het voor systeembeheerders na het installeren van de patch leek aslof alsof er niets aan de hand was.

Ik heb in januari onze netscaler onderzocht nadat bleek dat we lek waren. Ook wij hadden toen al bezoek van ongenode gasten gehad. Op dat moment had ik nog geen goede 'handleiding' voor handen hoe je op onderzoek uit moest gaan maar ondanks mijn beperkte ervaring met netscalers was de shell was in een paar minuten gevonden. Ik vond enkele directories waarvan een zeer recente modificatiedatum onlogisch was, dus dat was een eerste alarmbel. En een proces dat vanuit een tempdirectory draait is ook een red flag.

[kodak]

Hoe je op zoek kan gaan als je het niet weet lijkt me simpel: zorg dat je bij problemen iemand kan inzetten die er wel verstand van heeft. Zelf gaan oplossen is leuk als er niet zoveel kwaad kan maar niet heel professioneel als je bijvoorbeeld gegevens van klanten moet beschermen.

[Anoniem: 1322]

Dat is makkelijker gezegd dan gedaan in dit geval.. de response van Citrix was bedroevend en zelfs collega netscaler ‘experts’ wisten eigenlijk niet echt waar ze naar moesten kijken.

Het punt is dat dit een erg niche product is en het ook nog eens niet echt een ‘Citrix’ product is. Het is namelijk een netwerk appliance waar de meeste Citrix specialisten geen kaas van hebben gegeten.

Combineer dat nog eens met schijtclubs die je niet eens te woord willen staan tot je maar eerst een (wurg) support contract hebt ondertekend (kuch, Securelink, kuch) en dan ben je soms beter af om zelf met gezond verstand actie te ondernemen. Dus @tERRiON , goed gedaan!

[kodak]

Natuurlijk is het goed om een poging te doen als er geen alternatief is. Alleen is het te kort door de bocht om alleen te kijken of je het zelf kan oplossen. Zeker als je zelf eigenlijk geen kennis hebt hoe je dat kan doen. En dat lees ik een beetje in die reactie. Er was geen handleiding om het te controleren is niet de enige weg om dit te voorkomen of te controleren. Daarnaast vraag ik me af hoe goed een bedrijf voorbereiding heeft getroffen als je als bedrijf meent afhankelijk te zijn van handleidingen en zelf doen. Het is heel normaal dat dit soort beveiligingsproblemen kunnen gebeuren en dan wil je niet afhankelijk zijn van een handleiding of zelf maar doen als je niet goed weet hoe het moet. Tegen brand neem je als bedrijf toch ook vooraf maatregelen en ga je niet kijken of er een handleiding is om tijdens de brand te lezen hoe je daarmee om gaat? Mag ik hopen. Dus ik weet niet of dit echt wel goed gedaan is als ik niet lees hoe goed iemand voorbereid zou zijn.

[Anoniem: 1322]

Zoals aangegeven zijn dit complexe apparaten. De meeste consultants die ik er mee zie werken hebben een cursus gehad maar hebben echt geen diepgaande kennis van het apparaat. Het zijn Citrix consultants en ze hebben kennis van desktops, Windows en gebruikers zaken (de zogenaamde front-end). Dit is een netwerk apparaat en daarom wordt je tijdens support vragen heen en weer gegooit tussen netwerk consultants (kijk mij niet aan, het is een Citrix ding) en Citrix consultants (kijk mij niet aan, het is een netwerk ding).

Het hele apparaat is ook een appliance die behoorlijk dichtgetimmert is en Citrix wil helemaal niet dat je te diep in het apparaat gaat kijken. Daarom is het ook een grote faal van Citrix geweest die dit zo lang heeft door kunnen laten gaan.
Er was rook maar Citrix gaf niet aan dat er daarmee ook mogelijk brand was. Ze zeiden dat je moest wachten op de patch, niet dat de apparaten afgesloten moesten worden. Zelfs toen klanten gehacked werden kwam citrix maar niet met duidelijke communicatie en adviezen. Toen besloten de meeste klanten zelf maar de boel af te sluiten (zij die slim waren) en andere klanten besloten gewoon door te draaien. Zo te zien minimaal 39 Nederlandse klanten.

Het is inderdaad normaal dat er security problemen uitkomen maar niet normaal als dit gebeurd en deze worden al actief uitgebuit terwijl je leverancier niet communiceert. Ik denk dat je de wereld iets te rooskleurig ziet als je denkt dat organisaties een procedure hebben voor deze situatie.

[kodak]

Ik snap je argumenten als je een standpunt inneemt dat je je afhankelijk stelt van een leverancier of consultants. Maar zo niets verplicht een koper om zich zo afhankelijk op te stellen terwijl de koper vaak wel verplichtingen en verantwoordelijkheden heeft die verder gaan dan een fabrikant of consultant kan of wil leveren. Het lijkt mij geen verstandige houding om daar pas op het moment dat het mis gaat rekening mee te gaan houden. Daar is niets te rooskleurigs aan.

[Lieftalig]

Heftig, maar komen dit dagelijks tegen. Waarschijnlijk zijn er veel meer bedrijven en organisaties slachtoffer, maar weten ze dit pas als er wat heftigs gebeurd of als een specialist wordt ingeschakeld.

[zenlord]

... weten ze dit pas als er wat heftigs gebeurd of als een specialist wordt ingeschakeld.

Inderdaad - en een specialist wordt veelal pas ingeschakeld als er wat heftigs is gebeurd...

[densoN]

Zijn er n.a.v. deze bevindingen nieuwe forensic artifacts waar we naar kunnen zoeken? Of zijn de adviezen uit het verleden nog steeds actueel?

[tERRiON]

Uit mijn hoofd:
crontab -l -u nobody
ps aux |grep nobody
cat /var/log/notice.log|grep nobody
zcat /var/log/notice*.gz|grep nobody

Ervan uitgaande dat ze geen privilege escalation bug gevonden hebben, zou dit nog steeds een goed startpunt moeten zijn.

[aikebah]

Uit mijn hoofd:
cat /var/log/notice.log|grep nobody
zcat /var/log/notice*.gz|grep nobody

waarom niet meteen zgrep de file-io laten doen en 1 commando besparen?
zgrep nobody /var/log/notice*
doet volgens mij, er vanuitgaand dat er alleen notice.log en notice*.gz files staan, hetzelfde met een commando minder (of is die niet beschikbaar op de appliances?)

[kodak]

Daarom schrijf je de logbestanden ook direct naar een andere locatie waar iemand bij privilege escalation niet bij kan? Dan heb je tenminste meer dan niets of iets wat je niet meer kan vertrouwen.

[dezejongeman]

het artikel geeft aan dat het om een kwetsbaarheid van eerder dit jaar gaat. echter gaat het om het lek uit december vorig jaar. daarnaast geeft de laatste zin aan dat er 3300 kwetsbaar zijn. de tabel eronder geeft aan dat het niet gaat om systemen die kwetsbaar zijn, maar zijn gecomprimeerd ofwel gehackt dus.

om het artikel tweakers waardig te maken zou ik ook graag in het artikel zien hoe wij zelf kunnen controlleren of wij tweakers bij 1 van die bedrijven werken. ik bedoel daarmee zelf check of we dat XML op de server hebben staan bijvoorbeeld.

[SunnieNL]

Hoe je het kan controleren staat toch ook in het artikel? Wat ik begrijp is dat Citrix een controle script heeft. Echter, denk ik dat het gewoon het veiligst is een herinstallatie uit te voeren.

Overigens bleek in het artikel dat het gaat om nog niet gepatchte systemen en systemen die wel gepatched zijn maar nog vulnerable zijn omdat ze eerder gehacked waren dan de patch werd geïnstalleerd.

[dezejongeman]

In het artikel staat een link naar citrix waar je kunt controlleren of jou adc kwetsbaar is of voor het lek. Echter het issue wat Fox IT aanstipt is dat er op de ADC's is gebroken voordat deze gepatched zijn/waren en na de patch nog steeds gehacked zijn omdat de aanvallers een backdoor hebben zodat ze nog van alles uit kunnen vreten op de ADC. het is natuurlijk als lezer dat in het artikel een aantal controle slagen aangehaald worden waarmee je kunt controleren of jou ADC een backdoor geïnstalleerd heeft gekregen. natuurlijk kan ik daar zelf ook naar zoeken, maar als je door dit artikel hierop getriggered wordt is het fijn om een startpunt te hebben.

[SunnieNL]

hierbij dan.. 3 seconde op google...

https://github.com/citrix/ioc-scanner-CVE-2019-19781/

Let erop dat deze mogelijk niet alle backdoors herkent. De enige echte goede manier om 100% zeker te zijn dat je geen backdoors hebt is een volledige factory reset na de patch te hebben geinstalleerd. Daarna opnieuw configureren of een backup config van voor december 2019 terug zetten.

Meer info over de tool staat hier: https://www.citrix.com/bl...-tool-for-cve-2019-19781/

En bij mogelijke compromise of om zeker te weten dat je niet gehacked bent staat de uitleg wat je moet doen hier: https://english.ncsc.nl/l...en-citrix-gateway-servers en bestaat oa uit:
* Citrix systems store private TLS keys, which should also be considered compromised. In that case, it is necessary to issue new TLS certificates, and to revoke the compromised certificates.
* Keep in mind that passwords that are stored on the Citrix systems are also compromised, and should therefore be changed.
* (en een stap verder dan alleen ADC herinstallatie, dus zou dat alleen doen als je 100% zeker bent van problemen): As far as possible, use new hardware components and an entirely new installation of the software. If you only update compromised systems, the risk remains that intruders have not completely been removed.

[Het.Draakje]

Je begrijpt dat Tweakers die informatie (welke bedrijven) niet heeft? Dat heeft alleen Fox-it (die niet aan naming en shaming wil doen; zij willen hun naam promoten met dit onderzoek, en gaan dit ook niet aan Tweakers overhandigen).

Je begrijpt dat die XML pas aan het eind van de aanval op je server gezet wordt? En dat dit een van de manieren was waarop een aanval uitgevoerd kon worden? (De techniek zal ongeveer gelijk zijn, maar de namen kunnen uiteraard per aanvaller verschillen). Dus even een find op bestandsnaam gaat je niet helpen.

Dan zijn er in principe twee mogelijkheden: je kan zelf valideren (want je hebt de technische kennis) dat je niet gecomprimeerd bent. De tweede mogelijkheid is er een vakman/vrouw bij te halen die wel de kennis in huis heeft. Uiteraard kan je ook nog Fox-it benaderen, ze willen je graag (voor een fee) helpen. Op zijn minst verkopen ze je een scan van je services/servers (zelfs als ze die al eerder in hun onderzoek tegengekomen zijn).

Je kunt het zekere voor het onzekere nemen en ervan uitgaan dat je wel besmet bent en de boel 'even' opnieuw installeren. En vervolgens heb je toch nog een vakman/vrouw nodig om het systeem te beheren, want niets is zo schadelijk als een service/systeem aan het internet waarbij de beheerder onvoldoende kennis heeft. Zeker bij dit soort systemen.

[tERRiON]

om het artikel tweakers waardig te maken zou ik ook graag in het artikel zien hoe wij zelf kunnen controlleren of wij tweakers bij 1 van die bedrijven werken. ik bedoel daarmee zelf check of we dat XML op de server hebben staan bijvoorbeeld.

Een goed beginpunt van je zoektocht:
crontab -l -u nobody
ps aux |grep nobody
cat /var/log/notice.log|grep nobody
zcat /var/log/notice*.gz|grep nobody

Verder zijn er online wel handleidingen te vinden die ook goede handvatten geven. Ik heb de link alleen even niet voor handen.

[dezejongeman]

dit is waar ik op doelde en een link of dergelijke naar zoiets in het artikel had wat mij betreft een welkome aanvulling geweest.

[basix]

Bijzonder om te lezen dat er blijkbaar heel wat organisaties alleen vertrouwd hebben op het doorvoeren vand de patch terwijl men wist dat het risico van een nieuwe besmetting in de periode tussen melding van CVE en uitkomen patch mogelijk was. Dan ga je toch niet alleen maar de patch doorvoeren maar de omgeving opnieuw inrichten op basis van een clean install met nieuwe patch. Beetje naief en gemakzuchtig van deze bedrijven.

[F0nn3kke]

Er zit hier natuurlijk ook een financieel plaatje aan vast. ik ben het wel met je eens maar als je als bedrijf geen budget hebt om dit te doen. Maar (hoe veilig of goed dan ook) je met die patch wel kunt werken en geld kunt maken. Dan zal er snel een keuze gemaakt zijn.

En dan blijft de discussie of dat verstandig is natuurlijk leven. Maar ik snap dat wel.

[Taghorn]

Een clean install betekent bij een hoop organisaties een hoop handwerk, helaas is lang niet alles geautomatiseerd => klik deploy. Dat betekent down-time of weekend werk (en downtime in weekend). Kost weer €€€.

Ga je dit doen voor elke security patch die opgeleverd word? Niet elke komt zo groot in het nieuws, maar reken elke maand maar op een patch ronde.

[K-aroq]

Dat is inderdaad praktisch onuitvoerbaar om bij iedere patch downtime te hebben. Dat heeft enorm veel impact op de bedrijfsvoering. Er zijn vrijwel nooit momenten te vinden dat je een tijdslot kunt vinden dat voor alle afdelingen prima is om downtime te hebben.

[SunnieNL]

Bij iedere patch is ook onzin, maar bij deze was het wel zinvol geweest.
Aan de andere kant heb je een backup van je config. Als die van voor december was (zo vaak wordt de config van een netscaler niet veranderd) is het een kwestie van patch installeren, reset naar factory default en inlezen van de backup.

[caspar M]

De titel van dit artikel is wel erg misleidend of "clickbait"

Het is namelijk niet "ondanks" de patch... de patch werkt... maar de remote shells zijn aangebracht voor de betreffende patch.

[0xygen500]

Zou je niet verwachten dat als iets gepatched is, de malware niet meer kan communiceren via de oude route, omdat dit gepatched is?

[caspar M]

Nee in dit geval zijn de geplaatste remote shells / malware geheel andere / nieuwe software die toegang verschaffen. Die maken dus geen gebruik van de eerder gebruikte methode die de patch van Citrix verholpen heeft.

Als ik een deur van een woning forceer, en vervolgens wat ramen openzet en later via die ramen terug de woning binnen kom, dan ga je toch ook niet de slotenmaker aanklagen die een nieuw slot heeft gezet (op de deur)?

Dat je als bewoner dan niet had opgemerkt dat er ramen openstonden.... dat is dan je eigen schuld

[Reactie gewijzigd door caspar M op 23 juli 2024 08:08]

[Anoniem: 1322]

Beetje te kort door de bocht, Citrix had gewoon een aanbeveling er uit moeten doen dat de beste oplossing is om de appliance (gepatched en wel) volledig opnieuw uit te rollen. Dat is de standaard en enige goede aanbeveling bij iedere hack.

Ik ken genoeg bedrijven die gewoon door zijn blijven draaien en het 'wel in de gaten hielden'. Later patch er op en gewoon doordraaien. Ook veel bedrijven draaiden een script wat ze 100% vertrouwden dat hun appliance 'not compromised' stempelde en zijn gewoon met het apparaat door blijven draaien.

Als je binnen bent geweest is moet je het apparaat als verloren beschouwen. Alleen dat kost tijd en geld.
Ik heb persoonlijk geen medelijden met Citrix of de organisaties die geen acties hebben genomen. Ze leren er hopelijk (nog) van.

[0xygen500]

Helder. Tsja dat is de verantwoordelijkheid van de ict afdeling lijkt mij.

[Cergorach]

In theorie is dat zo, echter is het meest veilige wat @mkools24 aangeeft, compleet nieuwe installatie. Hell, gezien de issues met CPUs zou men zelfs de virtualisatie laag eronder in kunnen zijn gekomen, wellicht zelfs de firmware... Dus hele server(farm) vervangen?

Daarnaast als een ICT afdeling een hele nieuwe Citrix omgeving moet bouwen, zal daar capaciteit voor moeten zijn. Zowel op de servers, licenties, uren. Want als je x doet kost dat tijd, waardoor je y niet kan doen. Wellicht zelfs externe inhuren hiervoor. ICT afdelingen hebben over het algemeen voldoende capaciteit om bepaalde noodsituaties op te vangen, vaak niet om een hele omgeving opnieuw op te bouwen.

Daarnaast staat er in contracten met leveranciers van ICT diensten, waar je mogelijk je omgeving afneemt, dat zij niet verantwoordelijk kunnen worden gehouden voor externe factoren. Zoals bv. bugs in software (gemaakt door derden) die misbruikt kunnen worden, vaak valt dat fixen ook buiten het contract. In dit geval werd het al in het wild gebruikt voordat er melding van werd gemaakt. Zelfs als de leverancier toen de server al had uitgezet was dit mogelijk al te laat. Voor alle fixes/workarounds moet de klant vaak betalen en als die dat niet wil, maar nog wel van de server gebruik wil maken, dan moet je stevig in je schoenen staan (contractueel) om die servers weer aan te zetten zonder fixes/workarounds... Aangezien je anders voor contractbreuk kan worden aangeklaagd. Het ligt er maar net aan wat voor contract er is, wie welke verplichtingen heeft en wat er wel/niet onder de afgenomen dienst valt.

[bvdli]

Het gaat hier slechts om de Netscaler appliance, niet de hele Citrix omgeving.
Heeft dan ook niets met je servers te maken.

In principe draait de Netscaler niet op een virtualisatielaag zoals hier verder wordt gesuggereerd.

[Cergorach]

Gaat wel effe verder dan je aangeeft:

A vulnerability has been identified in Citrix Application Delivery Controller (ADC) formerly known as NetScaler ADC and Citrix Gateway formerly known as NetScaler Gateway that, if exploited, could allow an unauthenticated attacker to perform arbitrary code execution.

The scope of this vulnerability includes Citrix ADC and Citrix Gateway Virtual Appliances (VPX) hosted on any of Citrix Hypervisor (formerly XenServer), ESX, Hyper-V, KVM, Azure, AWS, GCP or on a Citrix ADC Service Delivery Appliance (SDX).

Further investigation by Citrix has shown that this issue also affects certain deployments of Citrix SD-WAN, specifically Citrix SD-WAN WANOP edition. Citrix SD-WAN WANOP edition packages Citrix ADC as a load balancer thus resulting in the affected status.

De impact ligt geheel aan hoe iets is ingericht en hoe het wordt gebruikt.

[m.z]

Is het niet beter vergelijkbaar door te zeggen(?):

Een inbreker is eerder bij je langs geweest en heeft een raam opengezet, omdat hij weet dat de voordeur straks wordt voorzien van een dievenslot (patch)?

Gezien dat de patch (dievenslot) is geïnstalleerd, weet de inbreker via dat raampje naar binnen te komen.

[Reactie gewijzigd door m.z op 23 juli 2024 08:08]

[pica]

Nee, lek geeft algemene toegang tot server, er wordt vervolgens wat op de server geïnstalleerd.
Dan kan je de deur dichtmikken, maar de software blijft gewoon geïnstalleerd.

[bvdli]

Het gaat hier om de Netscaler appliance(s), niet om servers. Deze appliance wordt normaal gezien in een DMZ geplaatst in tegenstelling tot Citrix XenApp servers of XenDesktop systemen

[cosmo_roel]

jawel, en dat is dus ook zo. de oude route kan niet meer gebruikt worden na de patch. maar vóór de patch is een _nieuwe_ route aangelegd in de vorm van een webshell.

[Pinkys Brain]

Als de server eenmaal geroot is helpt alleen volledig nieuwe installatie, of als je echt paranoïde bent ook de hardware vervangen ... want bios en firmware update mechanismes vallen vaak ook niet te vertrouwen.

[Keypunchie]

Als je het slot op je voordeur vervangt, houd dat een inbreker die je ramen aan de achterkant heeft opengezet niet meer tegen.

Oh @caspar M heeft dit al gezegd en nog beter verwoord dan ik ook.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 08:08]

[Chinco]

Het is wel degelijk een goede kop. Er zullen beheerders zijn die denken veilig te zijn *omdat* ze de patch geïnstalleerd hebben. Die hebben deze waarschuwing juist nodig.

Vanuit de patch gezien heb je gelijk, vanuit beheerdersoogpunt niet.

[Freakie1NL]

En dan te bedenken dat universiteiten tegenwoordig video spyware verplichtingen om tentamens te maken. Misschien niet helemaal gerelateerd maar in relatie tot dit artikel wederom aangetoond dat je nooit kan vertrouwen dat iets 100% dicht zit. Daarom zullen vast binnenkort de eerste thuis beelden van studenten te zien zijn. Dat een rechter de UVA daarom in het gelijk heeft gesteld laat zien wat voor een gebrek aan IT risico inschatting er bestaan.

[Anoniem: 310408]

Daarom zullen vast binnenkort de eerste thuis beelden van studenten te zien zijn. Dat een rechter de UVA daarom in het gelijk heeft gesteld laat zien wat voor een gebrek aan IT risico inschatting er bestaan.

Zullen we daar dan maar even op wachten voor je grote uitspraken doet?

[Freakie1NL]

Zo een grote uitspraak is dat toch niet? Is m.i. een zeer reëel risico.

[theduke1989]

Ik vindt het altijd nog frappant dat we afhankelijk zijn van 3de partijen en hun servers bij Citrix wanneer je over hardware/software tokens praat.

Want die maakt verbinding met de token-boer en dan pas kan je ''veilig-verbinden' we hebben al enkele keren last gehad dat de token boer zijn ctx access op orde had, en we dus zomaar enkele uur niet online konden. Je wilt vaak je eigen omgeving zo goed mogelijk hebben. maar als 3de partijen zelf ook niet meewerken is het zo lek als een mandje.

[wildhagen]

Die hoef je echt niet per se bij 3e partijen te hosten hoor, in ieder geval bij Safenet weet ik dat je namelijk ook gewoon de token-appliance lokaal in je eigen netwerk kunt hosten. Dat is bij ons namelijk het geval.

Wellicht dat het bij andere tokenproducenten anders is, dat weet ik niet. Maar Safenet is dus lokaal te hosten (maar het kán ook op het Internet ja, maar dat hoeft dus niet).

Bij Citrix wordt helemaal niks gehost. Het gaat hier om een lek in de Netscaler, dat zijn appliances (of VPX-en) die je gewoon in je eigen netwerk/datacenter host, dat draait niet bij Citrix. Net zoals de VDA (of dat nu servers of VDI-desktops zijn), die ook gewoon lokaal in je eigen omgeving staat.

[theduke1989]

klopt, het ging mij er om dat we tokenboer hebben waarbij de tokens via 3de partij gaan. Zodra hij down is, je zelf ook niet meer op je VDI's kan. Of je moet de token uitschakelen voor een tijd zodat je medewerkers wel online kunnen vanuit home office. Ik zal dit aankaarten waarom we geen in-house hebben genomen of het puur met geld te maken heeft of niet, want in principe is het niks anders dan een string doorsturen naar de server die het goedkeurt, dit zou voordelig moeten zijn.