클라우드 메타데이터 엔드포인트, 숨은 공격 표면

모든 주요 클라우드 제공업체는 자사 플랫폼에서 실행되는 가상 머신에 인스턴스 메타데이터 서비스를 제공하며, 보통 링크 로컬 주소인 169.254.169.254로 접근할 수 있습니다. 인스턴스 내부에서 이 주소로 간단한 HTTP 요청을 보내면 인스턴스의 설정, 네트워크 정보, 그리고 기본 설정에 따라서는 인스턴스에 할당된 역할이나 ID의 임시 보안 자격 증명까지 반환됩니다.

특히 SSRF와 결합할 때 위험한 이유

메타데이터 엔드포인트는 인스턴스 자체에서만 접근할 수 있어야 하며, 공용 인터넷에는 노출되지 않습니다. 하지만 서버 측 프로세스를 속여 공격자가 지정한 주소로 HTTP 요청을 보내게 할 수 있고(전형적인 SSRF) 그 주소가 마침 메타데이터 엔드포인트라면, 서버가 스스로 자신의 클라우드 자격 증명을 가져와 응답으로 넘겨주게 됩니다. 외부에서 메타데이터 엔드포인트에 직접 네트워크로 접근할 필요는 없습니다. 취약한 서버가 공격자 대신 요청을 수행하기 때문입니다.

• 169.254.169.254는 더 넓은 169.254.0.0/16 링크 로컬 대역에 속하며, 이 대역은 정상적인 공개 DNS 확인 대상으로 취급해서는 안 됩니다.
• 일부 제공업체는 단순한 SSRF에 대한 장벽을 높이려고 토큰 기반 방식의 메타데이터 서비스로 옮겨 갔지만, 애플리케이션 계층에서 해당 주소를 완전히 차단하는 쪽이 여전히 더 견고한 방어입니다.
• 그래서 사용자가 입력한 도메인을 확인하는 모든 도구에서 링크 로컬 주소는 사설 주소 및 루프백 대역과 같은 차단 목록에 올려야 합니다. 이는 별개의 덜 심각한 위험 범주가 아닙니다.

실무에서 얻을 교훈

사용자를 대신해 URL을 확인하고 요청하는 시스템은 169.254.169.254와 이 주소가 속한 더 넓은 링크 로컬 대역을 엄격한 접근 금지 대상으로 취급해야 합니다. 이 검사는 실제 요청이 이루어지는 시점마다 수행해야 하며, 주소가 직접 입력되었는지 그 주소를 그대로 가리키는 DNS 레코드를 통해 도달했는지와 관계없이 적용해야 합니다.

특정 클라우드 제공업체만의 문제가 아닙니다

169.254.169.254는 구체적으로 AWS, Google Cloud, Azure에서 쓰는 관례이지만, 링크 로컬 주소가 인스턴스의 ID와 자격 증명을 해당 인스턴스에만 노출하는 근본 패턴은 거의 모든 주요 클라우드와 컨테이너 플랫폼에 어떤 형태로든 존재합니다. 같은 주소를 쓰는 곳도 있고 제공업체 고유의 주소를 쓰는 곳도 있습니다. Kubernetes 클러스터에도 파드 내부에서 접근할 수 있는 자체 메타데이터 유사 엔드포인트가 흔히 있습니다. 주요 클라우드 제공업체의 구체적인 주소는 외워 둘 만하지만, 실제로 일반화되는 것은 원칙입니다. 어떤 플랫폼에서 실행되든, 사용자가 입력한 URL을 확인하고 가져오는 모든 기능에서 메타데이터 성격의 엔드포인트는 접근 금지로 취급해야 한다는 것입니다.

IMDSv2: 단순한 필터가 아닌 실질적인 완화책

수년간 바로 이런 공격 패턴이 악용되자 AWS는 메타데이터 서비스의 두 번째 버전인 IMDSv2로 대응했습니다. IMDSv2는 메타데이터를 읽기 전에 특별한 PUT 요청으로 세션 토큰을 먼저 받아야 하며, 핵심은 취약한 코드 경로가 실제로 보내는 SSRF 유발 GET 요청으로는 이 PUT 요청을 재현할 수 없다는 점입니다.

의미 있는 개선이지만, 하위 호환성 때문에 많은 계정에서 선택 사항으로 남아 있고 보호 대상도 메타데이터 엔드포인트에 한정됩니다. SSRF가 여전히 도달할 수 있는 다른 모든 사설 주소와 내부 주소는 보호하지 못합니다. 어떤 버전의 메타데이터 서비스를 쓰든, 확인된 주소에 대한 애플리케이션 수준의 필터링은 여전히 필요합니다.