"가장 최신 이미지를 써라"는 코드 한 줄이 감춘 함정 — 클라우드 이미지 이름혼동 공격
“가장 최신 이미지를 써라”는 코드 한 줄이 감춘 함정 — 클라우드 이미지 이름혼동 공격
분류: Security · 클라우드·컨테이너 · 이름혼동 공격(공급망) [정보성]
덱. Datadog Security Labs 연구팀은 2024년, 수많은 코드가 AWS의 가상머신 이미지(AMI)를 “이름”만으로 찾아 쓰고 있다는 패턴을 발견했습니다. 이 패턴을 악용하면 아무나 특정 이름의 이미지를 공개로 올려두는 것만으로 다른 사람의 AWS 계정에서 코드를 실행시킬 수 있었습니다. 연구팀은 이 방식으로 AWS 내부 시스템까지 실제로 뚫렸다는 사실을 확인했습니다.
리드
클라우드 환경은 “정확히 어떤 리소스를 쓸지” 매번 명시하지 않고, 검색 조건에 맞는 것 중 가장 최근 것을 자동으로 골라 쓰는 경우가 많습니다. 이때 “누가 만들었는가”를 확인하지 않고 “이름이 맞는가”만 확인한다면, 그 이름을 먼저 선점해 등록해두는 쪽이 검색 결과를 가로챌 수 있습니다. 신원(identity)을 이름만으로 판단하는 시스템은 그 이름을 가장 먼저, 가장 그럴듯하게 등록하는 사람의 것이 됩니다. 이번 사례는 이 문제가 실제로 얼마나 광범위하게 퍼져 있었는지, 그리고 AWS라는 거대 클라우드 사업자 내부에서조차 어떻게 재현됐는지를 보여주는 사례입니다.
핵심 사실 요약
- AWS의 EC2(가상서버) 인스턴스는 AMI(Amazon Machine Image, 부팅용 가상머신 이미지)를 기반으로 만들어집니다. 정확한 이미지 ID를 이미 아는 경우도 있지만, “최신 우분투 이미지” 같은 조건만 정해두고
ec2:DescribeImages라는 검색 API로 조건에 맞는 이미지 중 가장 최근 것을 자동으로 찾아 쓰는 코드도 흔합니다. - 문제는 이 검색 API를 호출할 때 이미지를 누가 만들었는지(소유자, owner)를 지정하지 않고 이름 패턴만으로 검색하는 코드가 많다는 점이었습니다. AWS의 커뮤니티 AMI 카탈로그는 누구나 이미지를 공개로 올릴 수 있는 공간이라, 소유자를 지정하지 않으면 검색 결과에 제3자가 올린 이미지도 섞여 들어옵니다.
- 공격 방법은 단순합니다. 공격자가 피해자 쪽 코드가 찾는 이름 패턴에 맞으면서도 날짜상 더 “최신”으로 보이는 이름의 악성 이미지를 만들어 공개로 올려두면, “가장 최근 것”을 자동 선택하는 로직이 공격자의 이미지를 골라버립니다. 예를 들어 정상 이미지 이름 뒤에 접미사만 붙인 변형본을 만들어 공개하는 식입니다. 연구팀은 이 유형을 이미 알려져 있던 “의존성 혼동(dependency confusion, 소프트웨어 패키지 이름을 선점해 악성 버전을 먼저 설치시키는 공급망 공격)“과 같은 계열로 분류하고, 이름혼동(name confusion) 공격이라 이름 붙였습니다.
- 연구팀은 Terraform(인프라를 코드로 정의하는 널리 쓰이는 도구)뿐 아니라 Go·Python·Bash 스크립트 등 다양한 언어로 작성된 실제 공개 코드에서 이 취약한 패턴을 다수 발견했습니다. Datadog이 관측한 조직 중 약 1퍼센트가 이 패턴에 해당하는 것으로 추정됐습니다.
- 연구팀은 AWS의 정식 취약점 신고 절차를 통해, 무해한 “복제 이미지”를 공개로 올려 AWS 내부 시스템이 실제로 그 이미지를 가져다 쓰는지 확인하는 실험을 진행했습니다. 그 결과 AWS의 내부 비운영(non-production) 시스템 일부가 실제로 이 패턴에 취약했다는 사실이 확인됐고, AWS는 이를 신속히 수정했습니다. AWS 측은 영향받은 시스템이 고객 데이터에 접근할 수 없는 비운영 환경이었다고 공식 확인했습니다.
- 이 사례를 계기로 AWS는 2024년 12월 “Allowed AMIs”라는 계정 단위 방어 기능을 새로 도입했습니다. 신뢰할 계정 목록을 미리 지정해두면, 그 목록 밖에서 온 이미지는 아예 선택되지 않도록 막는 기능입니다. Terraform을 만드는 HashiCorp도 이후 버전에서 소유자를 지정하지 않고 “최신 이미지”를 찾는 코드에 경고를 띄우도록 바꿨습니다.
짧은 논평
이 사례가 흥미로운 지점은 취약점 자체의 기술적 난도가 아니라, “편의를 위한 자동 선택 로직”이 곧 신뢰 판단 로직이 돼버린다는 구조입니다. 개발자는 “가장 최근 것을 써라”고 썼을 뿐인데, 그 문장이 실제로는 “이름이 맞으면 누가 만들었든 믿어라”로 동작하고 있었던 것입니다. 이건 저희가 다른 글에서도 반복해서 짚는 패턴과 같은 뿌리입니다 — 신원을 검증하지 않고 상태나 이름만으로 판단하면, 그 판단 기준을 먼저 흉내 낸 쪽이 시스템을 대신 통과합니다. 방어 관점에서 남는 교훈은 단순합니다. 검색으로 리소스를 찾는 모든 자동화 코드에서 소유자·계정 ID 같은 신원 필드를 명시적으로 고정하고, 클라우드 사업자가 제공하는 허용목록(allowlist)형 가드레일이 있다면 기본으로 켜두는 것입니다. 이름은 언제든 흉내 낼 수 있지만, 계정 신원은 흉내 낼 수 없습니다.
References / 참고자료
- Seth Art, Datadog Security Labs, “whoAMI: A Cloud Image Name Confusion Attack” — 이 글이 재구성한 원 분석. 취약 패턴 발견 과정, AWS 내부 시스템 실증, 방어 기능(Allowed AMIs) 도입까지 다룸. https://securitylabs.datadoghq.com/articles/whoami-a-cloud-image-name-confusion-attack/
이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·코드·명령어를 그대로 옮기지 않았으며, 작동하는 재현 절차는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.