citrix "hack" wat is nu de echte oorzaak ?

[vso]

Dit speelt al langer dan een 5 tot 7 dagen ? (gemeente x.y.z gehackt) en nieuws: Advies NCSC: overweeg Citrix ADC- en Gateway-servers uit te schakelen

Goed ik vind het best wel wat ..

Wat is nu technisch gezien de issue, en wat maakt het voor citrix zo lastig op te lossen

Mitigeren (risico kleiner maken) .. door je clients te witelisten is heel anders.

Normaal gezien blockeer je een poortje, zet je een applicatie uit .. maar nu een server uit te zetten is wel erg radikaal.

Daarnaast staan gateways vaak (hopenlijk) in een DMZ zodat wanneer de server gehackt word zoals nu .. schade beperkt blijft.. en blijkbaar is de "kwaadwillende" niet gelimiteerd tot die server maar kan ook doorhoppen naar interne servers (wat veel erger is)


Wie kan hier wat meer uitleg over geven technisch gezien.

[Paul]

Er zit een fout in een bepaald onderdeel waardoor je door ".." te gebruiken door een directorystructuur kunt lopen en daarmee dingen op kunt vragen in directories die je normaal niet kunt bereiken. Als je hiermee alleen bestanden op zou kunnen vragen dan was dat vervelend, maar te overzien. Echter, het zorgt er ook voor dat je bepaalde scripts aan kunt roepen, en middels die scripts bestanden downloaden naar het apparaat. Die bestanden kun je vervolgens ook weer uitvoeren.

Door zo diverse bugs / vulnerabilities te combineren kun je dus willekeurig (zelf-geschreven) code uitvoeren op de server.

offtopic:
Ik zei eerder "zelfs root-toegang krijgen", maar ik weet niet zeker of je root kunt worden. Ook zonder root is dit een hele ernstige situatie

Ik zeg server, maar het is een reverse proxy en loadbalancer. Dat betekent dat het dus verbindingen kan maken naar andere servers, namelijk de webservers. Als die in je LAN staan (want er staat een reverse proxy tussen) dan heb je dus toegang tot een server in LAN. Vaak op poort 443 (of 80), maar de first line of defence ben je al door. Vervolgens kun je dus gaan kijken of je bij de volgende server binnen komt. Alle requests die de reverse proxy normaal tegenhoudt kun je nu wel aanroepen, zoals admin-urls en dergelijke.

Tevens is zo'n reverse proxy vaak ook degene die SSL-verkeer decrypt. Dat zorgt er dus voor dat je op dat apparaat heel veel verkeer zonder de gebruikelijke encryptie kan bekijken. Als dit de reverse proxy is voor je telebankieren of het patiëntenportaal van een ziekenhuis kun je dus meekijken wat mensen doen. En omdat het unencrypted is, zie je ook usernames en wachtwoorden langskomen.

In principe doe je door "een poortje te blokkeren of een applicatie uit te zetten" hetzelfde als je nu met de "server" uitzetten doet: Je zorgt dat men er niet meer bij kan. In plaats van het ding uitzetten kun je ook de firewall regel op block zetten. Alleen, over het algemeen verzorgt zo'n Netscaler / ADC functionaliteit voor meer dan één website. Denk aan de thuiswerkplek, webmail, je externe website, een support portaal, etc. Als ik snel even tel op de onze dan hebben we in DMZ meer dan 30 websites, en voor al die websites wordt die ene 'server' gebruikt.

De reden dat oplossen zo lang duurt is omdat het een ingewikkeld apparaat is met heel veel mogelijkheden. Vinden waar de fout in zit kost tijd, maar testen of de oplossing werkt en geen onbedoelde neveneffecten heeft (zoals teveel blokkeren, of nieuwe veiligheidslekken introduceren) kost nog veel meer tijd.

Ze hebben nu een hoop imagoschade, maar wel mitigerende stappen. Als ze nu een oplossing uitbrengen die niet werkt of zelf ook lek is, dan is die imagoschade nog veel groter.

De mitigerende maatregelen werken wel, maar je moet ze wel goed toepassen: "a bug exists that affects responder and rewrite policies bound to VPN virtual servers" -> de mitigerende maatregelen zeggen dat je het globaal moet binden, niet aan losse VPN virtual server. Overigens is een Netscaler / ADC die zijn policies niet toepast behoorlijk waardeloos, dus ik ben ergens wel benieuwd hoeveel bedrijven überhaupt op die versies zaten...

Het is overigens niet ongewoon of bijzonder lang dat er een maand zit tussen het uitkomen van een vulnerability, en het beschikbaar hebben van een patch. Alleen staat er meestal niet na een paar dagen al een script op Github zodat de hele wereld kan gaan scriptkiddy'en, en dat is nu wel gebeurd.

---

N.a.v. Tylen in "Systeembeheerders en hun problemen - deel 38"

Drardollan schreef op vrijdag 17 januari 2020 @ 15:21:
Heel veel (ook goede en verstandige) bedrijven hebben gekozen voor een Citrix oplossing. Dit probleem is enkel en alleen te wijten aan Citrix, en dan met name het niet oplossen van het probleem. Daar kan geen enkele afnemer iets aan doen eigenlijk.

Ze lossen het wel op Volgens mij zit er wel vaker een maand tussen het bekend worden dat iets lek is, en het beschikbaar zijn van een patch. De pest hier is mede dat er zo snel scripts op Github stonden die door iedere scriptkiddy gebruikt kunnen worden.

Het is een complex apparaat, en ze zullen dus behalve zoeken naar de oorzaak en vinden van een oplossing ook erg goed moeten controleren of die oplossing wel werkt en geen ongewenste neveneffecten heeft. Als de oplossing namelijk niet blijkt te werken of een ander lek introduceert dan is de imagoschade straks nog veel groter. En ze moeten het niet in één versie fixen, maar in vijf. Vandaar ook de staggered release date, eerst de nieuwste versies (met, hopelijk, de grootste install base. 12.1 is al behoorlijke tijd in maintenance phase), en dan de oudere versies.

Wat ik overigens niet snap ik waarom er geen fatsoenlijke VPN oplossing voor zit bij veel bedrijven?

Waar voor? Het is een reverse proxy en load balancer. Daar een VPN voor zetten zorgt er vooral voor dat jij eerst een VPN op moet zetten met Nu.nl / de Rabobank / de website van de gemeente om een afspraak in te plannen / ... voordat je die publieke diensten kunt gebruiken En VPN-software kan ook lek zijn.

Er is altijd een eerste aanspreekpunt, en de pech is nu dat het dit eerste aanspreekpunt is dat lek is.

[ Voor 22% gewijzigd door Paul op 19-01-2020 22:43 ]

[vso]

@Paul goed verhaal (punt)

Maar wat je eigenlijk zegt probleem inhoudelijk dat iemand gewoon heeft zitten slapen, want zover ik weet pak bv apache kan je dit soort situaties redelijk "eenvoudig" ontwijken. zeker als je compartmentalisation op 1 of andere manier toepast.

En dan heb ik het nog niet eens over de doorhop mogelijkheid..

En ja ik vind dat citrix best 24/7 hier aan had mogen werken ondanks de feestdagen.. (lees heftig bloeden) .. (ik heb wel medelijden met de mensen/coders die het wel opgemerkt hebben maar "just do it" te horen hebben gekregen. en nu dus dat issue mochten fixen)


tja kan je dit wel scharen tot een vunerability ? zoals ik al opmerk is dit relatief simpel af te vangen met een webserver .. applicatie.
Dat is geen rocket sience, net zo min als een test script/tool (jenkins) die dit soort dingen kan doorlopen.

Even voor de beeldvorming een "appliance" wat je nu hier schetst is niks anders als een simple custom pc/android ding met apache webserver draaiend .. met 1 tot (in jou geval 30) x websites.


sommige andere issues .. ssl, man in the middle en doorhoppen zijn min of meer gerelateerd je kan ding doen die niet eens bereikbaar horen te zijn .. afgezien dat je als citrix dat soort dingen niet eens wilt ondersteunen .. is het al slecht dat het kan.

goed dat gezegd hebbend .. als het slechte "code" is dan zou je het relatief makkelijk en snel kunnen fixen..
is het echter van de basis (zoals ik in deze post omschrijf) dan tja heb je aardige uitdaging(en)

[mutsje]

Reken maar dat Citrix hier 24/7 aan werkt. Echter is het een enorm stuk complex code wat ze 'even' moeten patchen. En nee men gaat niet op zwart men zet uitsluitend de netscaler / gateway uit en hierdoor is telewerken etc niet meer mogelijk. Steeds meer instellingen kiezen of uitsluitend ip adressen uit Nederland middels geoblocking of gewoon helemaal uit. Als de patch uitkomt zal ook niet iedere instelling gelijk na toepassen van de patch de zaak weer in de lucht brengen, er zullen eerst heel veel testen uitgevoerd worden van alle bekende methodieken om te kijken of men er alsnog doorheen kan komen. Ook zijn de cijfers van 'servers' die getroffen zijn niet geheel correct omdat sommige een false positief geven simpelweg omdat men de directories verplaatst heeft. Nu wachten tot andere grote vendor getroffen wordt. Het geeft de security bij veel instellingen in ieder geval opeens veel meer budget om toch nog security zaken door te voeren. Dat is dan ook weer positief.
Zoals jij het schets ' het is geen rocket sience' zou ik mee eerst eens in gaan lezen wat een netscaler allemaal kan en hierna je oordeel vellen.

[Paul]

vso schreef op vrijdag 17 januari 2020 @ 15:52:
Maar wat je eigenlijk zegt probleem inhoudelijk dat iemand gewoon heeft zitten slapen

Alle software heeft fouten Ook Apache. De ene wat groter dan de ander, en de impact verschilt ook van geval tot geval, maar niets is perfect. Ik weet dan ook niet of je kunt stellen dat iemand heeft zitten slapen. Misschien wel. Maar het kan ook een combinatie van factoren zijn, en we zijn allemaal mensen.

want zover ik weet pak bv apache kan je dit soort situaties redelijk "eenvoudig" ontwijken

Dat valt tegen. ".." is een geldig mechanisme in URLs, en wordt in relatieve URLs heel veel gebruikt. In absolute URLs kan ik me er zo geen voorstelling van maken waar je het nodig zou hebben maar ik ben geen webdeveloper.

Het gaat mis als je te vér omhoog kunt in de boom, maar dat kan bijvoorbeeld zo simpel zijn als een "off by one" error, door > te gebruiken ipv >= bijvoorbeeld. Geen idee of dat hier de oorzaak is, maar het geeft aan dat het niet altijd onmiddellijk duidelijk is dat je buiten je sandbox kunt komen.

En dan heb ik het nog niet eens over de doorhop mogelijkheid..

Wat is daarmee? Als je eenmaal ingelogd bent op een server en daar commando's kunt uitvoeren, dan kun je alles wat je met "normaal inloggen" ook kan. Dus ook connecties maken naar andere servers. Als jij thuis inlogt met je VPN naar de thuiswerkplek dan kun je ineens ook bij allemaal zaken waar je eerst niet bij kon. Dat is hetzelfde principe als wat er nu met de Netscaler speelt, men "logt in" op de Netscaler en kan daarna bij alles waar de Netscaler ook bij kan.

Even voor de beeldvorming een "appliance" wat je nu hier schetst is niks anders als een simple custom pc/android ding met apache webserver draaiend .. met 1 tot (in jou geval 30) x websites.

Nee, het is een doorgeefluik. Zie het een beetje als een firewall voor websites. De Netscaler host zelf niks, maar geeft ze door naar één of meer webservers. Door een reverse proxy of ADC (Application Delivery Controller) tussen de gebruiker en de webserver te zetten kun je meerdere webservers gebruiken, de load verdelen, een van de webservers offline halen voor maintenance zonder je site offline te halen, maar bijvoorbeeld ook bepaalde URLs blokkeren voor de ene bezoeken en vrijgeven voor de andere bezoeker, of aan de hand van het verzoek bepalen welke webserver iets af moet handelen.

sommige andere issues .. ssl, man in the middle en doorhoppen zijn min of meer gerelateerd je kan ding doen die niet eens bereikbaar horen te zijn .. afgezien dat je als citrix dat soort dingen niet eens wilt ondersteunen .. is het al slecht dat het kan.

Ik denk dat je niet goed doorhebt wat een reverse proxy is SSL decrypten, tussen de gebruiker en de webserver zitten, en bij die webserver kunnen zijn nu precies de dingen die een reverse proxy WEL moet kunnen

Zonder SSL decryption kun je het verzoek niet onderzoeken en kijken welke server het af moet handelen, of het een geldig verzoek is, en het scheelt ook een heleboel load op je webservers. Er lopen veel minder connecties van de reverse proxy naar de webserver dan van de gebruiker naar de reverse proxy, en iedere connectie die je minder hebt scheelt handshakes, uitwisselen van certificaten, afspreken van sleutels etc. etc.

Als de reverse proxy niet tussen jou en de webserver zit heeft'ie überhaupt geen invloed op de connectie. Kan er niet gekeken worden of de server het te druk is, of de server het überhaupt doet, etc.

En als de reverse proxy niet bij de webserver kan, dan kan hij de website ook niet aan jou laten zien

als het slechte "code" is dan zou je het relatief makkelijk en snel kunnen fixen..

Het is een enorm complex stuk software. Zelfs al hebben ze de oorzaak snel gevonden, dan nog wil dat niet zeggen dat de fix simpel is. Het is niet ongebruikelijk dat een kleine aanpassing op plek A, ergens bij plek H of I iets stuk maakt. En omdat het zo'n complex stuk software is (en ze vijf versies moeten onderhouden) moet je het ontzettend goed testen. Ik ben een tijdje programmeur geweest, en GOED testen is echt een vak apart. Dat kost een heleboel tijd.

[vso]

[~Paul tja aangezien je geen webdeveloper bent ... word dit soort dingen "lastig" omdat je 50/50 weet waarover je praat (no offence intended) en ik gok zelf naar je kennis
Maar ik wil niet op de man af en zijn kennis een discussie in gaan, vandaar no offence.

De kunst van hacken is de "gaten" vinden die er eigenlijk niet horen te zijn.. als we dat als basis gebruiken kan je gelijk een paar conclusies trekken die ik dus in de vorige post stel (en waar @mutsje wat "gaten" in tracht te prikken of het lukt dat laat ik aan de rest over

Om het even simpel te houden .. je beperkt de data invoer & toegang dat kan op verschillende plekken
- op het web pagina's laat je alleen een letters en cijfers toe. en je beperkt de invoer lengte.
- in je code doe je dat ook
- je beperkt de uitvoeren van instructies
- je damt in dat gebruikers toegang hebben tot .. (directories)
- je doet ongewenste data standaard naar de digitale prullenbak /dev/null

Code is niet complex, wat is er complex aan 0 of 1 ? het grote probleem is dat mensen eraan werken die niet goed afspraken kunnen volgen en andere doelen hebben dan netjes progammeren.
Code review kost geld, en is vaak van ondergeschikt belang.
Je wilt niet weten hoeveel fouten software bevat, puur uit history uit onbegrip.

Het onderhoud van software is niet complexer als het bijhouden van een magazijn, het nadeel van de onderdelen is dat deze ook weer magazijn(en) zijn en je dus tenzij je erinduikt enorm verstrengeld kan raken ..

Maar het blijven ja/nee diagrammen in de basis (iets meer mogelijkheden maar goed) ..

Dus als ".." een valide of invalide opdracht (ja/nee) ligt puur aan de locatie waar je het toestaat..
Binnen Apache (@mutsje & @Paul wat ik als voorbeeld nam .. kan je jailen, en dus beperken waar de gebruiker bij kan .. dit geld ook voor de commando's die toegankelijk zijn.. zo is "cd" waarmee ".." (en "." aangeroepen word iets wat je wilt beperken tot een bepaald niveau binnen de website.
En dit kan je ook doortrekken voor andere commando's die je eventueel toegankelijk wilt hebben.

Het zelfde voor het "doorgeven" van commando's tussen website A en B waar een (reverse) proxy voor kan zorgen.

Als je het snapt is het relatief simple materie, wat ik dus stel is dat Citrix in dit geval liever kiest voor snelheid dan kwaliteit .. Tuurlijk rolt er wel een kop, maar degene die de kop laat rollen was ook de gene die wellicht teveel druk heeft gezet op kwantiteit ipv kwaliteit.

[shoombak]

Volgens mij is het heel simpel, er is een mitigatie, echter niet voor een aantal versies in de 12.1 reeks. Het NCSC speelt paniekvoetbal en stuurt de wereld in dat de beste mitigatie is om je Netscalers uit te zetten. (Duh). Iedereen volgt als een mak schaap.

[anboni]

vso schreef op vrijdag 17 januari 2020 @ 19:44:
[~Paul tja aangezien je geen webdeveloper bent ... word dit soort dingen "lastig" omdat je 50/50 weet waarover je praat (no offence intended) en ik gok zelf naar je kennis
Maar ik wil niet op de man af en zijn kennis een discussie in gaan, vandaar no offence.

Om dit soort opmerkingen van iemand die zelf ook overduidelijk niet heel diep in de materie zit, moet ik altijd best wel gniffelen

Om het even simpel te houden .. je beperkt de data invoer & toegang dat kan op verschillende plekken
- op het web pagina's laat je alleen een letters en cijfers toe. en je beperkt de invoer lengte.
- in je code doe je dat ook
- je beperkt de uitvoeren van instructies
- je damt in dat gebruikers toegang hebben tot .. (directories)
- je doet ongewenste data standaard naar de digitale prullenbak /dev/null

Dat zijn inderdaad allemaal hele logische maatregelen ja. Vervolgens moet de theorie echter ook nog naar code omgezet worden en voor dit soort grote en complexe systemen, heb je het dus ook meteen over behoorlijke lappen code. En als je ergens in een check een > ipv >= opneemt, kan je al een potentieel lek geintroduceerd hebben wat makkelijk maanden of jaren onopgemerkt blijft.

[Paul]

vso schreef op vrijdag 17 januari 2020 @ 19:44:
[~Paul tja aangezien je geen webdeveloper bent ... word dit soort dingen "lastig" omdat je 50/50 weet waarover je praat (no offence intended) en ik gok zelf naar je kennis
Maar ik wil niet op de man af en zijn kennis een discussie in gaan, vandaar no offence.

Wat heb ik er als ADC-beheerder aan om te weten hoe ik een connectie met een MySQL database opzet of hoe ik een div een ander kleurtje kan geven? Een website ontwikkelen en een ADC beheren zijn twee compleet andere dingen. Maar prima, twijfel maar aan mijn kennis over het apparaat dat ik dagelijks beheer

Code is niet complex, wat is er complex aan 0 of 1 ?

Ik denk dat het verstandig is dat ik verder niet meer reageer...

shoombak schreef op vrijdag 17 januari 2020 @ 19:59:
Volgens mij is het heel simpel, er is een mitigatie, echter niet voor een aantal versies in de 12.1 reeks.

Dat is ook mijn interpretatie (en die van een aantal buitenlandse websites). Mogelijk heeft het NCSC meer bronnen dan wij maar dan zou het fijn zijn als die bronnen zich er zelf ook over uitspreken. Vooralsnog zie ik dit advies niet uitgesproken worden door andere partijen / landen.

Semi-random quote:

quote: https://www.bleepingcompu...ces-mitigations-may-fail/

When ZDNet reached out Citrix for comment yesterday about the NCSC recommendation, Citrix stood by its mitigations.

"The mitigations we published cover all supported versions of our software and contain detailed steps designed to stop a potential attack across all known scenarios. But all steps must be followed," Citrix Chief Information Security Officer Fermin Serna told ZDNet.

ZDNet is niet de beste (snelste, uitgebreidste, whatever) site om security info vandaan te halen, maar dit stukje is hier wel toepasselijk

[ Voor 42% gewijzigd door Paul op 18-01-2020 00:17 ]

[vso]

anboni schreef op vrijdag 17 januari 2020 @ 20:00:
[...]


Om dit soort opmerkingen van iemand die zelf ook overduidelijk niet heel diep in de materie zit, moet ik altijd best wel gniffelen

Dat moet ik juist om mensen die op de persoon spelen, ipv elkaar wijzer maken wat ik nu voor je ga doen ieder zijn ding zeg maar. jij en ik kunnen er gelukkig tegen toch ?

Dat zijn inderdaad allemaal hele logische maatregelen ja. Vervolgens moet de theorie echter ook nog naar code omgezet worden en voor dit soort grote en complexe systemen, heb je het dus ook meteen over behoorlijke lappen code. En als je ergens in een check een > ipv >= opneemt, kan je al een potentieel lek geintroduceerd hebben wat makkelijk maanden of jaren onopgemerkt blijft.

Dit is iemand die net 20 pagina's geschreven heeft op pagina 12 op regel 14 een komma verkeerd staat tja .. dat kan je als "fout' rekenen en daar zou men misschien een hele hetze over kunnen maken ..

In tegenstelling tot @mutsje en @Paul die naar mijn mening zeker wel weten waar ze over praten en zeker een bijdragen leveren oftewel de vraag beantwoorden .. want dat ontken ik in iedergeval niet .. is je omschrijving wat je in elk programma / hack tekst boek kan lezen ..

Paul legt bv netjes uit dat het een zeer complexe hack is, hoewel ik het wellicht niet zo complex vind (en dus dat uitleg) is het handig in een discussie wel toe te lichten .. en ik onderschat niet dat de eerder genoemden en anderen niet weet dat lappen code zeker wel een uitdaging zijn ..

maar je moet ook verder kunnen kijken citrix bv is een orgaan/apparaat dat niet zijn zaakjes op orde heeft. maar goed laten we inhoudelijk daarop verder gaan ik hoop dat jij en ik ook inhoudelijk op de materie kunnen blijven

[dcm360]

Je moet vooral even terzijde schuiven dat er raakvlakken zijn met webdevelopment, want die zijn er nauwelijks. Appliances als dit zijn firewalls die in hoge mate configureerbaar zijn en waarop software draait die complexe regelsets kan uitvoeren. Desondanks wordt de performance eerder gemeten in kloktikken dan milliseconden, want op pakketniveau moeten er miljoenen ip-pakketten per seconde verwerkt worden, en op applicatieniveau duizenden requests. Op dat niveau kan een ongelukkige reguliere expressie al het verschil maken tussen een werkende en nutteloze appliance.

[vso]

dcm360 schreef op zaterdag 18 januari 2020 @ 00:49:
Je moet vooral even terzijde schuiven dat er raakvlakken zijn met webdevelopment, want die zijn er nauwelijks. Appliances als dit zijn firewalls die in hoge mate configureerbaar zijn en waarop software draait die complexe regelsets kan uitvoeren. Desondanks wordt de performance eerder gemeten in kloktikken dan milliseconden, want op pakketniveau moeten er miljoenen ip-pakketten per seconde verwerkt worden, en op applicatieniveau duizenden requests. Op dat niveau kan een ongelukkige reguliere expressie al het verschil maken tussen een werkende en nutteloze appliance.

Moest wel ff goed lezen, wat je bedoelt dus ... als ik je niet 100% begrijp vergeef me aub

Tegenwoordig kan ik me zeer lastig voorstellen dat dergelijke appliances custom software draaien, dat maakt zoiets onnodig complex en duur .. immers het wiel is al uitgevonden en je praat een bekende standaard (die in dit hele verhaal "attacked" word)

en je kan nog verbaast staan hoeveel een zogeheten router on a disk kan verstouwen .. denk bv aan een raspberry pi b+ achtig device met 2 netwerkkaarten welliswaar .. met bv linux ..
bv men krijgt "doom" speelbaar op hp4000 laserprinter ..

Oke maar dat maakt je punt verder niet minder relevant..

[Oogje]

vso schreef op zaterdag 18 januari 2020 @ 08:29:
[...]

Moest wel ff goed lezen, wat je bedoelt dus ... als ik je niet 100% begrijp vergeef me aub

Tegenwoordig kan ik me zeer lastig voorstellen dat dergelijke appliances custom software draaien, dat maakt zoiets onnodig complex en duur .. immers het wiel is al uitgevonden

Wat versta je onder custom software en wie heeft het wiel al eens uitgevonden?
IMO zijn appliances altijd custom, meestal een gestripte Linux-variant en custom software van de leverancier aangezien die appliance voor een specifiek doel gemaakt wordt.

[vso]

@Oogje

custom is wat "in-house" gemaakt word, bv een moederbord voor de appliance .. of de softeware-gui

Wiel uitgevonden: firewalls en webserver apache/nginx bv zijjn heel erg customizeable en kan je opnemen in je eigen appliance/product. en voor dit soort doeleinden is dus 95% van je software niet custom made maar opensource En dat op (hopenlijk) maat geconfigureerd. temintste dat hoop ik hoe meer je generiek houd hoe meer attack vector je krijgt.

Je wilt dus de bare essentials hebben voor je Open Source. je interface (gui, api of commandline) kan custom made zin.

En waarom zou je HW of softeware ontwikkelen wat al goed werkt, en jij "mag" en kan ook geheel verbergen dat je producten van anderen gebruikt. Er zitten wel wat haken en ogen aan die met voeten getreden worden .. maar dat is een andere discussie.

Dus waarom zou je voor je appliance zelf een firewall of webserver opnieuw uitvinden ? de enige reden is dat functionaliteit mist maar ook dan kan je beter een add-on schrijven (custom made)

je werkt immers met een welk bekende standaard (tcp/ip) en de daarop liggende protocollen (http enzo)
ICA daarintegen is een ander punt maar die kan je 1:1 doorschuiven naar je Terminal server en of client. de appliance zorgt er voor dat je die TS-verbinding tot stand kan brengen.

[Paul]

vso schreef op zaterdag 18 januari 2020 @ 08:59:
Wiel uitgevonden: firewalls en webserver apache/nginx

En wie denk je dat die firewalls en webservers maakt?

Citrix en F5 zijn DE twee grote jongens op dit (ADC) gebied. nginx probeert mee te komen, en ik denk zelf ook zeker dat het wel een goed product is, maar het is geen Netscaler of F5. Qua Apache, dat gebruikt Citrix ook op de Netscaler. Een ADC is geen webserver. Er zijn functionaliteiten die wel een webserver nodig hebben, en dat deel laat Citrix dus door Apache doen. Het lijkt er op dat deze CVE nu net op dat stuk speelt: https://www.tripwire.com/...81-what-you-need-to-know/

Men vindt het wiel niet opnieuw uit door een Netscaler of F5 te kopen, men gebruikt JUIST bestaande wielen door een Netscaler (of F5) te kopen. Maar die wielen worden wel door iemand gemaakt, onderhouden, uitgebreid.

Nnginx of Apache inzetten waar je normaal een Netscaler of F5 neerzet is als een vrachtwagenband onder een Formule 1 auto zetten. Niks mis met die vrachtwagenband, maar het is niet het goede product op een F1 auto. En natuurlijk is dat een groot grijs gebied (welke analogie is ooit perfect?) en zijn er dingen die beide kunnen, maar je moet dingen gebruiken waar ze voor bedoeld zijn.

[Bezulba]

shoombak schreef op vrijdag 17 januari 2020 @ 19:59:
Volgens mij is het heel simpel, er is een mitigatie, echter niet voor een aantal versies in de 12.1 reeks. Het NCSC speelt paniekvoetbal en stuurt de wereld in dat de beste mitigatie is om je Netscalers uit te zetten. (Duh). Iedereen volgt als een mak schaap.

Ik ben het compleet niet mee eens dat het paniekvoetbal is. Dit is naar mijn idee 1 van de weinig keren dat er daadwerkelijk op zo'n schaal preventieve maatregelen genomen worden om een beveiligingslek tegen te gaan.

Enige vergelijkbare is denk ik het gedoe met de beveiligingscertificaten van diginotar (tor?) van een aantal jaar geleden.

De mentaliteit die veel vaker voorkomt is inderdaad "Och valt wel mee..." en dan ben je opeens het slachtoffer van ransomware...

Maar goed, blijkbaar weet jij het beter en is het inderdaad zwaar overtrokken.

[Paul]

Bezulba schreef op zaterdag 18 januari 2020 @ 13:25:
Ik ben het compleet niet mee eens dat het paniekvoetbal is. Dit is naar mijn idee 1 van de weinig keren dat er daadwerkelijk op zo'n schaal preventieve maatregelen genomen worden om een beveiligingslek tegen te gaan.

De 'paniekvoetbal' is niet 'Voer deze mitigerende stappen uit', dat deel is prima en inderdaad heel hard nodig. Wat als 'paniekvoetbal' wordt gezien is het advies om het hele ding uit te zetten, zonder dat ze daar substantiële bronnen bij plaatsen.

Gebaseerd op dingen die door Citrix zelf worden gezegd is de mitigatie alleen onvoldoende als je:
1) een van de paar specifieke, oude, versies draait
2) en de maatregelen zoals de fabrikant ze uiteenzet niet tot op de letter volgt, en maar de helft doet of het op een andere plek in je config hangt dan aangegeven.

Beide prima op te lossen zonder het ding uit te zetten. Maar het NCSC zegt toch dat de 'fix' (wat is een goed Nederlands woord voor "mitigerende maatregelen"? ) "onbetrouwbaar" zou zijn en je het ding beter uit kunt zetten. Citrix heeft daarop als reactie gegeven dat ze achter hun 'fix' staan zolang je deze ook daadwerkelijk uitvoert zoals ze aangeven.

Of je het statement van Citrix gelooft, dat is natuurlijk ieder voor zich. Ik denk dat ze bewezen hebben alles op tafel te leggen wat ze weten (eergisteren uitbreiding van de CVE met SDWAN, gisteren de waarschuwing dat zelf aan de maatregelen prutsen mis gaat op bepaalde firmware versies), en dat ze er veel meer mee te verliezen hebben dan te winnen om zoiets stil te houden.

[SMSfreakie]

gevalletje met de wortels toch iets dieper dan gedacht denk ik zo

[Wim-Bart]

De fix van Citrix is afdoende, maar ik heb nu al een paar situaties gezien waar men hem niet goed heeft toegepast. Ik kan gissen om de reden, maar ik heb bij een oud klant gezien, dat ze daar versie 12.1.nogwat draaiden omdat upgrade niet lukte zonder dat er twee URL Virtual Services niet meer goed functioneerden en een web portaal kapot ging. En wat bleek, wanneer de mitigatie uitgevoerd werd conform Citrix werkte die twee Services ook niet meer. Het probleem met de Netscaler is, dat je, wanneer je op de "beheer" interface iets niet voor elkaar krijgt, je hele mooie configuraties op de CLI aan de praat kan krijgen. Het nadeel is dan ook weer dat deze dan stuk kunnen lopen bij een upgrade.

Overigens is een Netscaler een product wat grotendeels op Open Source draait en ik heb mij er niet in verdiept, maar ligt het issue ook bij een open source component, waardoor het fixen meer tijd kost.

[Rolfie]

vso schreef op zaterdag 18 januari 2020 @ 08:59:
custom is wat "in-house" gemaakt word, bv een moederbord voor de appliance .. of de softeware-gui

De Netscaler SDX draait op Dell hardware, of op 1 van de grote Hypervisors die bestaan.

Wiel uitgevonden: firewalls en webserver apache/nginx bv zijjn heel erg customizeable en kan je opnemen in je eigen appliance/product. en voor dit soort doeleinden is dus 95% van je software niet custom made maar opensource

Wat denk je dat F5 en Citrix gebruiken? ADC heeft ook gewoon Apache draaien, maar juist in die 5% is de fout.

En dat op (hopenlijk) maat geconfigureerd. temintste dat hoop ik hoe meer je generiek houd hoe meer attack vector je krijgt.

Je wilt dus de bare essentials hebben voor je Open Source. je interface (gui, api of commandline) kan custom made zin.

En waarom zou je HW of softeware ontwikkelen wat al goed werkt, en jij "mag" en kan ook geheel verbergen dat je producten van anderen gebruikt. Er zitten wel wat haken en ogen aan die met voeten getreden worden .. maar dat is een andere discussie.

Dus waarom zou je voor je appliance zelf een firewall of webserver opnieuw uitvinden ? de enige reden is dat functionaliteit mist maar ook dan kan je beter een add-on schrijven (custom made)

je werkt immers met een welk bekende standaard (tcp/ip) en de daarop liggende protocollen (http enzo)
ICA daarintegen is een ander punt maar die kan je 1:1 doorschuiven naar je Terminal server en of client. de appliance zorgt er voor dat je die TS-verbinding tot stand kan brengen.

Eigenlijk precies wat iedere loadbalancer doet van de grote merken die dit soort software maken.
Juist de Management Interface of extra models die integreren maakt deze software zo goed.

[kodak]

Paul schreef op zaterdag 18 januari 2020 @ 15:16:
[...]
De 'paniekvoetbal' is niet 'Voer deze mitigerende stappen uit', dat deel is prima en inderdaad heel hard nodig. Wat als 'paniekvoetbal' wordt gezien is het advies om het hele ding uit te zetten, zonder dat ze daar substantiële bronnen bij plaatsen.
....
Of je het statement van Citrix gelooft, dat is natuurlijk ieder voor zich.

De term paniekvoetbal gaat toch over een situatie waar iemand op basis van emotie een reactie geeft? Maar als je niet weet waarop een reactie is gebaseerd lijkt me ook niet dat er makkelijk valt te oordelen of iets wel of niet paniekvoetbal is. Ook niet door er een vertrouwenskwestie van te maken. Het hebben van vertrouwen in de een hoeft toch niet per definitie te betekenen dat je wel of geen vertrouwen hebt in een ander? Stel iedereen had dezelfde mening, alleen de een geeft geen onderbouwing en de ander heel veel. Als je dan vertrouwen hebt in de persoon met heel veel onderbouwing dan zegt dat toch ook niet dat de betrouwbaarheid van de ander dus afwezig is op basis van hoeveelheid of zelfs maar gebaseerd zou zijn op emotie? Hooguit dat je minder vertrouwen hebt in onderbouwing puur op basis van de hoeveelheid.

[Paul]

Rolfie schreef op zaterdag 18 januari 2020 @ 20:40:
De Netscaler SDX draait op Dell hardware, of op 1 van de grote Hypervisors die bestaan.

Afaik Supermicro voor de hardware (de BMC / IPMI is erg herkenbaar ), de hypervisor op de SDX is XenServer Een VPX
kun je inderdaad op bijna iedere (grote) hypervisor draaien[/]

kodak schreef op zaterdag 18 januari 2020 @ 23:09:
De term paniekvoetbal gaat toch over een situatie waar iemand op basis van emotie een reactie geeft? Maar als je niet weet waarop een reactie is gebaseerd lijkt me ook niet dat er makkelijk valt te oordelen of iets wel of niet paniekvoetbal is.

Juist omdat het NCSC geen bronnen plaatst lijkt het op paniekvoetbal. Citrix zelf zegt "De fix is afdoende", NCSC zegt "Wij denken van niet", zonder daarbij te vermelden waarom ze dat denken. Blijkbaar hebben ze geen vertrouwen in de statements van Citrix.

Het probleem hier is dat iedereen een andere mening heeft. En dan wordt het lastig je eigen mening te vormen. Dus ga je op zoek naar "bewijs" of statements van mensen die je vertrouwd. Ik vertrouw het NCSC over het algemeen prima, maar ik vertrouw Citrix over het algemeen ook prima. En toch geven ze tegenstrijdige berichten... En nu?

[Brahiewahiewa]

Paul schreef op zondag 19 januari 2020 @ 16:42:
[...]
Ik vertrouw het NCSC over het algemeen prima, maar ik vertrouw Citrix over het algemeen ook prima. En toch geven ze tegenstrijdige berichten... En nu?

Da's toch simpel? Citrix veegt z'n eigen bordje schoon: "als je precies doet wat wij zeggen is er niets aan de hand". Het NCSC heeft ondertussen al zoveel gevallen gezien waar de beheerders er niet in slaagden de stappen die door Citrix worden aangeraden correct uit uit te voeren, zodat zij adviseren om de netscaler maar uit te zetten

[kodak]

Paul schreef op zondag 19 januari 2020 @ 16:42:
[Juist omdat het NCSC geen bronnen plaatst lijkt het op paniekvoetbal. Citrix zelf zegt "De fix is afdoende", NCSC zegt "Wij denken van niet", zonder daarbij te vermelden waarom ze dat denken. Blijkbaar hebben ze geen vertrouwen in de statements van Citrix.

Het probleem hier is dat iedereen een andere mening heeft. En dan wordt het lastig je eigen mening te vormen. Dus ga je op zoek naar "bewijs" of statements van mensen die je vertrouwd. Ik vertrouw het NCSC over het algemeen prima, maar ik vertrouw Citrix over het algemeen ook prima. En toch geven ze tegenstrijdige berichten... En nu?

Rationeel nadenken over wat een gepaste keuze is lijkt me alvast beter dan het irrationeel maar te gooien op een beschuldiging en het emotioneel te maken. Het leven zit vol met keuzes van anderen zonder dat we weten waarom iemand echt een keuze maakt. Dus misschien is het dan een oplossing om te bedenken wat de gevolgen kunnen zijn als we als citrixgebruikers een keuze kunnen maken. Dus wat zijn de risico's als je toch een keuze maakt?

[Paul]

Brahiewahiewa schreef op zondag 19 januari 2020 @ 17:13:
Het NCSC heeft ondertussen al zoveel gevallen gezien waar de beheerders er niet in slaagden de stappen die door Citrix worden aangeraden correct uit uit te voeren, zodat zij adviseren om de netscaler maar uit te zetten

Sorry, maar als je als beheerder niet kunt copy/pasten dan is het misschien beter als je inderdaad de boel uitzet. Veel simpeler kan Citrix de stappen niet maken.

Niet dat ik Citrix op wil hemelen, ze hebben een paar flinke ballen laten vallen, maar als je die stappen niet WIL uitvoeren, of er zelf aan gaat zitten prutsen, prima, maar geef dan niet Citrix de schuld

kodak schreef op zondag 19 januari 2020 @ 17:38:
Rationeel nadenken over wat een gepaste keuze is lijkt me alvast beter dan het irrationeel maar te gooien op een beschuldiging en het emotioneel te maken.

Wie doet dat hier? Ik niet... Ik denk rationeel na over de diverse bronnen, kijk wat anderen er van zeggen, en bepaal welke van de twee adviezen ik opvolg.

Als iemand het advies van het NCSC opvolgt, prima. Als iemand het advies van Citrix opvolgt, ook prima. Maar beide tegelijkertijd kan niet... Nu ja, het NCSC heeft ondertussen hun advies afgezwakt, maar het gaat om het idee. Als je het advies van het NCSC opvolgt dan denk je dus dat de maatregelen die Citrix noemt niet afdoende zijn (ook wel: je hebt niet voldoende vertrouwen in die maatregelen). En als je het advies van het NCSC niet opvolgt dan denk je dus dat ze overtrokken reageren. Ook dat valt onder 'vertrouwen' te scharen. Derde optie is natuurlijk dat je vindt dat de gevolgen ervan voor je organisatie te groot zijn, dan denk je NCSC en doe je Citrix

Dat heeft niks met emotie of beschuldigingen te maken. Of het irrationeel is; tja, als het NCSC hun bronnen er niet bij zet kan ik dat niet beoordelen Ik denk dat je teveel lading geeft aan het woord "vertrouwen"; in ieder geval een stuk meer dan ik

[Brahiewahiewa]

Paul schreef op zondag 19 januari 2020 @ 22:27:
[...]
Sorry, maar als je als beheerder niet kunt copy/pasten dan is het misschien beter als je inderdaad de boel uitzet. Veel simpeler kan Citrix de stappen niet maken.

Dat is dus precies wat het NCSC zei, maar dan wat politiek correcter geformuleerd ;o)

[kodak]

Paul schreef op zondag 19 januari 2020 @ 22:27:
[...]
Wie doet dat hier? Ik niet... Ik denk rationeel na over de diverse bronnen, kijk wat anderen er van zeggen, en bepaal welke van de twee adviezen ik opvolg.

De reactie en discussie is op de uitleg hoe/of een situatie paniekvoetbal genoemd zou kunnen worden en waarom wel/niet.

[Paul]

Brahiewahiewa schreef op maandag 20 januari 2020 @ 09:02:
Dat is dus precies wat het NCSC zei, maar dan wat politiek correcter geformuleerd ;o)

Dan komen we dus bij het tweede stukje dat ik typte: Dan moet men niet doen alsof het aan Citrix ligt

kodak schreef op maandag 20 januari 2020 @ 11:59:
De reactie en discussie is op de uitleg hoe/of een situatie paniekvoetbal genoemd zou kunnen worden en waarom wel/niet.

Ik ben bang dat ik die zin niet goed kan ontleden, de "is" halverwege brengt mijn parser in de war Noem je mij emotioneel, irrationeel en beschuldigend, of het NCSC? Als dat op mij slaat raad ik je aan mijn vorige reactie nog een keer te lezen, als je op het NCSC doelt dan weet ik niet of ik daar zo'n sterke mening over heb maar kan ik de jouwe wel begrijpen

[kodak]

Paul schreef op maandag 20 januari 2020 @ 13:18:
Ik ben bang dat ik die zin niet goed kan ontleden, de "is" halverwege brengt mijn parser in de war

Vertaling: het was een discussie, niemand hoeft zich aangevallen te voelen.

[CAPSLOCK2000]

Paul schreef op zondag 19 januari 2020 @ 22:27:
Niet dat ik Citrix op wil hemelen, ze hebben een paar flinke ballen laten vallen, maar als je die stappen niet WIL uitvoeren, of er zelf aan gaat zitten prutsen, prima, maar geef dan niet Citrix de schuld

Het gaat niet om schuld. Het gaat om zekerheid en duidelijkheid.

De afgelopen maand heeft Nederland een paar pittige cyberaanvallen over zich heen gekregen zoals de ransomware-aanval in Maastricht. De IT-managers van NL zijn momenteel bloednerveus. Dat er wat problemen waren met de workaround heeft voor nog veel meer onrust en onzekerheid gezorgd. Tal van organisaties dachten het probleem te hebben opgelost maar dat bleek toch niet zo te zijn, en er wordt actief misbruik van gemaakt.

Misschien is het advies op technische gronden wel erg streng, maar veiligheid is meer dan alleen techniek, en het NCSC zorgt voor het hele land, niet (alleen) voor individuele organisaties. Gezien de onrust in het land snap ik dat er is gekozen voor de harde aanpak. Liever nu wat ongemak dan dat er opeens verschillende grote instellingen tegelijk plat gaan door ransomware.


Iedereen die niet helemaal up-to-date was en/of niet onmiddellijk de patch heeft toegepast kan in principe gehackt zijn, zelfs als dat nu nog niet zichtbaar is.

Als je je IT echt goed op orde hebt dan is het niet nodig om Citrix uit te schakelen. Als je zeker bent van je zaak kun je het advies van het NCSC negeren. Het is een advies, geen eis. Als je niet zo zeker bent van je zaak en het NCSC nodig hebt om een oordeel te vormen dan kun je misschien beter het zekere voor het onzekere nemen.

Als dat betekent dat je hele organisatie plat gaat dan is het misschien een goed moment om nog eens na te denken over je afhankelijkheid van je infrastructuur, en hoeveel je over hebt voor de beveiliging daar van.

[ Voor 10% gewijzigd door CAPSLOCK2000 op 20-01-2020 14:30 ]

[Paul]

CAPSLOCK2000 schreef op maandag 20 januari 2020 @ 14:25:
Het gaat niet om schuld. Het gaat om zekerheid en duidelijkheid.
[knip]
Dat er wat problemen waren met de workaround heeft voor nog veel meer onrust en onzekerheid gezorgd.

Het gaat me er niet om dat ze met dit advies komen, maar hoe De maatregelen die Citrix noemt zijn erg duidelijk Dat ze niet werken als je ze niet doorvoert mag logisch zijn. Dat ze iets anders doen dan Citrix zegt als je ze maar deels doorvoert, of op een andere manier dan voorgeschreven doorvoert, lijkt me ook evident.

Ik vind het advies "Als je de maatregelen niet op de juiste manier wil doorvoeren, zet dan het apparaat uit" prima, maar het NCSC bracht het alsof het aan de maatregelen zelf lag. En in die context vind ik zeker wel dat ze Citrix onder de bus gooien.

Misschien is het advies op technische gronden wel erg streng, maar veiligheid is meer dan alleen techniek, en het NCSC zorgt voor het hele land, niet (alleen) voor individuele organisaties. Gezien de onrust in het land snap ik dat er is gekozen voor de harde aanpak. Liever nu wat ongemak dan dat er opeens verschillende grote instellingen tegelijk plat gaan door ransomware.

Eens. Maar haal dan niet Citrix nog verder onderuit dan ze zelf al gedaan hebben door de oorzaak van deze hele zware maatregel ook bij hen te leggen

[RobbieB]

Beste overzichtelijke toelichting die ik tot dusver heb kunnen vinden en ook richting mijn management kan sturen...

Met name het bericht van het NCSC van vandaag dat als je voor 9 januari niet gepatcht hebt, je eruit van mag gaan dat je gecomprimitteerd bent gaat veel impact hebben.