SSRF 공격 설명: DNS는 어떻게 악용될까

서버 측 요청 위조(SSRF, Server-side request forgery)는 공격자가 서버로 하여금 애플리케이션 개발자가 아닌 공격자가 선택한 대상으로 HTTP(또는 다른 네트워크) 요청을 대신 보내게 만들 때 발생합니다. 전형적인 경로는 이미지 가져오기, 웹훅 대상, 링크 미리보기처럼 사용자가 제공한 URL을 가져오는 기능이며, 공격자는 공개 리소스 대신 내부 인프라를 가리키는 URL을 제공합니다.

공격에서 DNS가 맡는 역할

순진한 방어는 제공된 URL의 호스트 이름이 내부 주소처럼 보이는지 확인하는 것입니다. 이는 아주 쉽게 우회됩니다. 공격자가 공개 도메인을 등록하고 그 DNS 레코드를 내부 IP로 지정한 뒤, 아주 평범해 보이는 호스트 이름을 서버에 건네기만 하면 됩니다. 검증 로직은 IP가 아니라 도메인을 보게 되고, 위험한 부분은 DNS 확인이 일어난 뒤에야 드러납니다. 이는 대개 실제 요청을 만드는 HTTP 클라이언트 라이브러리 깊숙한 곳에서, 사전 검증 단계를 한참 지난 뒤에 일어납니다.

실제 방어는 어떤 모습인가

• 요청을 보내기 전에 호스트 이름을 직접, 명시적으로 확인하세요. HTTP 클라이언트가 눈에 보이지 않게 대신 확인하도록 두지 마세요.
• 확인된 모든 주소(도메인은 여러 개를 반환할 수 있으므로 전부)를 사설/루프백/링크 로컬/클라우드 메타데이터 차단 목록과 대조하세요.
• 첫 번째로 반환된 주소만 검사하지 말고, 확인된 주소 중 하나라도 허용되지 않으면 요청을 거부하세요.
• 입력 시점뿐 아니라 요청 시점에도 다시 검증하여, 별도로 설명한 DNS 리바인딩의 틈을 막으세요. 실제로 SSRF와 리바인딩은 함께 쓰이는 경우가 많습니다.

여기서 클라우드 메타데이터 엔드포인트는 특별히 언급할 만합니다. 대부분의 클라우드 제공업체에서 VM 내부에서 특정 링크 로컬 주소로 요청하면, 머신 외부에서는 접근할 수 없어야 하는 자격 증명, 인스턴스 메타데이터, 설정이 반환될 수 있습니다. SSRF와 메타데이터 엔드포인트 대상의 조합은 현실에서 가장 흔하고 영향이 큰 공격 연쇄 중 하나이며, 그 시작은 언제나 평범해 보이는 도메인 이름입니다.

주소가 아니라 문자열을 검사하는 필터는 통하지 않습니다

IP 주소는 대부분의 검증 코드가 고려하는 것보다 더 많은 유효한 텍스트 표현을 가집니다. “127.0.0.1”이나 “localhost”에 대한 문자열 일치로 작성된 필터는, 아래의 모든 대체 형식을 그대로 통과시킵니다. 어느 것도 검사 대상 문자열처럼 보이지 않기 때문입니다.

신뢰할 수 있는 유일한 방어는 주소를 먼저 실제 숫자 값으로 파싱하고 그 값으로 차단 목록을 평가하는 것입니다. 이 도구의 리졸버가 취하는 방식이 정확히 이것이며, 주소가 어떻게 쓰였는지에 따라 패턴을 매칭하는 방식이 아닙니다. 리졸버는 원래 호스트 이름의 레코드가 어떻게 인코딩되었는지와 무관하게 정규화된 주소를 돌려줍니다. 공격자가 선택할 수 있는 모든 형식의 원본 문자열을 검증하려는 것보다 먼저 확인하고 확인된 결과를 검증하는 편이 더 견고한 이유가 바로 이것입니다.

리디렉션은 또 다른 흔한 우회 경로입니다

처음 URL을 올바르게 확인하고 검증하는 시스템도 HTTP 리디렉션에 걸릴 수 있습니다. 승인된 공개 URL에 요청했는데 내부 주소를 가리키는 302로 응답할 수 있으며, 리디렉션을 자동으로 따라가는 HTTP 클라이언트(대부분의 라이브러리의 기본 동작)는 처음에 통과한 검증을 다시 실행하지 않고 두 번째 요청을 그대로 수행합니다. 사전에 한 번만 검증하고 리디렉션 처리는 기반 HTTP 클라이언트에 맡기는 모든 SSRF 방어는, DNS 확인이 만드는 틈과 똑같은 모양의 틈을 가집니다. 해결책도 같습니다. 한 번 통과한 URL이 계속 안전한 곳을 가리키리라 신뢰하지 말고, 리디렉션을 따라가기 전에 명시적으로 다시 검증하세요.