DNS 리바인딩이란 무엇이며 왜 신경 써야 할까요?

도메인과 관련된 대부분의 보안 검사는 IP 주소가 한 번 검증하고 이후에 신뢰해도 될 만큼 안정적이라고 가정합니다. DNS 리바인딩은 바로 그 가정을 악용합니다. 공격자는 도메인의 DNS를 제어하며, 처음에는 일반적인 공개 IP 주소로 확인되도록 설정해 대상 시스템의 검증을 통과합니다. 그리고 검사가 이미 끝난 뒤의 이후 요청에서는 응답을 내부 주소(127.0.0.1이나 내부 10.x.x.x 대역 등)로 바꿉니다.

이것이 이론에 그치지 않는 이유

매우 짧은 TTL이 이 공격을 현실적으로 만듭니다. 공격자가 레코드를 몇 초 안에 만료되도록 설정하면, 검증 검사와 그 뒤에 이어지는 실제 요청이 몇 밀리초 간격으로 서로 다른 두 응답을 보게 되며, 피해 시스템은 기반이 바뀐 것을 알아차리지 못합니다. 도메인을 한 번 확인한 뒤 그 IP를 여러 작업에 재사용하는 시스템, 또는 더 나쁘게는 검증을 위해 한 번 확인하고 실제 요청에서는 다른 구성 요소가 다시 확인하도록 두는 시스템은 모두 노출될 수 있습니다.

유일하게 신뢰할 수 있는 방어

호스트 이름 문자열만 검증하는 것도, IP를 한 번 검증하는 것도 충분하지 않습니다. 유일하게 견고한 방어는 실제로 연결이 이루어지는 시점에 확인된 실제 주소를 비공개/내부 대역 차단 목록과 대조하는 것이며, 최초 검증 때만이 아니라 매번 해야 합니다. 그러면 리바인딩이 의존하는 시간 간격이 사라집니다. “검사한 시점”과 “사용한 시점” 사이에 응답이 바뀔 수 있는 틈이 더 이상 없기 때문입니다.

• IPv4와 IPv6 모두에 대해 사설 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), 루프백(127.0.0.0/8), 링크 로컬(169.254.0.0/16), 클라우드 메타데이터 엔드포인트를 차단합니다.
• 입력 검증 때 한 번만 하지 말고 사용할 때마다 다시 확인합니다.
• IPv4 매핑 IPv6 주소(::ffff:127.0.0.1 등)는 내장된 IPv4 주소와 동등하게 취급합니다. 리바인딩 시도는 단순한 IPv6 전용 검사를 피하려고 바로 이 인코딩을 쓰기도 합니다.

실제로 문제가 되었던 사례

DNS 리바인딩은 일부 연구자만의 관심사가 아닙니다. 신뢰할 수 있는 로컬 트래픽만 접근할 수 있다고 가정하고 인증 없는 로컬 관리 인터페이스를 노출하는 가정용 라우터, 스마트홈 허브 등의 기기에 반복적으로 사용되어 왔습니다. 같은 네트워크의 일반 브라우저 탭에서 악성 웹 페이지가 열리면, 리바인딩을 이용해 피해자의 브라우저가 공격자를 대신해 그 관리 인터페이스에 직접 요청을 보내게 할 수 있습니다. 이 브라우저는 로컬 네트워크에 있다는 이유만으로 이미 라우터의 신뢰를 받고 있습니다. 브라우저는 내내 원래의 공개 도메인과 통신하고 있다고 생각하며, 그 아래의 DNS 응답만 바뀐 것입니다.

더 교묘한 변형: 다중 응답 리바인딩

더 정교한 방식은 TTL이 만료되기를 기다릴 필요조차 없습니다. 하나의 DNS 응답에는 합법적으로 A 레코드가 여러 개 들어갈 수 있고, 일부 클라이언트 소프트웨어는 이를 순서대로 시도하거나 요청마다 라운드 로빈으로 돌려 씁니다. 공격자는 정상적인 공개 주소와 내부 주소를 같은 응답에 함께 담아 반환하고, 클라이언트가 결국 두 번째 항목을 시도하기를 기대할 수 있습니다. 기다릴 필요도 시간 간격도 없이, 여러 응답의 모든 주소가 똑같이 신뢰할 수 있다고 보장하도록 DNS가 설계된 적이 없다는 점을 악용하는 것입니다. “처음 반환된 주소만 확인한다”는 방식은 결코 충분하지 않으며, 응답에 포함된 모든 주소를 똑같이 엄격하게 검사해야 한다는 점을 상기시켜 줍니다.