마스터카드 DNS 오타, 거의 5년간 미발견

 (krebsonsecurity.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • MasterCard는 mastercard.com 일부 트래픽을 안내하는 Akamai DNS 서버명 하나를 akam.net이 아닌 akam.ne로 잘못 설정했고, 이 오타가 2020년 6월 30일부터 2025년 1월 14일까지 거의 5년간 남아 있었음
  • 보안 연구자 Philippe Caturegli는 니제르 국가 최상위 도메인 아래의 akam.ne가 미등록 상태라고 보고, 300달러와 약 3개월을 들여 도메인을 확보해 악용 가능성을 차단함
  • akam.ne에 DNS 서버를 켜자 전 세계에서 하루 수십만 건의 DNS 요청이 들어왔고, 같은 오타를 낸 조직 중 MasterCard가 가장 큰 사례였음
  • 이 도메인이 악용됐다면 잘못 전달된 이메일 수신, 영향을 받는 웹사이트용 SSL/TLS 인증서 확보, 일부 Windows 인증 정보 수동 수신으로 이어질 수 있었음
  • MasterCard는 “시스템에 위험은 없었다”고 밝히고 오타를 수정했지만, 이후 Bugcrowd를 통한 LinkedIn 게시물 삭제 요청까지 이어지며 공개 방식 논란이 남음

거의 5년간 방치된 DNS 오타

  • MasterCard는 mastercard.com 네트워크 일부 트래픽을 안내하기 위해 Akamai의 공유 DNS 서버 5개를 사용함
  • 2020년 6월 30일부터 2025년 1월 14일까지 이 중 하나가 잘못된 이름으로 설정돼 있었음
    • 정상 서버명은 akam.net으로 끝나야 함
    • 문제 설정은 akam.ne를 가리켰음
  • akam.ne는 서아프리카 니제르의 국가 최상위 도메인 관리 범위에 있는 도메인임

연구자가 도메인을 먼저 확보

  • 보안 컨설팅 회사 Seralys 창업자 Philippe Caturegli가 이 오타를 발견함
  • Caturegli는 akam.ne가 아직 등록되지 않았을 것으로 보고 니제르 레지스트리를 통해 도메인을 확보함
    • 비용은 300달러
    • 등록까지 거의 3개월이 걸림
  • DNS 서버를 활성화하자 전 세계에서 매일 수십만 건의 DNS 요청이 들어옴
  • MasterCard만 같은 오타를 낸 것은 아니었지만, 들어온 요청 기준으로는 가장 큰 조직이었음

오타 도메인이 만들 수 있었던 위험

  • Caturegli가 akam.ne에 이메일 서버를 켰다면 mastercard.com이나 다른 영향받은 도메인으로 향하던 잘못 전달된 이메일을 받을 수 있었음
  • 접근 권한을 악용했다면 영향을 받는 웹사이트의 트래픽을 받아 전달할 수 있는 SSL/TLS 인증서를 얻을 가능성도 있었음
  • 직원 컴퓨터에서 Microsoft Windows 인증 정보를 수동으로 받을 수 있었을 가능성도 남아 있었음
  • Caturegli는 이런 행위를 시도하지 않았고, MasterCard에 도메인을 넘길 수 있다고 알림
    • 통지에는 Krebs on Security 작성자도 참조로 포함됨

MasterCard와 Bugcrowd의 대응

  • MasterCard는 몇 시간 뒤 실수를 인정했지만 운영 보안에는 실제 위험이 없었다고 밝힘
    • “시스템에 위험은 없었다”
    • “이 오타는 수정됐다”
  • 이후 Caturegli는 Bugcrowd를 통해 메시지를 받음
    • 메시지는 Caturegli가 akam.ne를 확보한 뒤 LinkedIn에 공개한 일이 윤리적 보안 관행과 맞지 않는다는 취지였음
    • MasterCard가 해당 게시물 삭제를 요청했다는 내용도 포함됨
  • Caturegli는 자신이 Bugcrowd 프로그램을 통해 제보한 적이 없고, 문제를 MasterCard에 직접 보고했다고 답함
  • 그는 공개 전에 영향받은 도메인을 등록해 악용을 막았고, 그 비용도 직접 부담했다고 밝힘

DNS 캐시가 키울 수 있는 영향 범위

  • 일반적으로 조직은 최소 2개의 권한 있는 DNS 서버를 두지만, 요청이 많은 조직은 부하 분산을 위해 더 많은 DNS 서버 도메인을 사용함
  • MasterCard는 5개의 DNS 서버를 쓰기 때문에 공격자가 그중 하나만 장악하면 전체 DNS 요청의 약 5분의 1만 볼 수 있을 것처럼 보일 수 있음
  • 실제 인터넷 사용자는 Cloudflare나 Google 같은 공개 DNS 리졸버에 의존하기 때문에 영향이 더 커질 수 있음
    • 리졸버 하나가 잘못된 네임서버에 질의하고 결과를 캐시하면 됨
    • DNS 레코드에 긴 TTL을 설정하면 대형 클라우드 제공자를 통해 잘못된 지시가 퍼질 수 있음
  • Caturegli는 긴 TTL을 쓰면 트래픽 재라우팅 범위가 단순히 5분의 1보다 훨씬 커질 수 있다고 봄

문제 서브도메인과 과거 등록 흔적

  • Caturegli가 공개한 스크린샷에는 잘못 설정된 DNS 서버가 MasterCard의 az.mastercard.com 서브도메인과 관련돼 있음
  • 이 서브도메인이 정확히 어떻게 쓰이는지는 불분명함
  • 이름 규칙상 Microsoft Azure 클라우드의 프로덕션 서버와 관련된 도메인으로 보이며, Caturegli는 해당 도메인들이 Microsoft 인터넷 주소로 해석된다고 밝힘
  • akam.ne는 과거에도 등록된 적이 있음
    • 2016년 12월 um-i-delo@yandex.ru 이메일을 쓰는 사용자가 등록함
    • Yandex는 이 계정이 모스크바의 “Ivan I.”에 속한다고 표시함
    • DomainTools.com의 수동 DNS 기록에 따르면 2016년부터 2018년까지 독일의 인터넷 서버에 연결돼 있었고, 2018년에 만료됨
  • 전 Cloudflare 직원은 Caturegli의 LinkedIn 게시물 댓글에서 비슷한 사례를 다룬 보고서를 링크함
    • 일부 조직이 AWS DNS 서버 awsdns-06.net을 awsdns-06.ne로 잘못 입력했을 가능성이 있는 오타 도메인 사례임
    • DomainTools에 따르면 이 오타 도메인도 Yandex 사용자에게 등록됐고, 같은 독일 ISP인 Team Internet에 호스팅됐음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 사례처럼 공개 등록 가능한 네임서버는 댕글링 DNS 문제의 비교적 드문 하위 유형일 뿐이고, 더 흔한 건 공격자가 확보할 수 있는 클라우드 제공자의 IP 주소로 도메인이 직접 매핑된 경우임
    클라우드 서비스는 범위가 넓고 전역 가시성이 부족한 경우가 많아서, 클라우드를 쓰는 기업은 하위 도메인 어딘가에 이런 취약점이 있을 가능성이 큼
    버그 바운티 프로그램은 “하위 도메인 탈취”를 일괄 제외하는 경우가 많지만, 발견되면 쉽게 악용 가능하고 이런 설정 실수로 민감 정보가 유출된 내부·공개 데이터도 있음
    현재 취약점 공개 환경은 기업이 실제 취약점 인정을 회피하기 너무 쉽고, 선의의 연구자는 윤리·법적 제약 때문에 제공자가 요구하는 수준의 증거를 제시하기 어렵게 되어 있음
    이런 취약점으로 실제로 TLS 인증서 발급이 간단히 가능하다는 위험도 과소평가되고 있음
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • IP뿐 아니라 “조직이 더 이상 통제하지 않는 공유 클라우드 자원을 가리키는 DNS 레코드” 문제가 거대한 범주로 존재하고, 회사가 클수록 더 널리 퍼짐
      예를 들면 해제된 S3 버킷을 가리키는 CNAME, Azure Website/WebApp 인스턴스, 비탄력 IP를 가리키는 A 레코드, 더 이상 조직 AWS 계정에 속하지 않는 Route53 네임서버, 삭제·비활성화된 Heroku/Shopify/GitHub Pages 계정, 망한 트랜잭션 이메일 업체 도메인을 가리키는 MX 레코드 등이 있음
      원인은 IT 분산화로 잘 모르는 사람이 인프라를 만들고, 해체할 때 DNS를 잊고, 자회사·브랜드·지역별 조직이 많아 정책 발견과 강제가 어렵고, 국가별 웹사이트·앱이 많고, 보안팀에 알리지 않은 외부 업체 사용이 쌓이기 때문임
      이 분야의 이스라엘 사이버 보안 회사에서 Field CTO로 일하는데, 어제도 한 대형 컴퓨터 부품 회사와 그들의 도메인·페이지랭크·링크를 이용해 “운영”되는 인도네시아 도박 사이트 12개쯤에 대해 이야기했고, 이런 대화가 매주 반복됨
    • 버그 바운티가 모든 “하위 도메인 탈취”를 무효로 보는 건 너무 뭉뚱그린 대응이고, 도메인을 얼마나 쉽게 확보할 수 있는지로 구분해야 함
      “어떻게든 google.com을 탈취하면 Google 사용자를 침해할 수 있다”는 건 유효한 보안 취약점이 아니지만, 여기처럼 미등록·만료 도메인 탈취가 침해로 이어진다면 유효한 취약점으로 봐야 함
    • 버그 바운티 공개가 FCC 같은 정부 기관에도 자동 보고되고 해당 회사 이메일이 참조된다면 더 효과적일 수 있음
      회사가 보고를 기각하려면 명확한 증거를 내야 하고, 그 보고에서 나온 악용이 입증되거나 회사가 변경을 해서 보고서의 재현 절차가 더 이상 동작하지 않으면 보상 지급 또는 벌금 대상이 되게 할 수 있음
    • 어떤 암호화폐 거래소에서는 애플리케이션 수준 제어 없이 더 빠른 로드 밸런서에 접근 가능한 IP 주소를 허용 목록으로 관리했음
      클라우드 IP를 엄청나게 할당하고 반복해서 오래된 IP를 찾아 원래보다 훨씬 많은 용량을 얻었고, 더 높은 속도 제한으로 요청을 보냈음
      지금은 더 이상 통하지 않을 것 같고, 이제는 모두가 아는 방식임

  • 이 이야기에서 Bugcrowd 부분은 예상 밖임
    메일 스크린샷이 “Platform Behavior Standards Team”에서 온 것처럼 보이는데, 그렇다면 Bugcrowd가 플랫폼 밖 행동까지 규제하려고 플랫폼 기준을 지나치게 넓게 해석했거나, Mastercard가 공식 Bugcrowd 직원을 사칭한 셈임
    어느 쪽도 별로 받아들이기 어려움
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • Bug Bounty 플랫폼은 책임 있는 공개를 장려하기보다, 그것을 포획하고 막기 위해 존재한다는 해석이 있음
      그 주장을 자주 하던 사람이 보면 더 잘 풀어 설명할 수 있을 듯함
    • 문구도 심각하게 나쁨
      이미 잘못을 저지른 것으로 판정된 것처럼 쓰여 있고, 선택지는 따르거나 왜 잘못인지 추가 설명을 요구하는 것뿐임
      본인이 잘못한 게 아니라는 점을 설명할 기회가 없음
    • 내 경험상 BugCrowd는 보고서가 실제 회사에 도달하는 걸 지연시키고 늪에 빠뜨리려는 일을 다 함
      회사 입장에서는 바운티 지급과 내부 검토 비용이 줄고, 법적으로도 그럴듯한 부인 가능성을 확보할 수 있음
    • 여기 Bugcrowd 직원도 있을 테니, 그 이메일을 설명해 줄 수 있을 듯함

  • “실제 위협은 없었다”는 식의 대응은 다음번에 보안 연구자들이 이 회사나 다른 회사에서 영향 증거를 더 모으려고 더 깊게 침입하게 만들 가능성이 큼
    회사 대변인이 “문제없다”고 말할 수 있게 하고 싶다면, 영향이 축소되어도 연구자가 받아들일 만큼 충분히 보상해야 함
    이미 연구자가 올바르게 행동한 것처럼 보이는데도 뉴스를 억누르려고 연구자를 압박한 건, 신용카드 회사에 그럴 이유가 있었던 건지, 아니면 홍보 담당자의 잘못된 업무 인식인지, 혹은 정보보안 실수의 최종 책임자가 본인 임기 중 망신을 피하려 회사 자원을 쓴 건지 의문임

    • 이유는 있음
      보안 연구자들이 결과를 공개하기 두려워하게 만들고 싶은 것임

  • 몇 년 전 우크라이나에서는 온라인 거래 전부 또는 대부분이 masterpass라는 서비스로 검증되어야 했고, Mastercard식 3DS 같은 것으로 보였음
    그런데 기업 웹에서 흔히 그렇듯 SSL 인증서가 만료됐고, 특정 종류의 MasterCard 카드로 하는 온라인 거래 전부 또는 대부분이 그 순간 완전히 막힘
    Mastercard는 1년 넘게 인증서를 갱신하지 않았고, 고객인 나나 은행 IT 부서가 아무리 연락해도 소용없었으며, 나중에는 서비스를 조용히 접어버림
    살펴보니 서비스는 Microsoft 계열(IIS)로 작성되어 있었고, 인증서 체인은 들어본 적 없는 중간 인증서들로 비정상적으로 길었으며, 우크라이나에서 꽤 먼 제3세계 국가에 호스팅되어 있었음

    • masterpass는 Mastercard의 3DS 버전이고, 거래가 의심스러울 때 전 세계적으로 쓰임
      Mastercard 관점에서는 그 나라의 거래가 모두 현지 주체 간 거래여도 기본적으로 의심스럽다고 본 것 같음
      미국에서는 만료된 걸 본 적이 없고, 국가별 트래픽 처리를 어떻게 하는지는 모르지만, Mastercard가 아니라 다른 곳으로 트래픽이 라우팅된 것처럼 들림

  • akam.ne가 2016년에 Yandex 이메일을 쓰는 모스크바의 “Ivan I.”에게 등록됐고, 2016~2018년에 독일 서버에 연결됐다가 만료됐다는 점이 찜찜함
    비슷하게 AWS DNS 서버 awsdns-06.net을 awsdns-06.ne로 잘못 입력한 조직을 노린 듯한 오타 도메인도 Yandex 계정으로 등록됐고, 같은 독일 ISP인 Team Internet(AS61969)에 호스팅됐다는 대목이 특히 수상함

    • “Ivan I”는 러시아식 가짜 흔한 이름인 Ivan Ivanov를 뜻할 가능성이 크고, 영어권의 “John Smith” 같은 이름임

  • “접근을 악용했다면 영향을 받은 웹사이트의 트래픽을 받고 중계할 수 있는 SSL/TLS 인증서를 얻을 수 있었을 것”과 “우리 시스템에는 위험이 없었다”는 말은 둘 중 하나가 틀려야 함
    양쪽 모두 거짓말하거나 과장할 유인은 있음

    • 한쪽은 수십억 달러 규모의 거짓말·과장 유인을 갖고 있고, 다른 한쪽은 하루 종일 정교한 공격자의 최악의 시나리오를 생각함
      CS:GO 서버라면 정교한 공격자의 최악 공격은 과장일 수 있지만, 세계 최대 결제 처리 회사 중 하나를 말할 때는 과장이 아님
    • 인증서가 어떻게 발급되는지 조금이라도 알면 연구자가 맞고 MasterCard가 헛소리한다는 걸 알 수 있음
      10분만 조사해도 같은 결론이 나옴
    • 영향이 없다면 그가 캡처한 DNS 질의 전체 목록을 공개하도록 허락하면 됨
      그렇게 하지 않을 이유는 그 목록이 악의적 행위자에게 인프라 단서를 주기 때문임
      MasterCard는 거짓말을 하거나, 무지하고 무능한 것임
    • 핵심은 az.mastercard.com이 실제로 무엇이고 무슨 일을 하는지에 크게 달려 있음
      x@mastercard.com으로 가는 이메일을 받는다는 얘기는 맞지 않아 보이고, 이건 용도를 알 수 없는 하위 도메인일 뿐임
      TLS는 아마 가능하겠지만, 위험은 그 도메인이 무엇인지에 따라 달라지고 mastercard.com을 방문하는 사용자에게 바로 영향을 주지는 않을 듯함
    • SSL/TLS 인증서라면 먼저 ACME 기반 인증서 제공자가 떠오름
      도메인 DNS 제어권만 있으면 충분하고, TXT 레코드나 본인이 제어하는 HTTP 서버로 요청을 보내는 방식이 가능함

  • Mastercard의 큰 실수인 건 분명하지만, 원래 최상위 도메인과 한 글자 차이인 도메인을 존재하게 두는 것 자체도 실수처럼 보임
    예를 들어 .com과 .co, .net과 .ne 같은 경우인데, 문제를 자초하는 구조임
    그런 도메인이 없었다면 등록도 못 하고 잘못된 DNS 요청은 그냥 아무 데도 가지 않았을 것임

    • 꼭 그렇지는 않음
      오타는 최상위 도메인뿐 아니라 이름의 어디서든 날 수 있고, 오타가 없어도 인기 사이트 이름에서 1비트 차이 나는 도메인을 잡는 비트스쿼팅으로 각종 컴퓨터 오류에서 트래픽을 얻을 수 있음
      예시가 있는 논문도 있음
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • 대기업이라면 Markmonitor로 이 문제를 처리할 거라고 예상했음
      기본적으로 편집 거리 1인 오타 도메인을 가능한 한 함께 등록해 두는 방식임
      Wikipedia에 따르면 Akamai는 Markmonitor 고객 중 하나라서, 이 도메인이 이미 등록되어 있지 않았다는 점이 의외임
    • Niger와 Colombia의 ISO 3166-2 코드는 어떻게 할 생각인지가 문제임
    • 민감한 전화번호와 딱 한 자리 차이 나는 전화번호가 존재하는 것과 뭐가 다른지 모르겠음
    • ISO 3166-1 alpha-2 최상위 도메인은 분명 유용하지만, 주소 공간 특성상 한 글자 차이 오타가 많이 생김
      비국가 코드 도메인도 국가 코드 최상위 도메인에서 글자 하나 빠진 형태와 겹칠 수 있으니 큰 차이는 아님
      다만 이런 설정 오류는 좋은 DNS 점검 도구라면 잡아낼 수 있음
      등록된 네임서버 중 하나가 해석되지 않거나, 네임서버들끼리 같은 존 일련번호 또는 실제 응답을 반환하지 않는 식으로 드러남
      .is에서는 도메인을 등록하려면 정상 동작하는 네임서버 2개를 제공해야 했지만, .com은 이제 그렇게 까다롭지 않음

  • 그 도메인 이름은 akamai에 넘겼어야 함
    같은 주소로 다른 요청들도 오고 있고, akamai가 책임 있게 처리해야 함

  • “우리가 스스로를 조사해 보니 잘못이 없었다”는 전형적인 대응임
    Mastercard는 전 세계에 최소 34억 장의 브랜드 카드를 보유하고, 2024년 3분기에 전 세계 신용·직불·현금 거래 443억 건을 처리한 수십억 달러 규모의 상장사임
    잘못을 인정하는 건 시장에서 단기적으로 손해일 수 있지만, 부정하는 문화는 회사 문화를 망침
    ClownStrike와 다를 바 없고, 약탈적·기생적인 신용·직불 네트워크에는 혼란이 올 때가 됐음

  • “오타는 수정됐고 시스템 위험은 없었다”는 식의 말은 언제나 똑같고, 이런 성명은 정말 화가 남

    • 그들의 계산은 이렇겠지
      문제를 인정하면 주가 수백만 달러가 날아갈 수 있지만, 부인하면 괴짜들이 조금 더 징징거릴 뿐임
      침해 증거 없이는 강제하기 어렵고, 침해 증거가 있으면 감옥에 가게 됨
    • 실제 뜻은 “IT 부서의 아무것도 모르는 직원과 이야기했는데, 그 직원은 노출을 찾지 않을 개인적 유인이 있었고, 15초 안에 악용 방법을 떠올리지 못했다”에 가까움
      뭘 아는 사람이라면 무언가가 악용될 수 없다고 단정할 만큼 안전하다고 느끼는 경우가 거의 없음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.