Er zijn drie dingen waar u zeker van kunt zijn in het leven: overlijden, belastingen en nieuwe CVE’s. Voor organisaties die op CentOS 8 vertrouwen, is het onvermijdelijke nu gebeurd, en het duurde niet lang. Slechts twee weken na het bereiken van het officiële einde van het leven, brak er iets spectaculairs en vertrok CentOS 8 gebruikers met een groot risico op een ernstige aanval – en zonder ondersteuning van CentOS.
Je zou denken dat dit probleem een aanzienlijk aantal organisaties niet langer treft, omdat bedrijven inmiddels zouden zijn overgestapt van CentOS 8 naar een besturingssysteem dat actief wordt ondersteund door leveranciers. Ondersteuning van leveranciers is immers van cruciaal belang voor beveiliging en naleving.
Maar zoals altijd met deze dingen, kun je erop rekenen dat een groot deel van de CentOS 8-gebruikers doorgaat met een niet-ondersteund besturingssysteem, ondanks dat ze zich bewust zijn van de risico’s. Nu dat risico zich aan het uitkristalliseren is, gebruiken we dit artikel om te onderzoeken: CVE-2021-4122, de nieuw ontdekte kwetsbaarheid in LUKS-codering, en om uw opties te bespreken om deze te verminderen.
Wacht, wat is LUKS?
Dus wat is LUKS? LUKS staat voor Linux Unified Key Setup en is een mechanisme dat wordt gebruikt in door Linux aangedreven systemen om onder andere volledige schijfversleuteling te ondersteunen. Het wordt in veel “best practice”-gidsen aanbevolen als een essentiële systeemverhardingsoptie voor IT-teams die op beveiliging gericht zijn.
Hoe werkt LUKS? Welnu, tijdens de systeemimplementatie kunt u een partitie maken die alleen leesbaar is – dwz de gegevens erin zijn alleen begrijpelijk – met een door de gebruiker verstrekt wachtwoord. LUKS is vrij complex en veel beveiligingssystemen werken samen met LUKS, maar een uitgebreide LUKS-gids is niet het doel van dit artikel.
Het hebben van een volledig versleutelde schijf (block device in Linux “speak”) zorgt ervoor dat de gegevens veilig zijn voor nieuwsgierige blikken, zelfs als ze in rust zijn, wat betekent dat een aanvaller die bijvoorbeeld een laptop steelt, nog steeds niet in staat is om de vertrouwelijke gegevens in het.
U kunt verder bouwen op beveiliging door een specifiek blokapparaat aan een specifieke computer te koppelen via TPM (Trusted Platform Module). Dat voegt nog een hindernis toe voor een aanvaller, waardoor het moeilijker wordt om versleutelde gegevens fysiek van een machine te halen en deze aan te sluiten op een krachtig systeem met als doel brute-forcering van de toegang tot de gegevens. Hoewel, zoals altijd, hoe groot de kans is dat dit lukt, afhangt van de rekenkracht, het geselecteerde coderingsalgoritme en puur geluk.
Over het algemeen biedt LUKS uitstekende bescherming en om die reden wordt er vaak op vertrouwd om systemen in verschillende organisaties te beveiligen.
De LUKS-fout begrijpen
CVE-2021-4122 werd eind vorig jaar toegewezen, maar een volledig begrip van de veiligheidsrisico’s rond LUKS is pas onlangs ontstaan. Het blijkt dat het mogelijk is om, in ieder geval gedeeltelijk, een met LUKS versleutelde schijf te ontsleutelen en toegang te krijgen tot de gegevens erop zonder het wachtwoord te bezitten dat wordt gebruikt om de versleuteling te configureren.
Een belangrijke LUKS-functie is de mogelijkheid om de sleutel die wordt gebruikt om een bepaald apparaat te versleutelen, on-the-fly te wijzigen. U zou dit bijvoorbeeld doen voor geplande sleutelwisselingen in omgevingen met een hoge beveiliging.
Deze functie voor on-the-fly hercodering betekent dat het apparaat beschikbaar blijft tijdens het sleutelwijzigingsproces. Het wordt “online hercodering” genoemd, wat verwijst naar de mogelijkheid om een schijf opnieuw te coderen met een andere sleutel terwijl deze online is en actief wordt gebruikt.
Tijdens dit proces is een kwetsbaarheid vastgesteld. Het blijkt dat als je weet wat je doet, je deze bewerking kunt uitvoeren zonder het originele, huidige wachtwoord te bezitten. Ook zonder wachtwoord kunt u een hercodering aanvragen.
Door gebruik te maken van de fout, lijkt dit proces te zijn afgebroken en zouden sommige gegevens onversleuteld beschikbaar worden gesteld. Op geen enkel moment ervaart het apparaat afwijkend gedrag, dus het zou moeilijk zijn om een aanvaller te zien die de bewerking uitvoert door alleen maar naar de status van het geblokkeerde apparaat te kijken.
Sysadmins wordt sterk aangeraden om cryptsetup, het pakket dat LUKS ondersteunt, te upgraden op alle systemen onder hun controle, aangezien de kwetsbaarheid kan leiden tot het vrijgeven van informatie.
Ok, dus ik zal gewoon patchen en verder gaan…?
Precies. Dat is wat elke systeembeheerder op zijn systeem zou moeten doen: het getroffen pakket vervangen. Maar voor sommige systeembeheerders is dit makkelijker gezegd dan gedaan. Welke systeembeheerders zullen het moeilijk hebben? Je raadt het goed – die nog steeds afhankelijk zijn van CentOS 8.
De meeste leveranciers waren vroegtijdig gewaarschuwd voor de bug en bieden al bijgewerkte pakketten voor hun distributies. En net hetzelfde met Red Hat, dat CentOS ondersteunt. Maar nu CentOS 8 niet langer officieel wordt ondersteund, zal er geen CentOS 8-patch voor de LUKS-fout verschijnen.
Voor gebruikers van CentOS 8 ziet het er dus vrij somber uit. Niet-gepatchte systemen zijn kwetsbaar voor gegevensdiefstal vanwege een gepubliceerde, algemeen bekende fout. Het is een ernstige situatie en op de een of andere manier moet u up-to-date gepatchte versies van het getroffen pakket implementeren.
Niets doen is geen optie als vertrouwelijke gegevens gevaar lopen. En in wezen zijn al uw gegevens vertrouwelijk en niet voor openbaarmaking (anders zou het al openbaar zijn gemaakt), en u vertrouwt op een volledige schijfversleutelingsoplossing zoals LUKS, juist om openbaarmaking te voorkomen.
Uw patch-opties als u nog steeds op CentOS 8 zit
Er zijn twee paden beschikbaar voor systeembeheerders die afhankelijk zijn van getroffen Linux-systemen die aan het einde van hun levensduur werken. Een optie is om de upstream-projectbron te downloaden en deze lokaal te compileren, waardoor een vervangend systeempakket wordt gemaakt. De andere optie is om te tekenen bij een leverancier van uitgebreide ondersteuning die de patches levert die niet langer door de oorspronkelijke leverancier zijn uitgebracht.
De build-it-locally-aanpak heeft nadelen. Ten eerste houdt de oorspronkelijke broncode van het project geen rekening met een specifieke distributie. Elke distributie of familie van distributies heeft allemaal hun eigen eigenaardigheden. De RHEL-familie, waartoe ook CentOS behoort, zal deze eigenaardigheden ook hebben.
Dat omvat zaken als binaire locaties, configuraties voor het starten van services, instellingen, enzovoort. Uw lokale team zal deze handmatig moeten aanpassen. Of uw lokale IT-team over de nodige expertise beschikt, is een andere vraag. Evenzo, met technische teams die over het algemeen onder druk staan om dingen voor elkaar te krijgen, bestaat het risico dat uw doe-het-zelf-patching-inspanningen worden vertraagd. Ook op de LUKS projectpagina zelf, is er dit onheilspellende “Geef altijd de voorkeur aan distro-specifieke build-tools boven het handmatig configureren van cryptsetup”.
Uw alternatief is om leveranciers van uitgebreide ondersteuning te beschouwen als een betrouwbare, kosteneffectieve en gemakkelijkere benadering om dit probleem aan te pakken. TuxCare’s uitgebreide levenscyclusondersteuning service doet precies dat. TuxCare levert patches van hoge kwaliteit voor distributies aan het einde van de levensduur zoals CentOS 8 en doet dit op tijd.
Bovendien krijgt u ook volledige ondersteuning voor patches. Implementatie is eenvoudig, u implementeert TuxCare-patches net zo gemakkelijk als door de leverancier ondersteunde patches.
Je moet handelen – nu
Als u besluit om niet voor externe ondersteuning te gaan, moet u toch nú iets doen om uw systemen te beschermen tegen de nieuwe kwetsbaarheid. Je zou kunnen besluiten om de kogel door de bocht te nemen en cryptsetup en zijn afhankelijkheden lokaal te compileren, en de implementatie op al je systemen uit te voeren.
Maar het is zeker niet de laatste CVE die uitkomt die invloed heeft op CentOS 8. Om je een idee te geven van de omvang van waar we het over hebben: zelfs vandaag de dag komen er nog steeds kwetsbaarheden naar buiten die invloed hebben op CentOS 6-systemen. Hoe levensvatbaar is het op de lange termijn om te blijven omgaan met een continue stroom CVE’s die van invloed zijn op CentOS 8?
Mogelijk gebruikt u op dit moment CentOS 8 omdat u om de een of andere reden niet naar een alternatief kon migreren. Het kan compatibiliteit, ondersteuning of een van de vele redenen zijn.
Kwetsbaarheden stoppen niet bij de EOL-datum, dus maak het leven van uw IT-teams gemakkelijker, veiliger voor uw beveiligingsprofessionals en voldoe aan de nalevingsvereisten rond patching voor uw bedrijf – bekijk TuxCare’s familie van diensten, en in het bijzonder Extended Lifecycle Support. Het is een solide manier om doorlopende bescherming te verkrijgen tegen nieuwe CVE’s die van invloed zijn op CentOS 8 – u tijd besparen om naar een ander besturingssysteem te migreren.
