TL;DR

  • Slack의 도메인 기반 워크스페이스 가입 기능에서 공유 소비자 이메일 도메인이 관리자의 명시적 활성화 없이 승인 도메인으로 설정될 수 있어, 해당 도메인 계정 소유자가 조직의 초대 절차를 우회해 가입할 위험이 있음.
  • 조직이 직접 관리하는 도메인에서는 이메일 주소를 통한 셀프서비스 가입이 유용하지만, ISP·소비자 이메일 도메인은 단일 조직의 소속 경계를 증명하지 못함.
  • 새로 가입한 구성원은 워크스페이스 설정에 따라 공개 채널, 메시지 기록, 공유 파일, 구성원 목록·프로필 데이터, 내부 논의를 볼 수 있음.
  • Slack은 버그 바운티 신고를 ‘정보 제공’으로 종결하고, 승인 도메인 사용은 의도된 동작이며 관리자가 비활성화할 수 있고 공유 도메인 차단 목록을 계속 유지하기 어렵다고 답함.
  • 문제의 핵심은 관리자가 기능을 명시적으로 켠 뒤 작동하는 것이 아니라, 공유 도메인이 명확한 확인 없이 승인 상태로 남아 초대 우회 수단이 될 수 있다는 점임.

도메인 기반 셀프서비스 가입

  • Slack에는 워크스페이스 관리자가 하나 이상의 이메일 도메인을 승인해 사용자가 직접 가입하도록 하는 기능이 있음.
  • 안전한 설정에서는 example.com을 관리하는 회사가 @example.com 메일함 보유자의 가입을 수동 초대 없이 허용할 수 있음.
  • 승인 도메인을 하나의 조직이 관리하지 않는 경우에는 이 모델이 무너짐. 오래된 Slack 계정을 검토하는 과정에서 Slack의 워크스페이스 검색 화면은 공용 이메일 제공업체의 동일한 도메인을 통해 가입 가능한 서로 무관한 여러 워크스페이스를 표시함.
  • 해당 문제가 실제 Slack 워크스페이스에 계속 접근할 수 있게 할 가능성이 있어 정확한 도메인은 공개하지 않음.
  • 해당 도메인은 회사가 관리하는 네임스페이스가 아니라 과거 ISP가 제공한 소비자 이메일 도메인임.
  • ISP는 해당 도메인의 새 메일함 생성을 더 이상 허용하지 않지만, 기존 메일함은 다른 서비스로 이전되어 계속 이용 가능함.
  • 그 도메인의 무관한 메일함을 보유했다는 사실은 Slack 워크스페이스를 운영하는 조직의 구성원임을 증명하지 않음. 이를 접근 키로 취급하는 것은 @gmail.com, @hotmail.com 등 공용 제공업체 도메인을 내부 회사 경계로 신뢰하는 것과 같은 범주의 오류임.
  • 문제를 악화하는 점은 직접 관리하는 Slack 워크스페이스에도 해당 도메인이 승인 이메일 도메인으로 설정되어 있었으며, 이를 적극적으로 활성화하거나 신뢰할 조직 가입 경계로 취급한 적이 없다는 것임.
  • 관찰한 내용으로는 Slack이 서버 측에서 이 설정을 활성화한 것으로 보임. 따라서 관리자가 수동으로 잘못된 도메인을 선택할 수 있다는 데 그치지 않으며, Slack이 명확하고 명시적인 관리자 결정 없이 접근 제어 우회 수단을 활성 상태로 둘 수 있다는 우려임.

문제가 중요한 이유

  • 승인 이메일 도메인은 사실상 초대 절차를 단축하는 기능임. 자체 도메인을 관리하는 조직에서는 관리 부담을 줄이지만, 안전하지 않게 설정되면 일반 이메일 계정의 통제권만으로 워크스페이스 가입 자격을 얻을 수 있음.
  • 노출 범위는 각 워크스페이스 설정에 따라 달라지지만, 새로 가입한 구성원은 다음 항목을 볼 수 있음.
  • 기본 공개 채널
  • 열람 가능한 메시지 기록
  • 공유 파일
  • 구성원 목록과 프로필 데이터
  • 일반 구성원에게 공개된 내부 논의
  • 소비자 이메일 주소나 ISP 제공 이메일 주소에 연결된 워크스페이스는 특히 위험함. 해당 이메일 도메인은 단일 조직을 나타낸 적이 없으며, 이런 워크스페이스에는 타당한 근거가 없는 신뢰 경계가 조용히 유지될 수 있음.

Slack의 답변

  • 해당 동작을 버그 바운티 프로그램을 통해 Slack에 신고했으나, Slack은 신고를 ‘정보 제공’으로 종결함.
  • Slack의 답변은 실질적으로 다음과 같음.

워크스페이스에서 승인 이메일 도메인을 활성화하면 해당 도메인의 사용자가 가입할 수 있으며, 관리자는 이 설정을 비활성화할 수 있음. Slack이 공유·공개 도메인의 차단 목록을 계속 관리하는 것은 현실적으로 어려우며, 일부 사용자는 해당 도메인을 이런 방식으로 쓰고 싶어 할 수 있음.

  • 이 답변은 핵심을 놓침. 우려되는 점은 관리자가 의도적으로 기능을 켠 뒤 해당 기능이 작동한다는 사실이 아님. 워크스페이스 소유자가 직접 활성화하지 않았는데도 공유 소비자 이메일 도메인이 승인된 가입 도메인으로 이미 설정되어 있을 수 있고, Slack의 답변은 그로 인한 위험을 고객의 문제로 취급함.
  • ‘완벽한 차단 목록을 유지할 수 없다’는 주장은 접근 제어의 기본 설정에 대한 충분한 답변이 아님. 모든 소비자 이메일 제공업체를 완벽히 나열하지 않더라도, 명시적 확인 없이 도메인 기반 가입 규칙을 켜거나 유지하지 않을 수 있음.
  • 최소한 공유 제공업체 도메인을 사용하는 워크스페이스에는 검토 절차를 요구해 해당 도메인이 초대 우회 수단으로 계속 작동하지 않도록 해야 함.
  • 공개 이메일 제공업체 도메인으로 실제 워크스페이스가 노출될 수 있는 설정을 ‘의도된 동작’이라며 대수롭지 않게 여기는 것은 납득하기 어려움. 보안 경계가 ‘이 공유 도메인의 어떤 메일함이든 얻을 수 있는 사람’이라면, 이는 조직 경계가 아님.

책임 있는 취약점 공개

  • 관련 문제가 여전히 악용될 수 있으므로 제삼자 워크스페이스 이름이나 영향을 받는 이메일 도메인은 공개하지 않음.
  • 발견된 문제는 접근 제어 패턴임. 공유 공개 이메일 도메인이 신뢰할 수 있는 조직 경계로 취급될 수 있으며, Slack이 명시적 확인 없이 서버 측에서 해당 설정을 활성화했을 가능성이 있음.