Badlock, dit is bizar…

Roel1

12 april 2016, de publicatie van Badlock, donkere wolken pakken zich samen boven het IT landschap. Volgens de site www.badlock.org kan er iets bekend worden gemaakt over deze kwetsbaarheid en dat  kan voor de IT-infrastructuur zorgen voor hel en verdoemenis. We kunnen er maar beter klaar voor zijn, of anders....

 

Het lastige is dat we niet eens weten wat er nu precies aan de hand is. Is dit iets dat daadwerkelijk heel serieus is, valt het mee, of is het zelfs een 1 april grap? Hoe bereid je je op zoiets voor?

File locking en CIFS

File locking is een mechanisme dat voorkomt dat een bestand dat geopend is door de ene gebruiker ook door een andere gebruiker geopend wordt. Het moet voorkomen dat twee gebruikers, of processen, tegelijkertijd wijzigingen in een bestand gaan aanbrengen, waardoor de inhoud van dat bestand mogelijk corrupt wordt. Deze functie is aanwezig in de meeste bestandssystemen en zit in de kern van het besturingssysteem.

Het Common Internet File System (CIFS) is een standaard die zowel op Windows als op Unix/Linux systemen gebruikt wordt om bestandssystemen via het netwerk te kunnen benaderen. Zo kunnen bestanden op de ene computer door een gebruiker op een andere computer gebruikt worden. Ook CIFS kent een file locking mechanisme.

Wat is er aan de hand?

Wanneer we de broncode die met locking te maken heeft van de CIFS implementatie voor Unix/Linux, dan valt meteen het commentaar van de programmeur op:

"/* this is quite bizarre - the spec(ifications) says we must lie about the length! */"

Het lijkt er dus op dat er een probleem zit in de specificaties van het CIFS protocol zelf. Het eerste dat dan bij mij in mijn gedachte opkomt is dat dit weleens gekoppeld zou kunnen zijn aan een ‘buffer overflow’.

Een aanvaller die gebruik maakt van een buffer overflow doet dit meestal of om een systeem te verstoren of uit de lucht te halen, of om de controle over het systeem over te nemen. File locking is een kernfunctie van een besturingssysteem. Het proces draait bijna altijd met hoge privileges, dus als een aanvaller met gebruikmaking van Badlock het systeem overneemt, zal hij waarschijnlijk ook meteen brede toegang tot dat systeem hebben.

Zeker als dit laatste echt het geval is, dan is het belangrijk dat we zijn voorbereid op de publicatie op 12 april, die trouwens samenvalt op Microsoft's maandelijkse ‘Patch Tuesday’.

Impact

Deze bug heeft naar verwachting impact op alle systemen die bestanden delen over het netwerk. In het datacentrum zijn dat minimaal alle ‘Active Directory Domain Controllers’ en file servers. Systemen die geen bestanden delen met gebruikers lijken misschien veilig, maar let er wel op dat bijna alle Windows systemen ook ‘hidden shares’ presenteren. Ze kunnen dus bestanden delen, ook al adverteren ze dit niet.

In een goede opzet van het datacentrum wordt toegang tot bestandssystemen waar gebruikers niet bij hoeven en de hidden shares geblokkeerd door één of meer firewalls. Let er wel op dat als Badlock inderdaad gebruikt kan worden voor het overnemen van systemen, een aanvaller via een kwetsbaar systeem alsnog bij andere, niet-kwetsbare of afgeschermde kwetsbare systemen kan komen.

Ook desktopsystemen zitten in de gevarenzone. In een beheerde omgeving hebben alle desktopsystemen een hidden share, om beheerders toegang te geven tot de lokale harddisk voor onderhoudswerkzaamheden. Zonder additionele maatregelen in de infrastructuur kunnen aanvallers dus alle pc’s bereiken. En we weten dat in elke gebruiker potentieel een aanvaller schuilt.

Voor een klein bedrijf hoeft dit niet direct een probleem te zijn, maar voor een school met veel leerlingen, die diezelfde pc's ook nog eens gebruiken voor het afnemen van toetsen wel.

Voorbereiden

Hoe bereid je je voor op iets dat aan de horizon hangt, maar waarvan niet duidelijk is wat het nu precies is?

Stap 1: bereid de organisatie voor

Als eerste moet de organisatie worden voorbereid. Op de beheer afdeling moeten de juiste mensen aanwezig zijn, zodat er gehandeld kan worden. Op Patch Tuesday worden de patches meestal tussen 17:00 en 18:00 onze tijd vrijgegeven.

Claim een onderhoudsvenster op 12 april. Bereid de gebruikers erop voor dat er onderbrekingen kunnen zijn in de dienstverlening op de 12e.

En als er dan toch gecommuniceerd wordt, bereid de gebruikers ook voor op de eventualiteit dat de exacte inhoud van Badlock bekend wordt voordat de patch er is. Afhankelijk van de daadwerkelijke impact kan het bijvoorbeeld nodig zijn om systemen met vertrouwelijke informatie af te sluiten.

Stap 2: bereid de infrastructuur voor

Zelfs in deze tijd van aandacht voor beveiliging komt het nog veel voor dat toegang voor gebruikers niet is beperkt tot de systemen waar zij echt toegang toe moeten hebben. Zo is het bijvoorbeeld in veel desktop omgevingen helemaal niet nodig dat PC's onderling elkaar kunnen benaderen. Waarom blokkeren we die toegang dan niet? Dit beperkt de impact van Badlock op het pc-landschap enorm en creëert dus meer tijd voor de beheerders om hun werk te doen.

Hetzelfde geldt voor het datacentrum. Daarbij kun je in overleg vooraf met de eigenaar van een systeem of databron zelfs beslissen om bij dreiging systemen met daarop zeer cruciale of vertrouwelijke data tijdelijk niet beschikbaar te maken. Of dit haalbaar is blijkt bijvoorbeeld uit de classificatie van de data. Als de beschikbaarheidsattribuut niet op het hoogste niveau staat is het de moeite waard om de eigenaar te vragen of deze maatregel haalbaar is.

Het voorbereiden van de infrastructuur is ook het beste wapen tegen het voortijdig bekend worden van de inhoud van Badlock. Let wel, het is een aanname dat de precieze inhoud nog niet bekend is, maar iedereen die programmacode kan lezen, kan in essentie de ontdekken waar het om gaat. De Unix/Linux implementatie is Open-Source.

Stap 3: als dit, dan dat

De exacte impact is op dit moment onbekend. Wat wel kan is dat er nu al een scenarioplanning wordt gemaakt met daarin de meest waarschijnlijke scenario’s Vragen die je jezelf kunt stellen zijn o.a.:

  1. Stel dat misbruik niet, of wel heel eenvoudig is, welke tijdslijnen koppel ik hier dan aan voor het oplossen van het probleem?
  2. In welke gevallen beperk ik de toegang tot bepaalde systemen?
  3. In welke gevallen sla ik het testen van de patch over?

Normaal gesproken moet alles dat in een productie omgeving uitgerold wordt getest zijn. Maar stel dat je drieduizend pc's in je landschap hebt en je niet in staat bent al deze pc's voor woensdagochtend opnieuw in te richten, dan zou je de beslissing kunnen nemen om de patch on-getest uit te rollen.

Ter afsluiting

Er zijn dus best wat zaken die gedaan kunnen worden als voorbereiding. Het is de moeite waard deze voorbereiding goed in te zetten. Het draaiboek is immers herbruikbaar voor het volgende incident van deze omvang. Daarbij, de Wet van Murphy stelt dat als je goed voorbereid bent, dit een storm in een glas water blijkt te zijn.

Hoe je je IT-landschap zo bouwt dat de impact van dit soort incidenten zo minimaal mogelijk is? Bakkie?

Deel dit bericht via:Tweet about this on TwitterShare on LinkedInEmail this to someoneShare on FacebookShare on Google+Pin on PinterestPrint this page

Door de site te te blijven gebruiken, gaat u akkoord met het gebruik van cookies. meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten