9min

Tags in dit artikel

, , ,

Techzine had een exclusief interview met Fermín Serna, de Chief Information Security Officer (CISO) van Citrix, met als belangrijkste vraag: waar ging het mis? Citrix heeft de afgelopen dagen het nieuws gedomineerd met een kritiek beveiligingslek in Citrix ADC en Citrix Gateway. Een probleem dat elke dag groter leek te worden. Wij stelden de CISO een aantal kritische vragen over hoe deze situatie uit de hand liep en welke lessen eruit getrokken kunnen worden.

Voorafgaand aan het interview met Citrix hebben we het beveiligingslek kritisch geanalyseerd, gekeken naar de eerste meldingen, media-aandacht en de door Citrix aangedragen oplossingen. Daarnaast hebben we proberen vast te stellen wanneer het echt misging. Onze eerste conclusie is dat dit verhaal alles behalve uniek is; wat Citrix is overkomen kan elk bedrijf overkomen. Er is hier sprake van een domino-effect, waarbij de situatie steeds erger wordt. Met als dieptepunt dat er op de radio werd gesproken over Citrix-files, omdat mensen op kantoor moesten werken in plaats van thuis. Welke lessen kunnen we hiervan leren?

Wat is er nu precies gebeurd?

We zijn met de CISO van Citrix, Fermín Serna, stapsgewijs door het besluitvormingsproces gelopen om goed te kunnen achterhalen wat er misging en of dat voorkomen had kunnen worden.

Het begin van het verhaal rond deze zeer kritieke beveiligingslek begint al medio december. Tot op heden leek het erop dat Positive Technologies het enige bedrijf was dat het beveiligingslek had ontdekt en gemeld bij Citrix. Tijdens ons gesprek corrigeert Serna ons. Positive Technologies heeft het lek gemeld, maar er zijn nog twee beveiligingsonderzoekers van andere bedrijven die in een tijdbestek van twee dagen dezelfde melding hebben gemaakt.

Hoe drie verschillende beveiligingsonderzoekers in een tijdbestek van twee dagen dezelfde melding kunnen maken is niet duidelijk, zeker als het gaat om een beveiligingslek dat waarschijnlijk al langere tijd in deze producten zit. Wel weten we dat beveiligingsonderzoekers vaak samenwerken en kennis delen. Wellicht dat ze onderling kennis hebben gedeeld?

Wat deed Citrix met de drie meldingen?

Wanneer een beveiligingslek wordt gemeld bij een grote vendor als Citrix, is de eerste stap om het beveiligingslek te verifiëren en vervolgens een analyse te doen. Daarbij kijken ze:

  • Hoe groot (kritiek) is het beveiligingslek?
  • Wordt het lek al misbruikt door kwaadwillenden?
  • Hoe groot is de kans dat het algemeen bekend wordt?
  • Zijn er mogelijkheden om het nog een aantal weken of maanden stil te houden zodat er eerst patches ontwikkeld kunnen worden?

Dit is bij vrijwel elk groot softwarebedrijf de gangbare procedure. Er is ook een soort van industriestandaard onder melders van beveiligingslekken dat leveranciers 90 dagen worden geboden om een patch te ontwikkelen, voordat het lek publiek wordt gemaakt.

Citrix werkt gewoonlijk ook volgens deze procedure, maar in dit geval was er dus niet één partij, maar waren er drie partijen die melding maakten van hetzelfde beveiligingslek. Dat maakte de situatie al direct een stuk complexer. De kans dat het beveiligingslek vroegtijdig naar buiten zou komen, een ongecontroleerde publicatie, is met drie partijen vele malen groter.

Volgens Serna liet één van de drie beveiligingsbedrijven weten het beveiligingslek hoe dan ook op 23 december te publiceren. Serna noemde hierbij geen namen. Uit ons eigen onderzoek bleek echter dat Positive Technologies op exact deze datum een uitgebreide blog publiceerde over de kwetsbaarheid. Voor Citrix was er dus geen mogelijkheid het lek nog een aantal weken stil te houden om eerst een patch te ontwikkelen.

We hebben Serna ook gevraagd of een van de beveiligingsbedrijven geld heeft gevraagd voor het stilhouden van het beveiligingslek, zodat Citrix een patch kon ontwikkelen. Hierop kregen we een ferme “nee” te horen.

Citrix publiceerde het lek en een tijdelijke oplossing om het te dichten

Citrix’ opties waren beperkt nadat het wist dat er een publicatie op korte termijn zou volgen. In zo’n kort tijdbestek is het onmogelijk een degelijke patch te ontwikkelen, deze goed te testen met alle verschillende versies en te verspreiden naar klanten.

Citrix besloot uiteindelijk de regie te nemen en publiceerde zelf op 17 december het beveiligingslek. Met deze publicatie werd ook direct een tijdelijke oplossing gepubliceerd die het beveiligingslek dicht. Deze oplossing bestaat uit een aantal commando’s die door beheerders van Citrix-servers in twee blokken moeten worden uitgevoerd. 

Deze tijdelijke oplossing zorgt ervoor dat het niet langer mogelijk is het beveiligingslek te misbruiken, maar houdt de Citrix-servers wel in de lucht, zodat gebruikers nog gewoon (extern) in kunnen loggen. De tijdelijke oplossing heeft dus geen negatief effect op het gebruik van de Citrix-servers.

“De tijdelijke oplossing werkt op alle Citrix-versies, mits beide blokken met commando’s zijn uitgevoerd.”

We vroegen Serna hoe het zit met de berichten in de media dat deze tijdelijke oplossing niet zou werken op alle Citrix-servers, of bij bepaalde versies of builds. Serna geeft aan dat die berichten Citrix niet zijn ontgaan en ze dit nader hebben onderzocht. Ze concluderen dat de tijdelijke oplossing wel degelijk werkt, maar alleen als beide blokken met commando’s zijn uitgevoerd en niet enkel het eerste blok. Het lijkt er dus op dat sommige Citrix-beheerders niet alle commando’s hebben uitgevoerd.

Analyse van het beveiligingslek en tijdelijke oplossing

We hebben het beveiligingslek geanalyseerd, evenals de tijdelijke oplossing. Het beveiligingslek kan misbruikt worden door een URL van een Citrix-server te manipuleren om zo commando’s uit te voeren op de server. Als we naar de tijdelijke oplossing kijken, zien we dat, als er een URL-aanvraag is richting “/vpns/”, wat een standaard directory is op Citrix ADC en Citrix Gateway, gecombineerd met “../”, dat de server dan een 403 forbidden moet sturen (het verzoeken afbreken). Er waren nog een paar commando’s, maar dit is wel de belangrijkste.

Op basis van deze regel, laat Citrix al min of meer zien in welke richting gezocht moet worden naar dit beveiligingslek. We vroegen Serna dan ook of dit niet anders had gekund. Nu lijkt het er een beetje op dat ze op 17 december gemeld hebben dat de deur open staat met een soort schatkaart erbij die in de juiste richting wijst. Volgens Serna heeft Citrix zijn opties voorafgaand aan de publicatie goed afgewogen en is er gekozen voor een gebalanceerde oplossing. Een oplossing waarbij de klant volledig beschermd is en waarbij er zo min mogelijk informatie wordt gedeeld om kwaadwillenden in de juiste richting te wijzen. Daarom is de forbidden regel zo simpel en breed mogelijk gemaakt.

Op 8 januari verscheen de exploit om het lek te misbruiken

De tijdelijke oplossing van Citrix werkte ruim twee weken goed, maar daarna ging het snel bergafwaarts. Zodra duidelijk werd dat er een groot beveiligingslek in Citrix zat, trok dit de aandacht van kwaadwillenden en beveiligingsbedrijven die op zoek zijn naar aandacht. Uiteindelijk achterhaalden meer beveiligingsonderzoekers het lek en werden er screenshots en voorbeelden getoond, weliswaar met zwarte balkjes, maar al die screenshots gaven volgens Serna wel aanwijzingen in welke richting gezocht moest worden.

Op 8 januari kwam het beveiligingslek in een stroomversnelling en werd het probleem groter doordat een exploit online verscheen waarin exact is te zien hoe het beveiligingslek kan worden misbruikt. Er volgden rapporten van beveiligingsonderzoekers die aangaven dat actief gejaagd werd op kwetsbare Citrix-servers. Er kwamen analyses van de hoeveelheid kwetsbare Citrix-servers in het land. Overheidsinstanties voelden zich genoodzaakt te komen met waarschuwingen. Dat zorgde voor een extra golf van media-aandacht, waarna de Nederlandse overheid uiteindelijk besluit de Citrix-servers uit te schakelen. Het dieptepunt werd echter bereikt toen op de Nederlandse radio melding werd gemaakt van “Citrix-files”, omdat mensen op kantoor moeten werken in plaats van thuis.

“Als Citrix-beheerders de tijdelijke oplossing hadden uitgevoerd in de dagen na onze publicatie op 17 december, waren ze gewoon beschermd tegen dit beveiligingslek.”

Het was een domino-effect dat simpelweg niet tegen te houden was en waarbij men over elkaar heen viel om Citrix de schuld te geven. Wat mensen daarbij vergeten is dat, uiteindelijk, beveiliging een gedeelde verantwoordelijkheid is.

Of zoals Serna het wat simpeler zegt: “Als Citrix-beheerders de tijdelijke oplossing hadden uitgevoerd in de dagen na onze publicatie op 17 december, waren ze gewoon beschermd tegen dit beveiligingslek.”

Patches beschikbaar

Op zondag 19 januari zijn de eerste patches verschenen voor dit beveiligingslek, maar alleen voor versies 11.1 en 12.0. De patches voor de overige versies verschijnen op vrijdag 24 januari.

Wat wij niet helemaal begrepen is waarom Citrix ervoor gekozen heeft deze versies als eerste te patchen. Er zijn namelijk ook nog versies 10.5, 12.1 en 13.0. Waarbij 13.0 de laatste versie is en daar zou je toch als eerste een patch voor verwachten. Serna stelt dat ze de meest gebruikte versies eerst hebben gepatched. Wat wij vreemd vinden, want gebruikers die de software up2date houden worden nu eigenlijk gestraft, zij moeten langer wachten op een patch. Serna liet doorschemeren dat hij onze redenatie kan volgen, maar dat het ontwikkelteam prioriteiten moet stellen en deze keuze is gemaakt. Verder benadrukt hij nogmaals dat de tijdelijke oplossing op alle versies werkt, zowel de nieuwste als oudere versies, zelfs versies die eigenlijk niet langer worden ondersteund.

Welke lessen heeft Citrix hieruit getrokken?

Wat heeft Citrix hiervan geleerd? Zouden ze in de toekomst andere keuzes maken? Serna laat weten dat ze nog steeds achter hun procedures staan en de manier waarop ze hiermee zijn omgegaan. Deze procedure is ook min of meer een industriestandaard. In de meeste gevallen werkt de procedure ook gewoon goed.

Serna voegt toe dat hij graag wat meer redelijkheid zou willen zien bij de beveiligingsonderzoekers en dat ze zich bewust zijn van de impact die hun acties hebben. Hij laat zich verder niet uit over specifieke beveiligingsbedrijven, maar het is duidelijk dat “whitehat-hackers” er zo hun eigen agenda op na houden.

Citrix gaat verder onderzoek doen naar hoe ze ervoor kunnen zorgen dat dit soort fouten in de code minder snel worden gemaakt en dat beveiliging nog meer prioriteit krijgt bij de ontwikkeling van applicaties. Feit is echter, en dat erkent Serna direct: het voorkomen van fouten in software is onmogelijk.

Er werken honderden of zelfs duizenden mensen aan dit soort grote applicaties. En waar mensen werken worden nou eenmaal fouten gemaakt. Hoe goed bedrijven dit ook proberen te controleren en optimaliseren. We kunnen de website dagelijks volschrijven met beveiligingsupdates als we zouden willen.

Citrix heeft schadebeperking ook hoog op de agenda gezet

Citrix heeft de afgelopen weken getracht de schade zoveel mogelijk te beperken. De afgelopen weken is actief contact gezocht met klanten om ze te wijzen op het beveiligingslek en de tijdelijke oplossing. Hiervoor zijn eigen sales en customer succes medewerkers ingezet, maar ook het partnerkanaal van Citrix.

Het bedrijf heeft ook een tool geïntroduceerd die klanten kunnen gebruiken om hun Citrix-servers te analyseren. Deze tool is ontwikkeld in samenwerking met forensisch onderzoeker FireEye. De tool kan Citrix-servers scannen en herkennen of er misbruik is gemaakt van het beveiligingslek en of er wellicht bekende malware of ransomware is achtergelaten. Citrix stelt dat de tool niet alle gevolgen in kaart kan brengen, dus als de tool aangeeft dat er misbruik is gemaakt van het lek, is het verstandig een forensisch beveiligingsbedrijf in te schakelen.

Whitehat hackers op zoek naar aandacht en marketing voor bedrijf

We zijn al eens eerder getipt door softwarebedrijven dat de praktijken van sommige whitehat-hackers niet altijd even netjes zijn. Bedrijven praten hier liever niet over en ook Citrix wilde niet ingaan op de drie beveiligingsbedrijven die zich hebben gemeld. Maar Citrix kan niet heel blij zijn geweest met de manier waarop de beveiligingsonderzoekers in dit geval te werk zijn gegaan.

De motieven van kwaadwillende hackers zijn niet zuiver, maar dat lijkt dus ook te gelden voor enkele whitehat hackers. Deze goed bedoelende hackers zijn vaak op te delen in twee kampen. Degenen die op zoek zijn naar een financiële vergoeding en zich daarom vooral richten op software van bedrijven die goed betalen voor het vinden van beveiligingslekken. Bedrijven als Facebook, Google en Microsoft betalen forse bedragen voor kritieke lekken.

Aan de andere kant heb je ook beveiligingsonderzoekers die voor een bedrijf werken dat beveiligingsoplossingen en diensten verkoopt. Door het vinden van beveiligingslekken en deze te publiceren krijgen ze media-aandacht en dat is goed voor het bedrijf. De media aandacht is groter bij een kritiek lek en helemaal als de oplossing niet direct voor handen is. Beveiligingslekken die direct kunnen worden gedicht leveren slechts minimale aandacht op. Het bieden van een wachttermijn van 90 dagen voor het bekendmaken van een lek is goed voor de veiligheid, maar dus niet voor de aandacht waar deze beveiligingsbedrijven naar op zoek zijn. Dat lijkt in dit geval mogelijk een van de oorzaken te zijn geweest dat dit beveiligingslek zo is geëscaleerd.