WPS ER모드의 취약성

WPS는 PBC, PIN, ER, 이렇게 총 세가지 모드로 동작할 수 있는데, 이 중에 ER모드는 EAP와 UPNP로 동작할 수 있다. 그런데, EAP로 동작하는 경우, 무선클라이언트가 항상 AP의 WPS세션을 개시한다는 점이 요즘 문제가 되고 있다 [1]. 게다가 AP PIN의 첫 네자리가 맞을 경우 EAP를 통해 AP가 다르게 응답함으로서 해킹을 위해 시도해야할 횟수를 줄일 수 있다는 점도 문제이다. 

WPS 스펙에 의하면 가장 널리 사용되는 8자리 PIN를 만들기 위해서는 첫 7자리를 결정한후 이 숫자들을 체크섬함수에 넣고 나온 결과를 마지막 자리에 넣는다. 따라서 전체 가능한 경우의 수는 10^7 = 10,000,000이 된다. 하지만 EAP상으로 첫 네자리를 확인하는 것이 가능하기때문에 실제로 해킹에 필요한 전체 경우의 수는 10^4 + 10^3 = 11,000으로 줄어들게 된다. 만일 락다운기능(잘못된 PIN으로 시도했을 경우 AP가 일정시간동안 락다운)이 비활성화 되어 있고 매 30초마다 시도가 가능하다고 가정하면 평균 11,000 * 0.5 분 / 2 = 이틀, 그리고 최대 11,000 * 0.5 분 = 나흘 만에 해킹이 가능하다는 결론이 나온다.

그리고, 브로드컴 장비의 경우, lockdown기능이 기본설정으로 비활성화되어 있고, 이를 활성화시키더라도 lockdown period의 기본값이 300 초 = 5 분으로 설정되어 있다. 결국, 이 기능이 활성화되어 있을 경우, 해킹하는데 평균 11,000 * 5 분 / 2 = 27,500 분 = 458 시간 = 약 19 일이 걸리게 된다. 이 경우, 비록 lockdown 기능이 비활성화된 경우보다 10배의 시간이 걸리지만, 일반사용자가 AP PIN을 거의 바꿀일이 없거나 바꿀수 없도록 hardcode되어 있거나, 아니면 아예 AP PIN이 뭔지도 모르는 경우가 대부분이라는 사실을 생각하면 결코 긴 시간이 아니다.

이미 Wi-Fi Alliance에서는 이를 막기위한 토론을 진행중에 있는데, (1) an exponential lockout, (2) a “permanent” lockout after a certain number of failed attempts, (3) a requirement that the user positively act to enable static AP PINs for a time-limited period 등의 옵션을 고려중에 있다. 커스터머들도 그 옵션이 들어간 새로운 WPS 2.x 스펙이 나오기 전까지 ER모드를 일시적으로 Disable 시켜줄 것을 요청하고 있기도 하다.

by 유나아빠 | 2012/01/11 03:38 | Embedded System | 트랙백 | 덧글(0)

PMIPv6

RG를 설계하는 우리 사업부에 요즘 갑자기 상업용 라우터 기능을 넣어달라는 주문이 들어오고 있다. 사실 이 기능을 다 넣게 되면 RG가 아니라 Small Business Gateway(SBG)가 되는 셈인데, 그 기능 중의 하나가 Proxy Mobile IPv6 (PMIPv6)이다. PMIPv6은 기존의 Mobile IP와 달리 모바일 노드(MN)는 Mobility Management에 참여하지 않고 오직 Access Network의 LMA(Local Mobility Anchor)와 MAG(Mobile Access Gateway)으로만 이를 구현하는 기술이다. 예를 들어, 802.11에 PMIPv6를 적용하면 MAG는 AP(혹은 WLC)상에서 그리고 LMA는 ISG에서 구현되어야 한다. 현재까지 출시된 제품에서는 아직까지 IOS상으로만 구현되어 있지만 조만간에 다른 부서에서 공식적인 리눅스 포팅이 끝나는 대로 우리 RG 플랫폼에서 테스트를 시작할 예정이다.

PMIPv6에서는 LMA와 MAG사이에 IPv6터널을 사용한다. 리눅스에서 터널은 세가지 방법으로 구현된다.
(1) IPIP Tunnel : 가장 간단한 형태의 터널로서 오버헤드가 적지만 IPv4에서만 동작하고 라우팅 프로토콜 사용에 제한이 있어서 현재는 거의 사용되지 않고 있다.
(2) GRE (Generic Routing Encapsulation) 터널 : Cisco가 개발했으며 가장 널리 사용되는 사실상의 표준 터널로서 IPv4와 IPv6 over IPv4를 지원한다.
(3) SIT (Simple Internet Transition) 터널 : IPv4로 단절된 IPv6 네트워크들을 연결하기 위해 개발된 터널로서 IPv6 over IPv4를 지원한다.

다른 한편으로 PMIPv6을 더욱 잘 이해하기 위해 OAI PMIPv6 오픈소스코드를 포팅해달라는 요청이 있어서 결국 하게 되었는데 이 과정에서 알게된 이 코드의 특징은 다음과 같다.

(1) 오리지널 코드에서는 Cisco Aironet 1100을 AP로 사용하였지만, 우리 테스트베드에서는 MAG에 AP기능을 포함시켰다. AP는 MAG에게 MN의 연결상태를 syslog를 이용해 보고하고, MAG은 ingress interface를 통해 들어오는 syslog 패킷을 캡춰해서 MN의 연결상태에 대한 정보를 얻은 후 라우팅 설정및 정보를 LMA에 보고한다. 그런데, 여기서 발생하는 문제들중의 하나는 MN이 다른 AP로 옮길때 항상 disassociation message를 보내지는 않는다는 점이다. 임시변통으로 일단 hostapd에서 inactive timeout을 1초로 설정하여 이를 해결하였다. 또 다른 문제는 MAG과 AP가 한 device에 구현되었으므로 syslog 메세지를 다른 방법으로 처리해야하는 점이다. 처음에 ingress inteface를 모두 loopback interface로 바꾸었었는데 그러다보니 라우팅이 제대로 되지 않는 점을 발견하고 디버깅하였다.

(2) handover과정에서 기존세션의 유지를 위해서는 MN의 라우팅 설정을 그대로 유지하는 것이 중요하다. 오리지널코드에서는 모든 AP의 SSID와 무선 인터페이스 MAC address를 동일하게 설정하도록 되어 있지만 우리 테스트베드의 경우 공간적 제약때문에 이와 같은 설정은 불가능하다. 결국 SSID와 MAC address는 다르게 설정하고 IPv6 link address만 동일하게 설정하여 같은 효과를 얻을 수 있었다.

이 코드는 실험용 코드이기 때문에 상업용으로 사용할만큼 완성도가 높지 않으며 그로 인해 핸드오프시 delay가 상당하다.

by 유나아빠 | 2011/10/14 02:42 | Embedded System | 트랙백 | 덧글(2)

IEEE802.11r과 hostapd/wpa_supplicant

이번에 한 커스터머가 시제품을 주문하면서 요구한 항목들 중의 하나가 IEEE802.11r (Fast BSS Transition;FT)이었다. 그런데, 내가 최근 몇년동안 11r을 지원하지 않는 브로드컴 코드만 건드리다보니 11r이 어떻게 동작하는지 확인해본적이 없었다. 게다가 그동안 오픈소스 쪽으로 감을 많이 잃어버린 것 같아서 오랜만에 Atheros 라우터 보드들을 꺼내서 hostapd와 wpa_supplicant를 새로 컴파일하고 11r 모드로 테스트해보기로 하였다.

(1) 먼저 hostapd와 wpa_supplicant를 새로 컴파일해야 한다. 이 때, 기본설정에서는 CONFIG_IEEE80211R 옵션이 코멘트 처리가 되어 있는데 이를 제거해서 802.11r 옵션을 활성화시켜주어야 한다. 만일 이 옵션이 없이 생성되면 FT-PSK를 인식하지 못하는 에러를 낸다.

(2) 라우터 보드에서 hostapdwpa_supplicant의 config 파일을 설정한다. 내가 사용한 config 파일의 내용은 다음과 같다.

interface=wlan0
driver=nl80211
ssid=test-11r
hw_mode=g
channel=11
ieee80211n=1
ht_capab=[HT20]
wpa=2
wpa_key_mgmt=FT-PSK
wpa_pairwise=CCMP TKIP
rsn_pairwise=CCMP TKIP
wpa_passphrase=12345678
wpa_group_rekey=3600
auth_algs=1
nas_identifier=test1      # (test2 in the 2nd AP)
mobility_domain=a1b2
r0_key_lifetime=10000
r1_key_holder=000102030405       # (000102030406 in the 2nd AP)
reassociation_deadline=1000
pmk_r1_push=1
r0kh=00:A0:C9:29:3C:68 test1 000102030405060708090a0b0c0d0e0f       # (MAC addr of the radio in the 1st AP)
r0kh=00:11:22:33:55:00 test2 00112233445566778899aabbccddeeff        # (MAC addr of the radio in the 2nd AP)
r1kh=00:A0:C9:29:3C:68 00:01:02:03:04:05 000102030405060708090a0b0c0d0e0f
r1kh=00:11:22:33:55:00 00:01:02:03:04:06 00112233445566778899aabbccddeeff


ctrl_interface=/var/run/wpa_supplicant-wlan0
network={
        scan_ssid=1
        ssid="test-11r"
        key_mgmt=FT-PSK
        proto=RSN
        psk="12345678"
}


참고: Windows 계열의 OS에서는 802.11r을 지원하지 않기 때문에 위와 같이 설정된 AP의 encryption 모드를 제대로 판독하지 못한다. (가끔은 엉뚱하게도 WEP으로 인식하는 경우도 있다. 당연히 association이 불가능하다.) 따라서 리눅스 계열의 클라이언트에서 wpa_supplicant를 함께 사용하는 것이 필수적이다.

(3) 설정이 끝난후 실행을 시키면 다음과 같은 메세지를 볼수있다.

~ # iw wlan0 scan
BSS 00:03:7f:13:03:3f (on wlan0)
        TSF: 12134856 usec (0d, 00:00:12)
        freq: 2462
        beacon interval: 100
        capability: ESS Privacy ShortSlotTime (0x0411)
        signal: -41.00 dBm
        last seen: 2050 ms ago
        Information elements from Probe Response frame:
        SSID: test-11r
        Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
        DS Parameter set: channel 11
        ERP: <no flags>
        Extended supported rates: 24.0 36.0 48.0 54.0
        RSN:     * Version: 1
                 * Group cipher: TKIP
                 * Pairwise ciphers: CCMP TKIP
                 * Authentication suites: FT/PSK
                 * Capabilities: 16-PTKSA-RC (0x000c)
        HT capabilities:
(skipped...)

 

~ # hostapd ./hostapd.conf -dd
(skipped...)
mgmt::auth
authentication: STA=00:0c:42:66:48:b7 auth_alg=0 auth_transaction=1 status_code=0 wep=0
  New STA
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.11: authentication OK (open system)
wlan0: STA 00:0c:42:66:48:b7 MLME: MLME-AUTHENTICATE.indication(00:0c:42:66:48:b7, OPEN_SYSTEM)
wlan0: STA 00:0c:42:66:48:b7 MLME: MLME-DELETEKEYS.request(00:0c:42:66:48:b7)
authentication reply: STA=00:0c:42:66:48:b7 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
mgmt::auth cb
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.11: authenticated
mgmt::assoc_req
association request: STA=00:0c:42:66:48:b7 capab_info=0x431 listen_interval=10
WMM IE - hexdump(len=7): 00 50 f2 02 00 01 00
Validating WMM IE: OUI 00:50:f2  OUI type 2  OUI sub-type 0  version 1  QoS info 0x0
  new AID 1
HT: STA 00:0c:42:66:48:b7 HT Capabilities Info: 0x11ce
update_sta_ht STA 00:0c:42:66:48:b7 - no greenfield, num of non-gf stations 1
hostapd_ht_operation_update current operation mode=0x0
hostapd_ht_operation_update new operation mode=0x7 changes=2
nl80211: Set beacon (beacon_set=1)
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.11: association OK (aid 1)
mgmt::assoc_resp cb
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.11: associated (aid 1)
wlan0: STA 00:0c:42:66:48:b7 MLME: MLME-ASSOCIATE.indication(00:0c:42:66:48:b7)
wlan0: STA 00:0c:42:66:48:b7 MLME: MLME-DELETEKEYS.request(00:0c:42:66:48:b7)
wpa_driver_nl80211_set_key: ifindex=5 alg=0 addr=0x87430 key_idx=0 set_tx=1 seq_len=0 key_len=0 addr=00:0c:42:66:48:b7
wlan0: STA 00:0c:42:66:48:b7 WPA: event 1 notification
wpa_driver_nl80211_set_key: ifindex=5 alg=0 addr=0x87430 key_idx=0 set_tx=1 seq_len=0 key_len=0 addr=00:0c:42:66:48:b7
wlan0: STA 00:0c:42:66:48:b7 WPA: start authentication
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state INITIALIZE
wpa_driver_nl80211_set_key: ifindex=5 alg=0 addr=0x87430 key_idx=0 set_tx=1 seq_len=0 key_len=0 addr=00:0c:42:66:48:b7
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.1X: unauthorizing port
WPA: 00:0c:42:66:48:b7 WPA_PTK_GROUP entering state IDLE
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state AUTHENTICATION
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state AUTHENTICATION2
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state INITPSK
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKSTART
wlan0: STA 00:0c:42:66:48:b7 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=3 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
nl80211: Event message available
nl80211: Ignored unknown event (cmd=19)
IEEE 802.1X: 00:0c:42:66:48:b7 TX status - version=2 type=3 length=95 - ack=1
wlan0: STA 00:0c:42:66:48:b7 WPA: EAPOL-Key timeout
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKSTART
wlan0: STA 00:0c:42:66:48:b7 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=3 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:0c:42:66:48:b7 TX status - version=2 type=3 length=95 - ack=1
wlan0: STA 00:0c:42:66:48:b7 WPA: EAPOL-Key timeout
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKSTART
wlan0: STA 00:0c:42:66:48:b7 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=3 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:0c:42:66:48:b7 TX status - version=2 type=3 length=95 - ack=1
wlan0: STA 00:0c:42:66:48:b7 WPA: EAPOL-Key timeout
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKSTART
wlan0: STA 00:0c:42:66:48:b7 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=3 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:0c:42:66:48:b7 TX status - version=2 type=3 length=95 - ack=1
IEEE 802.1X: 246 bytes from 00:0c:42:66:48:b7
   IEEE 802.1X: version=1 type=3 length=242
FT: PMKR1Name from Supplicant - hexdump(len=16): fb da 48 31 57 84 3a d1 de 40 21 b2 69 36 e4 cc
wlan0: STA 00:0c:42:66:48:b7 WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKCALCNEGOTIATING
FT: PMK-R0 - hexdump(len=32): [REMOVED]
FT: PMKR0Name - hexdump(len=16): c8 19 cc 4e 1b 15 b6 01 f8 9a 44 e0 7b 97 d4 c5
FT: PMK-R1 - hexdump(len=32): [REMOVED]
FT: PMKR1Name - hexdump(len=16): fb da 48 31 57 84 3a d1 de 40 21 b2 69 36 e4 cc
FT: PTK - hexdump(len=48): [REMOVED]
FT: PTKName - hexdump(len=16): 46 0d 3a 2d 3e ef 98 3c e9 3b 73 27 53 fc 21 3e
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKCALCNEGOTIATING2
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKINITNEGOTIATING
wlan0: STA 00:0c:42:66:48:b7 WPA: sending 3/4 msg of 4-Way Handshake
FT: RSN IE before modification - hexdump(len=26): 30 18 01 00 00 0f ac 02 02 00 00 0f ac 04 00 0f ac 02 01 00 00 0f ac 04 0c0
FT: RSN IE after modification (PMKID inserted) - hexdump(len=44): 30 2a 01 00 00 0f ac 02 02 00 00 0f ac 04 00 0f ac 02 01 0c
WPA: Send EAPOL(version=3 secure=1 mic=1 ack=1 install=1 pairwise=8 kde_len=205 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=216): [REMOVED] IEEE 802.1X: 00:0c:42:66:48:b7 TX status - version=2 type=3 length=311 - ack=1 IEEE 802.1X: 99 bytes from 00:0c:42:66:48:b7
   IEEE 802.1X: version=1 type=3 length=95
wlan0: STA 00:0c:42:66:48:b7 WPA: received EAPOL-Key frame (4/4 Pairwise)
WPA: 00:0c:42:66:48:b7 WPA_PTK entering state PTKINITDONE
wpa_driver_nl80211_set_key: ifindex=5 alg=3 addr=0x87430 key_idx=0 set_tx=1 seq_len=0 key_len=16 addr=00:0c:42:66:48:b7
AP-STA-CONNECTED 00:0c:42:66:48:b7
wlan0: STA 00:0c:42:66:48:b7 IEEE 802.1X: authorizing port
wlan0: STA 00:0c:42:66:48:b7 RADIUS: starting accounting session 00053895-00000000
wlan0: STA 00:0c:42:66:48:b7 WPA: pairwise key handshake completed (RSN)
FT: Deriving and pushing PMK-R1 keys to R1KHs for STA 00:0c:42:66:48:b7
FT: R1KH-ID 00:01:02:03:04:06
FT: PMK-R1 - hexdump(len=32): [REMOVED]
FT: PMKR1Name - hexdump(len=16): 91 3f 19 52 69 a0 08 e1 0e 6b 80 00 a4 26 17 33
FT: R1KH-ID 00:01:02:03:04:05
FT: PMK-R1 - hexdump(len=32): [REMOVED]
FT: PMKR1Name - hexdump(len=16): fb da 48 31 57 84 3a d1 de 40 21 b2 69 36 e4 cc

by 유나아빠 | 2011/08/24 02:29 | Embedded System | 트랙백 | 덧글(6)

WPS와 MAC 주소 필터링

한 ISP부터 MAC 주소 필터링이 켜진 상태에서도 무선클라이언트가 WPS로 무선라우터와 연결이 가능하게 하는 기능을 넣어달라는 요청을 받았다. 하지만 필터링 리스트에 이미 WPS 클라이언트의 MAC 주소가 입력되어지 있지 않다면 Authentication 단계에서 더이상 진행되지 않기 때문에 정상적인 방법으로는 가능하지 않다. 따라서, WPS세션동안만 일시적으로 필터링을 멈추게 하거나 아니면 무선드라이버 코드를 고쳐서 WPS클라이언트를 받도록 하는 방법이 있는데, 두 방법 모두 보안문제 혹은 구현의 복잡성 등 여러가지 문제점들을 가지고 있다. 그러던 와중에 이번에 새로 나온 Wi-Fi Alliance의 WPS 2.0 Test Plan을 보니 테스트항목 4.2.7에 MAC 필터링이 켜진 상태에서도 올바른 PIN으로 접속을 시도하는 무선클라이언트를 받도록 하는 요구조건이 추가되었다는 것을 발견하였다. 지금 사용중인 SW버젼에서는 아직 WPS 1.0만 지원하고 있지만 올해 말쯤에 나올 벤더의 SW패키지에는 WPS 2.0기능이 추가될 예정이다.

by 유나아빠 | 2011/07/15 02:55 | Embedded System | 트랙백 | 덧글(4)

WiFi Alliance Certification과 TKIP/WEP

WiFi Alliance에서는 TKIP과 WEP를 폐기할 계획을 가지고 단계별로 이를 시행하고 있다[1]. Security Roadmap에 의하면 지금 현재 Phase 2에 있으며 (2011년 초부터 Phase 3이 시행될 예정이었지만 현재 보류중에 있다) TKIP 혹은 WEP를 802.11n모드에서 사용하는 것을 금하고 있다. 그리고, Phase 3이 시행되면 WPA-Personal/Enterprise를 TKIP-only로 사용하는 것이 금지된다. 그리고, Phase 5/6에서는 모든 TKIP(TKIP+AES도 금지)과 WEP 사용이 전면 금지된다. 하지만 제조사나 사업자 입장에서는 구형 무선랜카드를 사용하는 사용자들을 고려하지 않을 수 없으므로 아직까지는 TKIP과 WEP를 아무런 제한없이 사용할 수 있도록 요구하고 있는 상황이다.

by 유나아빠 | 2011/06/14 02:18 | Embedded System | 트랙백 | 덧글(0)

◀ 이전 페이지 다음 페이지 ▶