손상된 액세스 제어 + 잘못된 구성 = 아름다운 권한 에스컬레이션

안녕 그/그녀

이 이야기는 제가 최근에 발견한 권한 상승 취약점에 대한 것입니다.

• 이 사이트 작성자/계정 소유자에게는 2가지 역할이 있습니다.
• 계정 소유자 사용자는 관리이며 전체 계정 사용자 및 기타 기능에 액세스할 수 있습니다.
• 작성자 역할은 조직에서 일부 항목만 생성할 수 있지만 사용자 정보, UUID 및 기타 조직 정보/PII와 같은 항목에는 액세스할 수 없습니다.

• 손상된 액세스 제어를 찾기 위해 대부분의 끝점을 시도했지만 대부분 403이 금지되어 하나의 끝점에서만 사용자 정보/PII를 읽을 수 있었습니다.

GET /v1/account/customer/users?includeDetails=true HTTP/1.1 호스트: dontlookhere 쿠키: FewRoleUserCookies 사용자 에이전트: Mozilla/5.0(Macintosh; Intel Mac OS X 10.15; rv:106.0) Gecko/20100101 Firefox/106.0 수락: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https:// dontlookhere Dnt: 1 Sec-Fetch-Dest: empty Sec- Fetch-Mode: cors Sec-Fetch-Site: same-origin Te: trailers 연결: 닫기

• 위에서 발견한 끝점의 손상된 액세스 제어를 통해 이메일, 전화 번호, UUID, 주소 및 기타와 같은 조직 사용자 정보에 액세스할 수 있었습니다.

• 또한 대부분의 기능은 반환 금지 403 사용자 추가, 사용자 삭제 및 기타 쓰기 기능 반환 403
• 소수의 사용자 역할 계정에서 하나의 기능만 실행되고 200이 반환되었습니다.
• 그래서 나는이 요청을 시도

• 위의 요청에서 403 없이 사용자 상태를 비활성화로 변경할 수 있었고 사용자가 비활성화 상태로 변경되어 다시 활성화할 수 있음을 발견했습니다.
• 하지만 여기서 두 번째는 역할 변경 기능을 사용하여 작성자에서 계정 관리자로 내 역할을 업그레이드할 수 있었습니다.

[1]

역할 [2]는 생성자이고 역할 [1]은 계정 관리자
이므로 쿠키를 생성자 역할 계정 쿠키로 교체하고 UUID를 동일한 생성자 역할 계정 UUID로 변경했습니다. 그곳에서 UUID를 검색할 수 있었기 때문에 다른 사용자의 역할을 편집할 수 있었습니다.

• 소수의 사용자가 실행한 요청과 무엇?
• 그리고 계정 역할이 계정 관리자로 변경되어 이제 조직의 관리자가 된 것이 좋습니다. :)

• 에스컬레이션할 수 있는 기능은 다음과 같습니다.

사용자의 PII/정보에 액세스

내 역할/및 사용자의 역할을 변경하고 계정 소유자 역할을 얻습니다.

읽어주셔서 감사합니다 우리 다시 만날 때까지 좋은 날들 보내시기 바랍니다

소셜:

Linkedin.com/in/m359ah

Twitter.com/m359ah