▲

GN⁺: 15살 소년, Zendesk에서 1개의 백도어 버그를 찾아 $50,000을 벌다

(gist.github.com/hackermondev)
13P by neo 1달전 | favorite | 댓글 2개
  • 여가시간에 버그헌팅을 즐기는 15살 소년, 포춘 500대 기업이 쓰는 Zendesk에서 이메일 인증에 관련된 버그를 찾아냄
  • 이를 여러 기업에 제보해 $50,000 이상을 벌었지만, Zendesk는 이를 패치했으면서도 제보자에게 전혀 보상금을 주지 않은 과정을 소개

Zendesk 소개

  • Zendesk는 세계 최고의 기업들이 사용하는 고객 서비스 도구임
  • 지원 이메일을 Zendesk에 연결하면 Zendesk가 수신 이메일을 관리하고 티켓을 생성함
  • 많은 대기업들이 자체 티켓 시스템을 구축하는 대신 Zendesk에 의존하는 것이 놀라움

가장 취약한 고리

  • "가장 약한 고리만큼 강하다"는 말처럼, Zendesk는 종종 간단한 티켓 도구로 간주되어 신중한 설정 없이 사용됨
  • "@company.com" 도메인을 싱글 사인온(SSO)에 사용하며, Zendesk와 연결할 경우 보안 취약점이 발생할 수 있음
  • Zendesk가 도메인 이메일을 처리하기 때문에, SSO 시스템이 이메일 주소를 제대로 검증하지 않으면 Zendesk에 접근한 사람이 내부 시스템을 악용할 수 있음.

이메일 스푸핑

  • Zendesk의 심각한 취약점을 발견했으며, 공격자가 Zendesk를 사용하는 회사의 고객 지원 티켓을 읽을 수 있었음
  • Zendesk에는 이메일 스푸핑에 대한 효과적인 보호 장치가 없었음
  • 공격자는 지원 이메일 주소와 티켓 ID를 알고 있다면, 이메일 스푸핑을 통해 원래 발신자를 가장하여 티켓에 접근할 수 있었음
  • 저자가 버그를 제보했으나 Zendesk는 처음에는 관심을 갖지 않았음
    • 이메일 스푸핑(SPF, DKIM, DMARC 이슈)은 Out of Scope라고 답변이 옴
  • HackerOne 서비스를 통해 보고가 처리되었으며, Zendesk 팀원에게 직접 보고를 요청했으나 거절당함

이 이슈를 Slack 장악으로 확대

  • 이메일 스푸핑 버그를 개별 회사에 보고할 수도 있었으나, 더 큰 영향을 주고자 함
  • 과거 다른 연구자가 Zendesk를 통해 수백 개 기업의 Slack에 침투한 사례가 있었음 (TICKETTRICK)
  • 저자는 자신의 버그를 이용해 이를 재현하려 했지만 몇 가지 어려움이 있었음
  • Slack은 이메일 주소에 랜덤 토큰을 추가해 검증하는 방식으로 변경되었음
  • 하지만 OAuth를 이용하여 Apple ID로 로그인할 때는 토큰이 사용되지 않아 우회할 수 있었음

재현 단계: Apple → Zendesk → Slack

  1. "support@company.com"으로 Apple ID를 만들고 인증 코드 요청하면 Zendesk 티켓 생성됨
  2. company.com 지원 포털에서 자신의 이메일로 티켓을 생성하여 ID 범위를 추적함
  3. 이메일 스푸핑 버그로 해당 ID 범위의 모든 티켓에 자신을 추가 시도
  4. daniel@wearehackerone.com 계정으로 그 회사의 지원 포털에 로그인하고 CC된 티켓을 확인함
  5. Apple ID에 인증 코드 입력
  6. Slack의 "Apple 로그인" 기능으로 @company.com 이메일 연결된 Apple ID로 로그인하여 Slack에 로그인함
    저자는 이 6단계를 수백 개의 Zendesk와 Slack 인스턴스에 적용함

사건의 여파

  • 일주일 동안 개별 기업에 취약점 제보, 일부는 즉각 조치했지만 Zendesk 문제라고 주장하는 곳도 있었음
  • 몇몇 기업이 Zendesk에 연락하자, Zendesk는 결국 보고를 비공개로 유지해달라고 요청했으며, Slack 취약점에 대한 재현 단계를 요구함
  • Slack 장악 PoC 제공 후 Zendesk는 문제 확인했으나 해결까지 2개월 걸림
  • 많은 기업이 이메일 협업 기능을 비활성화해 인스턴스를 보호함
  • 저자는 이 버그바운티 신고를 통해서 HackerOne 및 기타 플랫폼의 개별 기업으로부터 5만 달러 이상의 포상금을 받았음
  • 일부 기업은 Zendesk와의 계약을 해지함

Zendesk의 수정과 나의 0달러 바운티

  • 2개월 후 Zendesk는 문제 해결을 확인함
  • Cloudmark와 Rspamd EAP 스팸 필터를 사용했으나 Rspamd 점수를 활용하지 않아 많은 이메일이 보류되지 않았음
  • 처음에는 특정 조건에서 Rspamd로 자동 전환하는 방식으로 수정
  • 이후 Apple, Google 인증 이메일을 자동 보류하는 필터 구현
  • 문제를 해결했음에도 불구하고 Zendesk는 결국 이 버그바운티 신고에 대해 포상금을 지급하지 않기로 결정
    • 작성자가 취약점을 영향을 받은 회사들과 공유함으로써 HackerOne의 공개 가이드라인을 위반

결론

  • 작은 이메일 버그가 세계 최대 기업의 내부 시스템 침투로 이어짐
  • Zendesk가 결국 취약점을 해결했지만 거부, 느린 대응, 무시 등 과정이 힘들었음
  • 버그헌팅의 현실로, 때론 이기고 때론 지는 것

GN⁺의 의견

  • Zendesk 사태는 서드파티 솔루션을 무비판적으로 도입하는 위험성을 보여줌. 아무리 잘 알려진 기업의 제품이라도 보안 검토는 필수적임.
  • 주요 기업의 내부 시스템 장악은 엄청난 피해를 초래할 수 있어 Zendesk의 늑장 대응은 매우 무책임했음. 바운티 지급 거부로 보안 연구자의 의욕을 꺾는 것도 바람직하지 않음.
  • 기업은 SSO 도메인을 신중히 선택하고, 이메일 검증 프로세스를 강화해야 함. DMARC, SPF, DKIM 등 이메일 인증 기술을 적극 활용할 필요가 있음.
  • HackerOne의 공개 가이드라인은 연구자 입장에서 너무 경직되어 있음. 심각한 취약점은 신속한 공유가 이뤄져야 하므로, 상황에 맞는 유연한 적용이 필요해 보임.
  • 버그헌팅은 기업과 연구자 모두에게 win-win이 되어야 함. 연구자의 선의와 노력을 존중하고 적절히 보상하는 문화가 정착되기를 기대함.
▲
aer0700 1달전  [-]

이런 이슈 보면, 보안 관련 솔루션은 가져다쓰기보단, 보안 전문가를 데려오고 육성하는 게 훨씬 나아보입니다 ㅠㅠ

답변달기
▲
neo 1달전  [-]
Hacker News 의견

  • 한 사용자는 2024년 6월에 Zendesk, Apple, Slack에 동일한 버그를 보고했으며, 이들이 버그에 대한 보상을 하지 않은 이유는 아마도 그들이 처음이 아니었기 때문이라고 언급함

    • 비디렉토리 SSO 옵션인 Sign in with Apple(SIWA)가 잘못 구현되었으며, 이는 Slack과 같은 대기업에서도 마찬가지임
    • 비디렉토리 SSO는 디렉토리 SSO와 동일한 신뢰를 가질 수 없으며, SSO 제공자는 동일한 이메일 주소를 사용하더라도 서로 대체 가능하지 않음

  • 다른 사용자는 Zendesk가 Google 검색 결과를 오염시키기 위해 "Zendesk Alternative"라는 가짜 밴드를 만들었다고 주장함

    • 이는 불법은 아니지만, 그들의 사고방식을 보여주는 조작적인 행동이라고 언급함

  • 한 사용자는 Zendesk가 버그에 대해 보상을 거부한 것이 실망스럽다고 말하며, 이는 큰 보상 프로그램에 참여하지 않게 만드는 방법이라고 언급함

    • Zendesk와의 인터뷰 경험이 매우 나빴다고 덧붙임

  • 또 다른 사용자는 비효율적인 버그 바운티 프로그램이 소프트웨어 서비스에 부정적인 영향을 미친다고 언급함

    • Zendesk가 보상을 하고 사과하며 프로그램을 수정해야 한다고 주장함

  • 한 사용자는 Zendesk가 13억 달러의 수익을 올리는 회사임에도 불구하고 보상을 하지 않는 것이 단기적인 시각이라고 비판함

    • 이는 합리적인 결정이 아니며, 사적인 자본이 비용을 절감하고 브랜드를 소모시키고 있다고 언급함

  • 다른 사용자는 Zendesk가 버그의 영향을 제대로 이해하지 못했기 때문에 무시했을 것이라고 설명함

    • 명확한 영향이 없으면 많은 취약점이 단순한 버그로 보일 수 있다고 언급함

  • 한 사용자는 Zendesk가 Apple 계정 확인 이메일 문제만 해결했으며, 근본적인 문제는 해결하지 않았다고 지적함

    • 기본 설정으로 이메일과 티켓 ID를 알면 누구나 지원 티켓을 탈취할 수 있는 가능성이 있다고 언급함

  • 두 가지 별도의 취약점이 존재한다고 설명함

    • Zendesk는 원래 요청자의 이메일 주소에서 회신을 보내 CC를 추가할 수 있도록 허용함
    • Slack은 추가 확인 없이 Sign in with Apple을 통해 도메인 전체 로그인을 허용함

  • Zendesk가 문제를 무시하고 비공개로 유지하려고 했다는 점을 비판함

    • 이는 비전문적인 태도이며, 보상을 하지 않은 이유가 될 수 있다고 언급함

  • 마지막으로, 한 사용자는 Zendesk가 버그에 대한 보상을 거부한 것을 비판하며, 보고자가 모든 절차를 올바르게 수행했음을 강조함

답변달기