보안
쿠키 보안 03
적외선
2010. 11. 23. 14:57
지난 2006년 11월 12월호에 걸쳐서 쿠키에 대해 알아 보았으며, 쿠키를 통한 사용자 정보 노출에 관한 내용을 알아보았다.
이번호에서는 쿠키를 이용하여 사용자 Session을 가로채기를 할수 있는 Cookie Spoofing에 관해서 알아보자.
매번 사용자가 로그인할 때마다 랜덤한 값으로 생성되는 일회용 토큰 형태의 Cookie 값을 이용한 인증을 하지 않는 사이트의 경우, 얻어낸 타 사용자의 Cookie 정보를 이용하여 다른 사용자로 로그인할 수 있다. Cookie를 위조하는 공격 기법이라고 하여 이를 Cookie Spoofing이라고 한다. Cookie Spoofing에는 도용하고자 하는 대상 사용자(희생자)의 Cookie 정보가 필요하지 않은 경우와 Cookie 정보가 필요한 경우가 있는데 전자와 후자를 각각 ‘단순 사용자 도용’, ‘Cookie Theft와 연계한 사용자 도용’으로 나누어 설명하도록 한다. 그 전에 잠시 ParosProxy 툴에 대해 알아보자.
① ParosProxy의 소개
Cookie를 조작하기 위해서는 클라이언트가 서버에 Cookie 헤더를 보내는 중간에, 혹은 서버가 클라이언트에게 Set-Cookie 헤더를 보내는 중간에 요청과 응답을 가로채어 수정해야 한다. 물론 브라우저 자체가 그런 기능을 제공하는 경우도 있지만(일례로 FireFox의 플러그인 TamperData가 있음) Proxy 계열의 점검 도구를 사용하는 것이 편리하다. 이런 툴의 경우 또 다른 Proxy Server를 다시 Proxy Server로 잡는 Proxy Chain 기능, Request, Response에 대한 저장 및 분석, Web Spidering(Crawling), 또한 SQL Injection, CRLF Injection 등의 보안 취약성 검사 기능 등의 유용한 기능을 제공하기 때문이다. 그러한 툴 중에 프리웨어로서 유명한 툴이 ParosProxy이다. 이 툴은 http://www.parosproxy.org/에서 다운로드할 수 있으며 설치 과정은 단순하므로 생략한다. 툴 설치 이전에 JRE(Java Runtime Environment)가 설치되어 있어야 하며 버전은 ParosProxy에서 요구하는 버전으로 설치하여야 한다.
ParosProxy 툴 설정이 끝난 이후, www.coconut.co.kr 사이트에 접속한 이후 ParosProxy에서볼 수 있는 결과 화면이다. 다음과 같이 요청과 응답의 내용을 헤더를 포함하여 상세히 볼 수 있다.
[그림 1] ParosProxy 사용 예
② 단순 사용자 도용
이 장에서 공격 기법을 설명하기 위해 구현된 사이트는 다음과 같다. ID, Password 정보를 입력하면 로그인할 수 있는 사이트로 Cookie Spoofing을 이용한 사용자 도용을 설명하기 위해 임의로 구현한 사이트이다. 하지만 현재 실환경으로 운영되는 많은 사이트도 이런 문제점을 갖고 있음을 간과하지 말아야 한다.
[그림 2] 로그인 시도 화면
위 사이트는 일반적인 로그인 페이지다. 로그인할 경우 다음과 같이 해당 회원에 대한 정보를 열람하는 페이지가 확인된다.
[그림 3] 로그인 성공 결과
물론 ID, Password를 잘못 입력하면 다음과 같은 오류 화면이 나타나는 일반적인 로그인 페이지이다.
[그림 4] 로그인 실패 결과
로그인한 이후 회원정보변경 페이지가 열릴 때의 요청을 ParosProxy를 통해 확인해 보면 아래와 같이 s_id라는 Cookie 값이 ‘coconut’으로 셋팅되었음을 알 수 있다.
[그림 5] 로그인 성공 이후 확인된 Cookie 헤더
이 Cookie 정보를 토대로 사용자의 인증 정보를 유지하며 또한 사용자가 coconut임을 구분하는 것으로 유추할 수 있다. 그렇다면 이것을 다른 값으로 바꾼다면 어떤 현상이 나타날 수 있을까? 그 이전에 로그인 과정에서 앞서 이야기한 Set-Cookie라는 Response Header가 확인되는지를 보자.
[그림 6] 로그인 성공 시 확인된 Set-Cookie 정보
ParosProxy에 저장된 요청과 응답 내용을 보니 Set-Cookie라는 헤더가 나타나는 것을 볼 수 있다. 그렇다면 이 Set-Cookie 값을 중간에 가로채서 다른 값으로 변경해버리면 클라이언트가 이후에 보내게 될 Cookie 값도 다른 값으로 보내지게 될 것이다. 정말 그런지 확인해 보자.
ParosProxy를 이용할 경우 Set-Cookie 값을 중간에 가로채어 조작하는 방법은 크게 두 가지가 있다. 우선 Trap 기능을 이용하는 것이다. Trap 기능은 다음과 같이 활성화할 수 있다. Trap request를 선택하게 되면 클라이언트에서 서버 측으로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이며 Trap response를 선택하게 되면 서버 측에서 클라이언트로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이다.
[그림 7] Trap response 설정
두 번째 방법은 Tools > Filter 메뉴에서 Detect and alert ’Set-cookie’ attempt in HTTP response for modification을 활성화 하는 것이다.
[그림 8] Set-cookie 시도 탐지 설정
두 번째 방법으로 할 경우 모든 응답 메시지를 가로채지 않고 Set-cookie 헤더가 나타났을 때만 가로채어 조작할 수 있도록 한다. 두 가지 중 어느 방법이든 가능하니 편한 방법을 쓰면 된다. 여기서는 Trap을 이용한 방법으로 기술하겠다.
우선 앞서 제시된 것과 같이 Trap Response 항목을 체크한다. Set-Cookie의 경우는 서버가 클라이언트에게 보내는 데이터를 조작하는 것이므로 Trap Response를 하는 것으로 충분하다.
Trap response를 셋팅한 상태에서 다시 로그인을 시도해본다. 요청에 대하여 응답을 계속 중간에 가로채어 보여줄텐데 Continue 버튼을 클릭하면 다음 단계로 넘어간다. 다음과 같이 Set-Cookie 화면이 나타날 때까지 넘어간다.
[그림 9] Trap 기능을 이용한 Set-Cookie 정보 변경 시도
여기서 Continue를 누르기 전에 Set-Cookie의 내용을 다음과 같이 조작한다.
[그림 10] Trap 기능을 이용한 Set-Cookie 정보 변경 시도
이제 Continue를 누른다. 그 전에 더 이상의 response를 중간에 가로챌 이유는 없으므로 Trap response 체크박스는 해제해도 좋다. 그 결과 다음과 같이 ahncoco 계정의 패스워드 정보를 입력하지도 않았고 알지도 못함에도 ahncoco로서 로그인 성공하였음을 알 수 있다.
[그림 11] 사용자 도용 성공 결과
이 예제에서는 이해를 돕게 하기 위하여 상황을 최대한 단순화시켰다. 하지만 s_id라는 ID 이름 대신 숫자로 표현된 값으로 사용자를 구분하는 경우도 실제로 구현된 사이트 중에 있다. 즉 hosik은 12341, ahncoco는 12342라고 표현되었다고 하자. 이 경우 Cookie 값을 12342로 변경하면 ahncoco로 로그인된다. 또한 이런 경우 주요 계정이 초기에 생성되었음을 감안하여 낮은 숫자로 시도함으로 종종 admin 계정과 같은 경우로 로그인 성공하는 경우도 있다.
③ Cookie Theft와 연계한 사용자 도용
Cookie Theft를 통해 Cookie 정보를 얻어내어야 하는 경우가 있다. 인증에 사용되는 Cookie 정보가 앞선 경우와는 달리 복잡하게 설정된 경우이다. 대표적인 경우는 아래와 같은 경우이다. 아래 정보를 보면 사용자ID, 해당 부서 등의 정보를 얻어내야 할텐데 앞서 논한 단순 사용자 도용과 같이 추측만으로 하기는 어려운 문제이다. 이 경우는 사용자의 Cookie를 얻어내는 방법 즉 Cookie Theft가 필요하다. 하나, 이 경우도 기억할 점이 있다면 Cookie 정보는 많지만 실제 로그인 정보를 유지하고 사용자 정보를 구분하는 핵심 Cookie 정보만 필요하다는 점이다. 그런 정보가 많지 않고 간단하게 구현되어 있다면 그것을 파악하면 좀 더 쉽게 작업을 할 수 있다.
얻어낸 Cookie를 재사용하여 로그인할 수 있는 문제점, 공격 기법을 Cookie Replay라고 부른다.@
이번호에서는 쿠키를 이용하여 사용자 Session을 가로채기를 할수 있는 Cookie Spoofing에 관해서 알아보자.
매번 사용자가 로그인할 때마다 랜덤한 값으로 생성되는 일회용 토큰 형태의 Cookie 값을 이용한 인증을 하지 않는 사이트의 경우, 얻어낸 타 사용자의 Cookie 정보를 이용하여 다른 사용자로 로그인할 수 있다. Cookie를 위조하는 공격 기법이라고 하여 이를 Cookie Spoofing이라고 한다. Cookie Spoofing에는 도용하고자 하는 대상 사용자(희생자)의 Cookie 정보가 필요하지 않은 경우와 Cookie 정보가 필요한 경우가 있는데 전자와 후자를 각각 ‘단순 사용자 도용’, ‘Cookie Theft와 연계한 사용자 도용’으로 나누어 설명하도록 한다. 그 전에 잠시 ParosProxy 툴에 대해 알아보자.
① ParosProxy의 소개
Cookie를 조작하기 위해서는 클라이언트가 서버에 Cookie 헤더를 보내는 중간에, 혹은 서버가 클라이언트에게 Set-Cookie 헤더를 보내는 중간에 요청과 응답을 가로채어 수정해야 한다. 물론 브라우저 자체가 그런 기능을 제공하는 경우도 있지만(일례로 FireFox의 플러그인 TamperData가 있음) Proxy 계열의 점검 도구를 사용하는 것이 편리하다. 이런 툴의 경우 또 다른 Proxy Server를 다시 Proxy Server로 잡는 Proxy Chain 기능, Request, Response에 대한 저장 및 분석, Web Spidering(Crawling), 또한 SQL Injection, CRLF Injection 등의 보안 취약성 검사 기능 등의 유용한 기능을 제공하기 때문이다. 그러한 툴 중에 프리웨어로서 유명한 툴이 ParosProxy이다. 이 툴은 http://www.parosproxy.org/에서 다운로드할 수 있으며 설치 과정은 단순하므로 생략한다. 툴 설치 이전에 JRE(Java Runtime Environment)가 설치되어 있어야 하며 버전은 ParosProxy에서 요구하는 버전으로 설치하여야 한다.
ParosProxy 툴 설정이 끝난 이후, www.coconut.co.kr 사이트에 접속한 이후 ParosProxy에서볼 수 있는 결과 화면이다. 다음과 같이 요청과 응답의 내용을 헤더를 포함하여 상세히 볼 수 있다.
[그림 1] ParosProxy 사용 예
② 단순 사용자 도용
이 장에서 공격 기법을 설명하기 위해 구현된 사이트는 다음과 같다. ID, Password 정보를 입력하면 로그인할 수 있는 사이트로 Cookie Spoofing을 이용한 사용자 도용을 설명하기 위해 임의로 구현한 사이트이다. 하지만 현재 실환경으로 운영되는 많은 사이트도 이런 문제점을 갖고 있음을 간과하지 말아야 한다.
[그림 2] 로그인 시도 화면
위 사이트는 일반적인 로그인 페이지다. 로그인할 경우 다음과 같이 해당 회원에 대한 정보를 열람하는 페이지가 확인된다.
[그림 3] 로그인 성공 결과
물론 ID, Password를 잘못 입력하면 다음과 같은 오류 화면이 나타나는 일반적인 로그인 페이지이다.
[그림 4] 로그인 실패 결과
로그인한 이후 회원정보변경 페이지가 열릴 때의 요청을 ParosProxy를 통해 확인해 보면 아래와 같이 s_id라는 Cookie 값이 ‘coconut’으로 셋팅되었음을 알 수 있다.
[그림 5] 로그인 성공 이후 확인된 Cookie 헤더
이 Cookie 정보를 토대로 사용자의 인증 정보를 유지하며 또한 사용자가 coconut임을 구분하는 것으로 유추할 수 있다. 그렇다면 이것을 다른 값으로 바꾼다면 어떤 현상이 나타날 수 있을까? 그 이전에 로그인 과정에서 앞서 이야기한 Set-Cookie라는 Response Header가 확인되는지를 보자.
[그림 6] 로그인 성공 시 확인된 Set-Cookie 정보
ParosProxy에 저장된 요청과 응답 내용을 보니 Set-Cookie라는 헤더가 나타나는 것을 볼 수 있다. 그렇다면 이 Set-Cookie 값을 중간에 가로채서 다른 값으로 변경해버리면 클라이언트가 이후에 보내게 될 Cookie 값도 다른 값으로 보내지게 될 것이다. 정말 그런지 확인해 보자.
ParosProxy를 이용할 경우 Set-Cookie 값을 중간에 가로채어 조작하는 방법은 크게 두 가지가 있다. 우선 Trap 기능을 이용하는 것이다. Trap 기능은 다음과 같이 활성화할 수 있다. Trap request를 선택하게 되면 클라이언트에서 서버 측으로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이며 Trap response를 선택하게 되면 서버 측에서 클라이언트로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이다.
[그림 7] Trap response 설정
두 번째 방법은 Tools > Filter 메뉴에서 Detect and alert ’Set-cookie’ attempt in HTTP response for modification을 활성화 하는 것이다.
[그림 8] Set-cookie 시도 탐지 설정
두 번째 방법으로 할 경우 모든 응답 메시지를 가로채지 않고 Set-cookie 헤더가 나타났을 때만 가로채어 조작할 수 있도록 한다. 두 가지 중 어느 방법이든 가능하니 편한 방법을 쓰면 된다. 여기서는 Trap을 이용한 방법으로 기술하겠다.
우선 앞서 제시된 것과 같이 Trap Response 항목을 체크한다. Set-Cookie의 경우는 서버가 클라이언트에게 보내는 데이터를 조작하는 것이므로 Trap Response를 하는 것으로 충분하다.
Trap response를 셋팅한 상태에서 다시 로그인을 시도해본다. 요청에 대하여 응답을 계속 중간에 가로채어 보여줄텐데 Continue 버튼을 클릭하면 다음 단계로 넘어간다. 다음과 같이 Set-Cookie 화면이 나타날 때까지 넘어간다.
[그림 9] Trap 기능을 이용한 Set-Cookie 정보 변경 시도
여기서 Continue를 누르기 전에 Set-Cookie의 내용을 다음과 같이 조작한다.
[그림 10] Trap 기능을 이용한 Set-Cookie 정보 변경 시도
이제 Continue를 누른다. 그 전에 더 이상의 response를 중간에 가로챌 이유는 없으므로 Trap response 체크박스는 해제해도 좋다. 그 결과 다음과 같이 ahncoco 계정의 패스워드 정보를 입력하지도 않았고 알지도 못함에도 ahncoco로서 로그인 성공하였음을 알 수 있다.
[그림 11] 사용자 도용 성공 결과
이 예제에서는 이해를 돕게 하기 위하여 상황을 최대한 단순화시켰다. 하지만 s_id라는 ID 이름 대신 숫자로 표현된 값으로 사용자를 구분하는 경우도 실제로 구현된 사이트 중에 있다. 즉 hosik은 12341, ahncoco는 12342라고 표현되었다고 하자. 이 경우 Cookie 값을 12342로 변경하면 ahncoco로 로그인된다. 또한 이런 경우 주요 계정이 초기에 생성되었음을 감안하여 낮은 숫자로 시도함으로 종종 admin 계정과 같은 경우로 로그인 성공하는 경우도 있다.
③ Cookie Theft와 연계한 사용자 도용
Cookie Theft를 통해 Cookie 정보를 얻어내어야 하는 경우가 있다. 인증에 사용되는 Cookie 정보가 앞선 경우와는 달리 복잡하게 설정된 경우이다. 대표적인 경우는 아래와 같은 경우이다. 아래 정보를 보면 사용자ID, 해당 부서 등의 정보를 얻어내야 할텐데 앞서 논한 단순 사용자 도용과 같이 추측만으로 하기는 어려운 문제이다. 이 경우는 사용자의 Cookie를 얻어내는 방법 즉 Cookie Theft가 필요하다. 하나, 이 경우도 기억할 점이 있다면 Cookie 정보는 많지만 실제 로그인 정보를 유지하고 사용자 정보를 구분하는 핵심 Cookie 정보만 필요하다는 점이다. 그런 정보가 많지 않고 간단하게 구현되어 있다면 그것을 파악하면 좀 더 쉽게 작업을 할 수 있다.
| ASPSESSIONIDCARTBSDR=CCNGEOOABFJGIHHCJIIEPFBP; LoginInfo=Key=79%1683%1667%1668%1660%1677%16&EditorMode=1&HOST=coconut%2Eonnet21%2Ecom&SvcOrder=5%2CB05%2C0%2C0%2C10%2CB10%2C0%2C0%2C12%2CC02%2C0%2C0%2C14%2CC04%2C0%2C0%2C17%2CC08%2C1%2C1%2C11%2CC01%2C1%2C1%2C7%2CB07%2C1%2C1%2C8%2CB08%2C1%2C1%2C3%2CB03%2C1%2C1%2C2%2CB02%2C1%2C1%2C13%2CC03%2C1%2C1%2C4%2CB04%2C1%2C1%2C9%2CB09%2C1%2C1%2C1%2CB01%2C1%2C0%2C6%2CB06%2C1%2C0%2C&MailHost=mail&EmpID=54&UserID=hosik&PosName=+%B4%EB%B8%AE&ComName=%28%C1%D6%29%BE%C8%B7%A6%C4%DA%C4%DA%B3%D3&bbp=YldWc2IyNW5JUT09&DOMAIN=coconut%2Eonnet21%2Ecom&ComID=COCONUT&DeptName=%BA%B8%BE%C8%B1%E2%BC%FA%BF%AC%B1%B8%C6%C0&UType=N&UpperDepts=i%5FDeptId%3D26+OR+i%5FDeptId%3D22+OR+i%5FDeptId%3D0&fmode=1&Name=%C0%CC%BF%EB%C7%D0&DeptID=26&ID=hosik |
얻어낸 Cookie를 재사용하여 로그인할 수 있는 문제점, 공격 기법을 Cookie Replay라고 부른다.@