1. IDOR
먼저 IDOR에 DOR를 살펴보면 Direct Object Reference로 직접 객체 참조라고 한다. DOR은 클라이언트가 URI path나 파라미터 등으로 값을 서버에 전달하면서 서버의 애플리케이션에서 전달받은 값을 참고해 특정 데이터와 객체에 접근하는 것을 의미한다.
따라서 클라이언트가 특정 데이터나 객체에 접근할 때 클라이언트가 해당 데이터에 접근할 권한이 있는지 검증 과정이 반드시 필요하다. 하지만 이런 검증과정이 미흡하게 구현되어 있는 취약점을 DOR에 Insecure를 붙여 IDOR(취약한 직접 객체 참조)라고 한다.
IDOR 취약점
IDOR의 취약점은 수평적, 수직적 권한 상승으로 볼 수 있다.
1. 수평적 권한 상승
일반 사용자 A, B가 있을 때 A가 조회할 수 없는 B의 정보를 조회하는 경우
2. 수직적 권한 상승
일반 사용자 A, B와 관리자 C가 있을 때 A가 관리자의 사용자 정보를 수정할 수 있는 권한을 이용해 B의 정보를 수정하는 경우
2. 모의 해킹 실습
1) 인증
먼저 IDOR은 사용자로부터 취약점이 발생되기 때문에 먼저 주어진 tom, cat이라는 아이디와 비밀번호를 입력해 로그인 한다.
2) 숨겨진 정보 찾기
다음 view Profile버튼을 통해 자신의 정보를 조회하는 request를 살펴보고 숨겨진 정보를 찾아보자.
View Profile를 눌렀을땐 name, color, size의 정보가 나오지만, Brub Suite를 통해 response를 보면 위 정보 뿐 아니라 role, userId의 숨겨진 정보가 있는 것을 확인할 수 있다.
숨겨진 정보를 다음과 같이 입력해주고 다음 단계로 넘어가보자.
3) 정보조회 url 파악
다음으로는 Restful API에서 DOR를 어떻게 수행할 것인지를 알아내야 한다. Restful API는 rest한 구조를 따르는 API로 HTTP Method로 어떤 행위를 할지 정의하고, DOR하기 위해선 HTTP 요청 본문을 통해 행위에 필요한 데이터들이 path parameter이나 query string에 포함될 수 있다.
따라서 이전에 정보를 조회하는 uri를 봤을 때 GET과 /WebGoat/IDOR/profile에서 뒤에 path parameter 이나 query string으로 요청을 보내보면 좋을 것 같다.
그럼 uri에 어떤 데이터를 넣어서 보내면 좋을까?
숨겨진 정보까지 모두 확인해 봤을 때, 사용자를 식별할 수 있는 name이나 userId를 넣어보면 좋을 것 같다. path parameter과 qeury string으로 name과 userId를 보낸 본 결과 다음과 같이 path parameter로 userId를 넣었을 때 다음과 같은 성공 메세지를 확인할 수 있었다.
4) 수평적, 수직정 권한 상승
그럼 우리가 이전 단계에서 확인했던 DOR 했던 uri를 살펴보면 다음과 같이 View Profile를 누르고 request를 확인해보면 /WebGoat/IDOR/profile/%7BuserId%7D 인것을 확인할 수 있고 여기에 %7BuserId%7D에는 userId가 들어간다는 것을 추론할 수 있다.
그럼 %7BuserId%7D에 tom의 userId를 넣어 조회해보자. 이번에 요청은 동일한 HTTP요청에 대하여 값을 변경해가며 반복적으로 요청 가능한 Repeater라는 기능을 이용해보자.
위에서 확인했던 프로필 조회 요청에 형식에 맞게 요청을 해야하기 때문에 화면에서 오른쪽 마우스를 눌러 Sent to Repeater를 눌러준다.
(1) 수평적 권한 상승
먼저 repeater탭으로 이동해 path parameter에 tom의 userId를 넣어 send해주면 다음과 같이 200코드와 함께 정상적으로 작동한 것을 확인할 수 있다.
그럼 우리는 tom 말고 다른 사용자를 찾기 위해 tom의 userId보다 1씩 큰 userId를 조회해보니 2342388 에서 다음과 같은 "Buffalo Bill"이라는 사용자의 정보를 조회할 수 있었다.
이런 경우 Tom은 동일한 권한을 가진 Buffalo Bill이라는 사용자의 데이터에 접근하게 되고 '해커는 프로필 조회 기능에 존재하는 IDOR 취약점을 이용해 수평적 권한 상승을 이루어냈다고 할 수 있다.
만약 제한된 정보를 조회할 수 있도록 서비스를 만들었다면 수평적 권한 상승이라고 볼 수 없지만, 서비스상 userId 이외에도 이메일주소, 결제 내역등 의도하지 않은 정보들을 조회할 수 있게 되는 경우에 수평적 권한 상승이라고 할 수 있다.
(2) 수직적 권한 상승
다음으로는 관리자의 권한으로 볼 수 있는 사용자의 정보수정을 통해 수직적 권한 상승을 실습해보자.
WebGoat에서 사용자의 권한은 기존보다 낫게, color은 red로 변경하라고 했고, 우리는 PUT이라는 HTTP method를 통해 정보를 수정해보자.
여기서 이전에 정보를 조회했을 때의 데이터 구조를 살펴보면 json형태로 정보를 주고 받는다는 것을 확인할 수 있다.
따라서 데이터를 수정할 때 json형태로 변경된 데이터를 넣어주고 json데이터라는 것을 알려주기 위해 request header에 Content-Type: application/json를 추가해주고 아래에 데이터를 json형태로 넣어주고 요청을 보내면 다른 사용자의 정보를 수정했다는 메세지를 확인할 수 있다.
{
"role":1,
"color":"red",
"size":"small",
"name":"Buffalo Bill",
"userId":"2342388"
}
이렇게 서비스상 관리자만 할 수 있는 사용자 정보수정을 함으로써 수직적 권한 상승을 이루는 것을 확인할 수 있다.
3. 정리
WebGoat에서는 사용자 본인이 아니면 자신의 데이터를 조회할 수 없고 관리자가 아니면 사용자의 정보를 수정할 수 없는 서비스를 제공하고 있다.
하지만 사용자의 접근제어가 제대로 이루어지지 않아 서비스의 의도와는 달리 다른 사용자의 정보를 조회하고, 관리자의 권한까지 사용함으로써 수평적, 수직적 권한 상승을 이루었다.
이 실습을 통해 서비스가 의도한 사용자의 권한을 통제하기 위해서 사용자의 검증과 접근제어가 철저히 이루어져야 함을 느낄 수 있었다.
