Reddit

Improper certificate validation in the HTTPS listener in Canonical LXD allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines via a crafted certificate chain.

LXD 인증서 검증 취약점, 신뢰된 클라이언트로 가장 가능

Canonical이 LXD와 MicroCloud의 상호 TLS 인증서 검증 취약점을 공개하고 수정 버전을 안내했습니다. 공격자는 신뢰된 클라이언트의 공개 인증서를 악용해 API에서 해당 클라이언트로 가장할 수 있으며, 공개 자료는 eMudhra를 원인으로 지목하지 않습니다.

본문

Canonical은 10월 29일 LXD와 MicroCloud에서 클라이언트 인증서 체인을 잘못 검증하는 취약점을 공개하고 수정 버전을 안내했습니다. LXD의 HTTPS API에 접근할 수 있는 공격자는 신뢰된 클라이언트의 공개 인증서를 체인 중간에 넣어 그 클라이언트로 인증될 수 있습니다. 공개된 자료는 eMudhra를 취약점의 원인이나 관련 기관으로 지목하지 않습니다.

LXD는 HTTPS API 요청에서 상호 TLS를 사용해 클라이언트를 인증합니다. 취약한 검증 방식은 클라이언트가 보낸 체인의 인증서를 신뢰 저장소와 대조했지만, 개인키 소유를 증명하는 리프 인증서인지 확인하지 않았습니다. 따라서 공격자는 신뢰된 클라이언트의 공개 인증서만 확보하면 해당 신원으로 가장할 수 있었습니다. CVE 기록은 공격자가 클러스터와 관리 대상 가상 머신에 완전한 접근 권한을 얻을 수 있다고 설명합니다. Canonical은 피해 사용자 권한에 따라 호스트의 루트 권한까지 이어질 수 있다고 밝혔습니다.

Canonical 공지와 CVE 기록은 인증서 발급기관 eMudhra를 언급하지 않습니다. 이 취약점은 특정 발급기관의 인증서 발급 문제가 아니라 LXD와 MicroCloud가 받은 클라이언트 인증서 체인을 확인하는 방식에서 발생했습니다. 따라서 댓글에서 나온 eMudhra 연관 주장은 확인된 근거가 없습니다.

Canonical이 취약 버전으로 기록한 LXD는 4.0.14, 5.0.10, 5.21.8, 6.9.0이며 각각 4.0.15, 5.0.11, 5.21.9, 6.10.1에서 수정됐습니다. MicroCloud 수정 버전은 2.1.5와 3.4.1입니다. Canonical은 해당 채널의 최신 버전으로 업데이트하라고 권고했으며 LXD 수정판은 stable 채널에 순차 배포 중이라고 공지했습니다.

자료: Canonical 공지, CVE 기록 / 정리·해설: Trawling

참고 자료

원문 보기 ↗토론 보기 ↗