계정 탈취에 대한 IDOR
요약
안녕하세요 사람들! 내 OSCP 인증을 완료하고 다시 버그 바운티에 대해 알아보고 싶을 때 누군가가 유용하거나 배울 수 있기를 바라며 이전에 발견한 내용을 기반으로 블로그를 작성해야겠다고 결정했습니다.
이 글에는 2개의 IDOR 취약점을 찾고 이를 활용하여 PII를 유출하여 계정 탈취를 초래하는 내용이 포함되어 있습니다 . 계정 탈취는 회사가 계정 복구 프로세스를 처리하는 방식으로 인해 가능했으며 사실 처음 버그 바운티를 시작했을 때 처음 발견한 것 중 하나였습니다. 이것을 발견한 짜릿함이 저를 계속해서 야근을 배우게 했습니다.
내가 말하는 이 IDOR는 무엇입니까?
Insecure Direct Object Reference
가장 자주 "IDOR"로 약칭되는 취약점은 access control
. IDORs
앱이 사용자 제공 입력을 사용하여 사용자에게 올바른 인증 권한이 있는지 확인하지 않고 객체에 직접 액세스할 때 애플리케이션 내에서 발생합니다. 수평적 권한 에스컬레이션과 가장 자주 연관되어 IDORs
애플리케이션과 해당 사용자 기반에 해로운 영향을 미칠 수 있습니다.
일반적으로 IDOR에 취약한 일반적인 매개변수의 대표적인 예는 다음과 같습니다 id= | userID= | messageId=
. 애플리케이션의 흐름을 이해하면 이러한 유형의 문제를 더 쉽게 식별할 수 있습니다.
위 이미지는 두 가지 시나리오를 보여줍니다. Scenario A
왼쪽에 있는 것은 users 2 and 3
자신에게 속하지 않은 민감한 레코드에 액세스하려고 시도하지만 그 결과는 access denied error
정상인 보다 안전한 애플리케이션을 전달합니다.
Scenario B
그러나 오른쪽에는 공격자가 액세스를 거부하지 않고 웹 서버에 요청을 발행하고 지정된 사용자에 대한 민감한 기록을 검색할 수 있는 취약한 애플리케이션을 보여줍니다.
IDORs
Vickie Li 에 대해 자세히 알아보려면 이 취약성 유형의 기본 사항을 조명하는 환상적인 블로그 게시물이 있습니다. 여기에서 확인할 수 있습니다 .
위의 예는 간단한 예이지만 애플리케이션에 따라 보고하기 전에 정보를 활용하여 영향력을 높일 수 있습니다. 이것이 제가 항상 목표로 하는 것입니다.
IDORs
이제 우리는 그것이 무엇인지, 어디서 찾을 수 있는지, 그리고 그 영향에 대한 아이디어를 얻었으니 , 제가 초기에 발견한 것 중 하나를 살펴보겠습니다! :)
정찰
문제가 해결되었지만 전체 공개에 대한 허가를 얻을 수 없었기 때문에 대상은 다음과 같습니다 example.com
. 모든 대상과 마찬가지로 scope
하위 도메인 열거는 공격 표면을 확장하는 데 중요합니다. 그러나 중요한 정보에 대한 파일을 분석할 수도 있으므로 하위 도메인 열거가 공격 표면을 확장하는 유일한 방법은 아닙니다 JavaScript
. Google Dork
이 경우 더 많은 결과를 얻기 위해 자동화된 도구를 사용하기 전에 흥미로운 하위 도메인을 찾을 수 있는지 확인하기 위해 빠른 사용으로 시작하기로 결정했습니다 .
구글 도크:site:*.example.com
Example.com
약 36개의 하위 도메인이 있으므로 함께 작업할 수 있는 상당히 많은 수의 하위 도메인이 있습니다!
그것들을 하나씩 살펴보면서 많은 기능을 가진 두 개의 하위 도메인을 적어 두었습니다. 하루나 이틀 정도 이 하위 도메인을 탐색하고 다양한 기능을 테스트하면서 해당 응용 프로그램에 특정한 몇 가지 더 흥미로운 기능을 염두에 두었습니다. 예를 들어, 애플리케이션에는 "결제 문제"와 같은 다양한 범주에서 직원의 지원을 받기 위해 티켓을 생성할 수 있는 기능이 있습니다.
초기 버그
나는 요즘 거의 모든 웹 사이트에서 구현되는 핵심 기능인 가입 및 로그인 프로세스가 어떻게 작동하는지 분석하는 것으로 시작하기로 결정했습니다. 웹 애플리케이션의 가입 흐름은 다음과 같이 요약할 수 있습니다.
- 사용자는 이메일을 통해 가입
- 계정 생성 프로세스가 완료되기 전에 사용자에게 a
PIN No.
및 a를 설정하라는 메시지가 표시됩니다 .security question
한 번만 설정할 수 있으며 변경할 수 없습니다. - 사용자가 로그인하기 전에 이메일을 확인하라는 메시지가 표시됨
account A
을(를) 사용하여 Burpsuite
발권 기능을 테스트하고 두 개의 테스트 계정을 만든 다음 테스트 목적으로 서로 다른 지원 범주에서 몇 개의 티켓을 생성했습니다. HTTP History
내부 를 살펴보면 Burpsuite
흥미로운 통화가 이루어지고 있습니다.
상품 청구와 관련된 티켓에서 직원에게 회신할 때 다음이 시작되었습니다.POST request
POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com
grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...
따라서 지금까지의 결과를 결론짓자면 다음과 같습니다.
- 가입 시 모든 사용자
PIN No.
는security question
- 웹 사이트를 통해 사용자는 지원 티켓을 만들 수 있습니다.
- 지원을 받으려면 사용자가 계정 복구, 상금 청구 및 지불 문제와 같은 민감한 문제에 대해
PIN No.
응답 해야 합니다.security question answer
IDOR
티켓팅 시스템 내에서 발견된 취약점으로 인해 공격자는 티켓 소유자나 직원이 아니더라도 모든 지원 티켓 내에서 의견을 제시할 수 있습니다.
따라서 소유자나 직원 권한 없이 티켓에 댓글을 달 수 있다면… 확실히 이것은 내가 어떤 티켓도 읽을 수 있다는 것을 의미할까요?
account A
를 통해 에 속한 티켓을 보려고 시도하면서 다음 GET 요청을 캡처했지만 account B
잘못된 오류가 발생했습니다 403
! 그래서 주어진 지원 티켓에 쓸 수는 있었지만 그 내용을 읽을 수는 없었습니다. 이 시점에서 나는 이것을 더 발전시킬 수 있는 가능한 방법을 정말로 찾고 싶었습니다.
웹 애플리케이션에서 티켓을 읽기 위한 GET 엔드포인트
GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close
발권 기능을 이용하려고 시도하는 동안 다음 요청을 우연히 발견했습니다.
GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:
IOS 앱에서 API를 통해 티켓 콘텐츠 유출
API
초기 정찰 중에 프로필 정보를 검색할 때 일부 요청이 전송되고 대상도 mobile app
범위 내에 있음 을 발견했습니다 . API version/endpoint
웹 애플리케이션 자체에서 다른 사용자 티켓을 읽을 수는 없지만 웹 애플리케이션과 다른 것을 사용할 수 있으므로 모바일 애플리케이션을 통해 달성할 가능성이 높습니다.
IOS 애플리케이션 내에서 티켓 세션을 시작 Burpsuite
하고 탐색하여 다음 엔드포인트에 도착했습니다.
GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com
그래서 이제 두 가지 버그를 발견했습니다. 모든 티켓에 글을 쓰고 다른 사용자에게 속한 모든 티켓의 내용을 볼 수 있었습니다.
에스컬레이션 티켓 읽기 IDOR > 계정 탈취
이 시점에서 나는 계정 탈취를 달성하는 데 필요한 모든 요소를 거의 갖추고 있었습니다. 모든 티켓을 읽을 수 있으므로 다음 단계를 통해 사용자 계정 탈취를 수행할 수 있습니다.
- 끝점 을 방문 하고 가능한 한 많은 티켓을 열거하기 위해 보내
/api/v1/support-tickets/234567/posts
십시오.intruder
Burpsuite
Grep
Pin Number
또는Security Question
응답에서 와 같은 키워드에 대해- 웹 사이트에서 새 계정을 만들고 아래에서 티켓을 엽니다.
account recovery
security question answer
할당된 직원은 복구하려는 계정의 사용자 이름 과 및 를 묻습니다PIN No.
. 두 번째로 발견된 IDOR을 통해 모두 유출될 수 있습니다. 따라서 계정 탈취가 발생합니다.
이미 계정 탈취가 이루어졌지만 티켓 쓰기 IDOR을 활용할 수도 있습니다. 직원 사용자 이름에는 회사 이름이 접두사로 붙습니다(예: example-John
. 적은 할 수 있습니다.
- 직원으로 위장하기 위해 위의 명명 규칙으로 새 계정을 만듭니다.
- 티켓 읽기 IDOR를 사용하여 모든 오픈/클로즈드 티켓 ID를 열거합니다.
- 다음과 같은 민감한 카테고리에 해당하는 티켓에 댓글을 달고
Payment Issues/ Prize Claims
사용자에게 추가 PII 정보를 공개하도록 요청합니다. - 티켓 읽기 IDOR를 통해 사용자가 제공한 응답을 읽습니다.
테이크아웃
- 범위가 허용하는 경우 웹 애플리케이션과 모바일 애플리케이션 모두에서 동일한 기능을 테스트합니다.
- 항상 영향을 높이려고 노력하고 낮은 결과를 > 영향력 있는 것으로 연결하려고 노력합니다.
- 덜 가본 길은 유익한 발견으로 이어집니다… 찾아보세요 :)