이번 포스팅 게시물은 관리자가 삭제한 계정을 로그인 할수있는 취약점에 관한 리포트 입니다. 어떤 특정한 기술 보다는 중간 과정에서 패킷을 조작하여 시도하였습니다.
번역을 하는 것이기 때문에 저의 시점이 아닌 글쓴이 시점으로 번역하겠습니다.
방가방가. 나는 너가 잘하고 있기를 기원해. 오늘 나는 내가 찾은 취약점을 설명해보려해. 이 취약점은 어떻게 내가 관리자가 삭제한 계정의 권한을 다시 가져오는지에 관한 글이야. 하지만 주소를 알려줄수 없기 때문에 example.com의 도메인으로 설명할게.
이 프로그램은 많은 기능을 가지고 있었어. 거기에는 유저를 초대하는 옵션이 있었고 거기에 주소 example.com/dashboard/setup/user-accounts 이었어. 그래서 나는 한번 취약점을 찾아볼까 생각했지. 빠르게 나는 내 이메이로 초대장을 보냈어. 그리고 이러한 응답을 받았지. 이건 아래와 같이 201 created였어.
그래서 나는 내 이메일에서 수락을 누르고 계정을 만들었지. 그리고나서 나는 example.com/dashboard/login으로 들어갔지. 그리고 나는 request와 responese를 만들었어.
난 response를 복사해서 서브라임에 붙여놓았지. 다시 나는 관리자 대쉬보드로 가서 내 계정을 삭제했어.
그리고 나서 나는 example.com/dashboard/login에 들어가서 로그인을 시도해봤더니 역시나 login failed error를 받았지. 아래와 같이.
그래서 나는 인터셉트를 키고 로그인 request를 캡쳐했어,
그리고 응답을 수정했어. 아래와 같은 원래 response를
이렇게 말이지.
그리고 나서 request를 포워딩하니까 나는 계정에 로그인이 됐어! 나는 빨리 리포팅했고 돈을 받았지만 노코멘트!
이번글은 IDOR 취약점을 중점적으로 설명하고 자신이 버그바운티 한 방법을 말해주는 게시물인데 타겟이 비공개라 IDOR을 소개하고 찾는 방법에 중점을 둔 리포팅이더라구요. 저도 그 흐름에 따라 진행하겠습니다.
이 취약점을 통해 $1,500의 버그바운티 금액을 수령했다고 합니다.
이번 취약점 분석글은 IDOR 취약점을 주제로한 버그바운티 게시글입니다.
IDOR 취약점은 Insecure Direct Object References 의 약자로 확인되지 않은 사용자의 input이 확인안된 접근으로 리소스나 조작을 할수있는 access control 취약점입니다. IDOR는 매우 사이버보안에 심각한 결과를 가질수 있고 찾기 힘들지만 exploit하기는 매우 간단하고 이 취약점을 통해 직접 URL파라미터를 변환할 수 있습니다.
IDOR 취약점은 아래에 소개드릴 3가지의 상황에서 발생합니다. 1. 응용 프로그램에서 내부 리소스 또는 작업에 대한 직접 참조를 표시할 때. 2. 사용자가 URL 또는 매개변수 양식을 조작해 직접 참조를 수정할 수 있을 때. 3. 응용프로그램이 사용자의 권한을 체크하지 않고 내부 개체에 대한 액세스 권한을 부여할때.
그렇다면 IDOR 종류에는 어떤 것들이 존재할지 말해보겠습니다.
- Obtaining unauthorized data access (허가되지 않은 데이터를 액세스 수용) : 노출된 객체 참조는 direct db ID를 보여주어 공격자들이 민감한 정보를 포함한 db 기록들을 검색하도록 허용되게 할 수 있습니다. db 키 이름들과 values는 또한 SQL Injection 페이로드를 만들때 사용될 수 있습니다.
- Performing unauthorized operations (허가되지 않은 조작들을 실행) : 검증되지 않은 사용자의 ID values, command name, API keys의 조작들 통해 공격자들은 허가되지 않은 조작을 응용프로그램에서 실행할 수 있습니다. 그 예로 계정의 비밀번호 강제 변경, 관리 권한의 명령어를 통해 사용자를 추가하거나 권한 상승을 하도록 실행, 유료 또는 제한이 설정된 어플리케이션 API 또는 기능에 접근 권한 획득을 할 수 있습니다.
- Manipulating application objects (application objects 조작) : 내부 object reference에 접근은 내부 상태 또는 어플리케이션 데이터에 대한 변경을 허가되지 않은 사용자가 할 수 있도록 허용할 수 있습니다. 이러한 취약점은 공격자가 세션 변수를 조작할 수 있습니다. 예를 들어 데이터 변경, 권한 상승 또는 제한된 기능에 대한 접근 등이 되겠습니다.
- Getting direct acess to files (파일에 대한 직접 권한 획득) : 일반적으로 path traversal과 결합되어 이 IDOR 방법은 공격자들이 파일 시스템 리소스 조작을 할 수 있습니다. 이 방법은 파일 업로드, 다른 사용자들의 데이터 조작 또는 유료 컨텐츠를 무료로 사용등을 가능하게 합니다.
How I discover vulnerability?
정보 수집과 특별한 방식의 파라미터 브루트 포싱은 항상 새로운 단계 또는 기대하지 않았던 결과를 가져다줍니다.
저는 "www.abc.com" 이라는 사이트를 통해 테스트 했습니다. (여기서 저 사이트는 가상의 사이트라고 가정한다고 합니다. 바운티 정책상 밝힐수 없다는 군요.)
저는 높은 수준의 취약점을 찾고 있었습니다. 왜냐하면 프로그램이 오래됐고 저는 일반적인 이슈들이 이미 제보되거나 중복된 취약점들이락 생각했기 때문입니다.
저는 XSS나 SQLi 그리고 다른 조작들을 시도해봤지만 찾을수 없었습니다. 그 어플리케이션은 보안이 잘되어있었습니다. 아니면 제가 별로 일지도;;(이것도 원글 작성자가 쓴 조크입니다;; 밑에 짤도...)
충분한 퍼징을 통해 저는 숨겨진 파라미터 브루트포싱을 시작했습니다. 그리고 endpoint는 "https://www.abc.com/users/account/" 를 찾아냈습니다.
브루트 포싱은 아래 Arjun과 Parameth를 사용했습니다.
1. "https://github.com/s0md3v/Arjun"
2. "https://github.com/maK-/parameth"
Arjun은 "?id="이라는 파라미터를 찾아주었습니다.
그 뜻은 "https://www.abc.com/users/account/?id=" 을 사용가능 하다는 뜻입니다.
내 ID는 6781이었고 내가 ID를 6781에서 부터 6780까지 바꾸었을 때 다른 사용자의 데이터에 접근이 가능했습니다!!!
참 쉽죠잉? (작성자가 쓴거임)
하지만 hidden 파라미터 찾기는 어려웠습니다.
$1,500 돈을 받았습니다.
감사합니다.
여기까지가 원 글이네요.
어떻게 보면 바운티 리포트이긴 한데 IDOR 취약점을 찾을 수 있는 오히려 더 좋은 정보를 가진 게시물인 것 같습니다.
저도 나중에 저거 써봐야겠습니다.
이런 글들을 보면 참 쉽게 찾는 것 같은데 저것도 충분히 잘하는 사람이라 그런것 같습니다.
