2016년 10월의 어느 토요일, 브라질의 한 대형 은행이 인터넷에서 사라졌다. 건물이 아니라 온라인 버전이. 약 5시간 동안, 이 은행의 도메인 36개가 전부 은행 소유가 아닌 서버를 가리켰다. 브라우저에 은행 주소를 친 고객은 픽셀 단위로 똑같이 복제된 가짜 사이트를 만났고, 그 사이트는 자격 증명을 긁어가고 보안 플러그인으로 위장한 악성코드를 밀어넣었다. 온라인 뱅킹, 모바일, 이메일, FTP — 전부 리다이렉트됐다.
공격자들은 은행을 뚫지 않았다. 그럴 필요가 없었으니까. 이 사건을 파고든 Kaspersky의 Dmitry Bestuzhev는, 그들이 .br 레지스트라인 Registro.br의 은행 계정에 들어가 도메인이 가리키는 곳을 바꿔버렸다는 걸 밝혀냈다. 진입로로는 레지스트라 직원 대상 spear-phishing이 유력했고, 레지스트라 사이트 자체의 CSRF 버그도 한몫했다. 은행은 몇 년에 걸쳐 인프라를 단단히 조여왔다. 공격자들은 은행이 통제하지 못하는 유일한 문으로 걸어 들어왔다.
이런 일은 계속 일어나고, 계속 통한다. 대부분이 한 번도 생각해본 적 없는 사실 때문에: 당신의 도메인 레지스트라는 당신이 보안을 위해 하는 다른 모든 것 위에 앉아 있다.
스택 맨 위에 있는 것
당신이 실제로 뭘 지키는지 생각해보자. 아무도 사칭 못 하게 TLS 인증서를 받는다. 아무도 DNS 응답을 위조 못 하게 DNSSEC를 켠다. 오리진 앞에 WAF를 두고, 키를 교체하고, SSH를 잠근다. 이 전부가 한 가지를 참으로 가정한다: “이 도메인은 여기 산다”고 말하는 DNS 레코드가 당신 것이라는 가정.
레지스트라가 바로 그 가정이 사는 곳이다. 도메인의 control plane — 어느 네임서버가 authoritative인지, A 레코드가 어디를 가리키는지, 심지어 도메인이 누구 것인지를 결정하는 계정. 그리고 불편한 부분은 이거다: 그게 보통 아이디, 비밀번호, 그리고 설득당할 수 있는 사람들이 지키는 고객지원 회선으로 보호된다.
그래서 공격자에게는 선택지가 있다. 당신이 공들여 설계한 crypto를 공격할 수도 있다 — TLS, DNSSEC, 방화벽과 싸운다. 아니면 그 모든 걸 무의미하게 만드는 계정에 폼 하나 제출로 로그인할 수도 있다. 네임서버를 바꾸면 DNSSEC 키도 함께 딸려간다. 도메인을 자기 서버로 돌리면, 그들의 Let’s Encrypt 인증서가 90초쯤 만에 자물쇠를 초록색으로 만든다. 피해자가 보안에 투자한 전부가 자기 자신을 우회해버린다.
공격자들은 바보가 아니다. 그들은 control plane을 노린다.
plane 자체가 표적이 될 때
브라질 은행은 계정 하나였다. 2019년, Cisco Talos는 더 나쁜 걸 공개했다. Sea Turtle이라 이름 붙인 캠페인에서, 공격자들은 레지스트라와 레지스트리 자체를 노렸다.
Talos는 대략 2017년 1월부터 2019년 초까지 13개국 최소 40개 조직이 침해된 걸 추적했다 — 대부분 중동·북아프리카의 국가안보·정부 표적이었다. 방식은 같은 아이디어를 키운 것이었다: DNS를 편집할 수 있는 계정의 자격 증명을 탈취한 뒤, 네임서버·A·MX 레코드를 다시 써서 피해자를 공격자가 통제하는 머신으로 경유시키고, 그 길목에서 더 많은 자격 증명을 긁고 유효한 인증서까지 발급받는다.
거슬려야 할 디테일은 2019년 1월 스웨덴 DNS 사업자 Netnod의 침해다 — 첩보 목적으로 DNS 레지스트리가 뚫린 최초의 공개 확인 사례로 기록됐다. 레지스트리의 고객 계정이 아니라, 레지스트리 그 자체. TLD 레코드의 마스터 사본을 쥐고 있는 존재가 털리면, “DNSSEC 켜면 되잖아”는 갑자기 순진한 소리가 된다. 그 거짓말에 서명할 수 있는 자들이 집 안에 들어와 있었으니까.
Talos의 후속 보고는 이 그룹이 공개적으로 노출된 뒤에도 계속 활동했다고 짚었다. 경제학이 성립한다는 뜻이다. 근원에서 DNS를 장악하는 건 실행하기 비싸지만 엄청나게 가치 있고, 그래서 자원이 넉넉한 행위자는 계속 값을 치른다.
아예 해킹이 없을 때도 있다
가장 짜증나는 부분은 이거다. 기술적으로 인상적이지도 않아서.
2020년 말, 누군가 perl.com — 30년 넘은 프로그래밍 언어의 도메인 — 을 Network Solutions를 설득해 이전시켜 가져갔다. 사건 보도는 서버 침해가 아니라 위조 문서를 동원한 social engineering을 가리킨다. 공격자는 9월에 등록자 연락처를 바꾸고, ICANN의 변경 후 60일 이전 잠금(하이재킹을 막으려는 규칙을, 느긋하게 카운트다운 타이머로 써먹었다)을 기다린 뒤, 12월에 도메인을 BizCN으로, 1월에 Key Systems로 튕겨냈다. 그 무렵 Afternic에 190,000달러에 매물로 올라와 있었다. 기자들이 캐묻기 시작하고 커뮤니티가 목소리를 내면서야 돌아왔고, 도메인은 2021년 2월 초 오랜 소유자에게 복구됐다.
제로데이도 없고, 악성코드도 없다. 설득력 있는 이메일 한 통과 가짜 서류 몇 장, 그리고 고객지원 프로세스. 도메인 — 한 언어 커뮤니티 전체의 정체성 — 이, 레지스트라의 사람이 이야기를 믿었다는 이유로 움직였다.
이건 더 강한 cipher로 못 막는다.
거의 아무도 안 켜는 해법
진짜 방어책이 있다. 그것도 프로토콜 안에 처음부터 들어 있었다.
모든 도메인에는 EPP status code가 있다. 흔한 clientTransferProhibited는 레지스트라가 기본으로 걸어두는 “registrar lock”이다. 도메인이 다른 레지스트라로 이전되는 걸 막는다 — 유용하고, ICANN 인증 레지스트라라면 다 존중한다. 하지만 이건 client-side다: 당신 레지스트라에, 당신 레지스트라 계정의 통제 아래 산다. 누가 그 계정을 쥐면, 나머지 전부와 함께 이것도 꺼버릴 수 있다. 실수로 인한 이전은 막지만, 탈취된 로그인은 못 막는다.
더 센 건 registry lock이다: serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited, 한 단계 위인 레지스트리에 걸린다. 이걸 켜면 도메인의 핵심 속성 변경에 out-of-band 수동 검증이 필요해진다 — 전화 한 통, 암구호, 정말 당신이 맞는지 확인하는 레지스트리 쪽 사람. 즉 공격자가 당신 레지스트라 계정을 통째로 쥐어도, 여전히 도메인을 이전·삭제·재지정할 수 없다. 당신의 보안 스택 전체를 우회하던 그 유일한 공격 경로에 드디어 자물쇠가 걸린다.
거의 아무도 안 쓴다. 기본값이 아니고, 대개 돈이 조금 들고, 당신이 정당하게 뭔가 바꿀 때 살짝 성가시고, 당신을 구해주는 그날 전까지는 보이지 않는다. 그래서 registry lock을 걸어둔 도메인은, 이미 한 번 데였거나 남이 데는 걸 지켜보고 그 성가심이 장애보다 싸다고 결론 낸 사람들이 굴리는 경우가 많다.
중요한 뭔가를 운영한다면 — 은행, 패키지 레지스트리, 회사 전체 이메일이 흐르는 도메인 — 계산은 접전이 아니다. 브라질 은행은 세계적 수준의 인프라를 갖고도 계정 하나 때문에 5시간 동안 전부를 잃었다. Perl.com은 30년의 신뢰를 쌓고도 팩스 한 장 분량의 위조에 이름을 잃을 뻔했다.
레지스트라는 당신 스택의 맨 위이고, 대부분은 그 맨 위를 비밀번호 하나와 “지원 상담원이 오늘 컨디션이 좋기를”이라는 희망으로 지킨다. registry lock을 켜라. 당신 보안 예산 전체에서 가장 싼 보험이고, 다른 모든 게 이미 닫혀 있다고 가정하는 그 하나의 문을 겨냥한다.