starting point

ARP 스푸핑 실습 본문

해킹 보안 실습

ARP 스푸핑 실습

dundole 2020. 3. 7. 02:56

해당 실습은 개인 핫스팟을 이용한 제한된 환경에서 진행되었고,

해당 실습은 공부를 목적으로 진행했음을 알립니다.

 

 

ARP 프로토콜이란 LAN 상에서 데이터의 목적지의 IP주소만 알고 MAC주소를 알고 있을 때 목적지의 MAC주소를 획득할 때 사용되는 통신규약이다. 이 과정에서 발생하는 취약점을 이용하는 것이 ARP스푸핑이다.

 

우선 ARP 프로토콜의 동작과정을 알아보겠다.

A가 B의 MAC주소를 알아내는 과정이다.

 

[그림 1] ARP request

A가 보내는 ARP 패킷

opcode : request

Source MAC : A의 MAC 주소

Source IP : A의 IP 주소

Target MAC : 00:00:00:00:00:00

Target IP : B의 IP 주소

 

A는 위와 같은 ARP request 패킷을 브로드캐스트로 전송한다. LAN 상에 전달된 request 패킷의 Target IP와 일치하는 디바이스를 제외한 나머지 디바이스는 해당 패킷을 폐기한다

 

[그림 2] ARP reply

B가 보내는 ARP 패킷

opcode : reply

Source MAC : B의 MAC 주소

Source IP : B의 IP 주소

Target MAC : A의 MAC 주소

Target IP : A의 IP 주소

 

request 패킷의 Target IP에 해당하는 B는 위와 같은 패킷을 A에게 전송한다. reply 패킷을 받은 A는 전달받은 패킷의 Source MAC 주소를 보고 자신의 ARP 테이블을 갱신한다.

 

위와 같은 과정을 통해서 LAN 상에 각 디바이스들은 서로의 IP주소를 통해 MAC 주소를 주고 받는다. 문제점은 reply패킷에 대한 검증이 없는 것이다. reply 패킷을 항상 신뢰하기 때문에 악의적인 reply 패킷을 보낼 경우, reply 패킷을 받은 디바이스는 의심없이 자신의 ARP 테이블을 갱신하게 되고 이후 통신을 할 때 잘못된 디바이스로 데이터를 보내게 된다.

 

 

그렇다면 어떤 방식으로 ARP 스푸핑이 발생하는지 살펴보겠다.

 

[그림 3] ARP 테이블 초기 상태

[그림 3]과 같은 초기상태의 LAN이 있다. 주목할 것은 Router의 ARP 테이블과 Victim의 ARP 테이블이다.

 

[그림 4] Router의 ARP 테이블 감염

Attacker가 Router에게 보내는 reply 패킷

opcode : reply

Source MAC : Attacker의 MAC 주소

Source IP : Victim의 IP 주소

Target MAC : Router의 MAC 주소

Target IP : Router의 IP 주소

 

Attacker는 Router에게 위와 같은 reply패킷을 보내게 된다. reply 패킷을 받은 Router는 자신의 ARP 테이블을 갱신하게 된다. 지금 상태에서 만약 외부에서 Victim에게 데이터를 보낸다면 그 데이터는 Attacker에게 간다. 이 경우 Victim이 무수한 요청을 보내더라도 아무런 응답을 받을 수 없다.

 

[그림 5] Victim의 ARP 테이블 감염

Attacker가 Victim에게 보내는 reply 패킷

opcode : reply

Source MAC : Attacker의 MAC 주소

Source IP : Router의 IP 주소

Target MAC : Victim의 MAC 주소

Target IP : Victim의 IP 주소

 

다음으로는 위와 같은 reply 패킷을 Victim에게 보낸다. reply 패킷을 받은 Victim은 ARP 테이블을 갱신하게 된다. 이때 인터넷에 접속하게 될 경우, Victim의 요처은 Attacker에게 간다. 즉, 무수한 요청을 보내더라도 Attacker가 그 요청을 가로채게 되므로 Victim은 인터넷에 접속할 수 없게 된다. 하지만 당연히 Attacker는 공격사실을 숨기기 위해 서로의 패킷들을 중계해 준다.

 

위와 같은 과정을 일정한 주기로 반복해서 수행하게 된다. 그 이유는 각 디바이스는 라우터와 지속적인 ARP 패킷을 주고 받아 서로의 ARP테이블을 지속적으로 갱신하게 된다. 그렇기 때문에 그러한 갱신을 무시할 만큼의 변조된 패킷을 지속적으로 보냄으로써 ARP 테이블을 지속적으로 오염시키는 것이다. 

 

성공적으로 ARP 스푸핑이 이루어 졌을 경우, 중간에서 모든 피해자의 모든 패킷들을 볼 수 있게 되고 이는 피해자의 민감한 정보들을 공격자에게 넘겨주는 상황이 발생할 수 있다. 그렇다면 실제 실습을 통해 피해자는 어떤 피해를 입을 수 있고, 공격을 당하게 되면 어떤 현상이 일어나는지를 살펴보겠다.

 

 

공격자는 kali linux, 피해자는 windows 7으로 virtual box를 이용하여 구성하였다.

공격은 kali linux의 ettercap을 통하여 이루어 진다.

 

[그림 6] 피해자의 IP주소와 Router의 IP주소

피해자의 IP주소는 172.20.10.7, Router의 IP주소는 172.20.10.1이다. 

[그림 7] ettercap을 통해 확인한 IP주소와 MAC주소

ettercap을 통해 현재 LAN 상에 어떤 디바이스들이 연결되어 있는지 확인할 수 있다. ettercap은 이를 확인하기 위해서 브로드캐스트로 사용가능한 모든 IP주소를 대상으로 request패킷을 전송하게 된다. 피해자의 MAC주소는 08:00:27:f8:64:ac이고, Router의 MAC 주소는 4e:56:9d:25:c2:64이다.

[그림 8] 공격자의 IP주소와 MAC주소

공격자의 IP주소는 172.20.10.5이고, MAC주소는 08:00:27:1f:30:76이다. 

  피해자 라우터 공격자
IP 주소 172.20.10.7 172.20.10.1 172.20.10.5
MAC 주소 08:00:27:f8:64:ac 4e:56:9d:25:c2:64 08:00:27:1f:30:76

 

실제로 공격을 수행해 보겠다.

[그림 9] 피해자 PC에서 확인한 변조된 reply 패킷

ettecap을 통해 공격이 수행된 직후 피해자 PC에서 캡쳐된 ARP reply패킷들이다. 정상적인 ARP reply패킷이라면 request패킷과 reply패킷이 쌍을 이루는 것이 정상적이다. 하지만 [그림 9]는 비정상적으로 많은 reply패킷을 볼 수 있다. 

 

[그림 10] 피해자에게 도착한 reply 패킷

Sender MAC address는 공격자의 MAC주소이고, Sender IP address는 라우터의 IP주소이다. Target MAC address와 Target IP address는 피해자의 MAC, IP주소이다. 이를 통해 보내는 이의 MAC주소와 IP주소의 출처가 서로 다른 것을 확인할 수 있다. 피해자의 PC는 이러한 패킷을 받고 자신의 ARP테이블을 갱신하게 될 경우 자신의 ARP 테이블이 오염될 것이다. 그럼 실제로 ARP 테이블이 어떻게 변화했는지 살펴 보겠다.

[그림 11] 공격 이전 피해자 ARP 테이블
[그림 12] 공격 이후 피해자 ARP 테이블

공격이 진행된 이후 피해자의 ARP 테이블에서 라우터의 IP주소인 172.20.10.1의 MAC주소가 08:00:27:1f:30:76으로 공격자의 MAC주소로 설정된 것을 볼 수 있다. 이제부터 모든 통신은 공격자의 PC를 거쳐 가게 될 것이고, 공격자는 해당 데이터들을 모두 볼 수 있을 것이다.

 

실제로 민감정보가 노출되는 모습을 살펴보겠다.

[그림 13] 피해자의 로그인 패킷

위 패킷은 공격자의 PC를 통해 확인한 피해자가 로그인하기위해 보낸 HTTP요청이다. 피해자의 민감정보가 그대로 노출된 것을 확인할 수 있다.

 

이러한 공격이 이뤄지면 피해자의 PC에는 어떠한 현상이 발생하는 살펴보겠다.

우선, 인터넷환경이 느려지게 된다. 실습환경은 virtual box를 통해 구성되어 있기 때문에 공격이 발생하게 되면 인터넷 속도가 너무 느려져 접속 허용 시간을 초과하는 모습을 볼 수 있다. 실제로는 어느정도 인터넷 속도가 저하하는 모습을 목격할 수 있을 것이다.

 

다음은 반복적으로 들어오는 요청없는 reply패킷들이다. 피해자의 ARP테이블의 치료를 막기위해 반복적인 reply패킷이 캡쳐될 것이고 이러한 현상은 ARP 스푸핑 공격을 의심해 봐야 하는 상황이다. 

 

 

이러한 공격을 방어하기 위한 방법을 알아보겠다.

1. ARP 테이블의 주요한 정보들을 정적으로 설정해 놓는 것이다. 윈도우의 경우 arp -s [IP주소] [MAC주소]를 통해서 테이블의 정보를 정적으로 설정할 수 있다. 접근 권한 문제 발생 시 netsh interface ipv4 add neighbors "로컬 영역 연결" [IP주소] [MAC주소]를 통해서 설정가능하다.

[그림 14] 정적으로 설정된 ARP 테이블

피해자 PC의 ARP 테이블에서 라우터의 IP, MAC주소를 정적으로 저장했다. 이렇게 설정할 경우 reply패킷이 도착하더라고 ARP 테이블을 변경하지 않는다. 하지만 이렇게 설정될 경우 IP주소가 변경될 경우 수동으로 ARP 테이블을 수정해야하는 수고가 생기므로 완벽한 대응방안은 아니다.

 

2. ARP 스푸핑을 막는 기능이 있는 라우터를 사용하는 것이다. 하지만 이러한 공격은 유선뿐만 아니라 무선을 통해서도 가능하다. 즉, 공유기도 라우터의 일종이므로 공유기에 해당 기능이 없다면 공격의 위험성이 존재한다.

 

3. 주요 패킷들을 암호화하는 것이다. [그림 13]을 보면 피해자의 로그인 패킷을 통해 id, password를 알아낼 수 있었다. 그 이유는 http를 사용했기 때문이다. 이는 암호화가 되지 않은 패킷이다. 그래서 현재는 대부분의 사이트가 https를 사용한다. 이는 tls를 이용하여 암호화를 한다.

[그림 15] https패킷

위와 같이 https는 패킷의 내부를 볼 수 없게끔 암호화하였기 때문에 패킷이 오간다는 사실은 알 수 있지만 그 내부는 살펴볼 수 없게 된다. 그럼 패킷을 복호화하면 될 것이라 생각할 수 있다. tls를 이용한 암호화는 공개키와 비밀키를 이용한 통신이다. 비밀키는 서버가 가지고 공개키는 클라이언트가 가지게 된다. 공개키로 암호화된 정보는 비밀키로만 복호화가 가능하기 때문에 공격자가 공개키를 얻더라도 아무런 의미가 없게 된다.

 

 

현재는 대부분의 사이트가 HTTPS를 사용하여 이러한 ARP 스푸핑 공격에 대응하고 있다. 하지만 아직까지도 HTTP를 사용하는 사이트들은 분명히 존재하며 그러한 곳에는 아직도 ARP스푸핑의 위험이 존재한다. 이렇게 잘 알려진 공격에 대해서 대응하지 않는다면 다른 다양한 취약점들을 대비했다고 보기 어려울 것이다. 

 


이번 실습을 통해서 ARP 프로토콜의 동작과정과 ARP 패킷의 구조, ARP 스푸핑의 공격 과정, 공격을 통해 피해자에게 나타나는 현상, 피해자에게 나타날 수 있는 피해를 알 수 있었다. 아쉬운 점은 패킷을 조작하여 피해를 입히는 부분에 대한 공부는 부족했다. 보통 <iframe>태그를 이용한 공격이 많이 이루어 진다고 들었지만 이것을 실습해 보지는 못했다. 이후에 기회가 된다면 이런 공격은 어떻게 이루어지는지, 어떻게 대응할 수 있는지에 대해 알아보고 싶다.