해킹당한 Microsoft 테스트 계정에 관리자 권한이 있었음

• Microsoft 침해는 MFA 없는 오래된 테스트 계정이 고위 임원과 보안·법무팀 이메일 접근으로 이어졌다는 점에서 단순 계정 탈취보다 심각함
• 러시아 국가 연계 그룹 Midnight Blizzard는 약한 자격 증명을 password spraying으로 악용해 “legacy non-production test tenant account”에 로그인함
• 공격자는 손상된 테스트 테넌트에서 OAuth 앱 권한을 이용해 Office 365 Exchange Online의 full_access_as_app 역할을 확보함
• full_access_as_app 부여에는 관리자 권한이 필요하므로, 테스트 계정이 프로덕션 환경에서 과도한 권한을 가진 구성 오류였다는 비판이 나옴
• 최소 권한 원칙을 벗어난 테스트 계정과 주거용 프록시 기반 password spraying은 기존 침해 지표 중심 탐지를 어렵게 만듦

---

테스트 계정에서 이메일 접근까지

• 러시아 국가 해커는 password spraying으로 약한 자격 증명을 악용해 “legacy non-production test tenant account”에 로그인함
• 해당 테스트 계정은 다중 인증으로 보호되지 않았음
• 이후 Microsoft 고위 임원과 보안·법무팀 직원의 이메일 계정에 접근할 수 있는 권한이 확보됨
• 공격 그룹 Midnight Blizzard는 OAuth 인증 프로토콜을 악용해 권한 있는 이메일 계정에 지속 접근함
  • 손상된 테스트 테넌트에서 악성 앱을 생성함
  • Microsoft Office 365 이메일 서비스의 모든 이메일 주소에 접근할 수 있는 권한을 앱에 부여함
  • 기존 테스트 OAuth 애플리케이션으로 Office 365 Exchange Online의 full_access_as_app 역할을 부여함

관리자 권한을 가진 legacy 테스트 계정

• Microsoft의 업데이트에는 “legacy test OAuth application”이 Microsoft corporate environment에서 elevated access를 가지고 있었다는 내용이 포함됨
• Kevin Beaumont에 따르면 OAuth 앱에 full_access_as_app 역할을 부여하려면 계정에 관리자 권한이 있어야 함
• Beaumont는 이 구성을 “프로덕션의 꽤 큰 구성 오류”로 평가함
• 오래된 legacy 테스트 계정에 이처럼 넓은 권한을 부여하고 유지할 합당한 이유를 상상하기 어렵다는 비판이 나옴
• Microsoft는 테스트 계정이 처음부터 왜 그런 구성으로 설정됐는지, legacy 상태가 된 뒤에도 왜 유지됐는지에 대한 설명을 거부함

최소 권한 원칙을 벗어난 구성

• 이 구성은 계정이 작업 수행에 필요한 최소 권한만 가져야 한다는 최소 권한 원칙을 깨뜨림
• legacy 테스트 계정이 관리자 권한을 가져야 하는 이유를 이해하기 어렵다는 점이 핵심 문제임
• Beaumont는 이를 보안, MFA, 방화벽, 모니터링이 없는 테스트 도메인에 프로덕션 시스템의 Domain Admin 사용자를 둔 상황에 비유함
  • Domain Admin 사용자는 도메인 컨트롤러와 Active Directory를 포함해 네트워크에 연결된 장치에 대한 전체 관리자 권한을 가짐
  • 네트워크에서 가장 강력한 계정이므로 격리돼야 하며, 프로덕션 시스템에 포함되는 일은 드물어야 함
  • 강력한 비밀번호와 표준 보안 조치 없이 이런 계정이 방치되면 피해가 커짐

다른 조직 침해와 은밀한 password spraying

• Microsoft는 Midnight Blizzard가 다른 조직도 추가로 침해했음을 탐지했고, 영향을 받은 조직에 알림
• Hewlett-Packard Enterprises도 자사 네트워크가 Midnight Blizzard에 의해 해킹됐다고 밝힘
  • 해당 침해는 5월에 발생함
  • 발견 및 차단은 12월까지 이뤄지지 않았음
• 테스트 계정 접근에 사용된 password spraying은 제한된 수의 계정에 대해 계정당 적은 횟수로 수행됨
• 공격자는 분산된 주거용 프록시 인프라로 악성 활동을 덜 드러나게 만듦
  • 평판이 좋은 IP 주소에서 접속함
  • 예상 지역에 위치한 IP 주소를 사용함
  • 합법 사용자 트래픽처럼 섞여 보이게 함

기존 침해 지표 탐지의 한계

• 주거용 프록시를 사용한 방식은 새로운 기법이 아니며, 2020년 SolarWinds 공급망 공격에서도 사용됨
• SolarWinds 공격 역시 Midnight Blizzard가 수행한 것으로 연결됨
• 주거용 프록시는 많은 수의 합법 사용자 IP를 통해 트래픽을 라우팅하므로 전통적인 침해 지표 기반 탐지가 실질적으로 어려움
• Midnight Blizzard는 미국과 영국 정부가 러시아 해외정보국 SVR을 위해 활동한다고 밝힌 그룹임
• 같은 그룹을 추적하는 다른 이름으로 APT29, the Dukes, Cloaked Ursa, UNC2452, Dark Halo가 사용됨

[GN⁺]

Hacker News 의견들

• 예전에 들은 오래된 Roblox 해킹이 떠오름. 사용자 가입이 가능한 비운영 스테이징 사이트가 있었고, “여기 있는 것은 영구적이지 않다”는 배너가 붙어 있었음
  운영 환경에 새 관리자 계정이 추가됐는데, 누군가 스테이징 사이트에서 같은 사용자명으로 가입한 뒤 그 쿠키와 토큰을 이용해 운영 계정을 탈취하고 사이트를 침해할 수 있었음
  사용자명이나 사용자 ID 기반으로 암호화 토큰을 만들면서 운영/스테이징마다 다른 비밀값을 쓰지 않거나, 스테이징 사이트가 외부 서비스와 통신하면서 운영 권한 부여와 섞이는 경우라면 이런 문제가 그리 드물 것 같지 않음

  • 예전에 전자상거래용 배송 API를 구현했는데 DHL 같은 곳과 연동했음. 운영 서버로 전환하는 걸 깜빡해서 몇 달 동안 테스트 API에서 출력한 라벨로 배송했는데, 물건은 배송됐고 청구는 되지 않았음
    알아차리자마자 바로 사실대로 알렸음
  • 그래서 토큰에 대상 필드가 존재함

• 대기업에서 개발/운영 경계는 사람들이 생각하고 싶어 하는 것보다 훨씬 더 구멍이 많음
  전형적인 하루를 생각해보면, PC에 로그인하고 이메일을 확인한 뒤 같은 자격 증명으로 Azure 포털에 로그인함. 결국 모두 같은 테넌트에 묶여 있고, 계정은 GitHub와 클라우드 계정에도 연결돼 있음
  Groups와 Teams가 여기저기 만들어지고, 수상한 권한이 붙은 채 Teams나 OneDrive를 쓰기 위해 생겨난 것들이 회사 디렉터리 안에서 보안 그룹과 거의 구분되지 않은 채 남아 있음
  가끔 “아직 이게 필요하냐”는 자동 이메일이 오지만 메시지는 불투명하고, 아주 큰 회사에서는 물어볼 사람도 마땅치 않음. 헬프데스크는 이틀 뒤에나 답하고, 그렇다고 Twitter에서 John Savill에게 물어볼 수도 없으니 그냥 확인을 누르고 넘어가게 됨
  결국 조직의 천이 찢어지기 시작하고, 공격자는 약한 지점에서 운 좋게 들어와 테넌트 안을 횡이동하며 원하는 것을 가져감
  현명한 CISO가 말했듯, 해커는 침입하지 않고 로그인함

  • 여기서 말하는 “전형적”이라는 가정이 꽤 과감해서 흥미로움
    물론 모두가 Microsoft 클라우드, Skype, Twitter, OneDrive 같은 걸 쓰고 있다는 식이고, 그럴듯하게 어떤 사람 이름까지 던져 넣음

• “관리자 권한이 있는 계정만 OAuth 앱에 전권에 가까운 full_access_as_app 역할을 부여할 수 있다. 누군가 운영 환경에서 꽤 큰 설정 실수를 했다”는 Kevin Beaumont의 말을 두고, 시스템 세부를 모르는 상태에서 보자면 그게 핵심 문제처럼 보이지 않음
  그런 실수를 할 방법 자체가 없어야 함. 설계한 사람과 운영하는 사람이 불가능하게 만들었어야 하고, 책임도 거기에 있음
  내부 사람 모두를 감전시키는 버튼이 있는 공장을 만들고 운영하다가 누군가 실수로 그 버튼을 눌렀다면, 문제가 어디에 있는지는 분명함

  • 이건 기술 문제가 아닐 가능성이 큼. 기술적으로 막기 위한 모범 사례와 안전장치가 20개쯤 있었겠지만, 그런 가드레일은 조직·리더십·관료제가 신경 쓸 때만 의미가 있음
    수년 동안 정책·절차·규정·법을 모두 무시하고, 그런 권한이 전혀 필요 없는 VIP에게 슈퍼 관리자/root 권한을 주라는 요구를 여러 번 받았음
    요즘은 모든 일이 교차 겸직, 파트타임, 이중 역할, 삼중 역할처럼 되어 있어서 더 악화됨
    부여 가능한 실제 권한보다 역할 수가 더 많은 역할 기반 접근 제어도 봤음. 그러면 RBAC의 목적이 스스로 무너짐. 권한을 개별 부여하는 편이 더 빨랐지만, 그러면 보고서에 역할이 안 보인다는 이유로 허용되지 않았음
    이런 건 기술 담당자에게서 나오는 게 아니라 나쁜 리더십에서 나옴
    예전에 사내 ERP의 RBAC 권한 시스템에 이 문제를 완화하는 확장을 설계한 적이 있음. “권한 예외”라는 유형을 두고, 역할 밖 권한이 필요한 사람은 그 방식으로 배정해서 직무 역할 밖 작업이 가능한 사람 목록을 보고서로 만들 수 있게 했음
    결국 권한에 플래그 하나를 추가한 것뿐이지만 잘 작동했음. HR이 분기마다 권한 예외를 확인해 제거할 것을 검토했고, 파트타임 헬프데스크가 시행착오로 권한을 풀어헤치는 대신 실제로 아는 권한자가 통제할 수 있었음
  • 설정 실수를 어떻게 불가능하게 만들자는 건지 궁금함

• 정량화 가능한 위험으로 기업과 산업을 보호한다는 멋진 보안 인증은 잔뜩 있는데, Amazon에서 36달러짜리 책에 적힌 이성적이고 사려 깊은 모범 사례는 완전히 무시되는 게 웃김
  보안이 무슨 리본 캠페인 같은 것처럼 보임

  • 보안은 프로세스이지 제품이 아님
    보안을 제품처럼 파는 사람은 사기 치는 것임
  • 내가 보안 자격증을 갖고 있어도 다른 직원 1,000명은 없을 수 있음
    일반 직원들은 보안 자체에 관심이 거의 없고 그냥 자기 일을 함
    서버·애플리케이션·설정이 너무 많아서, 보안 의식이 있는 직원만으로 전부 검토하기에 충분하지 않음
    오래 들여다보면 어떤 회사든 언젠가는 열려 있으면 안 되는 것이 열려 있게 됨. 해커 그룹이 하는 일이 바로 계속 빈틈을 찾는 것임
    회사는 운영 중에 새 서버와 새 설정을 계속 만들어야 하므로, 한 번 설정하고 끝나는 문제가 아님
  • 어떤 책인지 궁금함

• 새 직장에 갔을 때 누가 “이게 더 쉬우니까”라며 권한을 잔뜩 주는 게 정말 싫음. 그러지 말아야 함
  회사가 침해에 노출될 뿐 아니라, 나에게 원치 않는 책임까지 떠넘기는 것임. 실수로 중요한 걸 망칠 수도 있고, 뭔가 해킹당했을 때 내가 그 권한을 갖고 있다는 이유로 사람들이 나를 의심할 수도 있음

  • 직원별로 여러 서비스의 계정과 권한을 전부 관리해야 하는 양을 생각하면, 그런 흐름이 자연스러운 진화처럼 느껴지기도 함
    사실상 서비스 수준에서 Windows XP 보안 팝업 같은 걸 겪는 중임. 작업의 매 단계마다 다른 무언가에 인증하라고 요구받고, 적절한 권한이 붙은 적절한 자격 증명을 받기까지 며칠이 걸릴 수 있음
    지원팀이 포기하고 신규 입사자에게 계정과 권한을 한꺼번에 던져주는 것도 인간적으로는 이해됨

• 이 글에서 빠진 부분은, 비운영 계정이 운영 도메인 관리자 권한을 갖고 있다면 작성자들이 “운영”을 어떻게 정의하느냐임

  • 이게 핵심이라고 봄. 글과 인용문은 이걸 “실수”라고 부르지만, Microsoft처럼 크고 복잡한 조직에서는 잘못된 권한 배정이 불가피하다고 봄
    그래서 “22만 명짜리 회사에서 어느 시점에 누군가 실수했다”는 각도에 집중하는 건 별로 도움이 안 됨
    하지만 대부분 회사에서는 운영 시스템과 테스트 시스템 사이에 보통 단단하고 두꺼운 선이 있음. 테스트 계정에 운영 접근 권한을 주는 일은 사실상 불가능해야 하므로, 어떻게 그런 일이 생겼는지가 조사 초점이 되어야 함

• 더 심한 경우도 봤음. 로펌에서 일했는데 관리자와 파트너에게 모든 것에 대한 관리자 접근 권한을 줬음
  비밀번호 재설정 후 기본 비밀번호는 “passme”였는데, 원래 비밀번호가 너무 길어서 기억하기 어렵다는 이유였음. 서버에 로그인한 뒤 비밀번호를 바꾸게 되어 있었음
  해커가 그들 계정 몇 개를 탈취해 이것저것 건드리고 데이터를 훔쳤음. 일부 테스트 계정에도 관리자 권한이 있었음
  더는 거기서 일하지 않아서 다행임. 나는 프로그래머 분석가였고 Visual BASIC 6.0을 동작시키기 위해 내 PC에 대한 관리자 권한만 갖고 있었음

• 이런 패턴은 Microsoft 생태계 전반에서 예외라기보다 규칙에 가깝지만, Microsoft 자신이 이렇게 했다는 건 특히 체면 구기는 일임
  Microsoft 보안팀은 이런 대형 사고를 막기 위한 도구와 모범 사례 문서에 상당한 노력을 들여왔음

  • 최초의 테스트 계정이 어떻게 탈취됐는지 궁금함. 아마 다중 인증이 없었고 OAuth ROPC 흐름을 통한 비밀번호 스프레이 이후 횡이동했을 가능성이 있음
    M365는 다중 인증 강제가 꽤 나쁨. 돈을 내야 되는 구조임
  • 이런 일은 곳곳에서 벌어짐. 같이 일해본 많은 사람들의 테스트 방식은 거의 항상 최대 권한을 주는 식이었음. 모르겠지만 산탄총식 디버깅 같은 느낌임
    더 큰 문제는 사람들이 잊어버린다는 것임. 관리자 권한을 가진 테스트 계정 다섯 개를 만들어두고, 전사 사용자 권한 감사를 누군가 하기 전까지는 드러나지 않음

• 예전에 일했던 회사는 운영 서버와 데이터베이스의 모든 비밀번호를 코드 저장소의 텍스트 파일에 넣어뒀음. 수석 아키텍트가 비밀번호를 기억하기 싫어한다는 이유였음
  CTO에게 그게 얼마나 멍청한지 말했더니 “우리는 직원을 신뢰한다”, “보안 감사를 통과했다”는 답을 들었음
  아직도 손바닥으로 얼굴을 친 여파가 남아 있음

  • 나도 데이터베이스 비밀번호가 싫음. 너무 빨리 크랙됨
    그냥 짜증나는 요소일 뿐 보안 기능이 아님. “c00lz500” 같은 비밀번호는 쓰지 않고, 아예 빈 문자열 같은 식을 씀
    대신 방화벽과 내부 네트워크를 사용함