2020.12.28

애저 환경에서 서브도메인 점유를 방지하는 방법

Susan Bradley | CSO
도메인을 설정하고 클라우드 리소스를 그대로 둔 채 해당 사이트를 삭제한 적이 있는가? DNS(domain name services) 설정에서 CNAME을 그대로 방치한 경우는? 
 
ⓒ Getty Images Bank

많은 관리자가 경험한 일이고 공격자들도 이를 알고 있다. 공격자는 관리자가 깜박 잊은 이와 같은 부분을 이용해 서브도메인 레코드에 사이트를 만들어 점유한다. 서브도메인 점유(Subdomain takeovers)는 많은 리소스를 만들고 삭제하는 대기업에서는 매우 흔하다. 특히 CNAME 레코드가 점유에 많이 노출된다. 악의적 행위자는 이런 사이트를 사용해 다양한 다른 사이트로 트래픽과 활동을 리디렉션한다. 마이크로소프트조차 이 문제에서 자유롭지 못하다.

DNS는 네트워크 인프라에서 잘못 이해되는 경우가 많으며, 잘못된 DNS 구성이 심각한 네트워크 문제로 이어지는 경우가 매우 많다. 단순히 레코드가 바뀌었을 뿐인데 웹사이트가 해킹된 것처럼 보일 수 있다. 또한 자산이 노출되어 공격에 사용될 수도 있다.


공격자가 서브도메인을 악용하는 방법

마이크로소프트가 공지한 바와 같이 애저 리소스를 설정하고 프로비저닝하는 시점부터 서브도메인 점유에 노출되기 시작한다. 예를 들어 애저 리소스의 이름이 app-on-azure001. azurewebsites.net이라고 가정해 보자. 

이 애저 리소스로 트래픽을 라우팅하는 서브도메인이 있는 실제 DNS 영역에 CNAME 레코드를 할당하고, 사용자를 app-on-azure001.azurewebsites.net으로 보내는 대신 easierurl.domain.com으로 보낸다. 얼마 후 이 서브도메인이 필요 없다고 판단해서 웹사이트를 디프로비저닝하고 삭제한다. 이 시점에서 DNS 영역의 subdomain.yourdomain.com을 제거해야 한다. 남은 CNAME은 활성 도메인임을 알리지만 활성 애저 리소스를 통해 트래픽을 라우팅하지는 않는다. 이것을 “매달린 DNS 레코드(dangling DNS record)”라고 한다.

공격자는 다양한 도구와 스크립트를 사용해 이와 같은 상태의 서브도메인을 검색하고 찾는다. 공격자는 기본적인 DNS 조회로 현재 라우팅하지 않는 CNAME 레코드를 손쉽게 알아낼 수 있다. 공격자는 현재 누락된 애저 리소스에 여러분이 할당한 것과 같은 이름을 사용해서 애저 리소스를 프로비저닝한다. 이제 이들의 공격 웹사이트 이름이 app-on-azure001.azurewebsites.net이 되고, 여러분의 subdomain.domain.com은 도메인 네임 리소스를 통해 공격자의 사이트를 라우팅한다. 공격을 받게 되면 콘텐츠에 대한 통제력을 상실하거나 쿠키 및 방문자 정보가 공격자 사이트로 넘어갈 수 있다.


서브도메인 점유를 방지하는 방법

잠재적인 문제를 파악하려면 맞춤형 도구 또는 마이크로소프트 깃허브 파워셸 도구의 Get-DanglingDnsRecords를 사용해 애저 리소스와 연결된 CNAME을 점검한다. 모든 취약한 CNAME 또는 자신의 소유가 아닌 자산을 가리키는 CNAME을 찾은 다음, DNS 영역이 호스팅되는 곳으로 가서 더 이상 프로비저닝되지 않는 리소스의 정규화된 도메인 이름을 가리키는 모든 CNAME 레코드를 삭제한다. 또한 웹사이트나 애플리케이션 코드에서 특정 서브도메인을 검색해 부정확하거나 오래된 서브도메인 참조를 업데이트해야 한다.

오쓰(OAuth)와 같은 서드파티 인증 프로세스의 인증 정보 또는 기타 민감한 정보가 서브도메인으로 전달됐다면 사고 대응에 돌입해서 노출 수준을 확인해야 한다. 공격자는 다른 도메인의 iframe을 내장해 이와 같은 서브도메인을 신뢰할 수 있는 서브도메인처럼 꾸밀 수 있다. 그런 다음 내부 피싱 공격이나 외부 고객에 대한 공격에 사용한다. 해당 사고를 유발하기 위해 발생한 프로세스가 무엇인지 확인하고 앞으로는 발생하지 않도록 조치를 취해야 한다.

애저에는 네트워크에서 이와 같은 매달린 사례가 발생하지 않도록 하기 위한 기본 프로세스가 있다. 이 가운데 하나는 애저 앱 서비스에서 도메인 확인 ID가 있는 asuid.(subdomain) TXT 레코드를 사용하는 것이다. 이렇게 하면 다른 애저 구독이 도메인을 검증하고 점유하지 못한다. 또는 점유에 민감한 웹사이트를 구축하지 않도록 개발자와 운영 부서 간의 상호작용을 더 늘리는 코딩 프로세스를 두는 방법도 있다.

서브도메인 점유로부터 스스로를 보호하는 다른 방법은 교육을 통해 개발자가 이 문제를 인지하도록 하고 체크리스트나 프로세스에 남은 DNS 항목 확인하기를 추가하는 것이다. *.azurewebsites.net 또는 *.cloudapp.azure.com을 가리키는 리소스가 없는지 DNS 레코드를 검토하기 위한 프로세스를 마련한다.

애플리케이션 보안 엔지니어 알룬 존스는 2020년 2월 열린 RSA 컨퍼런스에서 서브도메인 점유 취약점에 대해 발표했다. 존스는 웹 서버의 폐기를 담당하는 조직과 DNS 레코드를 설정하는 조직이 달라 CNAME이 DNS에 남게 되는 경우를 설명했다. 존스는 클라우드 제공업체가 기업과 동일한 보안 프로세스를 제공할 것으로 기대해서는 안 되며, 궁극적으로 이 문제는 개발자가 인프라의 설정 방식을 온전하게 이해하지 못하는 조직 내부적인 문제라고 설명했다.

흔히 사용되는 해결책으로 빈 CNAME 레코드를 찾는, 모든 DNS 레코드의 스크립트 리뷰를 매시간 실행하는 방법이 있지만 존스는 해커가 취약한 서브도메인을 찾는 데 걸리는 시간이 1시간 미만이므로 이 방법으로는 문제를 선제적으로 해결할 수 없다고 말했다. 

웹사이트를 제거하기 위한 준비 과정에서 단순히 리소스 그룹을 삭제하는 것은 웹사이트의 안전을 보장하기에 부족하고 교육을 받은 개발자가 아니라도 할 수 있는 일이다. 존스는 자동화된 스캔의 빈도를 늘릴 것을 권장한다. 또한 존스는 DNS 레코드 조정에는 의존하지 말라고 조언한다. DNS의 유효기간(TTL)은 약 24시간이므로 서브도메인은 여전히 장시간 활성 상태로 남아 다양한 웹 캐시에 존재할 수 있기 때문이다.

OWASP 어매스(OWASP Amass) 및 Sublist3r로 서브도메인을 열거해 취약한 서브도메인을 찾을 수 있다. 서브오버(SubOver)는 자동 점유 도구로 사용할 수 있지만 클라우드 플랫폼으로 애저를 선택한 경우에는 사용할 수 없다. 여러 클라우드 공급업체가 고객을 더 잘 보호하고 기업에 속한 웹사이트가 해당 기업의 통제 하에 유지되도록 보장하기 위한 프로세스를 제공한다.

존스는 DNS 환경을 더 잘 이해하고, 특히 TTL과 관련해 개발자를 대상으로 기본적인 DNS 개념에 대한 교육을 실시해야 한다고 강조했다. 마지막으로, 사용 중인 클라우드 제공업체에 이 문제를 방지하기 위해 무엇을 하고 있는지를 물어야 한다. editor@itworld.co.kr


2020.12.28

애저 환경에서 서브도메인 점유를 방지하는 방법

Susan Bradley | CSO
도메인을 설정하고 클라우드 리소스를 그대로 둔 채 해당 사이트를 삭제한 적이 있는가? DNS(domain name services) 설정에서 CNAME을 그대로 방치한 경우는? 
 
ⓒ Getty Images Bank

많은 관리자가 경험한 일이고 공격자들도 이를 알고 있다. 공격자는 관리자가 깜박 잊은 이와 같은 부분을 이용해 서브도메인 레코드에 사이트를 만들어 점유한다. 서브도메인 점유(Subdomain takeovers)는 많은 리소스를 만들고 삭제하는 대기업에서는 매우 흔하다. 특히 CNAME 레코드가 점유에 많이 노출된다. 악의적 행위자는 이런 사이트를 사용해 다양한 다른 사이트로 트래픽과 활동을 리디렉션한다. 마이크로소프트조차 이 문제에서 자유롭지 못하다.

DNS는 네트워크 인프라에서 잘못 이해되는 경우가 많으며, 잘못된 DNS 구성이 심각한 네트워크 문제로 이어지는 경우가 매우 많다. 단순히 레코드가 바뀌었을 뿐인데 웹사이트가 해킹된 것처럼 보일 수 있다. 또한 자산이 노출되어 공격에 사용될 수도 있다.


공격자가 서브도메인을 악용하는 방법

마이크로소프트가 공지한 바와 같이 애저 리소스를 설정하고 프로비저닝하는 시점부터 서브도메인 점유에 노출되기 시작한다. 예를 들어 애저 리소스의 이름이 app-on-azure001. azurewebsites.net이라고 가정해 보자. 

이 애저 리소스로 트래픽을 라우팅하는 서브도메인이 있는 실제 DNS 영역에 CNAME 레코드를 할당하고, 사용자를 app-on-azure001.azurewebsites.net으로 보내는 대신 easierurl.domain.com으로 보낸다. 얼마 후 이 서브도메인이 필요 없다고 판단해서 웹사이트를 디프로비저닝하고 삭제한다. 이 시점에서 DNS 영역의 subdomain.yourdomain.com을 제거해야 한다. 남은 CNAME은 활성 도메인임을 알리지만 활성 애저 리소스를 통해 트래픽을 라우팅하지는 않는다. 이것을 “매달린 DNS 레코드(dangling DNS record)”라고 한다.

공격자는 다양한 도구와 스크립트를 사용해 이와 같은 상태의 서브도메인을 검색하고 찾는다. 공격자는 기본적인 DNS 조회로 현재 라우팅하지 않는 CNAME 레코드를 손쉽게 알아낼 수 있다. 공격자는 현재 누락된 애저 리소스에 여러분이 할당한 것과 같은 이름을 사용해서 애저 리소스를 프로비저닝한다. 이제 이들의 공격 웹사이트 이름이 app-on-azure001.azurewebsites.net이 되고, 여러분의 subdomain.domain.com은 도메인 네임 리소스를 통해 공격자의 사이트를 라우팅한다. 공격을 받게 되면 콘텐츠에 대한 통제력을 상실하거나 쿠키 및 방문자 정보가 공격자 사이트로 넘어갈 수 있다.


서브도메인 점유를 방지하는 방법

잠재적인 문제를 파악하려면 맞춤형 도구 또는 마이크로소프트 깃허브 파워셸 도구의 Get-DanglingDnsRecords를 사용해 애저 리소스와 연결된 CNAME을 점검한다. 모든 취약한 CNAME 또는 자신의 소유가 아닌 자산을 가리키는 CNAME을 찾은 다음, DNS 영역이 호스팅되는 곳으로 가서 더 이상 프로비저닝되지 않는 리소스의 정규화된 도메인 이름을 가리키는 모든 CNAME 레코드를 삭제한다. 또한 웹사이트나 애플리케이션 코드에서 특정 서브도메인을 검색해 부정확하거나 오래된 서브도메인 참조를 업데이트해야 한다.

오쓰(OAuth)와 같은 서드파티 인증 프로세스의 인증 정보 또는 기타 민감한 정보가 서브도메인으로 전달됐다면 사고 대응에 돌입해서 노출 수준을 확인해야 한다. 공격자는 다른 도메인의 iframe을 내장해 이와 같은 서브도메인을 신뢰할 수 있는 서브도메인처럼 꾸밀 수 있다. 그런 다음 내부 피싱 공격이나 외부 고객에 대한 공격에 사용한다. 해당 사고를 유발하기 위해 발생한 프로세스가 무엇인지 확인하고 앞으로는 발생하지 않도록 조치를 취해야 한다.

애저에는 네트워크에서 이와 같은 매달린 사례가 발생하지 않도록 하기 위한 기본 프로세스가 있다. 이 가운데 하나는 애저 앱 서비스에서 도메인 확인 ID가 있는 asuid.(subdomain) TXT 레코드를 사용하는 것이다. 이렇게 하면 다른 애저 구독이 도메인을 검증하고 점유하지 못한다. 또는 점유에 민감한 웹사이트를 구축하지 않도록 개발자와 운영 부서 간의 상호작용을 더 늘리는 코딩 프로세스를 두는 방법도 있다.

서브도메인 점유로부터 스스로를 보호하는 다른 방법은 교육을 통해 개발자가 이 문제를 인지하도록 하고 체크리스트나 프로세스에 남은 DNS 항목 확인하기를 추가하는 것이다. *.azurewebsites.net 또는 *.cloudapp.azure.com을 가리키는 리소스가 없는지 DNS 레코드를 검토하기 위한 프로세스를 마련한다.

애플리케이션 보안 엔지니어 알룬 존스는 2020년 2월 열린 RSA 컨퍼런스에서 서브도메인 점유 취약점에 대해 발표했다. 존스는 웹 서버의 폐기를 담당하는 조직과 DNS 레코드를 설정하는 조직이 달라 CNAME이 DNS에 남게 되는 경우를 설명했다. 존스는 클라우드 제공업체가 기업과 동일한 보안 프로세스를 제공할 것으로 기대해서는 안 되며, 궁극적으로 이 문제는 개발자가 인프라의 설정 방식을 온전하게 이해하지 못하는 조직 내부적인 문제라고 설명했다.

흔히 사용되는 해결책으로 빈 CNAME 레코드를 찾는, 모든 DNS 레코드의 스크립트 리뷰를 매시간 실행하는 방법이 있지만 존스는 해커가 취약한 서브도메인을 찾는 데 걸리는 시간이 1시간 미만이므로 이 방법으로는 문제를 선제적으로 해결할 수 없다고 말했다. 

웹사이트를 제거하기 위한 준비 과정에서 단순히 리소스 그룹을 삭제하는 것은 웹사이트의 안전을 보장하기에 부족하고 교육을 받은 개발자가 아니라도 할 수 있는 일이다. 존스는 자동화된 스캔의 빈도를 늘릴 것을 권장한다. 또한 존스는 DNS 레코드 조정에는 의존하지 말라고 조언한다. DNS의 유효기간(TTL)은 약 24시간이므로 서브도메인은 여전히 장시간 활성 상태로 남아 다양한 웹 캐시에 존재할 수 있기 때문이다.

OWASP 어매스(OWASP Amass) 및 Sublist3r로 서브도메인을 열거해 취약한 서브도메인을 찾을 수 있다. 서브오버(SubOver)는 자동 점유 도구로 사용할 수 있지만 클라우드 플랫폼으로 애저를 선택한 경우에는 사용할 수 없다. 여러 클라우드 공급업체가 고객을 더 잘 보호하고 기업에 속한 웹사이트가 해당 기업의 통제 하에 유지되도록 보장하기 위한 프로세스를 제공한다.

존스는 DNS 환경을 더 잘 이해하고, 특히 TTL과 관련해 개발자를 대상으로 기본적인 DNS 개념에 대한 교육을 실시해야 한다고 강조했다. 마지막으로, 사용 중인 클라우드 제공업체에 이 문제를 방지하기 위해 무엇을 하고 있는지를 물어야 한다. editor@itworld.co.kr


X