2013년 12월 8일 일요일

ARP cache poisoning


ARP ( Address Resolution Protocol )
- IP의 주소 변환 프로토콜 ( 3계층 IP 주소를 통하여 2계층 MAC 주소를 알아내기 위한 프로토콜)


ARP의 문제점

인증 메커니즘의 부재
응답자가 보낸 MAC 주소가 진짜 응답자가 보낸 것 인지 중간에 공격자가 도청하여 변조를 한 것인지 진위 여부를 알 수 없다.

불필요한 트래픽 발생
ARP request 패킷은 목적지 MAC 주소가 ff:ff:ff:ff:ff:ff 로 되어 있다.
브로드캐스팅을 함으로서 불필요한 트래픽이 발생하게 된다.


 < ARP request Packet >





ARP cache poisoning

ARP cache poisoning 은 ARP 의 고질적인 문제점을 이용하여 공격하는 기법이다.
ARP Request 패킷이 브로드캐스팅을 한다는 점을 이용하여 공격자가 대신 응답을 하게 되면 
ARP cache table 이 공격자의 의도대로 변하게 되고 정상적인 응답인지 공격자에 의한 비정상적인 
응답인지 진위 여부도 파악하기 힘든 점 을 이용한다.



테스트 환경은 다음과 같이 구성하였다.




< HOST A> 


< Attacker >


< Gateway >

HOST A : IP = 192.168.1.10 / MAC = 00:0C:29:83:57:22
Attacker : IP = 192.168.1.20 / MAC = 00:0C:29:f2:48:f5
Gateway IP = 192.168.1.1 / MAC = 64:e5:99:82:78:24







< 정상적인 통신 경로 >

위 그림은 HOST A 가 외부와 통신 하기 위하여 Gateway를 통해 나갈 때의 트래픽 이동 경로 이다.





< HOST A - ARP cache table >

HOST A의 ARP cache table를 확인해 보면 게이트웨이의 IP와 MAC 주소가 정상적으로 매핑되어 있다.





1. ARP Spoofing을 통하여 ARP cache table 조작

root@bt:~#arpspoof -i <interface> -t <target> host

-i : 인터페이스가 복수개일경우 인터페이스 지정
-t : 타겟 지정

< HOST A - ARP cache table 조작 >

root@bt:~#arpspoof -t 192.168.1.10 192.168.1.1




위 명령을 실행하면 그림과 같이 외부로 송신되는 트래픽의 흐름이 
Attacker를 거쳐 게이트웨이로 나가게 된다.

하지만 HOST A의 테이블만 조작 한 상태이므로 
수신되는 패킷은 Attacker을 거쳐서 들어오지 않는다.

HOST A로 부터 송 수신 되는 패킷은 모두 Attacker을 거쳐가도록
경로를 조작하려면 게이트웨이 장비의 테이블도 조작하여야 한다.



 < Gateway - ARP cache table 조작 >

root@bt:~#arpspoof -t 192.168.1.1 192.168.1.10







위 두가지 절차를 정상적으로 수행하게 되면 HOST A 와 Gateway 사이 트래픽의 흐름이 위 그림과 같이 Attacker를 거치게 된다.

하지만 아직 정상적인 통신이 되지는 않는다. Attacker PC 에선 목적지가 자기 자신이 아닌 패킷을 Drop 시키기 때문이다.

HOST A와 Gateway의 테이블을 조작하여 패킷이 Attacker를 경유하도록 공격 하였다면 Attacker는 그 패킷을 정상적인 통신이 이루어지게 하기 위해 릴레이 해주어야 한다.





2. Packet Forwarding

Packet Forwarding 을 활성화 하려면 두 가지 방법이 있다.



- Kernel 지원 방식

Linux / Unix


/proc/sys/net/ipv4/ip_forward 파일의 내용을 보면 0 이란 값이 들어 있다. 이 값을 1로 수정 해주면 Packet Forwarding 기능이 활성화 된다.

root@bt:~# cat /proc/sys/net/ipv4/ip_forward
0

root@bt:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@bt:~# cat /proc/sys/net/ipv4/ip_forward
1



Windows









실행 - regedit
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\
IPEnableRouter = 기본 값 0 -> 1로 수정





- Application 사용

Linux / Unix


root@bt:~# fragroutr -B1
-B1 : 정상 IP 포워딩



 두 가지 방법 중 Kernel 지원 방식을 사용하게 되면 시스템이 라우터 처럼 동작하게 되므로 tracerouter 에 걸리게 된다. 

 그러므로 Application 사용을 권장한다.



공격 후 ARP cache table를 확인 해 보면 MAC 주소가 다음과 같이 공격자의 MAC 주소로 변경 되어 있다.





HOST A에서 google DNS로 ICMP request 패킷을 송신 하였다.
(Ping 8.8.8.8)


< Attacker PC 에서 패킷 캡쳐 >

위 스샷은 Attacker PC에서 패킷을 떠본 결과이다.

Request / reply 패킷이 모두 Attacker PC 에 잡히는 것으로 보아 송수신 되는 패킷이 

Attacker PC를 거쳐 송수신 된다는 것을 확인 할 수 있다.





ARP Spoofing 공격을 하게 되면 Attacker PC 에서는 ARP cache table의 변조를 유지 하기 위해 지속적으로 ARP reply 패킷을 발생시킨다.





Attacker PC 에서 공격을 중단 하게 되면 2쌍의(4개) ARP 패킷이 발생한다.


공격 중단시 갑자기 외부와 통신이 단절되면 의심을 살 수 있기 때문에 Attacker 는 HOST A , Gateway 장비 에게 자신의  IP와 MAC 주소가 담긴 ARP request를 전송 함으로서 ARP cache table에서 조작된 주소를 지운다.

이렇게 되면 HOST A는 다시 게이트웨이를 찾는 ARP request 를 발생시키게 되고
게이트웨이는 그에대한 응답을 해주게 되므로 테이블에는 정상적인 캐시 정보가 갱신된다.

이 절차가 아주 짧은 시간 내에 이루어 지므로 통신은 계속 원할하게 이루어 진다.



2013년 12월 3일 화요일

PPP (Point-to-Point Protocol)




- 점대점 프로토콜(1:1)

- 하나의 인터페이스로 하나의 장비만 통신 가능.

- 주로 WAN 구간에서 많이 사용 된다.

- PPP는 중계 장치를 거치지 않고 통신을 하는 방식이다. 즉, Hub & Switch 환경에서는 사용이 불가능 하다.

<사용이 가능한 예>



<사용이 불가능한 예>







PPP는 일반적으로 다음과 같이 몇가지 단계를 거쳐 통신이 가능한 상태가 된다.


1. 링크 비 활성화 단계


이 단계는 두 장비가 물리적으로 연결되어 있지 않을때의 상태이다. PPP에서 시작과 끝의 상태가 바로 이 상태이다. 물리적인 연결이 구성이 되면 다음 상태로 넘어간다.





2. 링크 수립 단계



이 단계에서는 물리적인 연결이 이루어진 상태이고 링크 제어 프로토콜 (Link Control Protocol,LCP)이 링크의 논리적인 연결을 위해 기본적인 설정들을 수행한다.

 두 장비중 한 장비는 먼저 LCP를 이용하여 서로간의 링크에 대한 설정 [요청] 메세지를 보내게 된다. 여기서 주의할 점은 양방향 통신이 가능해야 한다. 왜냐하면 이에대한 [요청] 메세지를 받게 된 장비는 [응답]을 위하여 ACK 메세지를 보내야 하는데 단방향 통신일 경우 한쪽으로만 전송이 이루어지기 때문에 [응답]을 할 수 없게 된다.

서로간의 요청-응답 쌍수를 정상적으로 수행하게 되면 링크는 개방이 되며 인증 단계로 넘어가게 된다.





3. 인증 단계

이 단계에선 링크는 개방이 된 상태이지만 서로간의 통신은 이루어지지 않는다. 인증 단계는 필수적인 단계는 아니다. 즉 필요할 경우 인증 설정을 할 수 있고 인증 설정을 하지 않을 경우 [2. 링크 수립 단계] 에서 [4. 링크 개방단계] 로 넘어가게 된다.

인증을 사용할 경우 인증 프로토콜인 PAP와 CHAP가 있는데 PAP의 경우 링크상에서 평문으로 전송되기 때문에 보안상 좋지 않다.












< PAP 사용 >

인증시 사용할 이름과 패스워드가 평문으로 그대로 노출 되어 있다.

username : R2
password : 1234



2013년 11월 27일 수요일

MTU / 패킷 재조립 - 2






< 1번 패킷 >

3계층 IPv4 Header 를 살펴보면 Flags -> More Fragments 필드가 Set 되어 있으면 이는 분할된 패킷임을 나타낸다.
Fragment offset 값이 0일 경우이는 분할된 패킷의 첫 번째 패킷임을 나타낸다.





< 1번 패킷 >


< 2번 패킷 (마지막 패킷) >


IPv4 헤더의 내용 중 Identification 필드의 값은 동일한 패킷임을 알려준다. [ 0x00b6 ]
(분할된 동일 패킷끼리는 동일한 값을 가지기 때문이다.)

분할된 패킷의 마지막 패킷은 IPv4 Header의 Flags -> More Fragments 필드가 Not Set 되어 있다.

수신 측에선 패킷이 모두 도착하면 Fragment offset 값이 낮은 순서대로 재조립 한다.








[출처] MTU / 패킷 재조립 - 2|작성자 육육

MTU / 패킷 재조립 - 1




MTU란 ?

Maximum Transmission Unit = 최대 전송 단위

즉 MTU란 하나의 패킷이 가질 수 있는 최대 크기를 말한다.

크기를 이렇게 나누어 놓은 이유는 데이터를 쪼개지 않고 하나의 커다란 덩어리로 전송을 하게 된다면
전송 과정 중 데이터에 손실을 입게 될 경우 그 데이터는 쓸모가 없어지기 때문이다.

하지만 데이터를 나누어서 전송을 한다면 손실된 부분만 다시 요청을 하여 그 부분만 다시 전송 받을 수 있으므로 신뢰성 있는 통신을 할 수 있다.


비슷한 예로 우리가 평소에 인도에서 흔히 볼 수 있는 보도블럭을 생각 해 보자.

만일 보도블럭이 나누어져 있지 않고 합쳐져 있다면 파손되었을 경우 전체를 교체해야 하지만
보도블럭이 나누어져 있으면 파손된 부분만 교체를 하면 되기 때문이다.



일단 패킷이 분할되는 크기를 보기 위하여 사진을 첨부하겠다.
< Source = 192.168.0.48 // Destination = 192.168.0.44 >

-l [n] = 전송할 byte 지정
-n [n] = count




Ping 전송시 패킷이 캡쳐된 부분의 패킷 길이를 보면 1514 byte 이다.
저 크기에서 Ethernet header 크기인 14 byte를 빼면 1500 byte가 나오는데, 이 값이 Ethernet 환경에서 기본 MTU 값이다.


근데 위의 스샷에서 Ping 전송시 -l 옵션을 주어 2000 byte를 전송 하였는데 왜 길이가 1514+562 
= 2076 byte 일까?

그 이유는 바로 패킷/프레임에 포장된 헤더 크기 때문이다.


우선 Ethernet 헤더부터 살펴 보겠다.


< Ethernet II Header >

1. Destination MAC address ( 6 byte ) = 송신지의 MAC 주소
2. Source MAC address ( 6 byte ) = 수신지의 MAC 주소
3. Type ( 2 byte ) = 상위 타입 ( 0x0800은 IP /// 0x0806은 ARP 등등...)

이더넷 헤더의 총 크기는 14 Byte 이다.



다음은 IPv4 헤더를 살펴 보겠다.




1. version ( 1 byte ) = IP 헤더에 사용된 IP 버전 정보 
2. Header length ( 1 byte ) = IP 헤더의 길이 
3. Differentiated Services Field ( 1 byte ) = 서비스 유형
4. Total Length ( 2 byte ) = IP 헤더 + 패킷에 포함된 데이터 크기
.
.
.
생략 ( IPv4 헤더를 따로 포스팅 할 예정...)

IPv4 헤더의 Header length 필드의 값이 IP 헤더의 길이를 나타낸다.
총 20 Byte 임을 알 수 있다.


첫번째 패킷에서의 데이터 크기는 1480 byte 임을 알 수 있다.
[ 총 크기(1514) - Ethernet Header(14) - IPv4 Header(20) = 1480 byte]



두번째 패킷도 Ethernet header 크기는 같다. 
하지만 다음 계층의 헤더 정보가 다르므로 한번 살펴보겠다.



[ 총 크기(562) - Ethernet Header(14) - IPv4 Header(20) = 528 byte]
데이터 크기가 528 byte 라는 것을 알 수 있다.

첫번째 패킷의 1480 byte + 두번째 패킷의 528 byte = 2008 byte ???
2008 byte가 나오는 이유는 ICMP 헤더 크기 때문이다.





ICMP 헤더의 크기는 총 8 byte 이므로 ICMP 헤더 크기를 빼주면 데이터 크기가 2000 byte 임을 
알 수 있다.



[출처] MTU / 패킷 재조립 - 1|작성자 육육

TCP 4 way handshake





네 방향 핸드셰이크란? 

TCP 기반의 통신은 맨 처음 데이터를 송/수신 하기위해 세 방향 핸드셰이크 절차를 수행한다.
송/수신 이전에 세션을 확립하는 절차이다.

네 방향 핸드셰이크는 세션을 종료하기 위해 수행하는 절차이다.



< 3 way handshake >



세 방향 핸드셰이크 과정에서는 SYN/ACK 플래그가 사용되었다. 

SYN = Synchronization
ACK = Acknowledgment




< 4 way handshake >


하지만 네 방향 핸드셰이크 과정에서는 FIN/ACK 플래그를 사용하게 된다. 

FIN = Finish
ACK = Acknowledgment



= = = = = = = = = = = = = = = = = = = =



1.  Client - > Server 연결 종료 요청






클라이언트는 [클라이언트 -> 서버] 방향으로 연결 종료를 위해 
TCP 제어 플래그에 FIN/ACK를 설정한 패킷을 전송 한다.

데이터 전송? = X
데이터 수신? = O

이 상태를 FIN_WAIT-1 상태 라고 한다.



= = = = = = = = = = = = = = = = = = = =



2. Server -> Client 확인 응답 
Server - > Client 연결 종료 요청



< Server -> Client 확인 응답 >





< Server -> Client 연결 종료 요청 >


클라이언트로 부터 연결 요청을 받은 서버는 
확인 응답으로 ACK 플래그를 설정하여 전송을 하게 되고


서버는 클라이언트로 보낼 데이터가 더이상 남아 있지 않으면 
서버->클라이언트 방향의 세션 종료를 요청하는 플래그가 설정된 패킷을 전송한다.

데이터 송신 = X
데이터 수신 = O

이 상태를 FIN_WAIT-2 라고 한다.





4가지 절차를 모두 수행하게 되면 클라이언트는
아직 도착하지 않은 느린 데이터를 위해 일정 시간 동안 
연결 종료를 하지 않고 포트를 개방 한 상태로 남아있게 된다.

이 상태를 TIME_WAIT 이라 한다.







[출처] TCP - 4 way handshake|작성자 육육