1Password, 내부 Okta 계정에서 “수상한 활동” 감지

 (arstechnica.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1Password는 직원용 앱 접근을 관리하는 내부 Okta 인스턴스에서 9월 29일 수상한 활동을 감지했으며, 사용자 데이터나 민감 시스템 침해는 발견하지 못함
  • 이번 접근은 Okta의 고객 지원 관리 시스템 침해와 연결됐고, 공격자는 고객이 업로드한 HAR 파일에서 인증 쿠키와 세션 토큰을 얻을 수 있었음
  • 1Password 내부 Notion 보고서에는 공격자가 IT 직원이 Okta 지원과 작업하며 만든 HAR 파일을 확보했고, 그 안에 Okta 트래픽과 세션 쿠키가 포함돼 있었다고 정리됨
  • 공격자는 1Password의 Okta tenant에서 관리자 사용자 보고서를 요청하고 Google 프로덕션 환경 인증용 IDP를 업데이트·활성화했지만, 이후 재사용 시도는 IDP 제거로 실패함
  • Okta 침해는 공급업체 침입이 고객사 공격으로 이어지는 후속 공격 사례가 됐고, 1Password는 알려진 두 번째 Okta 고객 표적이 됨

1Password 내부 Okta 접근 감지

  • 1Password는 수백만 명의 사용자와 10만 개 이상의 기업이 쓰는 비밀번호 관리자임
  • 회사는 직원용 앱 관리를 위해 쓰는 Okta 인스턴스에서 9월 29일 수상한 활동을 확인함
  • CTO Pedro Canahuati는 해당 활동을 즉시 종료하고 조사했으며, 사용자 데이터나 직원용·사용자용 민감 시스템 침해는 발견하지 못했다고 밝힘
  • 이후 1Password는 Okta와 함께 알 수 없는 공격자가 계정에 접근한 경로를 조사함

Okta 지원 시스템 침해와 HAR 파일 위험

  • 1Password 사건은 Okta가 공개한 고객 지원 관리 시스템 침해에서 비롯된 것으로 확인됨
  • Okta는 위협 행위자가 고객 지원 케이스 관리 시스템에 무단 접근해 일부 Okta 고객이 업로드한 파일을 봤다고 밝힘
  • 확보된 파일에는 Okta 지원 인력이 문제 해결 중 고객 브라우저 활동을 재현하는 데 쓰는 HAR 파일이 포함됨
  • HAR 파일에는 인증 쿠키와 세션 토큰 같은 민감 정보가 저장될 수 있어, 공격자가 정상 사용자로 가장하는 데 악용할 수 있음

BeyondTrust에 이은 알려진 두 번째 표적

  • 보안업체 BeyondTrust는 공격자가 유효한 인증 쿠키로 자사 Okta 계정 접근을 시도한 뒤 침입을 발견함
  • BeyondTrust에서는 공격자가 “몇 가지 제한된 작업”을 수행할 수 있었지만, 접근 정책 제어가 활동을 막고 계정 접근을 차단함
  • 1Password는 Okta 침해 이후 후속 공격 표적이 된 두 번째 알려진 Okta 고객이 됨

내부 Notion 보고서에 담긴 사건 흐름

  • 10월 18일자로 작성돼 1Password 내부 Notion 워크스페이스에 공유된 보고서에는 공격자가 회사 IT 직원이 만든 HAR 파일을 확보했다는 내용이 담김
    • 해당 직원은 최근 Okta 지원과 작업하면서 이 파일을 만들었음
    • 파일에는 1Password 직원의 브라우저와 Okta 서버 간 모든 트래픽 기록과 세션 쿠키가 포함돼 있었음
  • 1Password는 익명 직원이 텍스트와 스크린샷으로 제공한 문서의 진위 확인 요청에 응답하지 않음
  • 보고서상 공격자는 1Password의 Okta tenant에도 접근함
    • Okta tenant는 직원, 파트너, 고객에게 배정되는 시스템 접근 권한과 권한 수준을 관리하는 데 쓰임
    • 공격자는 그룹 할당을 보고 다른 작업도 수행했지만, 일부 작업은 이벤트 로그에 기록되지 않음
    • 로그인 중 Google이 제공하는 프로덕션 환경 인증에 쓰이는 IDP(identity provider)를 업데이트함

공격자가 수행한 작업과 차단된 재시도

  • 1Password IT 팀은 9월 29일 관리자 권한을 가진 1Password 사용자 목록 요청을 암시하는 예상치 못한 이메일을 받고 접근 사실을 알게 됨
  • 팀원들은 승인된 직원이 해당 요청을 하지 않았다고 판단해 회사 보안 대응팀에 알림
  • 공격자가 수행한 작업은 다음과 같음
    • IT 직원의 Okta 대시보드 접근을 시도했지만 차단됨
    • 1Password의 프로덕션 Google 환경과 연결된 기존 IDP를 업데이트함
    • 해당 IDP를 활성화함
    • 관리자 사용자 보고서를 요청함
  • 10월 2일 공격자는 다시 1Password의 Okta tenant에 로그인해 이전에 활성화한 Google IDP 사용을 시도했지만, IDP가 제거돼 실패함
  • 두 차례 접근은 모두 미국의 클라우드 호스트 LeaseWeb 서버에서 이뤄졌고, Windows 머신의 Chrome 버전을 사용함
  • 사건 이후 1Password는 Okta tenant 설정을 바꿔 비-Okta ID 제공자를 통한 로그인을 거부하도록 함

공급업체 침해가 고객사 공격으로 이어지는 구조

  • Okta 침해는 최근 몇 년간 대규모 고객을 보유한 소프트웨어·서비스 제공업체를 겨냥한 일련의 공격 중 하나임
  • 공격자는 제공업체에 침입한 뒤 그 위치를 이용해 고객사를 표적으로 삼는 후속 공격을 수행함
  • 앞으로 더 많은 Okta 고객이 확인될 가능성이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • SSO를 외부에 맡기는 건 기술적으로 더 쉬운지, 운영 역량이 있는지만의 문제가 아님. 고객 계약서에 평판 있는 SSO 제공업체를 쓴다고 적을 수 있고, 키 관리 방식과 키 자료 보호에 관한 문서화 책임도 그 업체가 지게 되는 게 큰 요소임
    1Password는 이미 그런 체계를 갖췄을 가능성이 높아서 조금 특이하지만, 보통은 “조직 내 누구도 키에 접근할 수 없다”고 말하는 편이 “Bob만 예외인데, 그가 SSO 서버를 운영하고 우리는 그를 믿는다”보다 훨씬 쉽다

    • “Bob은 믿는다”는 것보다 Okta가 더 나은 이유가 뭔가? 전혀 모르는 사람들을 믿는 셈이고, 이미 여러 유명 보안 사고를 일으켰음
    • 메시징 측면은 동의하지만, 실제 보안 측면에서는 서비스 제공업체 쪽의 Bob은 어떻게 볼 건가?

  • C의 메모리 안전성 취약점이 가장 많이 이야기되는 건 흥미롭지만, 실제 영향이 큰 건 이른바 모범 설계를 따르다가 과도한 복잡성으로 생기는 통찰 붕괴 쪽인 경우가 많음

    • 안전하지 않은 C를 비판하면서 다시 비잔틴 괴물을 만들어내는 사람들이 종종 같은 진영임. 단순한 장치를 Rube Goldberg 기계로 만들어 고용을 유지하게 만드는 정상화된 유인이 작동하는 듯함
    • 조직적 버그는 그 조직에 큰 영향을 줄 수 있지만, 메모리 안전성 버그는 보통 자동화된 방식으로 악용 가능하고 해당 소프트웨어를 쓰는 모든 조직에 영향을 줌. Heartbleed가 그렇게 많이 논의된 것도 영향이 컸기 때문임
    • 결국 복잡성임. 빠뜨리는 게 생기고, 뭔가 업데이트했을 때 다른 로직에 생길 연쇄 효과를 놓치게 됨. 복잡성은 취약성을 낳지만, 계층화된 보안 방어와 대응책은 위험을 줄일 수 있음
      거대한 복잡성을 파악하지 못하는 인간의 한계가 근본 원인이라고 봄
    • 측정 가능한 것은 최적화되기 마련임. 소프트웨어 취약점에 대해서는 숫자로 된, 쉽게 수집 가능한 데이터가 있지만, 조직에서 데이터가 어떻게 도난당하는지, 때로는 언제 도난당했는지에 관한 정보는 부족함
      후자는 인간과 관련되어 복잡할 가능성이 높고, 그래서 기술에서 구원을 찾기 쉬움
    • “통찰 붕괴”가 뭔지 궁금함. 아주 흥미로운 개념으로 들림

  • “IT 팀원의 모든 시스템 자격 증명을 교체했고, MFA는 Yubikey만 쓰도록 바꿨다”는 부분을 보면, 전 직원에게 Yubikey 기반 2단계 인증을 쓰게 하는 계기가 되면 좋겠음. FIDO2 미만은 정말 약함
    왜 아직도 사람들이 Okta를 선택하는지 궁금함. 개인적으로는 ID 제공자로 GSuite를 쓰는 게 훨씬 편하게 느껴짐. Okta는 꽤 심각한 침해를 겪었고, 솔직히 그 전에도 보안 관행에 대해 좋은 얘기를 듣지 못했음

    • Yubikey나 다른 브라우저 기반 MFA는 이번 공격을 막지 못했을 것임. 공격자는 MFA가 끝난 뒤의 유효한 관리자 세션 토큰을 얻었기 때문임
      하드웨어 기반 MFA 강제는 좋은 관행이고 향후 스피어 피싱 같은 공격을 막을 수는 있지만, 이번 사건 자체와는 무관함
      사람들이 Okta를 고르는 건 “IBM을 샀다고 해고당한 사람은 없다”에 가까움. 자체 Keycloak을 운영하다 털리면 내 책임이지만, Okta면 내 문제가 아니게 되는 아웃소싱 구조도 한몫함
    • 도난당한 건 세션 쿠키였고, 2단계 인증은 이 문제와 관련이 없음
      Google Workspace를 진지한 용도로 실제 써본 적이 있는지 의문임. 가장 기능이 부족한 ID 제공자 중 하나이고, Okta는 가장 기능이 많은 축에 듦. 둘 다 바퀴가 두 개라는 이유로 자전거와 오토바이를 비교하는 격임
      기술 포럼에서 Google Workspace를 ID 제공자로 추천하는 걸 보게 될 줄은 몰랐음
    • 대부분의 사람은 Okta를 선택하지 않음. 임원급 누군가가 Okta를 선택하고, 나머지는 그 결과를 감당하게 됨
      Yubikey를 쓰면 모든 비밀번호 문제의 고객 지원을 외주업체가 아니라 내부 IT 부서가 맡게 됨
      MFA에는 기술적 문제와 사회적 문제가 있는데, 키·토큰·휴대폰·SMS 같은 구현의 기술 보안 측면은 거의 사소하고, 고객 지원·분실한 비밀번호·세탁기에 들어간 키·메일 수신 불가 같은 사회적 문제가 압도적으로 큼
      모두가 보안에서 거대하고 멍청한 고객 지원 역할을 외주화하고 싶어 하지만, 그렇게 한 뒤에는 모두가 비용을 줄이도록 유인됨. 그 결과가 Okta임
    • GSuite를 ID 제공자로 쓰는 건 매우 제한적임. “ID 제공자입니다” 체크박스는 채우지만, “연결 가능”을 넘어서는 순간 어렵거나 불가능해짐
      예를 들어 모든 직원이 GSuite에 있는 조직에서 AWS 조직 접근을 제공하려면 AWS SSO[1]가 권장 방식임. 연결을 설정하면 접속은 가능하지만 빈틈이 있음
      GSuite 사용자 그룹을 기준으로 AWS SSO에 사용자를 자동 프로비저닝하거나 제거하는 기능이 없음. SSO의 SCIM 지원으로 코드를 직접 짤 수는 있지만 유지보수해야 함
      SSO 세션을 만들 때 MFA 확인을 강제할 방법이 GSuite 쪽에도 AWS SSO 쪽에도 없음. GSuite는 SAML 애플리케이션 인증 전에 MFA 확인을 요구할 수 없고, AWS SSO도 내부 Directory를 쓸 때와 달리 ID 제공자를 쓰면 MFA 확인 강제가 안 됨
      Okta와 유사 제품은 이런 일을 해주고, 사용 중인 엔드포인트에 따라 MFA 확인을 걸 수도 있다고 함. 직접 해본 건 아니고 마케팅 자료와 영업 설명 기준임
      요약하면 Okta는 ID 제공자와 사용 애플리케이션 사이의 자동화와 보안 접착제를 훨씬 많이 제공함
      [1] 여기서 AWS SSO는 AWS 제품인 “AWS IAM Identity Center (Successor to AWS Single Sign-On)”를 의미함
    • Okta가 다른 솔루션보다 낫거나 나쁘다는 증거가 있는가? 보안 측정은 매우 어려움
      지금 보이는 증거는 Okta가 작년에 침해를 겪었고, 이번에도 침해를 겪었으며, 이번 침해는 고객 지원 부서나 시스템에서 일어났다는 정도임. 침해 공개가 늦었을 수도 있지만, 허위 신고가 많아서 최근까지 증거를 찾지 못했을 수도 있음. 처음 신고한 고객에게 공을 돌리지 않았고, 신고 후 고객과 제대로 소통하지 않았을 수도 있음
      모르는 것은 훨씬 많음. 공격자가 얼마나 숙련됐는지, 각 ID 제공자가 몇 번 침해됐는지, 몇 번 탐지했는지, 탐지하고도 덮었는지, 각 서비스에 보안 버그가 얼마나 많고 얼마나 심각하며 찾기 쉬운지, 침해 탐지 역량은 어떤지, 직원 교육은 얼마나 잘 됐는지, 직원 중 실제로 보안을 신경 쓰는 비율은 얼마나 되는지 알 수 없음
      Okta가 침해를 보고했다는 이유만으로 제품이 더 나쁘다고 결론낼 수는 없음. 다른 제품이 얼마나 좋은지 모르고, Okta가 일부 또는 모든 경쟁사보다 나을 가능성도 있으며 물론 더 나쁠 수도 있음

  • 예전에는 1Password를 정가로 구매했고, 소프트웨어는 완전히 오프라인으로 동작하면서 암호화된 금고를 로컬이나 Dropbox에 저장했음. 온라인에 훔칠 것이 없으니 해커를 걱정할 필요도 없었음
    그런데 누군가 계산기를 두드리고, 수익성을 높이는 길은 모두의 데이터를 클라우드로 옮기고 구독료를 받는 것이라고 결정함. 그리고 이제 우리는 데이터가 유출됐는지 걱정하고 있음

    • 직접 다룰 만큼 숙련되지 않은 사람들에게는 편의성이 크게 늘어난 것도 사실임
      그리고 지금 아는 범위에서 Dropbox에 금고를 두는 것과 얼마나 다른가? Dropbox도 해킹될 수 있고, 그 데이터는 암호화되지 않는 것으로 유명함. 아직 실제로 1Password 금고가 침해됐다는 사례를 아는 건 아니지 않나?

  • https://blog.1password.com/okta-incident/
    원본 사고 보고서: https://blog.1password.com/files/okta-incident/okta-incident...

    • 흥미로운 부분임. IT 팀원이 Okta 지원팀과 작업하던 중 요청에 따라 Chrome 개발자 도구에서 HAR 파일을 만들고 Okta 지원 포털에 업로드했는데, 이 파일에는 브라우저와 Okta 서버 사이의 모든 트래픽 기록과 세션 쿠키 같은 민감한 정보가 포함되어 있었음
      이후 알 수 없는 행위자가 그 HAR 파일을 만들 때 쓰였던 동일한 Okta 세션으로 Okta 관리자 포털에 접근함
      은행이 늘 말하듯, 지원 담당자에게 비밀번호를 주면 안 됨

  • 이번 책임은 명확히 Okta에 있음. 문제 해결을 위해 평문 HAR 인코딩 세션을 요구하면서, 최종 사용자가 제대로 정리해주기만을 기대하고 있음
    업로드 시점에 HAR 데이터를 정리해서, 시스템에 들어가고 박봉에 인력도 부족한 지원 기술자들이 볼 때는 관련 있고 안전한 부분만 남게 하면 되지 않나?
    HAR는 구조화된 데이터라 프로그램으로 정리하기 매우 쉬움. 로켓 과학이 아님

  • 사람들이 왜 초간단·초친절 온라인 서비스 대신 자가 호스팅·자가 동기화 비밀번호 관리자를 쓰냐고 계속 묻는데, 이유는 같음. 아파트 열쇠를 동네 기차역 금고에 던져 넣지 않는 것과 같음

    • 그렇게 하면 더 안전하다고 느낄 수는 있지만 실제로는 아닐 수 있음. 전담 공격자가 Okta를 뚫을 수 있다면, 제때 업데이트를 잊었거나 업데이트가 늦게 오는 당신의 자가 호스팅 비밀번호 관리자도 충분히 뚫을 수 있음
      이런 조직들은 성명을 내기 몇 주, 때로는 몇 달 전에 문제를 고침
      오픈소스를 쓰다가 치명적 버그가 발견되면 보도자료와 함께 패치를 받겠지만, 대형 서비스들은 이미 그 문제를 고쳤을 가능성이 큼. 평균적인 사용자에게는 위험 대비 이득이 서비스형 솔루션 쪽에 있음
    • 관련 없는 얘기임. 1Password의 비밀번호는 사용자만 가진 키로 암호화되어 있음. 개인 홈서버를 1Password 서버보다 더 안전하게 유지할 수 있을지는 매우 의심스러움
    • 나도 pass 명령줄 도구 + git을 쓰고 있고, 지금까지 단 한 번도 문제가 없었음
      스크립트에서도 사용할 수 있음
      서버 침해도 없고, 웹 확장 취약점도 없고, 서버 오류로 모든 비밀번호를 잃을 일도 없음. 그냥 잘 동작함
    • 요지는 이해하지만, 비밀번호 금고가 자가 호스팅 소프트웨어와 자가 호스팅 금고 파일이었다면 매일 데이터 유실을 걱정했을 것 같음
    • 어떤 걸 쓰는지 궁금함

  • “1Password가 후속 공격 대상이 된 두 번째로 알려진 Okta 고객이 됐다”는 문장은 이상함. Ars는 Cloudflare도 피해자였다는 걸 모르는 건가?
    https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

    • BeyondTrust가 문제를 보고했고, Cloudflare가 공격 대상이 된 첫 번째로 알려진 Okta 고객이며 1Password가 두 번째라는 뜻으로 보임

  • 앱에서 수상한 행동을 모니터링하는 모범 관행이 궁금함. 서비스 범위의 요청률이나 오류율 확인 같은 기본은 알겠는데, 실제로는 얼마나 정교해지는가?
    이벤트 스트림을 넣으면 이상 행동을 찾아주는 지능형 도구가 있는지, 아니면 모니터링할 것을 전부 미리 고려하고 규칙을 추가해야 하는지 궁금함

    • 이 분야 경험 없는 방구석 일반인이니 걸러 들어야 함. 우선순위는 감사 추적임. 사용자 계정이나 데이터에 수행된 모든 작업, 시스템의 모든 변경이 타임스탬프와 사용자 등을 포함한 감사 로그에 있어야 함. 특히 비밀번호나 계정 세부 정보 변경 같은 것들임
      이런 이벤트 스트림이 생기면 데이터 분석 도구를 돌릴 수 있음. 며칠·몇 주·몇 달의 활동으로 정상 기준선을 만들고, 대량 비밀번호 변경이나 이메일 변경처럼 튀는 행동이 경보를 울리게 해야 함
      다만 방구석 가설일 뿐이라, 감사 로그와 그 활용을 실제로 다뤄본 사람이 있는지 궁금함
    • AI 스타트업 아이디어로 괜찮음. Security as a Service로 모든 요청을 제3자 서비스를 통해 프록시하고 이상을 탐지하게 하면 됨. 다만 탐지하지 못해도 그 서비스는 책임지지 않겠지
    • https://www.obsidiansecurity.com/

  • 또 탐지한 건가?
    https://news.ycombinator.com/item?id=37991863

답변달기