flawopen.com/SSRF/클라우드 메타데이터와 SSRF
SSRF는 어떻게 클라우드 메타데이터에 접근하며 자격 증명은 언제 위험해지나요?
메타데이터 서비스를 클라우드 머신 안의 잠긴 안내 창구라고 생각해 보세요. SSRF는 앱을 그 창구로 가는 전달자로 만들 수 있지만, 무엇을 가져올 수 있는지는 공급자의 요청 규칙, 인스턴스 설정, 앱의 네트워크 경로에 달려 있습니다. 엔드포인트에 도달할 수 있다고 해서 자격 증명이 자동으로 노출되는 것은 아닙니다.
메타데이터 엔드포인트가 위험할 수 있는 이유
AWS EC2, Azure, Google Compute Engine은 지원되는 VM 환경에서 접근 가능한 인스턴스 메타데이터 서비스를 문서화합니다. 169.254.169.254는 흔한 link-local 주소지만 요청 형식과 제어는 다릅니다. 메타데이터에는 민감한 인스턴스 정보가 포함될 수 있고, 인스턴스 프로필과 요청 경로가 허용하면 AWS가 역할의 임시 자격 증명을 반환할 수 있습니다. 공격자가 해당 서비스에 도달하는 서버 요청을 통제할 수 있을 때 SSRF가 문제가 됩니다. 도달 가능성만으로 자격 증명을 가져올 수 있다고 단정할 수는 없습니다. 필수 헤더나 토큰, HTTP 메서드, 프록시, 네트워크 위치, 인스턴스 설정이 결과에 영향을 줍니다.
영향이 이어지는 조건
영향이 발생하려면 여러 조건이 연결되어야 합니다. 입력이 서버 요청에 영향을 주고, 요청이 메타데이터 서비스에 도달하며, 공급자 제어에 따라 서비스가 요청을 수락하고, 반환 데이터가 유효한 접근 권한을 제공해야 합니다. 최종 범위는 워크로드 ID의 권한에 달려 있습니다. 고정 목적지, 엄격한 아웃바운드 제어, 공급자 메타데이터 보호, 최소 권한 ID로 연결 고리를 끊으세요.
자주 묻는 질문
아닙니다. 주소, 헤더, 메서드, 토큰 요구사항, 제공 데이터가 다릅니다. AWS는 HttpTokens가 required일 때 IMDSv2 메타데이터 조회에 세션 토큰을 요구하고, Azure는 Metadata: true 헤더를 요구하며, Google은 Metadata-Flavor: Google 헤더를 문서화합니다. 이러한 제어는 일부 SSRF 경로를 완화하지만 사용자가 목적지를 지정하지 못하게 하거나 불필요한 아웃바운드 트래픽을 차단하는 일을 대신하지 않습니다. VM과 컨테이너의 실제 설정은 공급자 문서에서 확인하세요.