ADSys w wersjach do v0.16.2 pobiera certyfikat CA z serwera Active Directory Certificate Services przez niezaszyfrowane połączenie HTTP, co umożliwia atakującemu przeprowadzenie ataku Man-in-the-Middle. Skutkiem jest zatrucie systemowego magazynu zaufanych certyfikatów, które pozwala na trwałe podsłuchiwanie i deszyfrowanie ruchu TLS na zaatakowanej maszynie.
▸ Pokaż oryginał (EN)
An issue was discovered in Canonical ADSys upstream versions through v0.16.2. During Active Directory Certificate Services (AD CS) certificate auto-enrollment via the vendored Samba client script (internal/policies/certificate/python/vendor_samba/gp/gp_cert_auto_enroll_ext.py), ADSys utilizes a plaintext HTTP connection (http://) instead of a secure HTTPS connection (https://) to request the CA certificate from the Active Directory Certificate Services server (GetCACert). An unauthenticated network attacker positioned between the managed Ubuntu host and the configured AD CS CA hostname can conduct a Man-in-the-Middle (MITM) attack. By intercepting the plaintext HTTP request, the attacker can supply an arbitrary, attacker-controlled Root CA certificate. Because the system automatically accepts this certificate and registers it into the local system trust store via update-ca-certificates, this results in system-wide trust store poisoning. Consequently, TLS clients utilizing the operating system trust store on the affected machine will accept rogue certificates for arbitrary domains, enabling persistent decryption and interception of subsequent TLS connections. This issue is resolved in version v0.16.3.
Podczas automatycznego pobierania certyfikatu (GetCACert) przez skrypt vendored Samba (gp_cert_auto_enroll_ext.py) ADSys nawiązuje połączenie HTTP zamiast HTTPS. Nieuwerzytelniający się atakujący ulokowany w ścieżce sieciowej między hostem Ubuntu a serwerem AD CS może przechwycić to żądanie i odpowiedzieć własnym, dowolnie spreparowanym certyfikatem Root CA. System automatycznie rejestruje otrzymany certyfikat w lokalnym trust store za pomocą update-ca-certificates (CWE-348: IP Address Spoofing / poleganie na niezweryfikowanej wartości), nie weryfikując jego autentyczności. Od tej chwili wszystkie klienty TLS korzystające z systemowego magazynu certyfikatów ufają certyfikatom wystawionym przez kontrolowany przez atakującego fałszywy CA.
Atakujący uzyskuje zdolność do trwałego odszyfrowania i przechwytywania kolejnych połączeń TLS nawiązywanych przez zaatakowany host, ponieważ jego certyfikat Root CA jest traktowany jako zaufany przez cały system operacyjny. Umożliwia to m.in. kradzież poświadczeń, modyfikację przesyłanych danych oraz dalsze działania w sieci (lateral movement).
Należy zaktualizować ADSys do wersji v0.16.3, w której problem został rozwiązany przez zastąpienie połączenia HTTP bezpiecznym HTTPS. Szczegóły dostępne w referencjach producenta: https://ubuntu.com/security/CVE-2026-12249 oraz commit: https://github.com/ubuntu/adsys/commit/8b1939f96d3827b4426eb06c1ced5bf317b0a99d
Canonical ADSys w wersjach do v0.16.2 włącznie, działający na hostach Ubuntu zintegrowanych z Active Directory i korzystający z funkcji automatycznego pobierania certyfikatów AD CS (AD CS certificate auto-enrollment).
Podatność wymaga od atakującego pozycji w ścieżce sieciowej (MITM), co podnosi złożoność ataku (CVSS AC:H), jednak w środowiskach korporacyjnych z rozbudowaną infrastrukturą sieciową warunek ten może być stosunkowo łatwy do spełnienia. Wektor CVSS wskazuje na dostępność publicznego exploita (E:P). Wersja naprawiona to v0.16.3.
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:Y/R:I/V:D/RE:L/U:Red