이 프로젝트에는 WPA2에 대한 KRACK 공격의 영향을 받는 클라이언트 또는 액세스 포인트(AP)를 테스트하는 스크립트가 포함되어 있습니다. 이 공격에 대한 자세한 내용은 저희 웹사이트와 연구 논문을 참조하세요.

이 스크립트는 공격 스크립트가 아니라는 점을 기억하세요! 액세스 포인트나 클라이언트가 KRACK 공격의 영향을 받는지 테스트하려면 적절한 네트워크 자격 증명이 필요합니다.

2024년 12월: 7번째 테스트 ./krack-test-client.py --gtkinit의 버그가 수정되었습니다. 이 버그 수정 이전에는 이 테스트의 (출력이) 신뢰할 수 없다고 언급되었지만, 이제 새 지침을 따르면 출력을 신뢰할 수 있습니다. 즉, 이 테스트가 장치가 취약하다고 표시하면 실제로 취약할 가능성이 높습니다.

2021년 1월: 이 스크립트는 Python3와 호환되도록 업데이트되었으며, 최신 Linux 배포판을 더 잘 지원하도록 업데이트되었습니다. 이전 버전으로 되돌리려면 저장소를 클론한 후 git fetch --tags && git checkout v1을 실행하세요(그리고 git checkout research를 사용하여 최신 버전으로 다시 전환하세요).

사전 요구 사항

이 스크립트는 Kali Linux에서 테스트되었습니다. Kali에 필요한 의존성을 설치하려면 다음을 실행하세요:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

이제 수정된 hostapd 인스턴스를 컴파일하고 Python 가상 환경을 만듭니다. 이렇게 하면 호환되는 Python 라이브러리(krackattack/requirements.txt에 나열된 라이브러리)를 사용하게 됩니다:

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

그런 다음 최적의 결과를 위해 하드웨어 암호화를 비활성화하세요:

cd krackattack
sudo ./disable-hwcrypto.sh

필요한 경우 나중에 sudo ./reenable-hwcrypto.sh 스크립트를 사용하여 하드웨어 암호화를 다시 활성화할 수 있습니다. 하드웨어 암호화를 비활성화한 후에는 재부팅하는 것이 좋습니다. Kali Linux에서 Intel Dual Band Wireless-AC 7260 및 TP-Link TL-WN722N v1을 사용하여 스크립트를 테스트했습니다.

매번 사용하기 전에

스크립트를 사용하기 전에 매번 네트워크 관리자에서 Wi-Fi를 비활성화해야 합니다. 그런 다음 다음을 실행하세요:

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

이 작업을 마치면 터미널을 닫지 않는 한 스크립트를 여러 번 실행할 수 있습니다.

disable-hwcrypto.sh의 효과를 되돌리려면 /etc/modprobe.d/nohwcrypt.conf 파일을 삭제하세요.

클라이언트 테스트

먼저 hostapd/hostapd.conf를 수정하고 테스트를 실행하는 데 사용할 Wi-Fi 인터페이스를 지정하려면 interface= 줄을 편집하세요. 모든 테스트에서 스크립트가 실행되면 테스트 대상 장치가 비밀번호 abcdefgh를 사용하여 SSID testnetwork에 연결하도록 해야 합니다. hostapd/hostapd.conf를 수정하여 AP 설정을 변경할 수 있습니다. 모든 테스트에서 클라이언트는 Wi-Fi 네트워크에 연결한 후 DHCP를 사용하여 IP를 받아야 합니다. 일부 테스트는 클라이언트가 DHCP를 사용하여 IP를 요청한 후에만 시작되기 때문입니다!

이제 krackattacks/ 디렉토리에 있는 다음 테스트를 실행해야 합니다:

1. ./krack-test-client.py --replay-broadcast. 이 테스트는 클라이언트가 재전송된 브로드캐스트 프레임을 수락하는지 확인합니다. 클라이언트가 재전송된 브로드캐스트 프레임을 수락한다면 먼저 패치해야 합니다. 클라이언트를 패치하지 않으면 이 스크립트는 그룹 키가 재설치되고 있는지 여부를 판별할 수 없습니다(그러면 스크립트가 항상 그룹 키가 재설치되고 있다고 말할 것이기 때문입니다).

2. ./krack-test-client.py --group --gtkinit. 이 테스트는 클라이언트가 그룹 키 핸드셰이크에서 주어진 수신 시퀀스 카운터(RSC)로 그룹 키를 설치하는지 확인합니다. 이 취약점에 대한 자세한 내용은 후속 연구 논문의 6.4절을 참조하세요.

3. ./krack-test-client.py --group. 이 테스트는 클라이언트가 그룹 키 핸드셰이크에서 그룹 키를 재설치하는지 확인합니다. 즉, 클라이언트가 CVE-2017-13080에 취약한지 테스트합니다. 이 스크립트는 이미 사용된(재전송된) 패킷 번호(여기서 패킷 번호 = nonce = IV)를 사용하여 클라이언트에게 브로드캐스트 ARP 요청을 보내 그룹 키 재설치 여부를 테스트합니다. 클라이언트가 재전송된 브로드캐스트 프레임을 항상 수락하는 경우(--replay-broadcast 참고), 이 테스트는 그룹 키가 재설치되고 있다고 잘못 결론을 내릴 수 있습니다.

4. ./krack-test-client.py. 이 테스트는 암호화된 메시지 3을 클라이언트에게 반복적으로 전송하여 4-way 핸드셰이크에서 키 재설치 여부를 테스트합니다. 즉, CVE-2017-13077(영향이 가장 큰 취약점) 및 CVE-2017-13078을 테스트합니다. 이 스크립트는 클라이언트가 보내는 트래픽을 모니터링하여 페어와이즈 키가 재설치되고 있는지 확인합니다. 이 테스트는 효과적으로 두 가지 테스트를 수행합니다: 페어와이즈 키 재설치 여부와 그룹 키 재설치 여부입니다. 그룹 키 재설치 테스트가 시작되도록 클라이언트가 DHCP를 사용하여 IP를 요청하는지 확인하세요. 클라이언트가 충분한 유니캐스트 프레임을 보내도록 하려면 선택적으로 AP에 핑을 보낼 수 있습니다: ping 192.168.100.254.

5. ./krack-test-client.py --tptk. 암호화된 메시지 3을 보내기 전에 위조된 메시지 1이 주입된다는 점을 제외하면 테스트 4와 동일합니다. 일부 클라이언트(예: wpa_supplicant v2.6)는 재전송된 메시지 3을 보내기 전에 위조된 메시지 1이 주입될 때만 4-way 핸드셰이크의 페어와이즈 키 재설치에 취약하기 때문에 이 테스트 변형이 중요합니다.

추가 참고 사항:

• 가장 중요한 테스트는 ./krack-test-client로, 4-way 핸드셰이크에서 일반적인 키 재설치를 테스트합니다.

• 간섭이 적은 방에서 테스트를 수행하세요. 패킷 손실이 많으면 이 스크립트의 신뢰도가 떨어집니다!

• 선택적으로 네트워크 트래픽을 수동으로 검사하여 스크립트의 출력을 확인할 수 있습니다(일부 Wi-Fi NIC는 스크립트를 방해할 수 있습니다):

  • 모니터 모드의 추가 Wi-Fi NIC를 사용하여 스크립트(AP)가 올바른 패킷 번호(IV)로 프레임을 전송하는지 확인하세요. 특히 재전송된 브로드캐스트 프레임이 실제로 이미 사용된 패킷 번호(IV)로 전송되는지 확인하세요.

  • 모니터 모드의 추가 Wi-Fi NIC를 사용하여 클라이언트가 보낸 프레임의 IV를 모니터링함으로써 페어와이즈 키 재설치를 확인하세요.

  • 클라이언트에서 트래픽을 캡처하여 재전송된 브로드캐스트 ARP 요청이 수락되는지 여부를 확인하세요.

• 클라이언트가 여러 Wi-Fi 라디오/NIC를 사용할 수 있다면 여러 Wi-Fi NIC를 사용하여 테스트를 수행하세요.

• 더 많은 디버그 출력을 위해 --debug 매개변수를 추가할 수 있습니다.

• 인식되지 않는 모든 매개변수는 hostapd로 전달되므로 -dd -K 같은 것을 포함하여 hostapd가 모든 디버그 정보를 출력하게 할 수 있습니다.

Wi-Fi Alliance 테스트와의 대응

Wi-Fi Alliance는 저희 스크립트를 기반으로 맞춤형 취약점 탐지 도구를 만들었습니다. 이 글을 작성하는 시점에서 이 도구는 Wi-Fi Alliance 회원만 접근할 수 있습니다. 이 도구는 여러 가지 테스트를 지원하며, 이러한 테스트는 저희 스크립트의 기능과 다음과 같이 대응됩니다:

• 4.1.1 (EAPOL 메시지 3의 평문 재전송). 현재 이 테스트는 지원하지 않습니다. 이 테스트는 어차피 필요하지 않습니다. 테스트 대상 장치가 4.1.3 테스트를 통과하는지 확인하면 이 테스트도 통과할 것입니다.

• 4.1.2 (평문 EAPOL M3의 즉시 재전송). 현재 이 테스트는 지원하지 않습니다. 다시 말하지만, 테스트 대상 장치가 4.1.3 테스트를 통과하는지 확인하면 이 테스트도 통과할 것입니다.

• 4.1.3 (페어와이즈 키 재교환 핸드셰이크 중 암호화된 EAPOL M3의 즉시 재전송). 암호화된 EAPOL M3를 즉시가 아닌 주기적으로 보낸다는 점을 제외하면 ./krack-test-client.py에 해당합니다.

• 4.1.5 (STA가 임시 PTK 구성을 사용할 때 4-way 핸드셰이크에서 PTK 재설치, 동일한 ANonce). 이 테스트는 ./krack-test-client.py --tptk를 사용하여 실행하세요.

• 4.1.6 (STA가 임시 PTK 구성을 사용할 때 4-way 핸드셰이크에서 PTK 재설치, 임의의 ANonce). 이 테스트는 ./krack-test-client.py --tptk-rand를 사용하여 실행하세요.

• 4.2.1 (STA에서 그룹 키 핸드셰이크 취약점 테스트). 이 테스트는 ./krack-test-client.py --group을 사용하여 실행하세요.

• 4.3.1 (WNM 슬립 모드를 지원하는 STA에서 GTK 및 IGTK 재설치). 현재 이 테스트는 지원하지 않습니다(사실 Wi-Fi Alliance도 지원하지 않습니다!).

액세스 포인트 테스트: 취약한 FT 핸드셰이크(802.11r) 탐지

1. 네트워크에 연결하는 데 사용할 수 있는 wpa_supplicant 구성 파일을 만드세요. 기본 예는 다음과 같습니다:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

   여기서 "FT-PSK"를 사용한 점에 유의하세요. network.conf 또는 비슷한 이름으로 저장하세요. 자세한 내용은 wpa_supplicant.conf를 참조하세요.

2. 플랫폼의 wpa_supplicant를 사용하여 네트워크에 연결해 보세요. 다음과 같은 명령이 필요할 것입니다:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   이 작업이 실패하면 AP가 FT를 지원하지 않거나 1단계에서 잘못된 네트워크 구성 옵션을 제공한 것입니다. AP가 FT를 지원하지 않으면 이 취약점의 영향을 받지 않습니다.

3. 이 스크립트를 이전 wpa_supplicant 명령의 래퍼로 사용하세요:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   이렇게 하면 제공된 매개변수를 사용하여 wpa_supplicant 명령이 실행되고, 공격 테스트를 수행할 가상 모니터 인터페이스가 추가됩니다. 먼저 root가 된 다음 Python 가상 환경을 로드하는 것이 중요합니다(이 가상 환경을 만드는 방법은 위를 참조하세요).

4. wpa_cli를 사용하여 같은 네트워크의 다른 AP로 로밍하세요. 예:

   root@kitploit:~

    wpa_cli -i wlan0
    > status
    bssid=c4:e9:84:db:fb:7b
    ssid=testnet
    ...
    > scan_results 
    bssid / frequency / signal level / flags / ssid
    c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    ...
    > roam c4:e9:84:1d:a5:bc
    ...
   

   이 예에서는 testnet의 AP c4:e9:84:db:fb:7b에 연결되어 있었습니다(status 명령 참조). scan_results 명령은 이 네트워크에 MAC c4:e9:84:1d:a5:bc를 가진 두 번째 AP도 있음을 보여줍니다. 그런 다음 이 두 번째 AP로 로밍합니다.

5. AP와 클라이언트 간에 트래픽을 생성하세요. 예:

   root@kitploit:~

    arping -I wlan0 192.168.1.10
   

추가: 하드웨어 복호화

하드웨어 복호화가 비활성화되었는지 확인하려면 Wi-Fi NIC를 연결한 후 systool -vm ath9k_htc 또는 유사한 명령을 실행하여 nohwcript/swcrypto/hwcrypto 매개변수가 설정되었는지 확인하세요. ath9k_htc를 무선 네트워크 카드의 커널 모듈로 교체해야 합니다.

추가: 5GHz 미지원

5GHz 대역에서 장치를 테스트하는 것은 공식적으로 지원되지 않습니다.

그럼에도 불구하고 5GHz 채널에서 도구를 사용하려면 사용 중인 네트워크 카드가 5GHz 채널에서 프레임 주입을 허용해야 합니다. 불행히도 규제 제약으로 인해 항상 가능한 것은 아닙니다. 어떤 채널에서 프레임을 주입할 수 있는지 확인하려면 iw list를 실행하고 Frequencies에서 disabled, no IR, 레이더 탐지로 표시되지 않은 채널을 찾아보세요. 이러한 조건은 네트워크 카드, 현재 구성된 국가, 연결된 AP에 따라 달라질 수 있습니다. 자세한 내용은 예를 들어 Arch Linux 문서를 참조하세요.

Linux 커널은 일반 프레임 전송이 허용되더라도 프레임 주입을 허용하지 않을 수 있습니다. 그 이유는 ieee80211_monitor_start_xmit 함수에서 cfg80211_reg_can_beacon이 false를 반환하면 커널이 프레임 주입을 거부하기 때문입니다. 결과적으로 Linux는 실제로 허용됨에도 불구하고 프레임 주입을 거부할 수 있습니다. 올바른(또는 모든) 조건에서 cfg80211_reg_can_beacon이 true를 반환하도록 하면 이 버그를 방지할 수 있습니다. 따라서 cfg80211_reg_can_beacon이 항상 true를 반환하도록 Linux 드라이버를 패치해야 합니다. 예를 들어 packport driver 코드를 수동으로 패치하는 것입니다.

추가: 수동 테스트

hostap git 저장소를 클론하여 (보다 상세한) 테스트를 수동으로 수행할 수도 있습니다:

git clone git://w1.fi/srv/git/hostap.git

그리고 tests/cipher-and-key-mgmt-testing.txt의 지침을 따르세요.