CBBH - Web Attacks[Identifying IDORs]

 

URL Parameter & API

IDOR 취약점을 악용하는 첫 번째 단계는 Direct Object References, DOR 를 식별하는 것이다. 특정 파일이나 리소스를 요청할 때, HTTP 요청을 분석해 URL 파라미터나 API에서 객체 참조를 찾는 것이다. Ex: ?uid=1 or ?filename=file_1.pdf 이러한 객체 참조 값은 주로 URL 파라미터나 API에서 발견되지만, 쿠키와 같은 기타 HTTP 헤더에서도 발견될 수 있다.

기본적인 경우, 객체 참조 값을 증가시키면서 다른 데이터에 접근할 수 있는지 테스트할 수 있다. 예를 들어, ?uid=2 또는 ?filename=file_2.pdf 로 변경해 다른 사용자의 데이터를 불러올 수 있는지 확인하는 것이다.

또한, Fuzzing 도구를 사용해 많은 변형을 통해, 응답이 있는지 확인할 수 있다. 만약 자신의 것이 아닌 파일을 확인할 수 있으면, 이는 IDOR 취약점이 존재한다는 신호가 된다.

AJAX 호출

웹 애플리케이션의 프론트엔드 코드(JavaScript)에서 사용되지 않는 파라미터나 API를 식별할 수 있다. 일부 Javascript 프레임워크 기반 웹 애플리케이션은 모든 기능 호출을 프론트엔드에서 수행하며, 사용자 역할(role)에 따라 실행 여부를 결정한다.

예를 들어, 관리자 계정이 없는 사용자에게는 일반 사용자 기능만 표시되고, 관리자 기능은 비활성화될 수 있다. 하지만, 프론트엔드 JavaScript 코드에서 관리자 기능을 찾아낼 수 있다면, 직접 호출을 시도해 IDOR 취약점을 테스트할 수 있다.

이는 관리자 기능뿐만 아니라, HTTP 요청을 감시하는 것만으로는 찾을 수 없는 다른 기능이나 API 호출에서도 적용될 수 있다. 다음은 기본적인 AJAX 호출의 예시이다.

function changeUserPassword() {
    $.ajax({
        url: "change_password.php",
        type: "post",
        dataType: "json",
        data: {uid: user.uid, password: user.password, is_admin: is_admin},
        success: function(result){
            //
        }
    });
}

위 함수는 일반 사용자가 웹 애플리케이션을 사용하는 동안 실행되지 않을 수도 있다. 하지만 프론트엔드 코드에서 이 함수를 발견했다면, 직접 호출해 테스트할 수 있다. 만약 실행이 가능하다면, 이는 IDOR 취약점이 존재한다는 의미이다. 같은 방식으로 오픈소스 웹 애플리케이션의 백엔드 코드에 접근할 수 있다면, 해당 코드를 직접 분석해 취약점을 찾을 수도 있다.

Understand Hashing/Encoding

일부 웹 애플리케이션은 객체 참조 값으로 단순한 숫자나 ID를 사용하지 않고, 이를 인코딩하거나 해싱할 수도 있다. 하지만, 백엔드에서 접근 제어가 없을 경우, 이러한 보안 기법이 적용되었더라도 여전히 IDOR 취약점을 악용할 수 있다.

예를 들어, 객체 값을 Base64 인코딩을 사용하고 있다면, 이를 디코딩해 원래 객체 참조 값을 확인한 후, 변형해 다시 인코딩해 공격할 수 있다.

예를 들어, ?filename=ZmlsZV8xMjMucGRm 과 같은 참조가 보이면 파일 이름이 Base64 인코딩이라고 추측할 수 있다. 그런 다음 이를 디코딩해 file_123.pdf 인 것을 확인했다면 file_124.pdf 를 인코딩해 ?filename=ZmlsZV8xMjQucGRm 와 같이 요청을 보내면, IDOR 취약점을 통해 접근이 가능한지 테스트할 수 있다.

객체 값이 해시된 형태로 존재할 수 있다. 다음과 같이

download.php?filename=c81e728d9d4c2f636f067f89cc14862c 존재할 수 있다. 이렇게 보면 객체 값의 보안이 강화된 것처럼 보이지만, 프론트엔드 코드에서 해싱 방식이 어떻게 적용되는지 확인할 수 있다.

$.ajax({
    url:"download.php",
    type: "post",
    dataType: "json",
    data: {filename: CryptoJS.MD5('file_1.pdf').toString()},
    success:function(result){
        //
    }
});

위 코드에서 볼 수 있듯이, 파일 이름을 MD5 해시로 변환해 API에 전달하고 있다. 그러면 여기서 다른 파일의 해시를 생성해 요청을 보낼 수 있다.

만약 해싱 알고리즘이 백엔드에서 유일한 보안 정책이면, 공격자는 다음과 같은 절차로 IDOR 취약점을 악용할 수 있다.

• 해시 알고리즘 확인
• 대상 파일명 해싱
• 생성된 해시 값을 이용해 API 요청 수행
• 정상적인 응답이 오면 IDOR 취약점이 존재한다고 판단

Compare User Roles

좀 더 IDOR 공격을 파고들기 위해 여러 개의 사용자 계정을 등록해 HTTP 요청 및 객체 참조 값을 비교하는 것이 중요하다. 이를 통해, 웹 애플리케이션이 어떻게 URL 파라미터와 객체 식별자를 생성하는지를 분석하고, 다른 사용자의 데이터도 조회할 수 있는지 확인할 수 있다.

예를 들어, 두 개의 사용자 계정을 가지고 있다고 가정해보려 한다.

• User1은 자신의 급여 정보를 조회할 수 있음

{
  "attributes" : 
    {
      "type" : "salary",
      "url" : "/services/data/salaries/users/1"
    },
  "Id" : "1",
  "Name" : "User1"
}

이 때, User1의 API 요청을 참고해 User2로 동일한 요청을 보내볼 수 있다. 만약 백엔드에서 단순히 유효한 로그인 세션만을 확인하고, API 요청을 수행한 사용자의 권한을 비교하지 않는다면, User2도 User1의 급여 정보를 조회할 수 있을 것이다.

이 경우 다른 사용자의 API 매개 변수를 계산할 수 있다면 이는 IDOR 취약점에 해당된다. 다른 사용자의 API 매개 변수를 계산할 수 없더라도 백엔드 접근 제어 시스템에서 취약점을 여전히 식별하고 다른 객체 참조를 시작할 수 있다.