출처: Gilbert Lee ARP spoofing
CAM 테이블
-
L2 스위치는 CAM(Content Addressable Memory) Table 정보를 가지고 있다.
MAC Address Table 이라고도 함. -
CAM 테이블: Mac주소(Key)와 Port번호(Value)의 매칭 정보를 가지고 있다.
또한 여기서의 Port는 스위치의 물려있는 물리적인 포트 그 자체이다.
L2스위치는 Source Mac을 가지고 학습을 한다. 그리고 Destination Mac을 가지고 스위칭 한다.
1) 상황 1 (BB:BB:BB -> AA:AA:AA)
처음에 BB:BB:BB에서 온 2번 포트는 CAM 테이블에 집어넣는다. 그러나 AA:AA:AA가 어떤 포트인지 모르기 때문에 이거는 브로드 캐스트 한다.(플러딩)
2) 상황 2 (AA:AA:AA -> BB:BB:BB)
위의 상황1과 마찬가지로 AA:AA:AA가 포트번호 1번이라는 것이 CAM 테이블에 추가된다. 그 다음 BB:BB:BB는 CAM 테이블에 있기에 유니캐스트 한다.
- 라우터와 반대로 L2 스위치는 처음 세팅 후 조정할게 딱히 없다.
- 무선환경에서는 L2스위치역할을 공유기가 한다. 즉 공유기가 라우터와 L2스위치 역할을 동시에 한다.
ARP 테이블
통신하는 모든 개체들은 ARP 테이블을 가지고 있다.
- ARP 테이블은 IP(Key)와 Mac주소(Value)를 갖는다.
Promiscuous Mode
-
Promiscuous Mode: 모든 패킷을 그냥 받아들임
나한테 오지도 않는 패킷도 보이는 것은 아님! 결국 나한테 오는것중에 선별해서 받아들일 거냐의 문제임
-
Non Promiscuous Mode: NIC가 패킷을 선별적으로 받아들임
목적지 맥주소를 봄: 나 자신 or 브로드 캐스트?
1) 나 자신의 Mac주소
2) 브로드캐스트 맥주소
3) 멀티캐스트 맥주소
패킷캡처링(스니핑)을 할때는 Promiscuous Mode로 전환이 필요하다.
와이어 샤크에서 Promiscuous Mode를 켜야한다.
ARP 프로토콜
ARP 프로토콜은 IP주소를 아는 상황에서 MAC 주소를 물어보기 위해 사용된다.
1) Who has 192.168.10.1? (ARP_REQ): BB:BB:BB -> FF:FF:FF
2) I am 192.168.10.1 (ARP_REP): AA:AA:AA -> BB:BB:BB
3) I am 192.168.10.1 (ARP_REP, 공격패킷): CC:CC:CC -> BB:BB:BB
감염상태가 된다.
중요 구현시 REP가 아니라 REQ로 어택을 해야한다. 어쨌든 ARP 패킷은 전달이 되고, ARP 스택으로 반드시 올리기 위해서는 REQ로 보내야한다.
ARP 리다이렉션
Stand-By 하고 있는 라우터(DD:DD:DD)에게 Active하라고 하고 AA:AA:AA는 Stand-By로 바뀐다.
이러면 DD:DD:DD는 브로드캐스트로 "내가 게이트웨이야!"하고 각자의 ARP 테이블이 다시 업데이트 된다. (ARP 리다이렉트)
IP Packet 흐름도
Source IP주소, Destination IP 주소는 원래 패킷 그대로 가면 된다.
그러나 Source Mac주소, Destination Mac 주소를 수정해 주어야 한다.
중요: Relay Packet을 쏠때 Source Mac을 Attacker의 MAC으로 해야한다.(Sender MAC X)
- Q: Source Mac을 Sender의 Mac주소로 했을때 응답 패킷은 과연 Sender(BB:BB:BB)에게 다시 올까?
- A: 아니다. Attacker인 CC:CC:CC에게 간다. 왜냐하면 CAM테이블이 이상해지기 때문이다.
BB:BB:BB : PORT2가 BB:BB:BB : PORT3으로 바뀐것이다.
(만약 Sender가 그 사이에 패킷하나라도 보내면 CAM 테이블이 다시 BB:BB:BB : PORT2로 바뀐다)
언제 ARP 테이블이 Recover 되는가?
1) Sender의 ARP REQ (브로드 캐스트)
우리는 Target이 보내는 ARP REP는 알수 없다. 하지만 Sender가 보내는 ARP REQ(브로드 캐스트)를 보고 Recover될 것이라는 것을 예측할 수 있다.
2) Target의 ARP REQ (브로드 캐스트)
Target에서 브로드캐스트로 ARP REQ를 보내는 경우도 있다. 이런경우에도 Sender가 이 ARP REQ를 보고 Recover 한다. 그러나 이 역시 브로드 캐스트이기에 나도 볼 수 있다.
3) Sender가 ARP REQ를 유니캐스트로 보내는 경우
캐시가 만료되기 직전(브로드 캐스트 보내기 전)에 보내는 ARP REQ는 유니캐스트이다. "너 IP 주소 이거 맞지? AA:AA:AA야?" 라고 물어본다.
즉 브로드캐스트 이전에 유니캐스트로 먼저 물어본다.
그러나 Attacker입장에서는 상관없다. 왜냐하면 이미 감염이 된 상태이기에 결국 그 유니캐스트도 나한테 온다.
4) Target이 ARP REQ를 유니캐스트로 보내는 경우
이것이 문제가 된다. 이 시점을 Attacker입장에서는 알 수 없다. 따라서 Target 도 속여야 한다.
즉 ARP 스푸핑 Flow가 2개가 되어야 한다. (Sender, Target)
ARP 스푸핑 용어 정리
| 용어 | 의미 |
|---|---|
| Attacker | ARP 스푸핑을 시도하는 호스트 |
| Sender | ARP 스푸핑의 패킷 전송자 |
| Target | ARP 스푸핑의 패킷 수신자 |
| ARP Spooging Flow | Sender > Attacker > Target의 패킷 흐름 단위 |
| Original IP Packet | Sender > Target의 IP 패킷 |
| Spoofed IP Packet | Sender > Attacker의 IP 패킷 |
| Relay IP Packet | Attacker > Target의 IP 패킷 |
| ARP infect | Attacker가 Sender를 속이는 행위 |
| ARP recover | Sender의 감염이 원상복귀되는 현상 |
Attacker는 Sender에서 Target으로 가는 IP 패킷을 본다.
Attacker는 Target이 아니라 Sender를 속인다.
- Original IP Packet: Sender에서 Target으로 가는 패킷(Sender -> Target)
- Spoofed IP Packet: Attacker가 탈취한 패킷(Sender -> Attacker)
- Relay IP Packet: Attacker가 탈취한 것을 Target에게 보내는 패킷(Attacker -> Target)
감염은 ARP 프로토콜을 통해 한다. ARP infect도 구현하고, ARP recover도 구현해야 ARP 스푸핑이 제대로 동작한다.
Attacker가 해야할일
1) 계속 감염시켜야 함
Sender의 ARP 테이블의 감염은 다른 ARP 프로토콜에 의해 다시 풀린다.(Recover)
따라서 Attacker는 Sender에게 ARP infect 패킷을 주기적, 혹은 비주기적으로 보내서 감염 시켜야 한다.
2) target에게 relay 해줘야함
Attacker는 Sender로 부터 Spoofed IP Packet을 수신하면 Relay IP Packet을 보내야한다.
ARP 스푸핑 방어법
1) HOST Level
가. Static ARP Table 설정
매우 불편해진다...
나. 백신
ARP 공격 탐지해서(ARP 테이블 갑자기 변경) 사용자에게 알려준다.
2) L2 Level
제대로 방지하기 위해서는 L2 스위치에서 방지하는 모듈이 들어가야한다.
국내 PC방에는 이것이 도입되어있다.
