Met FreeIPA Flaw Chain kunnen anonieme klanten herbruikbare beheerdersreferenties maken

Een foutje in GratisIPA laat een client die nog nooit heeft ingelogd een eigen Kerberos-identiteit in de directory aanmaken en in de beheerdersgroep terechtkomen, zegt Red Hat.

FreeIPA is het systeem dat bepaalt wie zich binnen een Linux-domein mag aanmelden en dat alle identiteiten bijhoudt in een 389 Directory Server-database die toegankelijk is via LDAP. Voor de aanval is een tweede fout in de databasesoftware nodig.

Het FreeIPA-project heeft zijn kant al vastgelegd in versie 4.13.4. Red Hat zegt dat het de keten twee keer heeft gereproduceerd tijdens een standaardinstallatie, het meest recentelijk op een machine zonder enige toegang.

Red Hat volgt de FreeIPA-fout als CVE-2026-76578 en beoordeelt deze als kritiek, met een CVSS-score van 9,8. Op dezelfde pagina staat dat de score voorlopig is en onderhevig is aan beoordeling.

Red Hat verzendt FreeIPA als zijn Identiteitsbeheerproductwaar het pakket wordt aangeroepen ipa.

FreeIPA levert een toegangscontroleregel, een zogenaamde ACI, waarmee een gebruiker zijn eigen eenmalige wachtwoordtoken kan beheren. De regel vereist niet dat de client is ingelogd en beperkt ook niet wat er nog meer naast het token kan worden geschreven.

Dat wordt pas gevaarlijk vanwege het tweede minpunt. 389 Directoryserver heeft een regeltype dat bedoeld is om ‘alleen de geverifieerde eigenaar van dit item’ te zeggen. Het vergelijkt de naam van de client met een opgeslagen waarde als platte tekst, en een client die niet heeft ingelogd heeft een lege naam, die overeenkomt met een lege opgeslagen waarde.

Een anonieme klant kan dus een token-invoer maken waarbij de eigendomsvelden leeg blijven, de eigendomscontrole doorstaan ​​door niemand te zijn, en er een Kerberos-identiteit en wachtwoord bij schrijven.

Red Hat scoort de directoryserverfout, CVE-2026-76560, op 7,5 en zegt Red Hat-directoryserver verzendt standaard geen regel met die vorm. Op zichzelf is de fout alleen van belang als een implementatie een dergelijke regel heeft geschreven.

FreeIPA is zo’n implementatie. De standaard geleverde regel is precies die vorm, en daarom werkt de ketting tegen een onaangeroerde installatie. Dat verband is onze lezing van twee adviezen die de helften afzonderlijk beschrijven.

Red Hat reproduceerde het directory-server-defect ook op zichzelf, op een eenvoudige 389-ds-build zonder geïnstalleerde FreeIPA-onderdelen, en een controletest met een waarde die niet leeg was, werd terecht geweigerd. Dat plaatst het defect in de toegangscontrole-engine en niet in alles wat FreeIPA doet.

De techniek die voor het eerst aan Red Hat werd gemeld, imiteerde het echte beheerdersaccount door een Kerberos-naam te maken die ermee overeenkwam. Een eerdere oplossing voor CVE-2026-13097 blokkeerde die botsing, maar liet de onderliggende niet-geverifieerde schrijfwijze op zijn plaats. De aanval werkt nu onder een naam die de aanvaller kiest, zegt Red Hat, “waarmee hetzelfde praktische resultaat wordt bereikt.”

Dat eerdere probleem, opgelost in FreeIPA 4.13.3, was een ander probleem. De controle of Kerberos-namen uniek zijn, liet geen verschillende manieren toe om dezelfde naam te schrijven, waardoor een gebruiker met schrijftoegang een service-identiteit kon creëren die een bestaande geprivilegieerde identiteit nabootste.

De twee projecten omschrijven het resultaat verschillend. Red Hat noemt het een echt lidmaatschap van een beheerdersgroep en herbruikbare beheerdersreferenties.

Het FreeIPA-project formuleert het nauwkeuriger en stelt dat de geïnjecteerde identiteit nog niet mag bestaan, dat de CVE-2026-13097-oplossing voorkomt dat bestaande accounts worden overgenomen en dat de aanval “kan worden gebruikt als opstapje” naar administratieve privileges.

Red Hat zegt dat het de keten heeft uitgevoerd tegen een standaard FreeIPA-containerimage met versie 4.13.1 en de resultaten heeft gecontroleerd met standaard beheerdersopdrachten in plaats van te vertrouwen op de uitvoer van de exploit. Geen van de adviezen of bugrapporten beschrijft de fout die bij een echte aanval wordt gebruikt.

Voor implementaties die gebruik maken van beveiligingsidentifiers in Windows-stijl, zegt Red Hat dat de aanvaller ook een Kerberos-ticket kan verkrijgen met autorisatiegegevens, waardoor de toegang tot de HTTP- en Dogtag-services van de server wordt uitgebreid. Dogtag is de ingebouwde certificeringsinstantie van FreeIPA.

Een tweede, afzonderlijke fout

Red Hat heeft daarnaast een tweede FreeIPA-fout onthuld, CVE-2026-79678, die niets te maken heeft met de bovenstaande keten. Zij beoordeelt deze als belangrijk, met een score van 8,1.

De opdracht idp-add geeft twee waarden door die de aanroeper levert, een organisatienaam en een basis-URL, aan een Python eval()-aanroep. Die aanroep wordt uitgevoerd vóór de toestemmingscontrole die bedoeld is om de opdracht te beperken tot beheerders van de identiteitsprovider, zodat elk account op de server er toegang toe heeft, ongeacht de rechten ervan.

De aanroep wordt beperkt door een patroon dat haakjes verbiedt, waardoor elke functie niet kan worden aangeroepen. Red Hat zegt dat er geen code-uitvoering mogelijk is.

Wat een aanvaller kan doen, is de omgevingsvariabelen van het serverproces één voor één lezen door de fout te observeren die de server retourneert, en het geheugen van de server gebruiken met een korte rekenkundige uitdrukking.

Hoeveel dat uitmaakt, hangt af van hoe FreeIPA is geïnstalleerd, zegt Red Hat. Bij een normale, op pakketten gebaseerde installatie bevat de procesomgeving alleen gedocumenteerde paden en instellingen. Containerinstallaties zijn anders.

Het officiële FreeIPA-serverimage neemt vaak de Directory Manager- en beheerderswachtwoorden als omgevingsvariabelen bij de eerste keer opstarten, en die wachtwoorden kunnen zichtbaar worden als ze achterblijven nadat de installatie is voltooid.

Red Hat crediteert Gia Bui uit Californië voor het melden van de FreeIPA-keten en de directory-server-fout, en crediteert Calif die met Anthropic samenwerkt voor de idp-add-fout.

Wat beheerders nu kunnen doen

De oplossing is op drie verschillende tijdstippen op drie verschillende plaatsen gearriveerd, dus het antwoord hangt af van welk stukje software u patcht.

Onderdeel Wat te installeren Geef aan wanneer gecontroleerd
FreeIPA, van het project GratisIPA 4.13.4

Lost beide FreeIPA-fouten op. De release notes bevatten geen datum en zeggen niet om welke eerdere versies het gaat.

389-ds-basis op Red Hat Enterprise Linux en Red Hat Directory Server

Het advies voor uw vrijlating

Op 8 september tussen 01:56 en 05:07 UTC werden veertien adviezen gepubliceerd, vermeld in het 389-ds bugrecord. RHSA-2026:64785 omvat Red Hat Enterprise Linux 10 met 389-ds-base-3.2.0-10.el10_2. Het advies wordt als kritisch beoordeeld en behandelt naast deze nog vier 389-ds-fouten.

ipa pakketten op Red Hat Enterprise Linux Nog niet vermeld

De bugrecords van Red Hat voor beide FreeIPA-fouten vertoonden geen vaste versie en geen advies toen ze op 8 september werden gecontroleerd.

389-ds-basis op Fedora Update wordt nog getest

De Fedora-tracker was gemarkeerd ON_QA bij controle op 8 september.

Er verscheen geen advies voor gewone Red Hat Enterprise Linux 9 in die lijst van veertien. Dat is wat de bugrecord op 8 september liet zien, en geen verklaring dat er geen oplossing voor de release komt.

Totdat er een vast pakket beschikbaar is, geeft Red Hat twee tijdelijke stappen voor de keten:

  1. Beperk de toegang tot de LDAP-service (meestal poort 389 en 636) tot hosts die u vertrouwt, met behulp van firewallregels of netwerksegmentatie.
  2. Het uitschakelen van anonieme LDAP-bindingen blokkeert dit specifieke pad, zegt Red Hat, maar controleer eerst of niets anders in uw implementatie ze nodig heeft.

Voor de idp-add-fout bestaat een dergelijke optie niet. Red Hat zegt dat geen enkele configuratie-instelling een gewoon geauthenticeerd account weghoudt van die code, en dat een vast pakket vereist is. Het voegt eraan toe dat iedereen die containerinstallaties uitvoert, moet verifiëren dat het wachtwoord dat bij de eerste keer opstarten is ingesteld, niet langer aanwezig is in de actieve procesomgeving.

Het gepubliceerde materiaal laat twee vragen onbeantwoord. Noch Red Hat, noch het FreeIPA-project zegt of 389-ds-updates op zichzelf de FreeIPA-aanval kunnen stoppen op een server waarvan de ipa-pakketten nog steeds verouderd zijn.

En geen van beide zegt of het toepassen van een oplossing een identiteit verwijdert die een aanvaller vooraf heeft gemaakt, of waar een beheerder op moet letten om erachter te komen.

Noch de adviezen, noch de bugrapporten publiceren detectieregels of indicatoren.

Thijs Van der Does