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

• 여가시간에 버그헌팅을 즐기는 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. "[email protected]"으로 Apple ID를 만들고 인증 코드 요청하면 Zendesk 티켓 생성됨
2. company.com 지원 포털에서 자신의 이메일로 티켓을 생성하여 ID 범위를 추적함
3. 이메일 스푸핑 버그로 해당 ID 범위의 모든 티켓에 자신을 추가 시도
4. [email protected] 계정으로 그 회사의 지원 포털에 로그인하고 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이 되어야 함. 연구자의 선의와 노력을 존중하고 적절히 보상하는 문화가 정착되기를 기대함.