알려지지 않은 SendBird 구성 오류

Nov 29 2022
우리 팀(thaivu, lamscun, thefool45, fergustr4n)과의 무작위 버그 헌팅 협업에서 우리는 여느 때와 같이 임의의 개인 대상과 부딪쳤습니다. 대상을 악용하는 과정에서 대상이 타사 플랫폼의 서비스를 사용하여 채팅 기능을 구현한 것을 발견했습니다.

우리 팀( 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 인스턴스에 대해 대규모 취약점 검사를 수행하는 방법

  1. 크롤링을 통해 애플리케이션에서 SendBird를 구현하는 대상을 확인하고 대상에서 콘텐츠 검색을 수행하며 "sendbird" 단어 및 SendBird의 애플리케이션 ID " [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12}
  2. SendBird를 구현한 대상을 확인하고 SendBird Application ID를 얻은 후 다음과 같은 방법으로 익명 사용자 로그인/생성을 수행하여 "액세스 토큰이 없는 사용자"에 대한 SendBird Application 보안 설정이 잘못 구성 되었는지 확인합니다.
  3. wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token}
  4. POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — 본문: {“app_id”:”<application_id>”}
  5. 4. 2번 단계가 성공하지 못한 경우 수동으로 타겟의 기능을 살펴보고 타겟이 수행하는 일반적인 방법으로 SDK 사용자 세션을 가져오고 3단계와 같이 ACL 구성 오류를 확인합니다.

    5. 모두 자동화!

    확인할 SendBird API 참조:

    • https://www.postman.com/sendbird/workspace/sendbird-platform-api/overview
    • https://sendbird.com/docs

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

    영향은 다양합니다.

    • 사용자 민감한 정보 유출
    • 채팅 채널 생성(새 리그 생성 없이)
    • 채팅 채널 관리
    • 사용자의 채팅 프로필 업데이트
    • 그룹 채널 구성 업데이트
    • 모든 사용자와 채팅
    • 공격자는 자체 생성 채널의 운영자 역할을 하는 동안 모든 사용자의 메시지를 편집/삭제할 수 있습니다.
    • 공격자는 모든 채널의 구성원인 동안 채널의 세부 정보, 구성을 업데이트할 수 있습니다.
    • 문서에 따르면 단일 SendBird 사용자는 최대 2000개의 그룹 채널에만 참여할 수 있으며 공격자는 2000개의 그룹 채널을 만들고 SendBird 애플리케이션의 모든 사용자를 해당 채널에 추가할 수 있습니다. 그 결과 이후 모든 사용자가 센드버드 채널에 가입할 수 없게 되어 Denial of Service가 발생할 수 있습니다.

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

    ### 센드버드 업데이트

    • SendBird에는 보안 권장 사항, 특히 ACL에 대한 더 많은 문서가 있습니다.
    • 이제 SendBird에서는 고객이 직접 ACL을 변경할 수 있습니다.

    읽어 주셔서 감사합니다! 행복한 해킹, 학습, 사냥 및 새 보호 유지!