포스트모템: Podman 5.0의 취약점이 공격자에게 프라이빗 컨테이너 레지스트리 접근을 허용한 방법

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown, and technical terms.

Executive Summary

2024년 3월 12일, 우리 보안 팀은 개인 컨테이너 레지스트리에 대한 무단 접근을 감지했으며, 이는 Podman 5.0의 레지스트리 인증 모듈에 존재하는 심각한 취약점으로 추적되었습니다. 이 사후 보고서에서는 사건의 타임라인, 근본 원인, 영향 및 수행된 복구 조치를 상세히 설명합니다.

사고 타임라인

• 2024-03-12 09:15 UTC: 보안 모니터링 경고가 인식되지 않은 IP에서 개인 레지스트리로의 비정상적인 풀 요청에 대해 트리거됨.
• 2024-03-12 09:30 UTC: 사고 대응 팀이 소집되어 2시간 동안 14건의 무단 레지스트리 접근을 확인함.
• 2024-03-12 10:45 UTC: 근본 원인이 Podman 5.0의 레지스트리 인증 토큰 검증 로직에 있는 CVE‑2024‑1234임이 확인됨.
• 2024-03-12 12:00 UTC: 모든 환경에서 Podman 5.0 인스턴스를 패치된 5.0.2 릴리스로 업그레이드함.
• 2024-03-12 14:30 UTC: 모든 손상된 레지스트리 자격 증명을 교체하고 접근 로그를 감사함.

근본 원인 분석

이 취약점은 Podman 5.0의 containers-registries.conf 인증 핸들러 구현에 존재했습니다. 프라이빗 레지스트리 접근을 위한 베어러 토큰을 검증할 때, 모듈은 만료 타임스탬프가 잘못된 토큰에 대해 서명 검증을 건너뛰고, 레지스트리 범위 내 모든 프라이빗 저장소에 대해 전체 읽기 권한을 부여하도록 기본 설정되었습니다.

구체적으로, pkg/registry/auth.go (라인 412‑438)의 결함이 있는 코드 경로는 JWT 토큰의 잘못된 exp 클레임을 파싱할 때 오류를 반환하지 않고, 대신 범위 제한이 없는 하드‑코딩된 기본 권한 세트로 되돌아갔습니다. 공격자는 잘못된 만료 값을 가진 악의적인 토큰을 만들어 인증을 완전히 우회할 수 있었습니다.

// Simplified excerpt from pkg/registry/auth.go (lines 412‑438)
func validateToken(token string) (*Permissions, error) {
    claims, err := parseJWT(token)
    if err != nil {
        // BUG: should reject malformed tokens
        return defaultPermissions, nil // grants full read access
    }
    if !claims.Valid() {
        return nil, fmt.Errorf("invalid token")
    }
    // normal permission handling...
}

영향 평가

• 무단 이벤트: 3개의 개인 컨테이너 레지스트리를 대상으로 14회 접근.
• 노출된 자산: 127개의 독점 이미지(프로덕션 마이크로서비스 빌드 및 내부 도구).
• 접근 유형: 읽기 전용; 이미지 변조나 데이터 유출은 감지되지 않음.
• 영향을 받은 환경: Podman 5.0을 실행하는 스테이징 및 프로덕션 Kubernetes 클러스터.
• 고객 데이터: 레지스트리에 PII가 저장되지 않아 고객 데이터 노출 없음.

독점 컨테이너 이미지가 노출됨으로써 지적 재산 절도 위험이 발생했으며, 즉각적인 복구 조치를 촉구했습니다.

복구 조치

• 모든 Podman 인스턴스를 버전 5.0.2로 업그레이드했습니다. 이 버전은 JWT 클레임 검증을 엄격히 적용하고 기본 권한 폴백을 제거함으로써 CVE‑2024‑1234를 패치합니다.
• 모든 레지스트리 서비스‑계정 자격 증명을 교체하고 6개월간의 접근 로그를 감사했습니다(추가적인 무단 활동은 발견되지 않음).
• CI/CD 파이프라인에 필수 Podman 버전 검사를 구현하여 패치되지 않은 런타임을 사용하는 배포를 차단했습니다.
• Podman 버전 < 5.0.2에서 레지스트리 접근 시 실시간 알림을 추가했습니다.

교훈

• Authentication fallback logic는 거부‑전체를 기본값으로 해야 하며, 허용‑전체가 되지 않도록 해야 합니다.
• Container runtime vulnerability scanning은 사전 배포 파이프라인에 통합하여 알려진 CVE를 더 일찍 포착하도록 해야 합니다.
• Segmentation of private registries를 환경(스테이징 vs. 프로덕션)별로 구분하면 레지스트리 수준 취약점의 영향을 제한할 수 있습니다.
• 낮은 영향도의 보안 사고라도 정기적인 사후 분석을 수행하여 시스템적 결함을 식별해야 합니다.

결론

이번 사고는 Podman 5.0의 인증 로직에 중대한 결함이 있음을 강조했지만, 신속한 사고 대응으로 데이터 손실이나 유출 없이 영향을 제한했습니다. 우리는 재발을 방지하기 위해 레지스트리 접근 제어와 런타임 배포 정책을 강화했으며, 공개 후 48 hours 이내에 빠른 패치를 제공해 준 Podman 유지관리자에게 감사를 표합니다.