1. Cookie 개요
Cookie는 사용자가 방문한 웹 사이트에서 추후에 어떤 용도로든 사용하기 위해서 사용자의 하드디스크에 남기는 정보를 의미한다. 예를 들어 사용자가 특정 팝업창에 대해 "더 이상 띄우지 않음", "오늘은 띄우지 않음" 등과 같은 체크 박스를 선택할 경우 다음부터 해당 사이트에 방문할 때 더 이상 그런 팝업창이 나타나지 않게 되는데 이는 Cookie 정보가 사용자의 PC에 저장되어 있기 때문이다. 엄밀히 말하자면 이런 Cookie는 Persistent Cookie라고 불리우며 메모리 공간에 상주하여 브라우저 관련 프로세스가 실행되고 있을 때까지만 유효한 Cookie 정보도 있는데 이를 Non-Persistent Cookie 혹은 Session Cookie라고 부른다.
2. Cookie 종류
Cookie의 종류에는 Persistent Cookie와 Session Cookie(Non-Persistent Cookie)가 있다. 이 두 개를 비교하면 다음과 같다.
3. Cookie 동작 원리
클라이언트가 웹서버에 접속할 때 Cookie가 어떤 식으로 교환되는지 살펴보기로 하자.
우선 클라이언트가 해당 서버에 대한 Persistent Cookie를 저장하고 있다면 저장하고 있는 Cookie 정보가 만료되었는지 여부를 확인하여 만료되지 않았다면 해당 Cookie 정보를 보낸다. 이 정보는 Request Header에 포함되어 전달된다.
클라이언트는 해당 Cookie 정보를 받아들이거나 무시할 수 있지만 특별한 브라우저 설정을 하지 않았고 Set-Cookie가 규약을 만족한다면 받아들이는 것이 기본이다. 다음에 해당 웹서버로 클라이언트가 요청을 하게 될 경우 앞서 보냈던 쿠키 정보에 Set-Cookie에 의해 새로이 추가된 쿠키 정보를 포함하여 보낸다.
여기서 웹서버가 브라우저에 보내는 Set-Cookie를 좀 더 상세히 보자. Set-Cookie는 다음과 같은 정보가 포함될 수 있다.
브라우저에 전송된 Set-Cookie가 악의적인 경우에 대처하기 위해 브라우저는 다음과 같은 경우 쿠키 정보를 거부할 수 있다.
- Domain 값이 '.'으로 시작되지 않는 경우
- 요청한 호스트 정보와 Domain의 값이 무관한 경우
- 요청한 호스트가 FQDN(IP 주소 형태가 아님)의 형태를 가질 때 요청한 호스트의 FQDN에서 Domain 값을 제외한 나머지, 즉 호스트명이 '.'을 하나 이상 포함하는 경우
(예를 들면 다음과 같음)
청한 호스트의 FQDN이 www.coconut.co.kr인데 Domain 값이 .co.kr 혹은 .kr인 경우
4. Cookie 파일 저장 위치 및 구조
Cookie(엄밀히 Persistent Cookie) 파일이 저장되는 위치, 그리고 저장 방식은 웹 브라우저 종류와 버전에 따라 상이하다. 예를 들어 Netscape Navigator 4.x 버전은 User Preference 폴더에 cookies.txt라는 파일 하나로 저장하였으며 Opera 4.x 버전은 cookies4.dat라는 파일로서 Opera 디렉토리에 저장한다. 국내에서 가장 많은 유저가 사용하는 인터넷익스플로러의 경우는 도메인마다 파일 하나로서 저장한다. 또한 저장되는 위치는 Windows 버전에 따라 다를 수 있다. 따라서 Cookie 파일을 찾기 위해서는 '파일 찾기'등의 검색 툴을 이용하여 검색어로서 'Cookie'를 입력하여 로컬하드디스크를 확인해보는 것이 쉽다.
이중 윈도우에 저장된 인터넷익스플로러의 Cookie 파일의 예를 보자. 다음은 로컬하드디스크에저장된 hosik@google[1].txt의 내용을 메모장으로 열어 본 경우이다.
|
PREF |
여기서 PREF는 Cookie의 Name이며 , ID=e86917dffe2b57c6.. (생략) .. S=R4sPpGRTj7axz2nH 는 Cookie의 Value, google.com/는 Cookie가 사용되는 Domain과 Path를 의미하며 1536은 해당 Cookie가 Secure하지 않음을 의미한다. 이렇게 Cookie 파일 그 자체로서 내용을 분석하는 것은 까다로운 문제이다. IECookieView라는 툴을 이용하면 다음과 같이 저장된 Cookie 내용들을 쉽게 열람하고 분석할 수 있다.
Persistent Cookie의 경우에는 사용자의 하드디스크에 저장된다. 특히 PC방이나 전산실, 도서관 등과 같은 공용 PC 환경에 저장된 하드디스크에 저장된 Cookie 정보는 쉽게 얻어낼 수 있다. 앞서 언급한 IECookieView 등을 통하여 종종 사용자의 ID, 비밀번호를 얻어내는 그런 직접적인 시도가 아니더라도 사용자의 ID, 비밀번호가 암호화된 형태로 저장되어 있을 때 해당 Cookie 값을 그대로 복사해와서 ID, 비밀번호 인증 절차를 거치지 않고 로그인할 수 있다. 이 경우는 자동로그인을 활성화한 거의 모든 사이트의 경우 ID, 비밀번호와 같은 중요 인증 정보를 Persistent Cookie로서 저장하기에 발생하는 문제이다.
5.1.1 XSS, XST 등의 취약점을 이용
XSS는 Cross Site Scripting의 약자로 CSS로 표기되지 않는 이유는 Cascading Style Sheet와 그 약자가 동일하기 때문에 혼동이 될 수 있어서이다. XST는 HTTP 메소드 중 디버깅을 위한 용도의 TRACE라는 메소드를 이용하는 것으로 Cross Site Tracing으로 XSS에 비해 진보된 공격 기법이다. XSS를 통한 Cookie Theft는 Cookie 옵션을 이용하여 근본적인 차단 방법이 있기에 이런 방법을 구현한 사이트에 대해서는 XST 기법을 사용한다. XSS, XST를 이용하는 경우에는 브라우저 프로세스 실행 중에만 유지되는 Session Cookie와 같은 정보도 얻어낼 수 있다.
XSS 취약성은 클라이언트 레벨에서 의도치 않은 스크립트(자바스크립트)가 실행되도록 하는 것이다. XSS 취약성을 응용한 공격 형태를 몇 가지 제시하면 다음과 같다.
ㅈ- 게시판에 HTML 태그(<script> 등)를 포함하는 방법
- Flash의 ActionScript를 이용하는 방법
- 웹 서버 취약성을 이용하여 URL에 HTML 태그 추가
`` http://www.victim.com/<script>alert(document.cookie)</script>
- 웹 어플리케이션의 취약성을 이용하여 파라미터에 HTML 태그 추가
```http://www.victim.com/hole.asp?q=<script>alert(document.cookie)</script>
아래 그림은 XSS 취약성을 이용한 일례이다. 게시판에 악성 스크립트를 포함하여 사용자가 원하지 않는 대화상자가 계속하여 나타나도록 만든 것이다.
이번에는 XSS 취약성을 이용하여 사용자의 Cookie 정보를 얻어내려는 시도를 해보겠다. 다음과 같이 그림 파일을 하나 포함하여 마우스커서를 그림파일 위로 이동하면 get_cookie.php가 실행되어 Cookie 정보를 저장하도록 한다.
위의 예시에서는 게시판을 포함한 사이트와 공격을 위한 이미지 파일과 get_cookie.php 파일이 동일한 사이트인 192.168.152.20에 저장되고 있지만 실제 공격 시에는 공격을 위한 이미지 파일과 get_cookie.php는 공격자가 Cookie 정보를 저장하고자 하는 사이트에 웹 사이트를 구성하여 저장한다.
get_cookie.php의 내용은 유포시 공격에 사용될 위험이 있음으로 생략 하도록 하겠다. 어느 정도의 웹 프로그래밍 지식이 있다면 개별적으로 구현을 해 보는 것도 좋을 것 같다.
저자가 구현해 놓은 get_cookie.php파일 내용에는 사용자의 IP 주소, Cookie가 노출된 시간, 노출된 Cookie 정보를 getcook.txt 파일로서 저장한다. 이제 일반 사용자가 해당 게시물의 그림을 보는 순간 다음과 같은 해당 사용자의 Cookie 내용이 공격자가 만들어둔 사이트의 getcook.txt 파일로서 저장된다.
○ XST 취약성을 이용
XSS 취약성을 이용한 Cookie Theft는 매우 위협적이다. 이 방법을 근본적으로 차단할 수 있도록 하기 위한 메커니즘이 있는데 이는 다음달 연재에서 자세히 다루겠다. 이런 메커니즘이 적용된 Cookie의 경우에는 XSS 취약성으로 얻어낼 수 없다. 이 경우 사용하는 것이 TRACE 메소드를 이용한 XST(Cross Site Tracing)이다. 이 공격 기법에 대한 상세한 내용은 언급하지 않겠다.
5.1.2 스니핑 기법을 이용
Cookie는 패킷 스니핑을 통하여 요청에 포함된 Cookie 헤더 필드를 통해서도 얻어낼 수 있다. 유선랜 환경과 무선랜 환경의 경우로 나누어 알아 본다.
○ Wired LAN
다음은 Ethereal을 통하여 실제로 특정 사이트에 대한 접속 시 Cookie 정보를 얻어낸 화면이다.
패킷 스니핑까지 할 수 있는 환경이라면 아예 Cookie 대신 로그인 시 전송되는 ID, Password 정보를 얻는 것이 더 현명할 수도 있겠다고 판단할 수 있다. 맞는 말이지만 로그인 과정이 SSL 등으로 암호화하여 전송되어 ID, Password를 얻을 수 없는 경우에 얻어낸 Cookie 정보는 매우 도움이 된다. 물론 접속 이후에도 모든 통신 과정이 SSL로 암호화되어 이루어진다면 스니핑으로도 Cookie 정보는 얻어낼 수 없지만 보안 수준이 매우 높지 않은 대부분의 사이트(즉 금융권 등을 제외한 사이트)는 로그인 과정에 전달되는 ID, Password 정도만 SSL 암호화를 적용하고 있음을 기억하자. 물론 심지어는 그런 최소한의 암호화도 안하고 있는 사이트도 많다.
두 번째로 의문을 가질 수 있는 점은 패킷 스니핑이 그렇게 쉬운가 하는 점이다. 유선랜 환경에서는 허브 환경이라 사용자의 모든 트래픽을 복사하여 아무 포트에서나 쉽게 다른 사용자의 트래픽을 볼 수 있는 방법, 혹은 스위치 환경이나 스위치를 제어할 수 있어서 특정 포트를 mirroring 포트로 지정하여 보는 방법이 있을 수 있다. 물론 이것도 저것도 아니면 ARP Redirect 등과 같은 기법을 쓸 수도 있으나 이러한 방법들은 최소한 중요한 정보를 얻고자하는 네트워크 내에 공격자가 포함되어 있어야 한다.
○ Wireless LAN
무선랜 환경에서는 스니핑을 통해 중요한 정보를 얻는 것이 매우 쉬워졌다. 무선랜 환경에서 패킷의 송수신은 안테나를 통해 전파를 수신하여 모든 사람이 라디오를 청취하는 것과 같아서 주파수만 맞추면 누구나 그 패킷을 수신할 수 있다. 그리고 그 주파수란 몇 개 되지 않는 값으로 그것을 맞추는 일은 아주 쉽다. 이러한 공격 기법에 대한 대응책으로서 보안 의식이 있는 네트워크 관리자는 자사가 보유한 AP(Access Point) 장비에 WEP, WPA 등과 같은 암호화를 적용하기도 하지만 아직도 단지 MAC 주소 인증만으로 어느 정도의 보안 조치를 끝냈다고 생각하는 관리자는 너무도 많다.
다음 그림은 AiroPeek를 통한 스니핑 결과 화면이다.
5.2 Cookie 정보 활용
여기까지 HTTP Session으로 이용되는 Cookie 값들을 수집하는 방법등을 알아 보았다. 그러면 이러한 방법들을 이용하여 Cookie를 수집하는 이유는 무엇일까?
5.2.1 개인정보 유출
저자는 지금 이 글을 읽고 있는 여러분이 직접 개인이 가입된 웹 사이트에 가서 Cookie값을 확인 해 봤으면 한다
가입된 웹 사이트에 로그인을 한 후 아래 그림과 같이 주소입력 창에
javascript
여러분들은 어떻게 결과 값이 나타나고 있는가?
저자의 쿠키값에는 계정과 이름 그리고 메일주소가 설정되어 있어, 누군가가 이 정보를 가지고 가면 저자의 정보들을 획득 할 수 있을 것이다. 만일, 이 쿠키값에 위 정보외에 주민 번호, 주소, 전화번호, 핸드폰번호등이 있다고 가정하면 자기 자신의 모든 개인정보들이 나도 모르게 외부에 알려지게 된다.
5.3 사용자 도용(Cookie Spoofing)
매번 사용자가 로그인할 때마다 랜덤한 값으로 생성되는 일회용 토큰 형태의 Cookie 값을 이용한 인증을 하지 않는 사이트의 경우, 얻어낸 타 사용자의 Cookie 정보를 이용하여 다른 사용자로 로그인할 수 있다. Cookie를 위조하는 공격 기법이라고 하여 이를 Cookie Spoofing이라고 한다. Cookie Spoofing에는 도용하고자 하는 대상 사용자(희생자)의 Cookie 정보가 필요하지 않은 경우와 Cookie 정보가 필요한 경우가 있는데 전자와 후자를 각각 ‘단순 사용자 도용’, ‘Cookie Theft와 연계한 사용자 도용’으로 나누어 설명하도록 한다. 그 전에 잠시 ParosProxy 툴에 대해 알아보자.
5.3.1 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에서볼 수 있는 결과 화면이다. 다음과 같이 요청과 응답의 내용을 헤더를 포함하여 상세히 볼 수 있다.
5.3.2 단순 사용자 도용
이 장에서 공격 기법을 설명하기 위해 구현된 사이트는 다음과 같다. ID, Password 정보를 입력하면 로그인할 수 있는 사이트로 Cookie Spoofing을 이용한 사용자 도용을 설명하기 위해 임의로 구현한 사이트이다. 하지만 현재 실환경으로 운영되는 많은 사이트도 이런 문제점을 갖고 있음을 간과하지 말아야 한다.
위 사이트는 일반적인 로그인 페이지다. 로그인할 경우 다음과 같이 해당 회원에 대한 정보를 열람하는 페이지가 확인된다.
물론 ID, Password를 잘못 입력하면 다음과 같은 오류 화면이 나타나는 일반적인 로그인 페이지이다.
로그인한 이후 회원정보변경 페이지가 열릴 때의 요청을 ParosProxy를 통해 확인해 보면 아래와 같이 s_id라는 Cookie 값이 ‘coconut’으로 셋팅되었음을 알 수 있다.
이 Cookie 정보를 토대로 사용자의 인증 정보를 유지하며 또한 사용자가 coconut임을 구분하는 것으로 유추할 수 있다. 그렇다면 이것을 다른 값으로 바꾼다면 어떤 현상이 나타날 수 있을까? 그 이전에 로그인 과정에서 앞서 이야기한 Set-Cookie라는 Response Header가 확인되는지를 보자.
ParosProxy에 저장된 요청과 응답 내용을 보니 Set-Cookie라는 헤더가 나타나는 것을 볼 수 있다. 그렇다면 이 Set-Cookie 값을 중간에 가로채서 다른 값으로 변경해버리면 클라이언트가 이후에 보내게 될 Cookie 값도 다른 값으로 보내지게 될 것이다. 정말 그런지 확인해 보자.
ParosProxy를 이용할 경우 Set-Cookie 값을 중간에 가로채어 조작하는 방법은 크게 두 가지가 있다. 우선 Trap 기능을 이용하는 것이다. Trap 기능은 다음과 같이 활성화할 수 있다. Trap request를 선택하게 되면 클라이언트에서 서버 측으로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이며 Trap response를 선택하게 되면 서버 측에서 클라이언트로 보내지는 데이터를 중간에 가로채어 조작하도록 할 것이다.
두 번째 방법은 Tools > Filter 메뉴에서 Detect and alert ’Set-cookie’ attempt in HTTP response for modification을 활성화 하는 것이다.
두 번째 방법으로 할 경우 모든 응답 메시지를 가로채지 않고 Set-cookie 헤더가 나타났을 때만 가로채어 조작할 수 있도록 한다. 두 가지 중 어느 방법이든 가능하니 편한 방법을 쓰면 된다. 여기서는 Trap을 이용한 방법으로 기술하겠다.
우선 앞서 제시된 것과 같이 Trap Response 항목을 체크한다. Set-Cookie의 경우는 서버가 클라이언트에게 보내는 데이터를 조작하는 것이므로 Trap Response를 하는 것으로 충분하다.
Trap response를 셋팅한 상태에서 다시 로그인을 시도해본다. 요청에 대하여 응답을 계속 중간에 가로채어 보여줄텐데 Continue 버튼을 클릭하면 다음 단계로 넘어간다. 다음과 같이 Set-Cookie 화면이 나타날 때까지 넘어간다.
여기서 Continue를 누르기 전에 Set-Cookie의 내용을 다음과 같이 조작한다.
이제 Continue를 누른다. 그 전에 더 이상의 response를 중간에 가로챌 이유는 없으므로 Trap response 체크박스는 해제해도 좋다. 그 결과 다음과 같이 ahncoco 계정의 패스워드 정보를 입력하지도 않았고 알지도 못함에도 ahncoco로서 로그인 성공하였음을 알 수 있다.
이 예제에서는 이해를 돕게 하기 위하여 상황을 최대한 단순화시켰다. 하지만 s_id라는 ID 이름 대신 숫자로 표현된 값으로 사용자를 구분하는 경우도 실제로 구현된 사이트 중에 있다. 즉 hosik은 12341, ahncoco는 12342라고 표현되었다고 하자. 이 경우 Cookie 값을 12342로 변경하면 ahncoco로 로그인된다. 또한 이런 경우 주요 계정이 초기에 생성되었음을 감안하여 낮은 숫자로 시도함으로 종종 admin 계정과 같은 경우로 로그인 성공하는 경우도 있다.
5.3.3 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라고 부른다.
'보안 > 해킹 기법' 카테고리의 다른 글
| Apache 다중 확장자 업로드 취약점 (0) | 2012.05.01 |
|---|---|
| Triple DES (0) | 2010.08.11 |
| 웹해킹 - 패킷 변조 (0) | 2010.08.11 |
| [MS08-067] 공격 코드 (2) | 2010.08.11 |
| DrDOS (0) | 2010.08.11 |