Верига от уязвимости във FreeIPA позволява на анонимни клиенти да създават идентификационни данни за администратор за многократна употреба

Грешка във FreeIPA позволява на клиент, който никога не се е влизал в системата, да създаде Kerberos самоличност по свой избор в директорията и да се окаже в администраторската група, съобщава Red Hat.

FreeIPA е системата, която определя кой може да се вписва в Linux домейн, и поддържа всички самоличности в база данни на 389 Directory Server, достъпна чрез LDAP. За атаката е необходима втора уязвимост в софтуера на базата данни.

Проектът FreeIPA вече е отстранил уязвимостта от своя страна във версия 4.13.4. От Red Hat заявяват, че са възпроизвели веригата два пъти на стандартна инсталация, най-наскоро на машина без никакъв достъп.

Red Hat проследява уязвимостта във FreeIPA като CVE-2026-76578 и я класифицира като критична с CVSS оценка 9.8. На същата страница се посочва, че тази оценка е предварителна и подлежи на преразглеждане.

Red Hat доставя FreeIPA като свой продукт Identity Management, където пакетът се нарича ipa.

FreeIPA предоставя правило за контрол на достъпа (ACI), което позволява на потребителя да управлява своя собствен токен за еднократна парола. Правилото не изисква клиентът да е влизал в системата, нито ограничава какво друго може да бъде записано заедно с токена.

Това става опасно само поради втората уязвимост. 389 Directory Server има тип правило, предназначено да гласи „само автентифицираният собственик на този запис“. То сравнява името на клиента със съхранена стойност като обикновен текст, а клиент, който не е влизал в системата, има празно име, което съвпада с празна съхранена стойност.

Така че анонимен клиент може да създаде запис на токен с празни полета за собственост, да премине проверката за собственост, тъй като е „никой“, и да запише Kerberos самоличност и парола заедно с него.

Red Hat оценява уязвимостта в сървъра на директорията, CVE-2026-76560, на 7.5 и заявява, че Red Hat Directory Server не съдържа такова правило по подразбиране. Самостоятелно уязвимостта е от значение само там, където внедряването съдържа такова правило.

FreeIPA е точно такова внедряване. Неговото предварително зададено правило е точно от такъв тип, поради което веригата работи срещу недокосната инсталация. Тази връзка е нашият прочит на две бюлетини за сигурност, които описват двете половини поотделно.

Red Hat също така възпроизведе дефекта в сървъра на директорията самостоятелно, върху чиста 389-ds версия без инсталирани компоненти на FreeIPA, като контролен тест с използване на стойност, която не е празна, беше правилно отказан. Това поставя дефекта в механизма за контрол на достъпа, а не в нещо, което FreeIPA прави.

Техниката, за която първоначално е съобщено на Red Hat, се е представяла за истинския администраторски акаунт чрез създаване на Kerberos име, което съвпада с него. По-ранна корекция за CVE-2026-13097 е блокирала този дублиращ се запис, но е оставила основното незащитено инжектиране на данни на място. Сега атаката работи под име, избрано от атакуващия, като според Red Hat се „постига същият практически резултат“.

Тази по-ранна уязвимост, отстранена във FreeIPA 4.13.3, беше различен проблем. Проверката за уникалност на Kerberos имената не позволяваше различни начини за изписване на едно и също име, което позволяваше на потребител с права за запис да създаде услужна самоличност, която да се представи за съществуваща такава с привилегии.

Двата проекта описват резултата по различен начин. Red Hat го нарича истинско членство в администраторска група и идентификационни данни за администратор за многократна употреба.

Проектът FreeIPA го определя по-тясно, заявявайки, че инжектираната самоличност не трябва вече да съществува, че корекцията за CVE-2026-13097 предотвратява превземането на съществуващи акаунти и че атаката „може да се използва като трамплин“ към администраторски привилегии.

От Red Hat заявяват, че са изпълнили веригата от атаки срещу стандартен FreeIPA контейнерен образ с версия 4.13.1 и са проверили резултатите със стандартни команди само за администратори, вместо да се доверяват на изходните данни на експлойта. Нито една от бюлетините или докладите за грешки не описва уязвимостта да е била използвана в реална атака.

За среди, използващи идентификатори за сигурност в стил Windows, Red Hat казва, че киберпрестъпникът може също да получи Kerberos билет, съдържащ данни за оторизация, като по този начин разшири достъпа до HTTP и Dogtag услугите на сървъра. Dogtag е вграденият сертификатен орган на FreeIPA.

Втора, отделна уязвимост

Red Hat разкри втора уязвимост във FreeIPA заедно с тези – CVE-2026-79678, която няма нищо общо с горепосочената верига. Тя оценява тази уязвимост като важна, с оценка 8.1.

Командата idp-add предава две стойности, предоставени от извикващия – име на организация и основен URL адрес – в извикване на Python eval(). Това извикване се изпълнява преди проверката на разрешенията, предназначена да ограничи командата до администратори на доставчика на самоличности, така че всеки акаунт на сървъра може да достигне до него, независимо от неговите привилегии.

Извикването е ограничено от модел, който забранява скоби, което спира извикването на каквато и да е функция. Red Hat заявява, че „не е възможно изпълнение на код“.

Това, което злонамереният субект може да направи, е да чете променливите на средата на сървърния процес една по една, като наблюдава грешката, която сървърът връща, и да изчерпе паметта на сървъра с кратък аритметичен израз.

Колко голямо значение има това зависи от начина, по който е инсталиран FreeIPA, казва Red Hat. При нормална инсталация, базирана на пакети, средата на процеса съдържа само документирани пътища и настройки. Контейнерните инсталации са различни.

Официалният контейнерен образ на сървъра FreeIPA често приема паролите на Directory Manager и администратора като променливи на средата при първоначално зареждане, и тези пароли могат да бъдат разкрити, ако останат след приключване на настройката.

Red Hat изказва благодарност на Gia Bui от Calif за съобщаването за веригата във FreeIPA и уязвимостта в сървъра на директорията, както и на Calif, работещи с Anthropic, за уязвимостта в idp-add.

Какво могат да направят администраторите сега

Корекцията пристигна на три различни места по различно време, така че отговорът зависи от това за кой софтуер инсталирате корекции за сигурност.

Никой бюлетин за стандартен Red Hat Enterprise Linux 9 не се появи в този списък от четиринадесет. Това е, което докладът за грешки показваше на 8 септември, а не твърдение, че за тази версия не предстои корекция.

Докато стане наличен коригиран пакет, Red Hat предоставя две временни стъпки за веригата:

1. Ограничете достъпа до услугата LDAP (обикновено портове 389 и 636) до хостове, на които се доверявате, като използвате правила за защитна стена или мрежова сегментация.
2. Изключването на анонимните LDAP връзки (binds) блокира този конкретен път, съобщава Red Hat, но първо проверете дали нищо друго във вашата среда не се нуждае от тях.

За уязвимостта в idp-add няма такава опция. Red Hat заявява, че никоя настройка на конфигурацията не поддържа обикновен автентифициран акаунт далеч от този код и че е необходим коригиран пакет. Добавя се, че всеки, който управлява контейнерни инсталации, трябва да потвърди, че паролата, зададена при първоначално зареждане, вече не присъства в средата на работещия процес.

Публикуваният материал оставя два въпроса без отговор. Нито Red Hat, нито проектът FreeIPA казват дали актуализациите на 389-ds сами по себе си спират атаката срещу FreeIPA на сървър, чиито ipa пакети все още са остарели.

И нито един от тях не казва дали прилагането на корекция за сигурност премахва самоличност, създадена от атакуващ предварително, или какво трябва да търси администраторът, за да разбере.

Нито бюлетините, нито докладите за грешки публикуват правила за откриване или индикатори.