Meeste Nederlandse ministeries hebben Citrix-servers uitgezet

De meeste Nederlandse ministeries blijken Citrix-servers te hebben uitgezet na een recent ontdekte kwetsbaarheid in de systemen. Eerder bleek al dat de Tweede Kamer en verscheidene gemeenten hun systemen hadden uitgezet.

Dat meldt het AD, nadat de krant navraag heeft gedaan bij de ministeries. Van de twaalf ministeries wilden er drie niet reageren en twee bleken er geen gebruik te maken van Citrix-software, maar de rest bleek na de recente incidenten hun Citrix-servers maatregelen te hebben genomen. Het gaat specifiek om de Citrix Application Delivery Controller en de Citrix Gateway Server, waarin een kwetsbaarheid is gevonden.

Buitenlandse Zaken vertelt tegenover AD dat de software is uitgeschakeld, en bij Economische Zaken en Klimaat en Landbouw, Natuur en Visserij zijn "maatregelen besproken en beoordeeld", al wordt verder niet uitgelegd wat dit inhoudt. Vrijdag bleek al dat de Tweede Kamer en verscheidene gemeenten voorlopig geen gebruik maken van Citrix.

Eind vorig jaar werd bekend dat er een kwetsbaarheid in de systemen zit waarmee een remote code execution mogelijk is. Eerder deze maand bleek dat er honderden kwetsbare servers in Nederland stonden. Er is nog geen patch beschikbaar voor dat lek. Naar verwachting komt die pas eind deze maand op z'n vroegst uit. Het uitzetten van de Citrix ADC- en Gateway-servers betekent onder meer dat werknemers niet op afstand kunnen werken.

Reacties (176)

[Stefanovic45]

Heel Nederland zet Citrix ADC's uit vanwege het NCSC dat roept om de servers uit te zetten zonder dit bericht te onderbouwen. Hoeveel geld gaat deze actie van het NCSC de gemeenschap nog kosten? Het NCSC heeft zijn eerste aanbeveling om de ADC's uit te zetten inmiddels genuanceerd:

https://www.ncsc.nl/actue...len-niet-altijd-effectief

Het NCSC raadt u in ieder geval aan Citrix ADC en Citrix Gateway servers uit te schakelen, als uw organisatie niet voor donderdag 9 januari 2020 door Citrix geadviseerde mitigerende maatregelen heeft getroffen.

Die 9 januari is een belangrijke datum. Als je voor die tijd al meetregelen hebt genomen en deze maatregelen hebt getest, dan is er dus nog steeds niets aan de hand. De mitigerende maatregelen zijn dan gewoon voldoende om deze kwetsbaarheid te laten misbruiken.

Zie ook het rapport dat Fox-IT heeft uitgebracht over dit onderwerp:
https://fox-it.com/nl/act...t-citrix-advisory-update/

[eelco74]

Als deze workaround zoals cirrix die heeft aanbevolen afdoende zou zijn. Waarom willen ze dan alsnog een patch gaan uitbrengen ?

Dat doe je toch alleen als je tijdelijke maatregel niet werkt

[AddictIT]

Met een tijdelijke fix is het probleem enkel tijdelijk verholpen, maar het probleem is er nog steeds.

De versies die ze nu gaan uitbrengen lossen het probleem op in de broncode, zonder dat je de tijdelijke fix nog hoeft uit te voeren.

[_wolf_]

Technisch gezien is beiden broncode. Echter de tijdelijke fix is waarschijnlijk meer een quick and dirty oplossing. Zoals een if then else structure in de main ui loop(voorbeeld ik heb niet de kennis van de applicatie). Waar het probleem beter op te lossen is op de plek waar het probleem geintroduceerd is, zoals in een van de procedures in een method of property van een class.

[AddictIT]

Nee.

De NetScaler is in staat om zelf te antwoorden op requests in plaats van de achterliggende webserver.
De quick fix houdt net dit in, de NetScaler die zichzelf beschermt door die specifieke requests niet toe te laten.
Dit is dus niets in de broncode.


De definitieve fix past inderdaad de broncode aan zodat de bug effectief verholpen wordt.

[MrFax]

De tijdelijke fix is geen fix van het probleem. Er is gewoon code om het probleem heengeplakt, die ervoor zorgt dat het niet misbruikt kan worden. De patch duurt langer omdat waarschijnlijk core code aangepast moet worden, en dat houdt heel veel testen in.

Het is heel vergelijkbaar met wat Intel doet: Ze passen hun CPU's niet aan om het probleem op te lossen, maar plakken allemaal code om het probleem heen. Maar omdat het probleem niet is opgelost kunnen er steeds nieuwe exploits gemaakt worden die zelf weer om die workaround heen gaat, tot het probleem is opgelost.

[Reactie gewijzigd door MrFax op 23 juli 2024 18:47]

[V-Hyper]

De code van de mitigerende maatregel is gepubliceerd, hier hoeven we dus niet over te speculeren:

https://support.citrix.com/article/CTX267679

[pixelsnader]

Op het moment dat bij een ruit sneuvelt en het binnenregent gaat er meteen een plank of vuilniszak voor zodat je binnen geen natte voeten krijgt. Maar toch willen de meeste mensen graag uiteindelijk weer naar buiten kunnen kijken.

Een tijdelijke fix kan performance problemen met zich mee brengen door b.v. dubbele validatie, usability issues omdat er wellicht een bepaalde subset van gebruikers wel remote access moet hebben en nu alles keihard buitengesloten wordt, deze fix kan zelf nieuwe gevoeligheden blootleggen. Deze fix is een oplossing voor DIT probleem, niet per se voor andere problemen.

Het is overigens best mogelijk (maar wel onwaarschiinlijk) dat deze fix wel alles fixt zonder nieuwe problemen te introduceren, maar dan wil je alsnog alles dubbel en triple checken voordat je een tijdelijke fix omdoopt tot permanent.

[Stefanovic45]

Inderdaad, wat AddictIT aan geeft

[batjes]

Lijkt er dus op dat maar 1 rijksdienst is hun IT-beveiliging een beetje op orde heeft, zo ver ik kan zien is alleen het MinEZK/LNV dat het aandurft om het thuiswerken toe te laten. Zal wel een lekkere chaos worden morgen bij de meeste ministeries, in het OV en op de weg.

Het bericht in de media is niet hetzelfde als wat het NCSC zelf de partijen aanraadt. Het NCSC raadt enkel aan de meuk uit te zetten als uit hun testen naar voren komt dat je niet veilig bent. Het lijkt er dus sterk op dat de meeste partijen (iig overheidsdiensten) hun veiligheid niet op orde hebben.

[vmNinja]

Het hoeft niet zo te zijn dat men niet up to date is, of de mitigatie niet op tijd heeft applied. Sterker nog, ik weet van een toko die ondanks de juiste versie, mitigatie op tijd toegepast en de exploit testscripts netjes aangeven dat men niet kwetsbaar is, toch de Netscalers van het net hebben gehaald. Er is ook zo iets als kudde gedrag... En het als iedereen van de brug spring, spring je er dan achteraan? "Weten zij meer dan wij weten?" En als laatste dooddoener: Managers niet gehinderd door technische kennis die een besluit nemen.
Mijn punt is, dit kun je niet zo zwart/wit zien. En laten we wel wezen, dit geintje heeft al laten zien, waar één bug zit, zitten er meer. Dit krijg zo veel (media) aandacht, dat het aantal 'security-onderzoekers' wat een Netscaler interessant doel gaat vinden natuurlijk doet groeien. Daarmee kun je het sentiment van een manager ook wel weer een beetje begrijpen.

[RJG-223]

als iedereen van de brug spring, spring je er dan achteraan?

Ja, en: waarvoor wordt je eerder op het matje geroepen, en waar kun je je dan beter uitkletsen: als je, de kudde volgt, of als je je eigen weg gaat...

[Rolfie]

En het als iedereen van de brug spring, spring je er dan achteraan?

Dit kan natuurlijk wel de meest veilig oplossing zijn, als de brug op instorten staat. Je kunt dan afwachten en misschien stort de brug niet in. Wat zeker een mogelijkheid is.
Echter als je van de brug sprint (wat je veilig kunt doen), dan ben ze zeker veilig.

Welke keuze zou je dan doen?

[R.van.M]

Het probleem met deze redenatie is dat je dus bij elke vibratie van de brug springt.

Er was van de week een item op nieuwsuur met een topman van Citrix en die gaf ook aan dat met de patch er geen probleem was en kon ook niet echt beantwoorden waarom NCSC en alleen Nederland ervoor kiest om het helemaal uit te schakelen.

[voske]

Er zijn ook overheidsdiensten die het wel op orde hebben, maar die bijvoorbeeld gewoon mee moeten in een ministeriebreed genomen beslissing.

[Bockelaar]

het is denk ik meer dat de meeste overheidsdiensten nog steeds geen goede analyse krijgen. Er spoken teveel tegenstrijdige verhalen en adviezen rond. Als je dus als verantwoordelijk manager (in overheidsland: bevoegd gezag) een goed besluit moet nemen in een risicovolle situatie en de adviezen zijn niet eenduidig en duidelijk, dan kies je dus (heel wijs!) voor het besluit om zo min mogelijk risico te lopen. Door die dingen van internet af te koppelen, want dat is het genomen CTO besluit, koop je dus een weekend lang tijd om nader onderzoek te doen zonder risico te lopen.
Stel dat alle adviezen dat het voldoende veilig (veilig is niks, voldoende veilig is de betere term) is en de mitigerende maatregelen toch stiekem niet voldoende waren, wat gebeurt er dan? Precies: dan roeptoetert iedereen, inclusief 90% van de populistische kamerleden dat het allemaal stom is want wie heeft dat dan open laten staan.
Ik denk dat er een verstandig besluit is genomen: koppel thuiswerken af per vrijdagmiddag 17:00 uur. Daarmee kopen we een weekend tijd om nader onderzoek te doen. Maandag wordt het besluit heroverwogen als er voldoende nieuwe informatie beschikbaar is.

[beerse]

Bekijk het eens vanaf de beheerder zijn stoel: Het is vrijdag middag en er is iets aan de hand. Er moet gehandeld worden en er zijn een aantal opties. Er staat wat management omheen dat ook weekend wil gaan vieren. 1 van de adviezen/opties is de boel uit zetten en wachten op een patch die er maandag morgen ook nog niet is. Dan is dat wel een heel aantrekkelijke optie: Weekend!

[Stefanovic45]

Ik snap heel goed dat beheerders de systemen uitzetten onder druk van de media/managers. De bron van alles is echter de NCSC die met dit advies komt. Als NCSC alleen feiten had gecommuniceerd was alle commotie niet nodig.

[AlexFL]

Gelukkig niet heel Nederland, mijn werkgever maakt gebruik van "KPN Werkplek", die hebben in December al de benodigde maatregelen getroffen, deze is dus ook gewoon online.

Gelukkig speelt niet iedereen paniekvoetbal.

[SSH]

Natuurlijk speelt KPN geen paniekvoetbal, anders kunnen ze hun dienst opheffen.

[TWyk]

Er zijn ook overheidspartijen met KPNWerkplek die deze uitgeschakeld hebben voor extern gebruik.

[AlexFL]

Terwijl KPN op tijd maatregelen heeft genomen, dan is het dus gewoon een PR/imago ding om ze alsnog uit te laten zetten.

[kodak]

Als je het over een gemeenschap hebt heb je het ook over meerdere belanghebbenden en verantwoordelijkheden. Ook als het gaat om risicos als bijkomende kosten of besparingen. Net doen alsof er maar een partij is of dat er alleen kosten zijn is niet realistisch.

[[_ave_]]

Stel de overheid doet niets, slaat de waarschuwing van NCSC in de wind en wij als Nelderland worden gehacked en er wordt ransomware geinstalleerd wat voor een volledige shutdown van de overheid zorgt. Wat kost dat dan?
Het is een kwestie van afwegingen maken en kiezen voor de minst slechte. Ik vind het een verstandige beslissing om het telewerken uit te schakelen en dat zoiets geld kost is evident.
Omdat de Citrix gateways zijn dichtgezet wil dat nog niet zeggen dat alle overheids ambtenaren niets meer doen. Er bestaat ook nog zoiets als departementen waar het merendeel gewoon aan het werk is.

[Bor]

Wat mij vooral verbaasd is dat het zo lang moet duren voor er een patch komt waarbij de verwachte (!) leverdatum ook nog eens afhankelijk is van de versie die men draait. Hier scoort Citrix absoluut geen punten.

Interessant artikel van het NOS: Citrix: we volgden na lek standaardprocedure, gebeurt duizenden keren per jaar

Op 6 december hoorde Citrix van een onderzoeker dat het bedrijf kampte met een beveiligingslek, waardoor hackers in potentie vrij spel hadden in computersystemen van bedrijven die van Citrix gebruikmaken.

"Op 17 december, na elf dagen, hebben we een tijdelijke oplossing uitgebracht met een security alert. Dat is zeer snel", zegt Van Rotterdam.

11 dagen is absoluut niet snel voor een lek van deze omvang welke ook nog eens erg makkelijk te misbruiken is. De reactie lijkt vooral damage control.

Het Amerikaanse softwarebedrijf Citrix noemt de acties die het ondernam nadat er een lek in de eigen software was ontdekt "niet heel bijzonder". Tegen Nieuwsuur zegt het bedrijf de gebruikelijke procedure te hebben gevolgd.

"In 2019 alleen waren er meer dan 17.000 security alerts wereldwijd", zegt Jeroen van Rotterdam, een Nederlandse topman bij het bedrijf. "Dit is een standaardprocedure die gevolgd wordt in de industrie."

Hoe is het aantal wereldwijde security alerts relevant? Het gaat om impact en communicatie hier omheen. Juist op dat laatste punt vind ik de aanpak niet optimaal. Je leest meer nieuws van andere bedrijven dan van Citrix zelf helaas.

De tijdelijke oplossing is volgens Van Rotterdam "absoluut" voldoende. Desondanks werkt Citrix nog aan een permanente oplossing én deed het Nationaal Cyber Security Centrum (NCSC) gisteren een dringende oproep aan de Rijksoverheid en andere vitale organisaties om Citrix uit te schakelen. Van Rotterdam noemt dit "een zeer defensieve actie" van het NCSC, maar wel een terechte.

De tijdelijke oplossing is "absoluut" voldoende maar het uitzetten is wel een terechte actie / terecht advies?

[Reactie gewijzigd door Bor op 23 juli 2024 18:47]

[Korvaag]

Wat mij verbaast is dat er blijkbaar zoveel bedrijven zijn die dit als enige layer hebben naar het interne netwerk. Het is binnen de informatiebeveiliging vrij gebruikelijk te werken met meerdere layers juist voor het geval dat dit soort kwetsbaarheden naar boven komen.

[Sandor_Clegane]

Als je de CVE bekijkt is het een hele specifieke request die opgevraagd wordt. Ik geef je het te doen als je deze specifiek eruit wilt filteren met een andere firewall. Ik zeg niet dat het niet kan, maar om alle verkeer naar een netscaler te filteren en dan ook nog eens het niet stuk maken is geen sinecure. Komt nog eens bij dat je juist een netscaler neemt zodat je niet nog weer iets anders hoeft te nemen. Turnkey enzo.

Om nog maar niet eens te noemen dat het geheel heel wat bewegende onderdelen bevat.

[Korvaag]

Als je de netscaler ontsluit via een andere Access Management-oplossing kom je niet bij de netscaler tenzij je door de Access Manager heen bent. Dat is dan je extra authenticatie- en autorisatielayer. Uiteraard kan die dan ook lek zijn, maar dat is dan je extra beveiligingslaag. De kans dat beide componenten gelijktijdig lek zijn neem sterk af. Je moet helemaal niet op requestbasis willen filteren in deze. Je wilt het hele component afschermen.

Uiteraard is deze layering op meerder manieren te bewerkstelligen, dat moge duidelijk zijn (of je nou de netscaler afschermt met een ander component of het andere component met de netscaler dat is een keuze), maar slechts de netscaler inzetten als gateway en als enige hop tussen je internet en intranet is niet slim of je moet een wel heel goed verhaal hebben om het risico te accepteren.

Ik moet overigens zeggen dat ik ook genoeg organisaties heb meegemaakt die hier wel een beter infra-ontwerp voor hebben met meerdere lagen voordat je op het interne netwerk zit. Meestal zijn dit wel klanten die een duidelijke visie hebben op de beveiliging van hun interne IP en/of andere gegevens.

Even een klein voorbeeld (wat niet correspondeert met een klant maar voor het idee):
Werkplek -> VPN naar laag A -> Citrix portaal in laag A start werkplek -> Stepping stone naar intern netwerk

Again: wellicht niet het beste voorbeeld maar slechts ter illustratie.

[Reactie gewijzigd door Korvaag op 23 juli 2024 18:47]

[rob12424]

Dat is leuk: maar het moet ook kunnen. Wij hebben op het werk ook meerdere firewalls en Citrix. De supercomputers staan alleen bijna allemaal extern die gebruikt worden bij ons in de wetenschap. Ga je de data die daarvan afkomt allemaal beveiligen met meerdere lagen dan heb je andere problemen. Soms moeten dingen ook kunnen en moet je kiezen tussen meerdere kwaden helaas.

[Korvaag]

Uiteraard zijn er uitzonderingen, maar een standaard werkplek van een medewerker bij een ministerie, gemeente, kleine organisatie etc. is daar meestal geen onderdeel van. Het remote kunnen starten van een Citrix werkplek is over het algemeen puur een manier om de werkplek beschikbaar te maken op een thuiscomputer als vervanger van een thin client on-premise (althans, dit gebruik kom ik heel vaak tegen).

En voordat ik hier weer een boel reacties op krijg: ik besef me dat dit niet de enige toepassing is van Citrix, maar zo zie ik het wel vaak gebruikt worden. Iets waar veel organiaties overigens ook actief van af willen/gaan.

Je ziet dan bijvoorbeeld combinaties komen van verstrekte werkplekken (laptops) met wederom VPN en de mogelijkheid om Citrix applicaties te starten na het automatisch opzetten van deze VPN.

[Reactie gewijzigd door Korvaag op 23 juli 2024 18:47]

[Verwijderd]

Gebruikersgemak is key in dit soort oplossing. De hele reden dat men naar deze oplossingen is gegaan is om het drama van vpn oplossingen te vermijden.

Er zijn weer genoeg oplossingen die na een vpn weer een portal bieden maar dan zit je weer met hetzelfde probleem alleen dan met verschillende fabrikanten. Ook weer een nachtmerrie als je gaat upgraden of support nodig hebt.

Daarnaast willen fabrikanten geen firewall oplossingen supporten tussen hun oplossing en het internet. Überhaupt moet je je sterk afvragen wat je dan aanschaft want meestal bied het helemaal geen extra bescherming. Applicatie firewalls vereisen zeer diepe kennis om goed af te stellen, kennis die 99% van de bedrijven niet hebben, meer problemen veroorzaken dan vermijden en uitgebreide en diepe technische analyse vereisen om er kaas van te maken. Allemaal zaken die bijvoorbeeld Citrix niet geven. Microsoft doet dit tevens ook niet.

Korst my door de bocht: Dit is een prima oplossing geoptimaliseerd voor gebruikers support maar de (security) support faalt keihard.

[Mad Cooky]

Wij hebben (gelukkig) ieder mogelijk component achter onze firewalls geknoopt. Iedere nacht wordt de IPS database van deze firewalls geüpdatet en zodoende was de CVE al een paar dagen bekend in onze firewalls.

De enige stappen die wij nog moesten ondernemen, was de CVE op 'prevent' zetten en specifieke rules aanmaken voor alle diensten achter de Netscalers met https inspection.

De mitigatie maatregel hadden wij overigens in december al doorgevoerd...

[Rolfie]

Als je ze er achterzet, heeft het alleen nut als je ook SSL Offloading / inspectie activeert op je firewall, zodat de IPS in het verkeer kan kijken.

Ik heb deze ook aan sommige netwerk specialisten moeten uitleggen de afgelopen dagen.

[Mad Cooky]

Ja, dat zeg ik.. dat hebben wij gedaan..

[Bor]

Als je de CVE bekijkt is het een hele specifieke request die opgevraagd wordt. Ik geef je het te doen als je deze specifiek eruit wilt filteren met een andere firewall.

Het hangt van de firewall af hoe makkelijk dit gaat. Veel oplossingen bieden bv ook Intrusion Prevention aan waarbij de exploit ook daar gedetecteerd en geblokkeerd kan worden.

[V-Hyper]

Een ADC/Gateway wordt in de regel in een DMZ geplaatst, dus met zowel aan de noord- als zuidzijde een firewall. Een goed geconfigureerde application firewall had in specifieke gevallen een mitigatie kunnen bieden.

[Bor]

Dit is ook vaak niet de enige layer. Doorgaans zit er bv een firewall voor / achter. Het probleem is echter dat deze oplossing juist wordt ingezet als secure gateway. Valt die functie weg dan mist men behoorlijk belangrijke functionaliteit.

[Korvaag]

Dat snap ik, maar ook een secure gateway kan lek zijn (zoals hier vrij duidelijk wordt). In dat geval ben je dus binnen. Vroeger werden dit soort zaken eveneens beveiligd met een VPN, maar dat is niet hip meer want alles zal en moet beschikbaar zijn via internet. Juist als je dat doet zou je niet op 1 authenticatie/autorisatielaag moeten vertrouwen.

[WCA]

De netscaler van citrix dient in deze functioneel als een soort vpn.

Vpn + Citrix is hetzelfde aantal beveiligingslagen als netscaler + citrix

[HollowGamer]

En je wilt er dan toch juist geen extra laag tussen hebben lijkt me? Dan krijg je VPN op VPN, elke laag heeft ook weer invloed op de performance. OpenVPN heeft bijvoorbeeld een minimale impact van 20% (mede door versleuteling) op de verbinding als ik mij niet vergist en dan moet je vervolgens ook nog de loadbalancers in een groot bedrijf nog goed afstellen voor Citrix. Dat lijkt me flink performance verliest en geklaag bij de gebruikers ter gevolg, laat staan wat je moet doen bij debugging met problemen en uitzoekwerk om het allemaal goed samen te laten werken dus.

Tuurlijk als je alles goed instelt moet het ~prima te doen zijn, maar dan lijkt me die NetScaler een beter alternatief, die doet namelijk al die dingen in één, is ingericht voor Citrix, krijgt updates/ondersteuning, en was tot voor kort toch een betrouwbaar apparaat? Er wordt nu net gedaan alsof we thuiswerken maar moeten verbieden door al die problemen of heel Citrix moet worden vervangen, terwijl er al workarounds beschikbaar zijn. Al vind ik de response van Citrix met patches en het hele gedoe met versies, niet erg in het voordeel van hun spreken. Al zijn er ook genoeg bedrijven die dit soort apparaten (en netwerk) niet van updates/onderhoud blijven voorzien onder het mom van 'if it ain't broke don't fix it' en dus je inderdaad het dan maar overal uitschakelt.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 18:47]

[WCA]

Klopt helemaal.

Security moet altijd een balans zijn tussen gebruiksgemak en veiligheid. In sommige gevallen voegt een extra laag security genoeg veiligheid toe om een reductie in gebruiksgemak te veroorloven.

Soms geeft een extra laag echter schijnveiligheid. Een Netscaler achter een VPN plaatsen is daar een voorbeeld van. Als de VPN gehackt wordt, dan heb je een groter probleem, en zal de netscaler niet het eerste doelwit zijn. Eerder de rest van het netwerk.

[HollowGamer]

Precies, het levert je vrijwel niets op. Beter monitor je op vreemde IP-adressen, logs en wijzigingen op bestandsniveau - dat kan je ook autoriseren. Dan weet je ook beter waar je het moet zoeken i.p.v. verstrikt te raken in meerdere lagen.

[Bor]

Beter monitor je op vreemde IP-adressen, logs en wijzigingen op bestandsniveau - dat kan je ook autoriseren.

Dat zijn belangrijke maatregelen maar wel allemaal reactief; wanneer je op die manier iets detecteert is het kwaad al geschied.

[Bor]

Als de VPN gehackt wordt, dan heb je een groter probleem, en zal de netscaler niet het eerste doelwit zijn. Eerder de rest van het netwerk.

In dit geval is de netscaler een mogelijke stepping stone naar het interne netwerk. Dat is juist mede waar het om gaat.

[mrmrmr]

Externe computers zijn ook te besmetten. Vanaf de Netscaler server zijn bijvoorbeeld client executables te downloaden.

[WCA]

Dat klopt, zelfde gevolg dus als je netscaler of je vpn gehackt wordt.

[IStealYourGun]

VPN gateways kunnen ook vulnerabilities bevatten, duckduck maar wat rond en je kan er met gemak enkele recente vinden. VPN zorgt voor andere uitdagingen als je met externe partijen samenwerkt, want als bedrijf heb je geen controle over die PC en moet je dus maar hopen dat ze malware-free zijn en alle nodige security patches hebben. Een ander nadeel is dat je ook nog eens admin rechten nodig hebt op een VPN client te installeren.

De oplossing hangt uiteindelijk af van wat je wil bereiken. Als mensen toegang nodig hebben tot je infrastructuur is VPN een goede oplossing. Moeten ze enkel toegang hebben tot enkele applicaties dan is Citrix eerder een keuze.

[Korvaag]

En daarom plaats je die dus achter elkaar en zorg je dat ze van verschillende vendoren zijn. Je moet dan al twee lekken in twee componenten hebben wil het interne netwerk bedreigd worden.

De werkplek met vpn client wordt in de regel geleverd door de werkgever in die specifieke gevallen.

Verder ben ik het je eens hoor. Voor een applicatie kan het prima. Helaas merk ik echter vaak dat er niet genoeg over is nagedacht. Beleid ontbreekt of is beperkt en de interne kennis is niet altijd aanwezig want 'dat regelt de beheerpartij'.

[Reactie gewijzigd door Korvaag op 23 juli 2024 18:47]

[HollowGamer]

Wat voegt het dan precies toe? Wat ik begrepen heb zat dit lek niet in Citrix, maar in de Apache software en/of was dit niet genoeg dichtgetimmerd. Wat nu als je op beide lagen Apache heb draaien (wat zeer goed kan voor bijvoorbeeld portals)? Of wat dacht je van een Linux-kernel root exploit die vaak werkt op beide lagen? Dan zit je wel met 2 'extra' vendor lagen, maar dan ben je nog altijd verloren.

Je kunt tig muren (VPN's, firewalls, etc.) bouwen, maar als je door de eerste bent, dan kan je vaak ook door de andere komen. De enige goede manier is juiste beveiliging (2FA, tokens, etc.) en actief monitoren wat er op je netwerk gebeurd. Backups maken over tape of via clouding lijkt me het beste om je te beschermen tegen invloeden van zowel binnen als buitenaf.

Tevens denk ik niet dat veel mensen hier de werking van die NetScaler snappen, ik zelf ook niet als leek, maar om maar te roepen om vendor-op-vendor te bouwen om je extra te beschermen, is roepen dat je de voordeur van tig sleutels moet voorzien en dat levert ook geen extra veiligheid op in de meeste gevallen. Wat denk je dat het oplevert in werk en onderhoud met al die lagen en de veiligheid winst mogelijk maar 3% is? Tevens zal de kans op fouten statistisch ook toenemen, zeker bij tijdnood of probleemgevallen.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 18:47]

[Korvaag]

Wat voegt het dan precies toe? Wat ik begrepen heb zat dit lek niet in Citrix, maar in de Apache software en/of was dit niet genoeg dichtgetimmerd. Wat nu als je op beide lagen Apache heb draaien (wat zeer goed kan voor bijvoorbeeld portals)? Of wat dacht je van een Linux-kernel root exploit die vaak werkt op beide lagen? Dan zit je wel met 2 'extra' vendor lagen, maar dan ben je nog altijd verloren.

Je kunt tig muren (VPN's, firewalls, etc.) bouwen, maar als je door de eerste bent, dan kan je vaak ook door de andere komen.

Ja klopt met dezelfde onderliggende software (als daar de kwetsbaarheid in zit) ben je potentieel nog steeds kwetsbaar (althans, ook weer afhankelijk van hoe de kwetsbaarheid misbruikt kan worden natuurlijk).

Je tweede opmerking is pertinent niet waar. Het achter elkaar plaatsen van beveiligingsoplossingen is al sinds jaar en dag best practice juist om te voorkomen dat gebeurt en 1 van de basismaatregelen van informatiebeveiliging op dit vlak (zie bijvoorbeeld CISSP).

[Reactie gewijzigd door Korvaag op 23 juli 2024 18:47]

[Bor]

Een van de zaken die je met deze devices kunt aanbieden zijn juist VPN diensten.

[Korvaag]

Dan moet je dat wel doen... De klanten die ik ben tegengekomen maken daar geen gebruik van. MFA dan weer meestal wel. Portaal direct beschikbaar op internet. Login user/pass/token en klaar.

[Reactie gewijzigd door Korvaag op 23 juli 2024 18:47]

[Rolfie]

En wat als je VPN lek is? Ik kan mij nog iets herinneren als de PulseVPN.

Maar de netscaler is juist het component dat de SSLVPN doet voor het Citrix Verkeer.

[Paul]

Je kunt moeilijk iedere bezoeker aan Nu.nl vragen een VPN-client te installeren voordat ze op de site kunnen (geen idee of ze tegenwoordig nog steeds GSLB en Netscaler gebruiken, paar jaar geleden wel).

Hetzelfde geldt voor een heleboel andere websites, zoals het patiëntenportaal van het MCL dat nu ook onbereikbaar is.

Er is ALTIJD een eerste point of contact, en de Netscaler is typisch een apparaat dat vaak dat eerste punt is. Maar ook als je daar een VPN tussenzet kan het mis gaan, die VPN server kan ook lekken bevatten. En een VPN-server mag over het algemeen ook bij een heleboel systemen, dus dan zit je met hetzelfde probleem.

Iedereen dit roept dat er een apparaat vóór had moeten zitten om de toegang te beveiligen heeft mijns inziens niet door dat de Netscaler nu juist zo'n apparaat is dat je ergens voor zet om de toegang te beveiligen...

[nst6ldr]

Papieren veiligheid. In het QA traject wordt er gevraagd om een maatregel, uitbesteding of acceptatie van een risico. Één van die drie is dan genoeg, en de kwaliteit lijkt weinig uit te maken. In mijn eigen omgeving heb ik daar heel lang over geklaagd, nu zit ik op een stoel waar mijn input wat meer gewicht heeft en vliegen al die QA certificaten de versnipperaar in als ze daar mee aan komen, ik wil dan alles overnieuw onderzoeken.

[Korvaag]

Ja vrij bekend hoor. Ik zie bij veel klanten dat er bij de organisatie zelf te weinig kennis aanwezig is en de leverancier (al dan niet via een aanbesteding) zo snel mogelijk 'klaar' wil zijn waardoor je vervolgens eindigt met een oplossing waar een risico naar mijn mening veel te makkelijk wordt geaccepteerd.

[Toontje_78]

Dat hoort bij uitbesteden, extra werk maakt je te duur of snijd in de marge.
Standaard produkten hebben hun plaats, maar ik heb ze regelmatig gezien waar tenminste de instellingen een stuk beter op de specifieke situatie ingesteld hebben kunnen staan.

[PTR]

Heb je een bron over de hoeveelheid bedrijven die enkel De ADC/Gateway gebruiken? Alle implementaties die ik ben tegengekomen hadden minimaal nog een vorm van firewall/IDS/IPS toegevoegd. Het maakt uiteindelijk niet uit voor deze kwestie, een bug in een edge systeem los op door snel en adequaat te reageren, Citrix in dit geval met juiste communicatie en patch/mitigatie effort, en dat hebben ze niet gedaan.

[Korvaag]

Nee niet direct. Slechts wat ik tegenkom bij klanten.

[TheMak]

Ook binnen een bedrijf (VPN) zou ik er niet vanuit dat iedereen zich aan zijn eigen taakomschrijving houdt, en daarvoor de juiste procedures volgt. In bijzonder bij grote bedrijven, met buitenlandse vestigingen.

[Skywalker27]

En het verbaasd mij ook hoeveel bedrijven hun privileges niet op orde hebben waardoor er traces zijn van domain admins op de servers.

[RJG-223]

11 dagen is absoluut niet snel voor een lek van deze omvang welke ook nog eens erg makkelijk te misbruiken is.

Is dat jouw onderbuikgevoel ? Of heb je harde gegevens over andere lekken in het algemeen, waaruit blijkt dat 11 dagen aan de lange kant is ?

Het gaat niet alleen om de omvang van het lek, maar ook om de omvang en complexiteit van de software, en om de bug zelf. Er moet veel gebeuren nadat de melding binnenkomt, en dat kan meestal niet binnen enkele dagen, behalve misschien bij triviale software:

• Melding beoordelen
• Probleem reproduceren / bug bevestigen / omvang van het probleem bepalen.
• Patch schrijven & testen door de programmeur
• Testen (door de testafdeling) of de patch het probleem afdoende oplost
• Testen (door de testafdeling) of de patch geen nieuwe bugs introduceert; testen/beoordelen of andere functionaliteit wordt aantast
• Eventueel terug naar de programmeur als het niet helemaal goed was
• Controleren in welke andere versies van het produkt het probleem ook voorkomt, of iets vergelijkbaars (kan deels parallel met bovenstaande stappen). Eventueel patch backporten
• Documenteren van patch / workaround voor de klanten
• Nieuwe versie van de software klaar maken voor uitrol bij klanten

Nu kan ik dit geval natuurlijk niet inhoudelijk beoordelen, maar in het algemeen zou ik zeggen dat 11 dagen niet onredelijk is.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 18:47]

[Bor]

• Melding beoordelen
• Probleem reproduceren / bug bevestigen / omvang van het probleem bepalen.
• Patch schrijven & testen door de programmeur
• Testen (door de testafdeling) of de patch het probleem afdoende oplost
• Testen (door de testafdeling) of de patch geen nieuwe bugs introduceert; testen/beoordelen of andere functionaliteit wordt aantast
• Eventueel terug naar de programmeur als het niet helemaal goed was
• Controleren in welke andere versies van het produkt het probleem ook voorkomt, of iets vergelijkbaars (kan deels parallel met bovenstaande stappen). Eventueel patch backporten
• Documenteren van patch / workaround voor de klanten
• Nieuwe versie van de software klaar maken voor uitrol bij klanten

Vanaf daar gaat het om de workaround en ontwikkeld men de patch parallel hieraan.
Er is nog helemaal geen patch en de gecommuniceerde data zijn verwachte opleverdata. De tijd tot de patch beschikbaar is duurt dus veel langer dan de genoemde 11 dagen. Er is op dit moment slechts een workaround die niet in alle gevallen optimaal bleek te werken. Natuurlijk moet een workaround / tijdelijke maatregel ook getest maar veel van de genoemde zaken hierboven gelden in grotere mate voor daadwerkelijke patches / firmware upgrades.

Verder vind ik dat er duidelijker gecommuniceerd had mogen worden. Ook na de melding van het NCSC bleef een reactie hierop vanuit Citrix voor mijn gevoel lang uit.

[Reactie gewijzigd door Bor op 23 juli 2024 18:47]

[RJG-223]

Vanaf daar gaat het om de workaround en ontwikkeld men de patch parallel hieraan.

Een patch is niet hetzelfde als een definitieve oplossing voor een probleem. Een patch is een (relatief kleine) aanpassing in de software. meer niet. Dat kan dus een tijdelijke aanpassing zijn: een workaround, totdat een definitieve oplossing gemaakt kan worden voor een probleem. En er zijn inderdaad meer vormen die een workaround aan kan nemen, maar een patch is daar beslist één van, en niet een heel zeldzame. In dit specitieke geval weet ik het niet, maar mijn lijstje was een algemeen lijstje. En daarin kwam de definitieve oplossing niet voor.

De acceptabele tijdsduur tot een definitieve patch is heel erg afhankelijk van hoezeer de workaround/tijdelijke patch de (belangrijke) functionaliteit aantast, en hoeveel moeite het kost om een goede definitieve patch te maken. En het is in 't geheel niet ondenkbaar dat er meer dan één tijdelijke oplossing uitgebracht wordt, bijvoorbeeld als de defintieve oplossing niet snel te maken is, maar de eerste tijdelijke oplossing teveel beperkingen heeft.

Edit: en hoe dan ook: die stappen, en in ieder geval een deel ervan, die jij doorgestreept hebt, moeten ook doorlopen worden bij een workaround waarvoor geen programmeur nodig is. Op z'n allerminst de laatste drie stappen, en vaak ook het testen door de test-afdeling.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 18:47]

[Bor]

Een workaround (tijdelijke mitigerende maatregel) is doorgaans wel degelijk iets anders dan een patch (het daadwerkelijk verhelpen van het lek door aanpassingen in de software).

Enige uitleg:

Workaround;

A workaround means a problem has been identified, there’s no official solution for it, but if you do some sort of temporary change on your end you can get things to function within reason. It may not be 100% correct behavior, but it’ll get you past the problem - in a way, you need to change your expectations to accept a workaround as a solution.

Fix/Patch:

A fix means the problem has been officially solved so, once applied, the expected behavior will be the actual behavior. The problem in the product no longer exists because it’s actually been fixed.

Het is een kwestie van interpretatie echter wordt met een patch doorgaans een echte oplossing bedoeld in de vorm van een update.

[Reactie gewijzigd door Bor op 23 juli 2024 18:47]

[RJG-223]

We kunnen hier over de terminologie gaan discussiëren, maar dan kan ik ook met definities komen (zie bijv. de betreffende wikipedia pagina's) die het anders beschrijven. In jouw definitie komt Citrix in ieder geval überhaupt niet voor in het 'workaround' verhaal, dus waar heb je het nu over: over het feit dat Citrix er meer dan 11 dagen over doet om (met jouw definitie) een patch te produceren, of over een workaround die door de gebruiker zelf gemaakt moet worden ?

Ik zou zeggen, lees mijn lijstje nog eens door. Dat is hoe het software-ontwikkelproces in een grotere organisatie grofweg werkt. Ook voor een enkele patch. En zelfs voor een andersoortige aanpassing is meestal een deel van die stappen nog steeds nodig. En voor al die stappen is 11 dagen echt niet belachelijk lang. Als je het sneller probeert te doen, zelfs al lijkt het op het eerste gezicht dat dat wel kan, dan heb je alleen maar meer kans dat je juist nieuwe problemen introduceert, en wellicht de zaak erger maakt - of helemaal niet oplost. En voor de meeste bugs is gewoon een patch nodig.

Nu kan ik me voorstellen dat het als gebruiker niet leuk is als je 11 dagen extra kwetsbaar bent, maar als het gemiddelde probleem makkelijk in 11 dagen opgelost kon worden, dan zou er voor kwetsbaarheden echt niet in het algemeen een termijn van 90 dagen gehanteerd worden.

[Rolfie]

Alles wat je door streept is ook van toepassing voor de huidige remediation responder. Die moet je ook testen op al je code en mogelijkheden, nog afgezien alle versies van je software.

11 dagen is hiervoor best netjes. Er zullen vast vele interne discussies hierover geweest zijn bij Citrix. Waar de bug zit, hoe deze gecorrigeerd kan worden in de code. Maar ook naar een noodoplossing als de code niet snel aangepast kan worden. En dan nog testen op diverse scenarios.

11 Dagen is best veel, maar afhankelijk van de impact (op de code aanpassingen) ook netjes.

[Bor]

Alles wat je door streept is ook van toepassing voor de huidige remediation responder. Die moet je ook testen op al je code en mogelijkheden, nog afgezien alle versies van je software.

Dat klopt, in dit geval bleek helaas dat dat testen niet al te rigide is gebeurd waardoor er alsnog weer een aanpassing op de advisory moest komen wat weer voor onduidelijkheid zorgde en een moment waarbinnen Netscalers met de aanpassing toch niet afdoende beschermd bleken afhankelijk van de software versie.

De workaround is in dit geval een aantal respond rules ipv echt een software matige aanpassing. Uit de advisory is ook gelijk een deel van de exploit te achterhalen wat het eea in een versnelling heeft gebracht. Het was immers op basis van de workaround duidelijk waar men moest zoeken. De exploit scripts volgden zeer snel.

[latka]

11 dagen is absoluut lang.
- Beoordelen: de melding is gedaan door een security export. Als bedrijf heb je uiteraard duidelijk een communicatie kanaal gedefinieerd voor dit soort zaken zodat de melding direkt bij de CSO op tafel ligt. Melding die gedaan is: "kritieke kwetsbaarheid wordt uitgebuit, kunnen aanvallers zich via het internet direct toegang verschaffen tot het lokale netwerk van een bedrijf en daarvoor zijn geen accounts of authenticatie nodig".
- Stap 2: bel de CEO uit zijn bed
- Stap 3: Informeer al je klanten
- Stap 4: constateer dat je software development practice nog uit 1980 stamt en adviseer iedereen alles uit te zetten

De route die Citrix kiest past bij een organisatie die niet gewend is met internet facing applicaties te werken.

[RJG-223]

Uit een eerdere reactie. 2e deel van de quote is blijkbaar van Citrix zelf:

Op 6 december hoorde Citrix van een onderzoeker dat het bedrijf kampte met een beveiligingslek, waardoor hackers in potentie vrij spel hadden in computersystemen van bedrijven die van Citrix gebruikmaken.

"Op 17 december, na elf dagen, hebben we een tijdelijke oplossing uitgebracht met een security alert. Dat is zeer snel", zegt Van Rotterdam.

Dat zijn die 11 dagen. Onder de omstandigheden (probleem nog niet publiek bekend) lijkt me dat niet problematisch. Er is dus helemaal geen sprake van dat Citrix slecht gereageerd heeft op een melding van een nieuw probleem dat actief uitgebuit werd. Want er werd op 6 december helemaal nog niets actief uitgebuit, en er was nog niets openbaar bekend. Dat was pas op 13 januari, bijna 4 weken na het openbaar maken door Citrix van het probleem en de tijdelijke fix, en ruim 5 weken na de eerste melding bij Citrix.

Jouw procedure is paniekvoetbal, en dus volkomen misplaatst. Daarmee heb je grote kans dat je meer problemen veroorzaakt dan dat je verhelpt. Een bedrijf zal een melding eerst zelf moeten verifiëren. Dat kan de CSO niet zelf, daar heeft ie mensen voor. En enkel op het woord afgaan van een security expert is onverantwoord. Die kan het mis hebben. En als je zondermeer je klanten gaat bellen om alles maar uit te zetten, dan moet je wel heel zeker weten dat er iets aan de hand is. Anders luisteren de klanten na een paar keer niet meer ('daar heb je hem weer...'). Of ze komen met schadeclaims.

[Rolfie]

Waarna bij stap 3 meteen wereldwijde paniek is, zonder een oplossing.
Daarom mis je stap erg veel stappen tussen 2 en 3.

Je moet meteen met een oplossing/antwoord komen voor je klanten.

Stap 4 is vrij uniek, en volgens mij is dit alleen een advies dat ons NCSC geeft. Zelfs Fox IT heeft hierbij zo zijn bedenkingen hierover.
Het statement van Citrix is dat momenteel de responder policy voldoende is (afgezien 3 versies van 12.1 versie. Maar dat komt door een bug in netscaler, niet de responder policy.)

Nu kiest men vaak liever voor safe then sorry, wat ik volledig kan begrijpen. Dat hebben we hier ook gedaan.

[Blokker_1999]

Waarom verbaasd het jouw dat het zolang duurt? Dit soort problemen wil je niet snel oplossen met wat paniekvoetbal in de hoop dat daarmee je problemen van de baan zijn. Je wil dit probleem grondig aanpakken zodat je zeker geen nieuwe problemen introduceert. Daarnaast is het mogelijk om deze aanval af te slaan met een tijdelijke aanpassing in je setup die je achteraf weer ongedaan kunt maken. Dat het NCSC dus de aanbeveling doet de systemen uit te schakelen lijkt mij dan ook een fout advies te zijn. Als de aanval af te slaan is met deze tijdelijke oplossing, dan is er toch geen probleem meer. Tenzij je de tijdelijke oplossing niet goed uitvoert.

[latka]

Als ik alles goed begrepen heb is de mitagatie niet waterdicht. Dus dan is uitzetten wel de enige optie.

[Bor]

Dat het NCSC dus de aanbeveling doet de systemen uit te schakelen lijkt mij dan ook een fout advies te zijn.

Zelfs Citrix geeft aan dat het een defensieve maar terechte maatregel is. Zie ook Bor in 'nieuws: Meeste Nederlandse ministeries hebben Citrix-servers uitgezet'

[Reactie gewijzigd door Bor op 23 juli 2024 18:47]

[AddictIT]

Dat komt omdat je eigenlijk totaal niet weet hoe de vork in de steel zit, en dus artikels als die van de NOS als waarheid aanschouwt.

Ik word een beetje moe van dit soort reacties.

Vraag maar eens aan een willekeurige vendor om een fix uit te brengen voor een product wat al enkele jaren end-of-life of end-of-support is. Kans is groot dat je eerst naar de nieuwste versie mag upgraden.

Citrix heeft absoluut punten gescoord op reactiesnelheid, gezien er genoeg aanwijzingen waren dat publieke exploits niet lang meer op zich zouden laten wachten. Dat organisaties vervolgens niet ingaan op hun tijdelijke fix, welke zonder impact geconfigureerd kon worden, is de echte boosdoener. Voor dat handjevol klanten waar de bug niet verholpen kon worden (1 specifieke build), waren er twee scenario’s: updaten naar een latere build of de toegang van buitenaf blokkeren (je moest ze niet eens uitzetten).

Dat een permanente fix op zich laat wachten, geeft aan dat dit een complex gegeven is, wat bovendien doorgedreven testen moet doorstaan op alle versies vooraleer het publiek wordt vrijgegeven. Doe je dat niet, en er ontstaan nieuwe problemen of instabiliteit, staan jullie ook weer op de barricades te schreeuwen.


Heeft er iemand al aandacht gegeven aan de CVE van Microsoft van deze maand? Crypt32.dll en RDP gateway issues? Deze zijn by far veel gevaarlijker, want we weten allemaal hoe erg het gesteld is met bedrijven en patchen van Windows.

[Bor]

Je gaat voorbij aan het feit dat de voorgestelde maatregel op sommige devices niet afdoende was. En ook Citrix raad aan te upgraden als je de advisories volgt.

Citrix heeft absoluut punten gescoord op reactiesnelheid, gezien er genoeg aanwijzingen waren dat publieke exploits niet lang meer op zich zouden laten wachten.

11 dagen wachten om een alert de wereld in te sturen bij een zeer makkelijk te misbruiken lek vind ik persoonlijk niet punten scoren op reactiesnelheid.

[Reactie gewijzigd door Bor op 23 juli 2024 18:47]

[SunnieNL]

Normaal in de industrie is eerst de patch, dan de alert de wereld in.
Daar zit vaak 90 dagen tussen de melding en de alert met patch. Soms komt zelfs eerst de patch en de alert nog veel later.

Citrix had dat hier ook kunnen doen. Zou mij niets verbazen dat de workaround het probleem heeft vergroot omdat daardoor reverse engineering kon plaatsvinden en juist bekend werd hoe je het kon misbruiken.

Gezien meer dan 700 bedrijven na 3 weken de workaround nog steeds niet geïmplementeerd heeft zegt overigens veel meer dan de reactie snelheid van Citrix. De overheden zouden zich moeten schamen dat ze dat na 3 weken nog niet hadden gedaan.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 18:47]

[AddictIT]

Ik ga helemaal nergens aan voorbij, integendeel ik zit er al de hele tijd midden in. Zoals ik al zei: dat is 1 specifieke build. Voor de rest doet de tijdelijke fix wat die moet doen.

Maar ja, van iemand met kennis ter zake wordt dergelijk commentaar niet aanvaardt.


Nogmaals, lees de advisory van Citrix goed door. Deze werd telkens aangepast na nieuwe ontwikkelingen, en hun initiële fix is nog steeds correct en afdoende.

Waar er eerst nog onduidelijkheid was door een mogelijke bug, is die later weerlegd (vooral als je de fix exact had toegepast zoals zij die initieel hebben aangekondigd). Er is 1 versie/build waar de fix niet werkte, en daar raadde Citrix inderdaad aan om te upgraden naar een latere build binnen dezelfde versie.

[domainator]

Het is pas later bekent geworden dat de mitigerende maatregel niet werkt voor een specifieke build (12.1.xx)

[Rolfie]

Maar dat komt niet door de maatregel, maar door in bug in de versies van 12.1.xx

[Bor]

Maakt dat uit? Het resultaat is immers hetzelfde; men is tegen verwachting in niet afdoende beschermd.

[Rolfie]

Wel voor het vertrouwen van de responder code.

Resultaat is dat je inderdaad hele grote problemen hebt. Maar dat komt door een andere bug.

[kodak]

Dat komt omdat je eigenlijk totaal niet weet hoe de vork in de steel zit, en dus artikels als die van de NOS als waarheid aanschouwt.

Maar ja, van iemand met kennis ter zake wordt dergelijk commentaar niet aanvaardt.

Dit soort aannames over mede tweakers en modder gooien is wel heel erg laag. Dat je een mening hebt en er ook wat van weet is duidelijk, maar als je je niet gehoord voelt kom dan misschien met betere onderbouwing en bedenk dat je zelf misschien ook niet alle wijsheid hebt.

Om het on topic te houden:

Citrix heeft absoluut punten gescoord op reactiesnelheid, gezien er genoeg aanwijzingen waren dat publieke exploits niet lang meer op zich zouden laten wachten.

Maar als je het zo stelt mis ik nog een belangrijk punt: als het de bedoeling was om het risico op publieke exploits te verkleinen, hoe zit dat dan met punten scoren door het criminelen wel heel makkelijk te maken om met de oplossing te ontdekken wat het lek was en een exploit te maken? Bij beveiliging is het niet alleen een kwestie van hoe snel je reactie is maar ook of die werkelijk doet wat je wil voorkomen bij de praktijk dat klanten blijkbaar moeilijk bereikt kunnen worden terwijl criminelen ze mogelijk eerder weten te vinden.

Dat een permanente fix op zich laat wachten lijkt voor bedrijven als Microsoft ook geen reden om een dan maar een tijdelijke oplossing te leveren die criminelen kan tegen houden maar ze ondertussen helpt om zich te bewapenen. Google onderzoekers hanteren dat 90 dagen een redelijke termijn is om softwareupdates te maken zolang er in de tussentijd niemand hint wat de fout kan zijn of gevonden kan worden. Anderen hanteren 120 dagen. Het tussentijds bekend maken wat de bug kan zijn is daarin niet de bedoeling juist om te voorkomen dat er meer risico is.

Ik ga helemaal nergens aan voorbij

Het punt wat @Bor maakt is dat de oplossing niet in alle gevallen werkte. Dat is wel degelijk belangrijk als een niet werkende oplossing dus voor problemen kan zorgen. En als je een mening hebt over de betrouwbaarheid van de oplossingen, misschien kan je dan ook uitleggen waarom je meent dat die nu wel voldoende zijn. Omdat de fabrikant het zegt lijkt me dan wel wat mager als ze dat eerder ook beweerde.

[PTR]

Over het up-to-date blijven, zeker met dit soort security producten, heb je helemaal gelijk. Hier ligt ook het lastige punt voor veel organisaties, de implementatiecyclus.

Edoch, 11 dagen erover doen om een mitigerende rule te bedenken die een path traversal (wat zo ongeveer een oerhack is op een webserver) blokkeerd, vind ik echt wel te lang.
Dat daarna ook nog blijkt dat in een specifieke versie er een bug zit in de rule engine (de kern van je gateway?) en men blijkbaar ook niet op het netvlies had, is ook bijna onvergeeflijk. Dit had Citrix zelf al moeten correleren...als ze het al wisten en dit niet dankzij de 'hoofd' bug naar voren is gekomen doordat een bedrijf met die versie getroffen is.
Nee, Citrix verdient zeker geen punten op dit gebied.

Het gaat om de consequenties. En vergelijken met bv microsoft of welk andere partij heeft niks met deze discussie te maken, met dat argument kan je elke discussie doodslaan.

[rene_fb]

Edoch, 11 dagen erover doen om een mitigerende rule te bedenken die een path traversal (wat zo ongeveer een oerhack is op een webserver) blokkeerd, vind ik echt wel te lang.

Met bug identificeren, oplossing maken en valideren. En dat alles in hoeveel versies?
Dit soort tools hebben een andere dimensie dan een bug in ms Paint.

Dat daarna ook nog blijkt dat in een specifieke versie er een bug zit in de rule engine (de kern van je gateway?) en men blijkbaar ook niet op het netvlies had, is ook bijna onvergeeflijk.

Als ik @AddictIT goed begrijp was er een latere build waar dit probleem opgelost was.
Oftewel, fout gemaakt, fout (h)erkent, oplossing uitgebracht. Dat organisaties niet updaten/upgraden kun je Citrix niet aanrekenen.

[PTR]

Het gaat hier over de mitigerende maatregelen, oftewel een workaround, niet om de uiteindelijke patch welke inderdaad meer tijd nodig heeft.

Ik gaf al aan dat bedrijven security technisch up-to-date dienen te blijven, citrix is inderdaad niet verantwoordelijk voor het update beleid van een bedrijf.
Dat een bedrijf eventueel op die andere buggy versie zaten is hun verantwoordelijkheid (de betreffende versie 10.5 is trouwens in end-of-maintenance, nog net niet end-of-life en krijgt nog security updates) en hebben ze wellicht plausibele redenen voor het nog niet updaten.

Mijn punt is alleen dat Citrix hun checks op orde moeten hebben, want ze zijn wel verantwoordelijk voor de juiste en alle informatie en alerting, helemaal vwb security producten.
Dus, als ze weten dat een rule een workaround voor een bug is en er nog een versie met een bug in de rule engine, zet dit er dan meteen bij. Het gaat hier ook niet om triviale bugs.

[latka]

Heb je gezien wat de exploit is? Het is een path-traversal bug (dus .../../../ niet voldoende afschermen). Dat kost geen maand om te fixen. Dat kun je fixen zonder impact op bestaande ketens (tenzij Citrix adviseert om dat soort URLs te gebruiken). Ik heb nog geen enkele reden of verdediging gehoord vanuit Citrix die plausibel is.

[Rolfie]

Je bent developer van de Netscaler code, waardoor je deze kennis en conclusie kunt onderbouwen?

[latka]

Nee, maar heb de exploit code even gegoogled. Is eern curl call met ../../.. in de URL. Dit soort path traversals zijn al bekend probleem sinds de eerste CGIs live gingen. Dat het in netscaler zit is dus triest. En een fix voor dit soort dingen heb ik eerder mogen maken in andere producten. Dus ik denk dat ik het een beetje snap.

[Rolfie]

Misschien dan solliciteren bij Citrix?

Ik heb ook wel eens wat mogen fixen in de code. Maar ik doe ook beheer op Netscalers.
Dus ik denk dat ik het een beetje snap, dat code best wel eens heel complex kan zijn.

Een eenvoudige exploit wil niet altijd zeggen een eenvoudige oplossing.

[latka]

Netscalers beheer ik (gelukkig) niet. Maar de doorlooptijd die ze nu aanhouden (2 maanden) past bij een club die zijn zaken niet op orde heeft. Ik heb wel wat Xen machines onder beheer gehad, en als ik die lijn daarvan doorzet naar Netscaler, dan ben ik er niet rouwig om dat netscaler aan mij voorbij heb laten gaan.

[Phntm]

Rijksoverheid werkt met flexplekken (0.7 fte in de meeste gevallen). Het zal maandag een feestje worden. De enige manier dat men dan kan werken is als ze hun eigen apparaten meenemen en dan verbinden met govroam om gebruik te kunnen maken van de Citrix omgeving. Ik verwacht persoonlijk drukte in alle ruimtes, zelfs de coffeecorners.

In het vorige artikel over de reactie van de overheid rondom Citrix had ik aangegeven dat er voor is gekozen is om de netscalers uit te schakelen/af te sluiten voor externe verbindingen. Dat wil zeggen dat men dus op werk zolang ze inloggen met de juiste credentials (ambtenaren accounts) dat ze via Citrix workspace app nog gewoon normaal kunnen verbinden en gebruik maken van een digitale werkplek.

Correctie: Het is toch echt helemaal uitgeschakeld nu voor alle ministeries die gebruik maakten van Citrix. Er is besloten om men te voorzien van een managed device als Leen laptop om te compenseren op kantoor voor gebrek aan werkplekken (thinclients).

[Reactie gewijzigd door Phntm op 23 juli 2024 18:47]

[EnigmaNL]

Bij EZK en LNV staan de servers nog gewoon aan hoor

[Phntm]

Gebaseerd op de assumptie van de AD?

[EnigmaNL]

Net nog ingelogd.

[Phntm]

Dank je voor het bevestigen dan de andere dienstleverancier heeft alles uit gegooid, BuZa was de eerste op hun eigen verzoek.

[dj1981]

Beetje ongenuanceerde reactie wat mij betreft.

Uiteraard maken alle ministeries (voor zover ik weet) gebruik van Citrix, maar dat is alleen voor het gebruik van je eigen laptop thuis, of voor het gebruik van bijvoorbeeld een chromebook of ipad. Werkplekken op ministeries zelf blijven gewoon werken, ook als het thin-clients zijn, net zoals het grootste deel van de werk-laptops (de managed-devices). Mijn laptop werkt prima hier thuis.

Zou ook niet best zijn als je voor al je werplekken op locatie gebruik zou maken van Citrix.

[Phntm]

Niet alle ministeries maken gebruik van Citrix. Rijnstraat is een voorbeeld van een rijkspand waar je vooral werkt met een BYOD of managed device, afhankelijk van over welke ministerie we het nu hebben (J en V, BuZa). Er zijn ministeries die geen citrix in gebruik hebben vanuit de dienstverlener, maar wel managed devices. Dus er zijn genoeg ambtenaren die hier niets van zullen merken. Thinclients zijn de leuke kleine kastjes die er staan op werkplekken. In elk rijkspand heb je daar een aantal van, dus je werkplek. Maar als men de mogelijkheid verliest om Citrix te kunnen benaderen met een chromebook of eigen laptop, als voorbeelden, dan zal men een thinclient gebruiken. Waar een bezetting van 0,7 fte verwacht wordt kun je denk ik wel verwachten waarom er besloten is om leen laptops gereed te stellen voor men om te kunnen werken.

[V-Hyper]

Er zijn organisaties waar intern ook Citrix VAD wordt gebruikt, en niet zelden worden ook intern netscalers gebruikt als loadbalancers en gateways. Dat zijn ontwerpkeuzes met voor- en nadelen. Je kunt niet zomaar zegggen dat dat "niet best" is.
Het is aan die organisaties geweest om een afweging te maken: responder installeren, al dan niet icm up- of downgrade, netscaler wel of niet aflsuiten van het internet, netscaler volledig uit zetten, etc.
Verschillende organisaties hebben verschillende configuraties, topologien en risico's. Er is niet 1 goede oplossing voor iedere organisatie.

[Mel33]

Zal mij maandag benieuwen hoe druk het op de weg is. Geen idee of dit of topic is maar thuiswerkers gaan dus ook de weg op morgen.
Ik ga wat eerder van huis iig.

[RobbyTown]

Dan moet er op kantoor wel ruimte zijn om te kunnen werken .

[Nox]

Ook dit, mijn zusje werkt bij een gemeente en die meldde al dat als ze niet heel vroeg is ze waarschijnlijk gewoon geen plek heeft en dan weer naar huis kan waar ze ook niks kan doen. Leuk al die flexplekken maar bij dergelijke situaties is het toch een beetje behelpen.

Buiten dat zit je met random collega's iedere keer denk ik? Ik heb er geen ervaring mee maar het lijkt me ook niet volledig ideaal.

[RJG-223]

Leuk al die flexplekken maar bij dergelijke situaties is het toch een beetje behelpen.

Dat is (als het goed is :-) een afweging die de organisatie gemaakt heeft: elk jaar (veel) kosten besparen op werkplekken en het risico nemen op incidentele hoge kosten en niet gehaalde planningen als er problemen zijn, of hogere kosten voor de werkplekken, en minder schade als externe toegang tot software een keertje niet functioneert.

[CH4OS]

Mits er gebruik wordt gemaakt van Citrix producten. Niet alle gemeenten doen dat.

[Nox]

Deze wel, anders had ze het niet gemeld denk ik

[Toontje_78]

Moeder de vrouw werkt zo; iedereen zit meestal op dezelfde plek.

Persoonlijk vind ik concept de kantoortuin nog een stapje verschrikkelijker in wat je je werknemers aan kan doen.

[Iblies]

Dit is dus gewoon nonsens.

Elk beetje deftige instelling heeft een locatie om te eten/lunchen. Daar zijn dus zat zitplaatsen.

Of het wifi-netwerk is slecht ingesteld wat net zo waardeloos is als je zogheet flexibele werkplekken hebt.
In principe kennen instellingen van dit formaat BYOD en zou je op een lokaal wifi-netwerk alles moeten bereiken.


Mij lijkt het eerder interessant om te kijken wat eigenlijk al die mensen in de praktijk doen. Als er namelijk werk is, kun je aan de slag. En met name aan dat eerste begin ik serieus te twijfelen als er nu al massaal wordt beweerd dat ze niets kunnen doen.

Je krijgt dat griezelig gevoel dat mensen die bij de overheid werken eigenlijk niet precies weten wat ze doen en hoe er naar een oplossing kan worden gewerkt. Komt later wel.

[eelco74]

Sorry hoor maar er zijn gemeenten en ministeries die maar voor 50 tot 70% van de werknemers werkplekken hebben. Dat ga je in de kantine niet opvangen. Even afgezien van het feit dat er ook vaak alleen vaste werkplekken (pc + monotor) zijjn en er dus in het pand helemaal geen alternatieven zijn.

[domainator]

Aan het externe wifi-netwerk voor bijvoorbeeld BYOD zal men maandag niks hebben om de Citrix portal te bereiken als de Netscaler/ADC uitstaat. Gemeentes hebben govroam wat wel gaat werken.
In de kantine gaan werken is zeker niet overal een optie, vroeg beginnen morgen is de beste tip.

[SPee]

Elk beetje deftige instelling heeft een locatie om te eten/lunchen. Daar zijn dus zat zitplaatsen.

Maar zitplaatsen zijn geen werkplekken.
Leuk dat jij vindt dat de kantine een goede werkplek is, maar de arbo dienst zal het daar niet mee eens zijn.

[Ruud2001]

En op kantoor moeten ze niet ook een infra op basis van Citrix met thin clients hebben...

[Trommelrem]

Het is niet zo dat alle Citrix producten geraakt zijn, er zijn een of twee producten geraakt die thuiswerkers beinvloeden.

[Soepergrover]

Ik ben toch beniewd of er organisaties zullen zijn die alle Citrix producten uit gaan zetten omdat ergens iemand in de beslisboom het woordje 'Citrix' heeft gehoord in combinatie met 'kwetsbaarheid' zonder er verder veel bij na te denken.

[Reactie gewijzigd door Soepergrover op 23 juli 2024 18:47]

[V-Hyper]

Het waren 3 productgroepen: ADC, Gateway en WAN-OP. Vreemd genoeg heeft NCSC geen aandacht geschonken aan WAN-OP.

[RJG-223]

En op kantoor moeten ze niet ook een infra op basis van Citrix met thin clients hebben...

Ik denk dat er bedoeld wordt dat externe toegang voor Citrix servers uitgezet is. Intern gebruik is natuurlijk niet echt een probleem.

[Coffee]

De gemeente Amsterdam werkte volledig op Citrix (ik heb er een half jaar stage gelopen) volgens mij kunnen die op het moment dus letterlijk niks doen.

[wisselwerking]

Je kunt alleen niet thuiswerken. Op kantoor, met thinclients, is het geen probleem hoor.

[Coffee]

De gemeente Amsterdam maakt ook op kantoor, met de thinclients, gebruik van Citrix. Heel omslachtig, maar je logt dus altijd in via Citrix.

[Source90]

Gaat enkel om remote access van buiten het netwerk.

[Coffee]

De gemeente Amsterdam maakt ook op kantoor, met de thinclients, gebruik van Citrix. Heel omslachtig, maar je logt dus altijd in via Citrix.

[Source90]

In Delft ook. Echter is dat intern netwerk en (iig) hier niet uitgeschakeld.

[Wim-Bart]

Je bent fout geïnformeerd. Tweakers noemt het Citrix Servers terwijl ze eigenlijk de Citrix Netscalers bedoelen. En daarom moet je de berichtgeving over Citrix op Tweakers even negeren want die is verwarrend en misleidend en fout.

[mikesmit]

De meeste thuiswerkers zijn niet heel de dag aan het werk thuis heh . Die moeten bijvoorbeeld ook op de kinderen passen.

Ik vermoed dat het morgen even druk word als normaal maar dat er bijzonder veel verlof opnames zijn

[oef!]

Onderzoek toont aan dat de gemiddelde thuiswerker harder werkt dan op kantoor - vooral omdat ze bang zijn voor de stempel die jij er op drukt.

[kimborntobewild]

Thuiswerkers kunnen thuis o.a. meer doen dan als ze hetzelfde op een kantoor zouden moeten doen, omdat ze in een comfortabelere werkomgeving zitten (vaak is er ook een partner die helpt - fysiek en mentaal), minder ver heen en weer hoeven te lopen (en tijdens dat lopen steeds praatjes maken met collega's) en geen reistijd nodig hebben. Thuisstudie blijkt ook effectiever dan gezamelijke studie (je kind kan thuis evenveel leren in 2 of 2,5 uur dan in 6 of 7 uur op school. Op school ben je veel tijd en energie kwijt aan het onderhouden van overbodige sociale contacten, het leren van overbodige zaken, en het vermijden van bullies). Niet dat sociale contacten overbodig zijn; maar op een school zijn er teveel van.
Het is dat ik niet goed/snel genoeg ben in netwerkbeheer; anders kon/wou ik graag (deels) thuiswerken .

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 18:47]

[GrooV]

Als ik thuiswerk heb ik geen tijd om op mijn zoon te passen hoor. Die gaat dan gewoon naar het kinderdagverblijf, opa/oma of er is iemand in huis. Daar ben ik ook altijd heel duidelijk in.

De enige keer dat je even een paar uurtjes op kan passen tijdens het thuiswerken is als ze net geboren zijn en de hele dag liggen te slapen.

[wjn]

Waarom wordt niet eens de moeite genomen om het artikel uit het AD goed te citeren?

"THUISWERK CITRIX"

Nu lijkt het alsof all Citrix servers uitgezet zijn. Fake news dus.

[Reactie gewijzigd door wjn op 23 juli 2024 18:47]

[Cyberwizzard]

Het lijkt mij vrij duidelijk dat niet Ctrix hun eigen servers hebben uitgezet maar dat het om de machines van de gemeentes ging. En die worden alleen voor werken op afstand gebruikt; dus wat klopt er niet aan dit artikel?

[Wim-Bart]

Alles klopt er niet aan. Het gaat alleen om de Citrix Netscaler's. En dat zijn Netwerk devices, geen servers. Netscalers zijn o.a. load balancers die ook SSL VPN bieden voor thuiswerken.

Citrix servers zijn Windows RDS servers welke in plaats van een RDS gateway en broker een Citrix beheer schil hebben en benaderbaar zijn via het ICA protocol. Citrix servers zijn ook niet om te telewerken, je kan een telewerk omgeving ermee faciliteren, maar dat is een ander verhaal.

KORTOM, refereren naar Citrix Servers is fout. En maakt het artikel al pertinent onwaar. Wanneer er was gerefereerd naar Citrix Netscalers (Netwerk device) is dan was het artikel goed.

Ik lees de artikelen niet eens meer op Tweakers over dit onderwerp omdat ze pertinent onjuist zijn. En Tweakers en andere media beginnen zich langzamerhand op het gebied van laster te begeven. En de schade die deze foute berichtgeving geeft zou wel eens als een boomerang terug kunnen komen.

[mrmrmr]

In de titel staat niet dat alle Citrix servers zijn uitgezet bij de ministeries, er staat feitelijk dat er meer dan 1 Citrix server is uitgezet bij alle betreffende ministeries. Dat is correct. In het artikel wordt nog nader aangegeven over welke Citrix servers het gaat. Netscaler valt ook onder de definitie van een server. Het is niet relevant of het een appliance is. Dat is de vorm, niet de functie.

De verschillende namen die Citrix zelf gebruikt voor hun producten maakt het niet makkelijk om het kwetsbare type server in een woord te vatten.

[Wim-Bart]

Het product is Citrix Gateway en komt in een aantal smaken. Maar het is geen server. Het is een netwerk device. Zo positioneert Citrix het zelf ook.

https://www.citrix.com/products/citrix-gateway/

Overigens zijn er een aantal variaties van het product, waarbij het een kwestie is van licenties inlezen en aanzetten.

https://www.citrix.com/products/

Maar het is geen server.

[mrmrmr]

Netscaler AAA is een server, het is gewoon Linux met een web server. Er draaien scripts op.

[Wim-Bart]

Ben ik niet met je eens. Er zijn zo veel netwerk devices welke een Linux kernel hebben draaien en toch zijn het geen servers. Netscalers zijn gewoon Netwerk devices, gateways. Sterker nog, de eerste Netscalers welke ik heb neergezet in Nederland waren niet eens in staat om een Website te publishen anders dan deze via een Virtual Service te proxien.

Overigens wordt de Netscaler niet alleen als Citrix product verkocht maar worden ze ook geleverd door andere grote namen met pakkende titels als, load balancer, application firewall.

[mrmrmr]

Op Wikipedia is te lezen: "Appliances A class of small specialist servers called network appliances".

Je vindt dat er absolute scheiding bestaat tussen wat jij "network device" noemt (Citrix noemt Netscaler een appliance) en servers, maar dat is hier niet het geval. Netscaler biedt ook gebruikersdiensten erop aan en het is niet puur een router of load balancer maar ook een server.

De lek zit in het webserver(!) deel van Netscaler. Vandaar konden kwetsbare scripts worden gestart - die naar bestanden schrijven - en de path traversal kwetsbaarheid zit ook in de webserver van Netscaler.

[wjn]

Ze citeren het AD, die schrijft letterlijk:
"een systeem dat wordt gebruikt voor thuiswerken".

Tweakers is een techsite, lijkt mij dat ze het nog beter specificeren dan een algemeen nieuwsblad cq. krant in plaats van het juist weg te laten.

[_Thanatos_]

In veel gevallen is Tweakers meer een copypaste-blog. Ik vind dat er weinig echte journalistiek gedaan wordt. Je zou toch beter verwachten nu ze allerlei verdienmodellen hebben.

Dus ipv het AD te citeren, het artikel in het AD als inspiratie gebruiken voor een origneel artikel met eigen journalisten die achter het verhaal aan gaan.

[Bor]

Waar het fout gaat is dat Citrix een merknaam is. Hier gaat het om een product of zelfs bepaalde functionaliteit. Het is een beetje hetzelfde als elk Oracle product simpelweg "Oracle" noemen. De praktijk is veel genuanceerder. Citrix levert veel verschillende zelfs totaal ongerelateerde producten.

[TheDudez]

Van tweakers mag je toch wel wat meer verwachten. Het klopt inderdaad niet. alleen d netscalers zijn uitgezet. De tinclients hoeven niet over de netscaler.

[Pietervs]

Waarbij het verhaal dat ze uitgezet zijn vaak schromelijk overdreven is: in de meeste gevallen wordt de toegang van buitenaf geblokkeerd, maar draaien ze nog steeds (anders zou patchen knap lastig worden )

[TheDudez]

Dat verschilt. Er zijn ook echt gemeentes die ze hebben uitgezet. Maar als de thc,s over de netscaler gaan dan wordt het heel lastig om ze uit zetten.

[iMars]

Je krijgt een 0 maar je hebt gelijk! Alleen de externe toegang is uitgeschakeld tot het Citrix platform. Intern werkt het gewoon.

[wildhagen]

Thuiswerk citrix is niet juist. Het zit in Delivery Controllers en de (Netscaler) Gateways.

Die eerste is voor alle XenApp en XenDesktop implementaties nodig, die laatste alleen voor extern inloggen, al kan je als workaround ook keurig een VPN implementeren en zo alsnog werken. Maar goed, competente IT heeft de overheid niet.

Kleine correctie, het zit in de Application Delivery Controller (het vroegere Netscaler ADC, nu Citrix ADC). Dus niet in de gewone Delivery Controllers die je in een interne XenDesktop/XenApp-site gebruikt.

Een Application Delivery Controller is niet voor alle XenApp/XenDesktop-implementatie nodig. Als je het alleen intern gebruikt, heb je géén ADC nodig. Die is pas nodig als je hem extern wil ontsluiten.

[FreshMaker]

al kan je als workaround ook keurig een VPN implementeren en zo alsnog werken. Maar goed, competente IT heeft de overheid niet.

Het zou juist incompetent zijn als je 'snel even' een vpn op gaat zetten.
Voor thuis of een MKB met zo'15 werknemers is dat te doen, maar grote organisaties stuur je niet zomaar even een andere kant op, voor een paar dagen.

Wat ga je doen, 1500 vpn configs via mail versturen naar de collega's op vrijdagmiddag, zonder te testen ?

[nelizmastr]

Er zijn al mitigations beschikbaar. Het spul hoeft echt niet allemaal uit.

[FreshMaker]

Natuurlijk.
Weet je wat makkelijk is ...

Op een zondagmorgen iemand incompetent noemen.
Zolang je straffeloos dingen mag aandragen zonder kennis van zaken, heb je altijd gelijk.

Maar als je aan het 'actuele' stukje zit, heb je weinig keuzes.
Je moet van alles, maar niemand neemt die verantwoording.
Dan kan je beter een weekend 'overlast' hebben dat er geen thuiswerk is, dan dat je over 5 maanden een bericht krijgt "door het niet opvolgens van advies is XXX gebeurt"

Maar dan kan jij weer mooi roepen "zie je wel .. incompetentie overheid !"

[eelco74]

Als de mitigatie zoals citrix die heeft aanbevolen voldoende zou zijn. Waarom zouden ze dan nu nog werken aan een patch ?

Er is kennelijk veel meer aan de hand dan citrix ons wil doen geloven.

[Zenety]

Waar haal je vandaan dat er in de Delivery Controllers deze bug zit?

[hotabibber]

Is er in dit geval een mogelijkheid tot schadeclaim richting Citrix?
Dit brengt in mijn ogen behoorlijk wat extra kosten met zich mee.

[V-Hyper]

De in eerste instantie ongenuanceerde communicatie vanuit NCSC heeft ook flink wat maatschappelijke kosten veroorzaakt. Benieuwd hoe dat geanaliseerd gaat worden.

[kevinvs]

De patch voor 12.0 en 11.1 is sinds 20:50 te downloaden na inloggen op https://www.citrix.com/downloads/citrix-adc/
De RSS feed met welke downloads er zijn is wel openbaar: https://www.citrix.com/co.../downloads/citrix-adc.rss

Aanvulling 21:45, tekst op https://support.citrix.com/article/CTX267027 is nu ook aangepast. Opvallend dat NCSC niet ook gelijk met een nieuw statement is gekomen; die waren in nauw contact en wisten ook al lang dat hij vandaag vervroegd rond 21:00 NL tijd zou uitkomen.

[Reactie gewijzigd door kevinvs op 23 juli 2024 18:47]

[Bor]

Dat de eerste patch vandaag rond 21:00 zou vrijkomen was al op verschillende plekken bekend. Er is hier ook op het forum over gesproken.

[kevinvs]

Volgens mij was het alleen informeel openbaar bekend, maar van de NCSC had ik verwacht dat zij het wel vooraf zouden weten én gelijk direct met een nieuwe update zouden komen, maargoed die kwam om 21:58.

In een nieuwe blog van de Citrix CISO staat trouwens gelukkig "While all the mitigations associated with CVE-2019-19781 are effective across all known scenarios, we strongly encourage customers to apply the permanent fixes as soon as possible."

Wat hij exact bedoeld met "all known scenarios" weet ik niet, maar dit i.c.m. het nieuwe NCSC bericht geeft mij wel vertrouwen dat met de juiste en tijdige maatregelen (en niet de specifieke 12.1 build) het wel 'veilig' is en was.

[Tweakez]

Inmiddels zijn de eerste patches reeds beschikbaar sinds zondagavond 19 januari

https://www.bleepingcompu...n-citrix-adc-111-and-120/

En hier

https://www.citrix.com/bl...ble-timeline-accelerated/

Met betrekking tot de 'quick en dirty' oplossing van citrix bleef het lek bestaan. Iemand die iets meer hersenen heeft kan nog steeds bypassen

De overige releases vinden plaats omstreeks 24 januari

[Reactie gewijzigd door Tweakez op 23 juli 2024 18:47]

[wildhagen]

Volgens https://support.citrix.com/article/CTX267027 zijn de patches voor versies 11.1.x en 12.0.x voor de Citrix ADC en Citrix Gateway nu uitgekomen (per zondag 19 januari). De veilige versies zijn respectievelijk 11.1.63.15 en 12.0.63.13.

Voor deze versies zijn de mitigations dus niet meer nodig.

Voor versies 10.5.x, 12.1.x en 13.0.x van ADC en Gateway zijn de patches nog niet uitgekomen, deze release staat nu geplanned voor vrijdag 24 januari. Deze versies moeten vooralsnog dus nog wél worden mitigated.

Ik heb ze zojuist op mijn test-omgeving uitgerold (11.1), en daarna nogmaals de test gedaan, en nu gaf hij aan inderdaad niet meer vulnerable te zijn (dat was eerst wel het geval, voor de mitigation).

[Reactie gewijzigd door wildhagen op 23 juli 2024 18:47]

[Earry]

Het gekke is dat ik momenteel bij meerdere klanten deze dingen nog gewoon aan het internet zie hangen. Bij mijn overheidsklanten zijn de netscalers inderdaad uitgezet maar bij enkele financiële instellingen niet

[wildhagen]

Het gekke is dat ik momenteel bij meerdere klanten deze dingen nog gewoon aan het internet zie hangen.

Als men de mitigation steps van Citrix heeft uitgevoerd hoeft dat helemaal geen probleem te zijn, want dan zijn deze specifieke Netscalers niet meer kwetsbaar, mits ze uptodate zijn.

Het advies voor uitschakelen geldt dan ook alleen voor Netscalers die niet vóór 9 januari al van de mitigation waren voorzien.

Het NCSC raadt u in ieder geval aan Citrix ADC en Citrix Gateway servers uit te schakelen, als uw organisatie niet voor donderdag 9 januari 2020 door Citrix geadviseerde mitigerende maatregelen heeft getroffen.

Staat gewoon in het advisory van de NCSC: https://www.ncsc.nl/actue...len-niet-altijd-effectief

[Reactie gewijzigd door wildhagen op 23 juli 2024 18:47]

[Domih]

Wij waren voor 9 januari voorzien van de mitigation, maar zijn toch gepakt op 12 januari omdat we versie 12.1 hadden.