알려지지 않은 SendBird 구성 오류

우리 팀( thaivu , lamscun , thefool45 , fergustr4n ) 과의 무작위 버그 헌팅 협업 에서 우리는 여느 때와 같이 임의의 개인 대상과 부딪쳤습니다. 대상을 악용하는 과정에서 대상이 타사 플랫폼의 서비스를 사용하여 채팅 기능을 구현한 것을 발견했습니다. 구글링 을 해보니 타겟의 채팅 기능이 센드버드 제품이라는 것을 알게 되었습니다.— "Paypal, Yahoo, Reddit, Delivery Hero 및 Hinge와 같은 최신 디지털 앱에서 신뢰하는 최고의 상호 작용 API 플랫폼으로 실시간 채팅, 음성 및 비디오를 앱에 쉽게 포함할 수 있습니다." 내 관심을 끌었고 내가 할 수 있는 숨겨진 작업이나 개발자가 놓칠 수 있는 숨겨진 구성이 있는지 확인하기 위해 작동 방식에 대해 더 조사하기로 결정했습니다.
1단계 — 제3자의 제품 및 문서에 대해 알아보십시오.
나는 내가 직면하게 될 것을 알기 위해 SendBird 메인 사이트로 곧장 갔다. SendBird 개발자 포털은 개발자에게 각 제품 유형(사용 가이드, 샘플 API, 참고 사항, 권장 사항 등)에 대한 매우 명확하고 유용한 문서를 제공합니다.
조사를 시작했을 때 몇 가지 흥미로운 메모가 있습니다( 이 블로그를 읽을 때 일부는 구식일 수 있음 ).
- 고객의 SendBird 애플리케이션의 호스트는 “https://api-{application_id}.sendbird.com” 형식일 것입니다.
- Sendbird는 다양한 액세스 제어 옵션 을 제공하며 일부는 샘플 앱을 만들 때 예기치 않은 오류를 방지하기 위해 기본적 으로 켜져 있습니다 .
- 고객이 직접 액세스 제어 목록 설정을 변경할 수 없습니다. ACL 설정 변경은 Sendbird의 솔루션 엔지니어링 팀 구성원만 가능합니다 .
- 기본적으로 " 액세스 토큰이 없는 사용자 "에 대한 SendBird 애플리케이션 보안 설정 은 "읽기 및 쓰기" — 채팅 및 "통화 및 응답" — 통화입니다.
SendBird의 작동 방식에 대한 개요를 살펴본 후, 사용할 대상으로 돌아가서 위에서 읽은 내용을 확인하기 위해 기능을 실행했습니다. "api-{application_id}.sendbird.com"과 동일한 패턴의 호스트와 문서에서 본 것과 동일한 경로를 가진 API가 있음을 확인했습니다. 그런 다음 현재 API 세션을 사용하여 API 문서에서 다른 API를 시도했습니다. 임의로 SendBird Application "GET /v3/users/"에서 사용자 목록 API를 선택했는데 놀랍게도 서버가 모든 사용자 목록으로 응답!!! 나는 기쁨에 펄쩍 뛰며 모든 팀원들에게 확인하라고 말했습니다.

우리는 사용자 세션이 다양한 API를 호출할 수 있고 대상의 SendBird 애플리케이션 내에서 사용자, 채널, 메시지 등에 대해 많은 작업을 수행할 수 있음을 시도하고 알고 있었습니다. ACL의 잘못된 구성으로 인해 액세스 제어가 크게 망가진 것은 분명합니다!!!
그런데 한 가지 응답에서 "Session-Key" 값을 볼 수 없었기 때문에 "Session-Key"가 어디서 왔으며 어떻게 생성되었는지 이해할 수 없었습니다.

SendBird Documents로 돌아가 더 많은 것을 읽고 더 많은 작업을 수행할 수 있습니다.
- “기본적으로 Sendbird 서버는 고유한 사용자 ID만으로 사용자를 인증할 수 있습니다.”
- "일치하는 사용자 ID가 없으면 서버는 사용자 ID로 새 사용자 계정을 생성합니다."
- “사용자 인증은 자신의 사용자 ID만으로 할 수 있지만 액세스 토큰이나 세션 토큰으로도 할 수 있습니다.”
- ClientApp으로서 우리의 목표는 다음과 같은 업그레이드 WebSocket URL 형식을 사용하여 WebSocket을 통해 SendBird 서버에 인증할 수 있습니다 . }”
- 대상의 SendBird 클라이언트는 WebSocket을 통해 SendBird 서버에 인증되었습니다.
- "Session-Key"는 클라이언트가 위와 같이 WebSocket URL 업그레이드를 호출한 후 WebSocket 메시지를 통해 클라이언트로 전송됩니다.
- 대상 SendBird 클라이언트는 “ access_token=null” 인 사용자 ID로만 인증할 수 있습니다.
- 또한 JS 파일에서 WebSocket 방식으로만 사용자 ID를 통해 인증하는 숨겨진 API를 찾았 습니다 . app_id”:”<application_id>”} ”
3차 — 다른 대상에 있는 다른 SendBird 인스턴스에 대해 대규모 취약점 검사를 수행하는 방법
- 크롤링을 통해 애플리케이션에서 SendBird를 구현하는 대상을 확인하고 대상에서 콘텐츠 검색을 수행하며 "sendbird" 단어 및 SendBird의 애플리케이션 ID " [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12} ”
- SendBird를 구현한 대상을 확인하고 SendBird Application ID를 얻은 후 다음과 같은 방법으로 익명 사용자 로그인/생성을 수행하여 "액세스 토큰이 없는 사용자"에 대한 SendBird Application 보안 설정이 잘못 구성 되었는지 확인합니다.
- wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token}
- POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — 본문: {“app_id”:”<application_id>”}
- https://www.postman.com/sendbird/workspace/sendbird-platform-api/overview
- https://sendbird.com/docs
- 사용자 민감한 정보 유출
- 채팅 채널 생성(새 리그 생성 없이)
- 채팅 채널 관리
- 사용자의 채팅 프로필 업데이트
- 그룹 채널 구성 업데이트
- 모든 사용자와 채팅
- 공격자는 자체 생성 채널의 운영자 역할을 하는 동안 모든 사용자의 메시지를 편집/삭제할 수 있습니다.
- 공격자는 모든 채널의 구성원인 동안 채널의 세부 정보, 구성을 업데이트할 수 있습니다.
- 문서에 따르면 단일 SendBird 사용자는 최대 2000개의 그룹 채널에만 참여할 수 있으며 공격자는 2000개의 그룹 채널을 만들고 SendBird 애플리케이션의 모든 사용자를 해당 채널에 추가할 수 있습니다. 그 결과 이후 모든 사용자가 센드버드 채널에 가입할 수 없게 되어 Denial of Service가 발생할 수 있습니다.
- …
- SendBird에는 보안 권장 사항, 특히 ACL에 대한 더 많은 문서가 있습니다.
- 이제 SendBird에서는 고객이 직접 ACL을 변경할 수 있습니다.
4. 2번 단계가 성공하지 못한 경우 수동으로 타겟의 기능을 살펴보고 타겟이 수행하는 일반적인 방법으로 SDK 사용자 세션을 가져오고 3단계와 같이 ACL 구성 오류를 확인합니다.
5. 모두 자동화!
확인할 SendBird API 참조:

여러 센드버드 애플리케이션의 취약점을 확인한 결과, 대부분 ACL 설정 오류에 취약한 것으로 나타났다. 그러나 비즈니스 요구 사항과 영향이 다른 다양한 애플리케이션을 기반으로 심각도도 다르게 고려해야 합니다(중간 - 위험).
영향은 다양합니다.





thaivu , lamscun , thefool45, fergustr4n $$$$ 과의 훌륭한 협력

### 센드버드 업데이트