6. Session Hijacking(세션 관리 및 탈취)

Session 네트워크 시간에도 이 단어를 배운적이 있다. 연결을 계속 유지한다는 개념이다.

HTTP는 TCP 기반의 프로토콜임에도 Stateless 방식

(client 요청에 따른 server 응답이 완료되면 session이 끊어짐)이다.

하지만 사용자 편의 등의 이유로 연결을 일정 시간동안 유지시키는 쪽의 기능이 생겨났다.

이러한 Session은 인증(세션 토큰)을 기반으로 작동하고 쿠키가 이를 저장한다.

쿠키의 저장된 세션 토큰을 탈취 할 수 있다면,

탈취한 토큰으로 서버로 하여금 공격자를 사용자로 인식할 수 있게 만들 수 있다. 

 

0. Session management

  # Session Token
  세션을 인증하기 위한 정보
  인증에 관련된 정보는 서버와 클라이언트 양쪽에 저장되어야 함

  # WAS에서 지원하는 세션 토큰
    ASP : ASPSESSIONID
    JSP : JSESSIONID
    PHP : PHPSESSIONID
   

  세션 토큰 저장 방식 → Cookie
  일반적인 Session Management 절차

1. Session hijacking
  Step1. 공격자가 클라이언트와 서버간의 패킷 전송을 sniffing
           - 같은 네트워크의 상황을 만들어야 sniffing이 가능하다 

              ; switch - 목적지가 지정됨 : 특별한 방법을 사용해야 sniffing이 가능함

                           - GNS를 써서 가상머신 연동해야 가능
              ; hub     - 목적지가 지정되어 있지 않음 : 같은 네트워크에 있는 것 만으로 sniffing이 가능함

                           - 현재 VMware 상의 상황 

           - 같은 네크워크 상황으로 침투하기 위해 다양한 방법을 고안한다.

           - 혹은 내가 서버를 열어놓고 피해자가 오게끔 한다(reverse).
   Step2. sniffing을 통해 사용자의 쿠키에서 토큰을 탈취

   Step3. 공격자는 서버로 request 시 탈취한 세션 토큰을 이용해 로그인

 

2. Hub 환경 VMware 내의 Session Hijacking 실습

    Step1. 공격자에서 paros 및 wireshark 준비 후 client에서 server로 페이지 요청
    Step2. 공격자에 wireshark에서 client가 서버로 부터 받은 쿠키와 세션 토큰 확인

                Cookie: ASPSESSIONIDQCSCBAAC=CGJLCAACCJLPFCIDIHHAIJHP

 

    Step3. client는 서버 페이지에 로그인

    Step4. 공격자에서 서버 페이지에 접속 하면서 paros로 request를 잡아두고 패킷마다 탈취한 쿠키 값 입력

    Step5. client와 동일한 로그인이 공격자에서 접속 성공

 

     id / pw 정보도 sniffing으로  post로 요청하는 패킷에서 모두 얻을 수 있음

 

3. Switch 환경에서 Session Hijacking

 

VMware는 기본적으로 hub로 구성되어 있어 
공격자가 클라이언트와 서버의 통신 내용을 볼 수 있었다.
그러나 실제 환경에서 switch가 많이 사용되고 있음 (가격인하로 hub 대체)
이 구성을 확인해보려면 GNS3를 이용하여 VMware와 연동하여 switch로 토폴로지를 구성하여 확인한다.

GNS와 VMware 연동
  Step1. GNS3 토폴로지 구성 (switch와 두 대 PC, 한 대 Server)
  Step2. VMware 네트워크 인터페이스 추가 3개의 host-only 인터페이스 확보 DHCP 옵션 해제
  Step3. GNS3로 돌아가서 각각의 client, server, attacker의 configuration으로 네트워크 인터페이스 지정
  Step4. VMware에서 각각의 client, server, attacker의 NAT를 각각의 해당 네트워크 인터페이스로 지정
  Step5. GNS3에서 client, server, attacker를 switch와 연결하여 토폴로지완성 
             (이 과정에서 선이 연결이 안되는 경우는 재부팅하면 해결 됨)
   Step6. GNS3와 VMware 연동이 완료된 것을 확인하고 VMware에서 Ping Test 시도 성공

스위치에서는 Attacker에서 클라이언트와 서버간의 통신 확인 불가

arp spoofing을 통해 클라이언트가 스위치에 전달한 패킷을 서버에게 전달하기 전에 

공격자가 먼저 받고 다시 서버로 전달되게한다

arp -a 최근 통신한 ip주소들에 매칭되는 맥주소 확인하는 명령어
192.168.1.20  00-0c-29-d6-24-44
192.168.1.30  00-0c-29-87-08-6c

클라이언트에게 서버 192.168.1.20의 맥주소를 공격자의 맥주소로 인식하게 만든다.
스위치는 포트와 맥주소를 맵핑해서 저장하고 있기때문에 클라이언트만 속이면 
공격자의 맥주소로 패킷을 보내게 된다.

결론은 그렇다면 클라이언트에게 어떻게 서버의 IP와 MAC주소 중에 MAC주소만을 

공격자의 MAC주소로 인식할 수 있게 조작할 수 있을까?


[실습 1] Switch 환경에서 Session Hijacking을 시도하세요.

공격자에서 클라이언트에게 arp spoofing을 하도록 만드는 툴 이용
Step1. 클라이언트가 서버의 IP로 보낸 패킷을 공격자 MAC주소로 인식하게 만든다.
arpspoof -h
Version: 2.4
Usage: arpspoof [-i interface] [-t target] host
root@bt:~# 
root@bt:~# arpspoof -t 192.168.1.10 192.168.1.20

클라이언트에서 cmd로 arp -a로 확인해보면
Interface: 192.168.1.10 --- 0x2
  Internet Address      Physical Address      Type
  192.168.1.20          00-0c-29-87-08-6c     dynamic
  192.168.1.30          00-0c-29-87-08-6c     dynamic

Step2. 포워딩을 시켜줘서 클라이언트로부터 받은 패킷을 서버에게 넘겨준다.
root@bt:~# fragrouter -B1
fragrouter: base-1: normal IP forwarding

이걸 걸어줘야 공격자에게 온 패킷을 서버로 계속 넘겨주어 클라이언트가 웹페이지에 접속하는 것도 
자연스럽게 진행된다.

Step3. 클라이언트는 서버 웹페이지로 접속하고 로그인한다.

Step4. 공격자에서 wireshark로 클라이언트의 쿠키를 훔쳐낸다.
Cookie: ASPSESSIONIDQSTCQCSD=LJANKBLANCHLGINKHFKCBLIA

Step5. 훔친 쿠키를 가지고 paros로 request Trap을 걸고 
보내는 쿠키를 훔쳐낸 쿠키로 변조하여 요청하면 클라이언트의 로그인된 페이지를 획득


[실습 2] 탈취한 Session 값을 수동으로 변경하지 않고 자동으로 변경될 수 있게 하세요.

tools - Filter 를 걸어서
request header 체크 아래와 같이 필터링
 
Cookie:*
Cookie: ASPSESSIONIDQSTCQCSD=LJANKBLANCHLGINKHFKCBLIA


4. Session Token 저장방식
  - HTML 페이지에 저장하는 방식
     ; 특수한 목적을 제외하고 거의 사용하지 않는다. (우클릭 페이지 소스보기로 다 볼 수 있기 때문에)
     ; HTML의 Hidden field에 저장

  - URL Rewriting
     ; 거의 사용하지 않는다.

  - Cookie에 저장하는 방식
     ; Session Cookie(클라이언트 일반적), Persistant Cookie(서버측) 저장하는 위치에 따라

  - Javascript를 이용한 Cookie 확인
    javascript:document.cookie 구문을 웹주소창에 넣어주면
    Cookie 값을 확인 할 수 있다.