vanhoefm/fragattacksWi-Fi 클라이언트와 액세스 포인트를 위한 자동화된 취약성 테스터로, 프레임 주입, 혼합 모드 테스트, 패킷 캡처 분석을 통해 FragAttacks 단편화/집성 결함을 탐지합니다.
이 저장소에는 FragAttacks 도구가 포함되어 있습니다. 이 도구는 Wi-Fi 클라이언트와 액세스 포인트에서 fragmentation 및 aggregation 공격을 테스트할 수 있습니다. 이러한 취약점은 모든 보호된 Wi-Fi 네트워크에 영향을 미칩니다. 이러한 취약점에 대한 자세한 내용은 fragattacks.com을 참조하세요.
다음과 같은 추가 리소스를 이용할 수 있습니다:
도구에 대한 2020년 8월 11일 이후의 업데이트에 대한 자세한 개요는 변경 로그를 참조하세요. 이 변경 로그에는 FragAttacks 도구가 기반으로 하는 hostap 버전에 대한 정보도 포함되어 있습니다.
WPA2와 WPA3는 CCMP 및 GCMP 암호화 암호가 동일하므로 공격은 두 방식에 동일하게 적용됩니다. 이전 WPA 네트워크는 기본적으로 TKIP를 암호화에 사용하며, TKIP에 대한 공격의 적용 가능성은 논문과 웹사이트에서 논의됩니다. Wi-Fi가 처음 만들어진 이후로 취약했다는 것을 보여주기 위해 논문과 웹사이트는 WEP에 대한 공격의 적용 가능성도 간략히 논의합니다.
특정 무선 네트워크 카드만 지원됩니다. 일부 네트워크 카드는 주입된 프레임의 시퀀스 번호나 프래그먼트 번호를 덮어쓰거나 서로 다른 우선순위의 프레임을 재정렬할 수 있으며, 이로 인해 테스트 도구가 방해를 받을 수 있기 때문입니다(예: 도구가 실제로는 취약한데도 안전하다고 판단할 수 있음). 다음 네트워크 카드가 제대로 작동하는 것을 확인했습니다:
마지막 두 열의 의미는 다음과 같습니다:
혼합 모드: 네트워크 카드를 권장되는 혼합 모드에서 사용할 수 있는지 여부.
주입 모드: 네트워크 카드를 주입 모드에서 프레임을 주입하는 두 번째 인터페이스로 사용할 수 있는지 여부.
예 는 해당 모드에서 카드가 추가 설정 없이 바로 작동함을 의미합니다. 패치된 드라이버/펌웨어 는 해당 카드가 패치된 드라이버 및/또는 펌웨어와 함께 사용할 때 호환된다는 뜻입니다. 아니요 는 해당 모드를 네트워크 카드가 지원하지 않음을 의미합니다. 테스트 도구는 혼합 모드로 사용할 것을 권장합니다.
USB 장치는 가상 머신 안에서 사용할 수 있으며 수정된 드라이버 및/또는 펌웨어를 가상 머신에 설치할 수 있습니다. 다만 가상 머신을 사용하면 네트워크 카드의 안정성이 떨어질 수 있음을 발견했습니다. 수정된 드라이버/펌웨어를 네이티브로 설치할 수 없다면 라이브 USB 이미지 사용을 권장합니다.
위 네트워크 카드에 대한 제 경험은 여기에서 확인할 수 있습니다. 요약하면:
혼합 모드의 AWUS036ACM은 최신 드라이버에서 안정적으로 보이며 제가 권장하는 제품입니다. 더 저렴하지만 거의 동일한 장치로는 MT7612U 칩셋을 사용하는 제품이 있습니다. 자세한 내용은 여기를 참조하세요.
이전에는 혼합 모드에서 Technoethical N150 HGA를 권장했습니다. 이 동글은 TP-Link TL-WN722N v1.x와 동일하며 패치된 드라이버와 펌웨어를 사용해야 합니다. 가장 많이 테스트된 동글 중 하나이지만 구하기 어렵습니다. 그래서 지금은 AWUS036ACM을 권장합니다.
Intel 3160 및 8265는 지원되며 광범위하게 테스트되었습니다. 가끔 펌웨어가 충돌하지만 재부팅하면 네트워크 카드를 다시 사용할 수 있습니다. Intel AX200은 테스트 도구와 호환되지 않습니다.
WN111v2는 광범위하게 테스트하지는 않았지만 잘 작동하는 것 같습니다.
AWUS036ACH용 드라이버는 Linux 커널에 포함되어 있지 않으며 별도 드라이버를 설치해야 합니다. Kali에서는 패키지 관리자를 통해 이 드라이버를 설치할 수 있습니다. 이 카드는 광범위하게 테스트되지 않았습니다.
위 네트워크 카드 중 하나를 구할 수 없다면 작동할 가능성이 높은 대체 네트워크 카드를 검색할 수 있습니다. 명시적으로 지원되지 않는 네트워크 카드를 사용하는 경우, 사용 전에 먼저 주입 테스트를 실행하고, 알려진 취약 구현을 대상으로 도구를 실행하여 도구가 제대로 작동하는지 확인하는 것을 강력히 권장합니다.
테스트 도구는 커널 5.8을 사용하는 Ubuntu 20.04에서 테스트되었습니다. 다른 Linux 배포판을 사용하는 경우, 5.12 이하의 커널 버전만 지원된다는 점에 유의하세요.
Ubuntu 20.04를 사용하는 경우 먼저 다음과 같이 커널 5.8을 설치해야 합니다. 기존 커널은 계속 설치된 상태로 유지되며 기본적으로 계속 사용됩니다:
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
이제 Ubuntu를 재부팅하고 부팅 중 Shift 키를 누른 채로 "Advanced options for Ubuntu"를 선택한 다음, "Ubuntu, with Linux 5.8.0-63-generic"을 선택하여 커널 5.8로 시작하세요. GRUB 설정을 편집하여 Ubuntu가 기본적으로 이 커널 버전을 사용하도록 할 수 있습니다. 이제 실행 중인 이 커널에서 다음 지침을 계속 진행하세요.
필요한 의존성을 설치합니다:
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc
이제 이 저장소를 클론하고 도구를 빌드한 다음 가상 python3 환경을 구성합니다:
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
위 지침은 한 번만 실행하면 됩니다. git을 사용해 새 코드를 가져온 후에는 ./build.sh와 ./pysetup.sh를 다시 실행해야 합니다.
패치된 드라이버는 다음 명령으로 설치합니다:
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
이 명령은 Linux가 지원하는 대부분의 네트워크 카드용 드라이버를 컴파일합니다. 제가 명시적으로 테스트한 네트워크 카드용 드라이버만 컴파일하려면 make defconfig-experiments를 대신 사용하세요. 다음과 같은 경고가 표시될 수 있습니다:
make defconfig-wifi를 실행할 때 -Wyacc 및 -Wformat-overflow 관련 경고가 표시될 수 있습니다. 드라이버가 성공적으로 컴파일되면 이러한 경고는 무시해도 됩니다... needs unknown symbol ..를 포함하는 여러 경고. /lib/modules/*/updates/ 디렉터리를 포함하지 않고 컴파일된 드라이버가 작동한다면 이러한 경고는 무시해도 됩니다.SSL error와 sign-file 명령을 포함하는 반복 경고. 이는 커널 모듈의 디지털 서명이 실패했음을 의미합니다. 보통 무시해도 됩니다.cat /sys/module/mac80211/parameters/fragattack_version를 실행하여 수정된 드라이버가 설치되었는지 확인할 수 있습니다. 이 파일이 존재하면 수정된 드라이버가 성공적으로 설치된 것입니다.이제 패치된 ath9k_htc 펌웨어를 설치합니다:
cd research/ath9k-firmware/
./install.sh
# Now reboot
./install.sh 스크립트는 ath9k_htc 펌웨어 이미지가 /lib/firmware/ath9k_htc 디렉터리에 있다고 가정합니다. 시스템에서 이 경로가 다르다면 htc_7010.fw와 htc_9271.fw를 적절한 디렉터리에 직접 복사해야 합니다.
패치된 드라이버와 펌웨어를 설치한 후에는 Wi-Fi 동글을 분리하고 시스템을 재부팅해야 합니다. Linux 커널이 업데이트되거나 패치된 드라이버가 업데이트되면 위 지침을 다시 실행해야 합니다.
장치가 기본적으로 바로 작동하더라도 수정된 드라이버를 설치할 것을 권장합니다. 커널 및 드라이버 코드에 예상치 못한 회귀가 없는지 보장할 수 있기 때문입니다.
수정된 드라이버/펌웨어를 네이티브로 설치할 수 없는 경우, 수정된 드라이버/펌웨어와 테스트 도구가 포함된 **라이브 USB 이미지**를 다운로드할 수 있습니다. 또는 USB 네트워크 카드와 함께 가상 머신을 사용할 수도 있지만, 가상 머신을 사용하는 것은 실제로 덜 안정적이라는 것을 발견했습니다.
테스트 도구를 사용할 때마다 먼저 루트 권한으로 가상 python 환경을 로드해야 합니다. 다음 명령으로 수행할 수 있습니다:
cd research
sudo su
source venv/bin/activate
이제 네트워크 관리자에서 Wi-Fi를 비활성화하여 테스트 도구를 방해하지 않도록 해야 합니다. 또한 다른 네트워크 서비스가 나가는 트래픽을 유발하지 않는지 확인하세요. ./droptraffic.sh를 실행해 iptables로 트래픽을 차단하면 이를 보장할 수 있습니다(재부팅하면 되돌릴 수 있습니다). 선택적으로 sudo airmon-ng check를 실행하여 무선 네트워크 카드를 사용 중이고 도구를 방해할 수 있는 다른 프로세스가 있는지 확인할 수 있습니다.
테스트 도구는 클라이언트와 AP를 모두 테스트할 수 있습니다:
AP 테스트: research/client.conf를 편집하여 테스트할 AP를 구성합니다. 이는 표준 wpa_supplicant 구성 파일이며, 지원되는 모든 옵션에 대한 개요는 hostap 문서를 참조하세요.
클라이언트 테스트: --ap 매개변수(아래 참조)를 사용하여 테스트 도구를 실행해야 합니다. 그러면 도구가 이름이 testnetwork이고 비밀번호가 abcdefgh인 AP를 생성합니다. 테스트하려는 클라이언트로 이 네트워크에 연결하세요. 기본적으로 클라이언트는 DHCP를 사용하여 IP를 요청해야 합니다. 생성된 AP의 속성(예: 생성 채널)을 편집하려면 research/hostapd.conf를 수정할 수 있습니다.
이 모드에는 무선 네트워크 카드 하나만 필요하지만 일반적으로 패치된 드라이버 및/또는 펌웨어가 필요합니다. 패치된 드라이버/펌웨어 설치 방법은 패치된 드라이버를, 호환되는 네트워크 카드는 지원되는 네트워크 카드를 참조하세요. 이 모드에서 테스트 도구를 다음 명령으로 실행합니다:
./fragattack.py wlan0 [--ap] $COMMAND
$COMMAND의 가능한 값은 취약점 테스트 및 확장 취약점 테스트에 나열되어 있습니다.
이 모드의 장점 중 하나는 절전 상태에 들어갈 수 있는 클라이언트를 테스트할 때 비교적 잘 작동한다는 것입니다. 그렇지만 가능하면 테스트 중인 클라이언트의 절전 기능을 비활성화하는 것이 좋습니다. 절전 모드 처리를 참조하세요.
이 모드에는 두 개의 무선 네트워크 카드가 필요합니다. 하나는 AP 또는 클라이언트 역할을 하고 다른 하나는 프레임을 주입하는 데 사용됩니다. 장점은 패치된 드라이버 없이도 이 모드가 작동할 수 있다는 것입니다. 이 모드에서 테스트 도구를 다음 명령으로 실행합니다:
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
여기서 wlan0 인터페이스는 합법적인 클라이언트 또는 AP 역할을 하고, wlan1은 프레임을 주입하는 데 사용됩니다. wlan0에는 Linux에서 일반적인 클라이언트 또는 AP 모드를 지원하는 카드를 사용할 수 있습니다. wlan1에는 지원되는 네트워크 카드에 따라 주입 모드를 지원하는 카드를 사용해야 합니다.
이 모드에서 클라이언트를 테스트할 때 주입된 프레임이 클라이언트가 절전 상태일 때 전송될 수 있습니다. 그러면 공격이 실패하므로 클라이언트가 절전 상태에 들어가지 않도록 해야 합니다.
이 모드는 실험적이며 연구 목적으로만 사용됩니다. 자세한 내용은 hwsim 모드 세부 정보를 참조하세요.
인터페이스 모드에서 설명한 대로 테스트 도구를 실행하고 $COMMAND를 아래 표의 명령 중 하나로 바꾸면 장치를 테스트할 수 있습니다. 클라이언트가 DHCP를 사용하여 IP를 요청한다고 가정합니다(그렇지 않은 경우 고정 IP 구성 참조). 별도로 명시하지 않는 한 모든 명령은 클라이언트와 AP 모두에서 작동합니다.
도구는 주어진 $COMMAND에 해당하는 공격에 장치가 취약하면 TEST COMPLETED SUCCESSFULLY를 출력하고, 취약하지 않으면 Test timed out! Retry to be sure, or manually check result를 출력합니다. 테스트가 완료된 후 CTRL+C를 사용하여 테스트 도구를 종료할 수 있습니다. 대부분의 공격에는 서로 다른 $COMMAND 값으로 표현되는 몇 가지 약간의 변형이 있습니다.
일부 테스트의 결과를 확인하려면 테스트 대상 장치에서 tcpdump 또는 wireshark를 실행해야 합니다(아래 표에 tcpdump를 사용해야 하는지 명시되어 있습니다). 이 tcpdump 패킷 캡처에는 PHY 및 MAC 계층 처리를 통과한 패킷만 포함되어야 합니다. 예를 들어 Linux에서 이 캡처는 무선 인터페이스가 모니터 모드가 아닌 "managed" 또는 "ap" 모드일 때 수행해야 하며, 즉 캡처에는 Wi-Fi 계층에서 처리를 통과한 패킷만 포함됩니다. AP에서 tcpdump를 실행하지 않고도 일부 테스트를 수행할 수 있는 방법에 대한 논의는 AP에서 tcpdump 회피를 참조하세요.
테스트 설정을 검증하려면 아래 표의 첫 번째 명령이 일반 핑을 보내며 반드시 성공해야 합니다. 두 번째 명령은 핑을 두 개의 분할된 Wi-Fi 프레임으로 보내며, 테스트 장치가 fragmentation을 지원하지 않는 드문 경우에만 실패해야 합니다. 이 테스트 중 하나가 작동하지 않는 경우 네트워크 카드 주입 테스트의 지침에 따라 네트워크 카드가 프레임을 올바르게 주입하는지 확인하세요. 테스트 중인 클라이언트가 절전 모드에 들어갈 수 있다면 절전 모드 처리를 참조하세요.
세 번째, 네 번째, 다섯 번째 명령은 공격이 아니라 장치의 기본 재조립(defragmentation) 동작을 확인하는 것이며 표 아래에서 자세히 설명합니다.
명령이 CVE와 어떻게 대응하는지는 아래에 나열되어 있습니다. 구현 결함의 경우 참조 CVE 식별자를 나열하지만, 구현 취약점은 일반적으로 영향을 받는 각 코드베이스에 대해 고유한 CVE가 부여되므로 공급업체가 다른 CVE를 사용할 수 있습니다. 그럼에도 불구하고 발견된 구현 결함 유형을 쉽게 참조할 수 있도록 항상 이러한 참조 CVE를 사용할 것을 권장합니다.
ping: 이 테스트는 항상 성공해야 합니다. 실패하면 테스트 설정에 문제가 있는 것입니다.ping I,E,E: 이 테스트는 모든 최신 랩톱, 스마트폰 및 AP에 대해 성공해야 합니다. 실패한다면 테스트 설정에 뭔가 문제가 있을 가능성이 높습니다. 해결 방법으로 --icmp-size 100 매개변수를 추가해 보세요. 이 추가 매개변수로 작동한다면 다른 모든 테스트도 이 추가 매개변수를 사용하여 실행해야 합니다. 이 테스트가 정당한 이유로 실패하는 것을 본 유일한 경우는 테스트 대상 장치가 단편화된 프레임 수신을 지원하지 않을 때였으며, 이는 경량 IoT 기기나 예를 들어 OpenBSD에서 발생할 수 있습니다.ping I,E,E --delay 5: 이 테스트는 두 단편 사이에 허용되는 최대 지연 시간을 확인하는 데 사용됩니다. 이 테스트가 작동하지 않으면 --delay 1.5 이하로 다시 시도해 보세요. 예를 들어 Linux는 2초 후에 단편을 메모리에서 제거하므로, 1.8의 지연은 작동하지만 2.2는 응답이 없게 됩니다. 허용되는 최대 지연 시간이 낮은 경우, 다른 테스트에서 전송되는 모든 단편은 이 최대 허용 지연 시간 내에 전송되어야 합니다. 그렇지 않으면 테스트가 무의미하게 실패하여, 실제로는 취약한데도 장치가 공격에 취약하지 않다고 잘못 결론을 내릴 수 있습니다.
ping-frag-sep: 이 테스트는 무관한 프레임으로 분리된 단편화된 Wi-Fi 프레임을 전송합니다. 즉, 첫 번째 단편을 전송하고, 그 다음 (일반적인) 무관한 Wi-Fi 프레임을 전송한 다음, 마지막으로 두 번째 단편을 전송합니다. 이 테스트가 실패하면 (기본) 혼합 키 공격과 캐시 공격도 실패할 가능성이 높습니다 (두 단편 사이에 다른 프레임을 전송해야 하기 때문입니다). 수신자가 단편의 패킷 번호가 연속적인지 확인하는 경우에도 이 테스트는 실패합니다 (다음 테스트 ping-frag-sep --pn-per-qos 참조).
ping-frag-sep --pn-per-qos: 위와 동일하지만, --pn-per-qos 매개변수를 추가하면 핑 요청의 두 단편 모두 연속적인 패킷 번호(PN)를 갖게 됩니다. 이는 보안을 위해 수신자가 검증해야 하는 사항입니다. 불행히도, 우리의 결과가 공개되기 전에는 많은 구현체가 PN이 연속적인지 검증하지 않았습니다. 이 테스트는 QoS TID별 최신 수신 패킷 카운터를 추적하지 않는 수신자의 경우 실패할 수 있으며, 이 경우 --pn-per-qos 매개변수를 포함한 다른 테스트는 무시해도 됩니다.
ping I,E --amsdu 테스트는 구현체가 비-SPP A-MSDU를 지원하는지 확인합니다 (장치가 CVE-2020-24588에 취약한지 여부는 확인하지 않습니다). 공격을 방지하려면 이상적으로 네트워크가 SPP A-MSDU 사용을 의무화하고 모든 비-SPP A-MSDU를 폐기해야 합니다. 그러나 대부분의 벤더는 현재 임시 방편 수준의 완화 조치를 구현하고 있습니다 (논문의 7.2절 참조). 이 때문에 집계(A-MSDU) 공격(CVE-2020-24588)에 장치가 취약한지 확인하려면 다음 두 테스트를 사용해야 합니다:
amsdu-inject: 이 테스트는 논문의 3.2절에 설명된 A-MSDU 주입 공격을 시뮬레이션합니다. 특히, 시작 부분이 유효한 LLC/SNAP 헤더이기도 한 A-MSDU 프레임을 전송합니다 (우리의 기준 공격에서도 이와 같은 일이 발생하기 때문입니다). 이 테스트가 성공하면 장치는 CVE-2020-24588에 취약합니다.
amsdu-inject-bad: 일부 장치는 유효한 LLC/SNAP 헤더로 시작하는 A-MSDU 프레임을 잘못 파싱하여 위 테스트가 실패하게 만듭니다. 그런 경우 대신 amsdu-inject-bad를 시도해 보세요 (논문의 3.6절 참조). 이 테스트가 성공하면 공격의 영향은 그러한 프레임을 올바르게 파싱하는 구현체와 사실상 동일하므로, 장치는 CVE-2020-24588에 취약합니다.
AP에 대해 혼합 키 테스트를 실행할 때, AP는 새로운 4-way 핸드셰이크를 실행하여 세션 키(PTK)를 정기적으로 (예: 1분마다) 갱신하도록 구성되어야 합니다. 도구는 이 PTK 재키 핸드셰이크를 기다리는 동안 Client cannot force rekey. Waiting on AP to start PTK rekey를 표시합니다. 소수의 AP에 대해서는 테스트 도구가 --rekey-req 매개변수를 추가하여 PTK 갱신을 요청할 수도 있으므로, AP를 주기적으로 키를 갱신하도록 구성할 필요가 없습니다.
일부 AP는 세션 키(PTK)를 정기적으로 갱신하도록 구성할 수 없습니다. 이러한 AP에 대해서는 대신 캐시 공격 테스트를 시도할 수 있습니다. AP가 캐시 공격에 취약하다면 혼합 키 공격에도 취약할 가능성이 높습니다 (이를 반박하는 강력한 증거가 없는 한, 예: 코드 감사에서 혼합 키 공격이 차단되었음을 나타내는 경우). AP가 캐시 공격에 취약하지 않다면 혼합 키 공격에 대한 민감성에 대해 아무것도 말할 수 없으며, 그 경우 코드 감사를 수행하는 것이 좋습니다.
ping I,F,BE,AE --pn-per-qos: 추가된 --pn-per-qos 매개변수는 두 주입 단편이 연속적인 패킷 번호를 갖도록 보장하며, 이는 특정 장치(예: Linux)에 대해 혼합 키 공격이 성공하는 데 필요합니다.
여러 장치가 4-way 핸드셰이크를 다르게 구현하므로 이 테스트의 성공 여부에 영향을 미칩니다. 테스트가 실패하는 경우 확장 취약점 테스트에 나열된 혼합 키 공격 테스트도 수행하는 것이 좋습니다.
AP를 테스트할 때 도구는 첫 번째 단편을 전송한 다음 AP와 재연결(reassociate) 을 시도하고, 마지막으로 두 번째 단편을 전송합니다. 그러나 모든 AP가 재연결 과정을 제대로 지원하지는 않습니다. 그런 경우 표에 표시된 대로 --full-reconnect 옵션을 추가하면 테스트 도구가 첫 번째 단편 전송 후 인증 해제(deauthenticate) 를 수행합니다.
클라이언트를 테스트할 때 도구는 첫 번째 단편을 전송하고 클라이언트를 연결 해제(disassociate) 시킨 다음, 클라이언트가 재연결되면 두 번째 단편을 전송합니다. 이상적으로 클라이언트는 연결 해제 프레임 전송 후 즉시 재연결해야 합니다. 이렇게 하려면 테스트 중인 클라이언트에서 다른 모든 네트워크를 비활성화해야 할 수 있습니다. 또한 일부 클라이언트는 연결 해제를 제대로 처리하지 못하는 것 같으며, 그런 경우 표에 표시된 대로 --full-reconnect 옵션을 추가하여 대신 인증 해제 프레임을 전송할 수 있습니다.
각 캐시 공격 테스트를 여러 번 실행하는 것이 가장 좋다는 것을 발견했습니다. 때때로 구현체가 실제로는 취약한데도 캐시 공격 테스트가 실패할 수 있습니다. 이는 배경 잡음, 다른 장치가 테스트 대상 장치로 프레임을 전송하는 등 여러 요인으로 인해 발생할 수 있습니다.
ping I,E,R,AE [--full-recon]: 여기서 두 번째 단편은 테스트 대상 장치와 재연결 직후 전송되며, 이는 장치가 짧은 시간 후 메모리에서 단편을 지우는 경우에 중요합니다. full-recon은 full-reconnect의 약어입니다.
ping I,E,R,E [--full-recon]: 여기서 두 번째 단편은 테스트 대상 장치와 재연결한 후 1초 뒤에 전송되며, 핸드셰이크 완료와 협상된 키 설치 사이에 약간의 지연이 있는 경우 유용할 수 있습니다.
전반적으로 장치가 캐시 공격에 취약한지 테스트하는 것은 지루할 수 있습니다. 따라서 네트워크에서 연결 해제 또는 인증 해제 후, 또는 재연결 후에도 단편이 메모리에 남아 있는지 확인하기 위해 코드 감사를 수행하는 것도 권장합니다 (디버그 출력을 사용하여 동적으로 확인할 수도 있습니다). 단편이 메모리에 남아 있다면, 악용 가능 여부가 알려지지 않았더라도 위험으로 간주해야 합니다. 이는 구현체에 버퍼 오버플로가 있다는 것을 알지만 아직 악용 방법을 모르는 것과 유사합니다.
우리 실험에서 이 테스트는 Linux와 단편화를 지원하지 않는 장치에서만 실패했습니다.
ping I,E,P 및 linux-plain: 이 테스트가 성공하면 그로 인한 공격은 논문의 6.3절에 설명되어 있습니다. 요약하면, A-MSDU 또는 캐시 취약점과 결합하여 패킷을 주입하는 데 악용될 수 있습니다. 다른 취약점과 결합되지 않은 경우 그 영향은 구현체별로 다릅니다 (CVE-2020-26147).
ping I,P,E: 이 테스트가 성공하면 네트워크에서 단편화가 사용되는 경우 장치에 평문 프레임을 주입하는 것이 사소하게 쉬워집니다 (CVE-2020-26147).
ping I,P: 이 테스트가 성공하면 구현체가 보호된 Wi-Fi 네트워크에서 평문 프레임을 수락하므로 사소한 패킷 주입이 가능합니다 (CVE-2020-26140).
ping I,P,P: 이 테스트가 성공하면 구현체가 보호된 Wi-Fi 네트워크에서 단편화된 평문 프레임을 수락하므로 사소한 패킷 주입이 가능합니다 (CVE-2020-26143).
다음 두 테스트는 자동으로 재전송되지 않는 브로드캐스트 프레임을 전송하므로 여러 번 실행하는 것이 좋습니다. 배경 잡음으로 인해 테스트 대상 장치가 주입된 브로드캐스트 프레임을 수신하지 못할 수 있기 때문입니다. 우리 실험에서는 주로 클라이언트가 영향을 받았습니다 (테스트한 AP 중 Free/NetBSD AP만 영향을 받았습니다).
ping I,D,P --bcast-ra: 연결 후 평문 브로드캐스트된 두 번째 단편에서 유니캐스트 핑을 전송합니다. 이 공격 변형의 결과는 테스트 도구가 자동으로 확인합니다.
ping D,BP --bcast-ra: 여기서 위 프레임은 네트워크에 연결하는 동안 (즉, 4-way 핸드셰이크 중에) 전송됩니다. 여러 클라이언트와 AP가 4-way 핸드셰이크 완료 전에만 취약하기 때문에 이는 중요합니다. 이 테스트의 결과를 확인하려면 피해자에서 wireshark 또는 tcpdump를 실행하고 주입된 핑 요청이 피해자에게 수신되는지 모니터링해야 합니다. tcpdump에서는 icmp 필터를 사용할 수 있고, wireshark에서는 frame contains "test_ping_icmp" 필터를 사용하여 이 핑 요청을 더 쉽게 감지할 수 있습니다. 우리 실험에서는 주로 클라이언트가 영향을 받았습니다.
eapol-amsdu I,P: 이는 논문의 6.5절에서 논의된 구현체별 취약점에 대한 표준 테스트입니다. 클라이언트와 AP 모두 취약할 수 있습니다. 그 결과는 테스트 도구가 자동으로 확인합니다.
BP로 끝나는 테스트 (eapol-amsdu BP 및 eapol-amsdu-bad BP): 이 테스트들은 4-way 핸드셰이크 실행 중에 악성 프레임을 주입합니다. 이 테스트의 결과를 확인하려면 피해자에서 wireshark 또는 tcpdump를 실행하고 주입된 핑 요청이 피해자에게 수신되는지 모니터링해야 합니다. tcpdump에서는 icmp 필터를 사용할 수 있고, wireshark에서는 frame contains "test_ping_icmp" 필터를 사용하여 이 핑 요청을 더 쉽게 감지할 수 있습니다.
eapol-amsdu-bad로 시작하는 테스트 (eapol-amsdu-bad BP 및 eapol-amsdu-bad I,P): 일부 구현체는 처음 6바이트가 EAPOL에 대한 유효한 RFC1042 헤더와도 일치하는 A-MSDU 프레임을 잘못 처리합니다. 이러한 구현체를 테스트하려면 eapol-amsdu-bad 테스트 변형을 사용해야 합니다. 이 테스트가 성공하면 공격의 영향은 그러한 프레임을 올바르게 파싱하는 구현체와 동일합니다 (자세한 내용은 논문의 3.6절 및 6.6절 참조).
테스트 도구가 작동하지 않는 것 같으면 다음 사항을 확인하세요:
다른 프로세스가 네트워크 카드를 사용하고 있지 않은지 확인하세요 (예: 네트워크 매니저 종료).
이전에 모든 것이 작동했다면 Wi-Fi 동글을 분리하고 컴퓨터나 가상 머신을 다시 시작한 다음 다시 시도하세요. 또한 disable-hwcrypto.sh 스크립트를 사용하여 하드웨어 암호화를 비활성화해 보세요 (이 스크립트 실행 후 컴퓨터를 재부팅하세요).
테스트 중인 장치가 절전 상태로 들어가지 않는지 확인하세요 (주입된 프레임을 놓칠 수 있음). 절전 상태에 들어갈 수 있는 클라이언트를 더 잘 처리하므로 혼합 모드에서 테스트 도구를 실행하는 것이 좋습니다.
주입 테스트를 실행하여 주입이 제대로 작동하는지 확인하세요. 또한 20 MHz 채널이 사용되는지 확인하세요. 다른 채널에서의 주입은 테스트되지 않았습니다.
컴퓨터가 테스트를 방해하는 배경 트래픽을 생성하지 않는지 확인하세요. 특히 OS에서 네트워킹을 비활성화하고 DHCP 클라이언트/서버를 수동으로 종료하세요. 모든 사용 전에도 참조하세요.
올바른 네트워크에 연결하고 있는지 확인하세요. client.conf를 다시 확인하세요.
테스트 중인 AP가 암호화 알고리즘으로 (AES-)CCMP를 사용하고 있는지 확인하세요. TKIP나 GCMP와 같은 다른 암호화 알고리즘은 지원되지 않습니다.
git을 사용하여 코드를 업데이트했다면 ./build.sh와 ./pysetup.sh를 다시 실행하세요 (전제 조건 참조). 패치된 드라이버가 업데이트된 경우 드라이버도 다시 컴파일하는 것을 잊지 마세요.
가상 머신을 사용 중이라면 대신 라이브 USB 이미지에서 테스트 도구를 실행해 보세요.
테스트 대상 장치가 ICMP 핑 요청을 차단하지 않는지 확인하세요. 핑에 응답하지 않는 경우 장치에서 tcpdump나 wireshark를 실행하거나 ICMP 미지원에 나열된 다른 방법을 시도할 수 있습니다.
wpa_supplicant 또는 hostapd와 테스트 도구 자체에서 추가 디버그 출력을 얻으려면 --debug 2 추가 매개변수와 함께 도구를 실행하세요.
두 번째 모니터 인터페이스를 사용하여 단편 사이에 다른 프레임이 전송되지 않는지 확인하세요. 예를 들어 Intel 장치가 때때로 단편 사이에 Block Ack Response Action 프레임을 전송하여 테스트 대상 장치의 역단편화 과정을 방해하는 것을 발견했습니다.
무선 네트워크 카드에 필요한 경우 수정된 펌웨어를 사용하고 있는지 다시 확인하세요. 테스트 도구는 ath9k_htc 장치에 대해 이를 자동으로 확인합니다. 테스트 도구는 수정된 드라이버 사용 여부도 자동으로 확인하지만, 특정 Linux 배포판에서 수동으로 다시 확인하는 것이 좋을 수 있습니다.
구현 변형으로 인해 특정 취약점, 특히 혼합 키 공격과 캐시 공격은 실제로 확인하기가 어려울 수 있습니다. 따라서 코드에 이러한 공격을 방지하는 명시적인 검사가 있는 경우에만 장치를 안전한 것으로 간주하는 것을 권장합니다. 또한 시간이 허락한다면 다음과 같은 고급 테스트도 권장합니다. 이러한 테스트는 새로운 취약점을 발견할 가능성은 낮지만, 일반 테스트로는 감지할 수 없는 공격 변형이나 특정 장치 동작을 드러낼 수 있습니다.
취약점 테스트의 일반 테스트가 특정 취약점 클래스의 존재를 이미 확인했다면, 해당 취약점의 다른 공격 변형을 테스트할 필요는 거의 없습니다. 별도로 명시되지 않는 한 모든 명령은 클라이언트와 AP 모두에서 작동합니다.
이 두 테스트는 기본 테스트 ping I,E --amsdu가 실패하고 테스트 대상 장치가 A-MSDU 프레임을 어떻게 처리하는지 더 잘 이해하려는 경우에만 유용합니다:
ping I,E --amsdu-fake: 이 테스트가 성공하면 수신자가 모든 프레임을 일반 프레임으로 취급합니다 (즉, A-MSDU 프레임을 지원하지 않음). 이 동작은 이상적이지 않지만, 공격자가 실제로 이를 악용할 가능성은 낮습니다 (논문의 3.5절 참조).
ping I,E --amsdu-fake --amsdu-spp: 이 테스트가 성공하면 수신자가 수신된 모든 프레임의 QoS A-MSDU 플래그를 인증하고 (즉, 수신 시 0으로 마스킹하지 않음) 모든 수신 프레임을 일반 프레임으로 취급합니다 (즉, 실제 A-MSDU 프레임의 수신을 지원하지 않음). 이 동작은 이상적이지 않지만, 공격자가 실제로 이를 악용할 가능성은 낮습니다 (논문의 3.5절 참조).
내가 테스트한 대부분의 장치는 혼합 키 공격에 취약합니다. 일반 혼합 키 공격 테스트가 장치가 취약하지 않다고 표시하지만 ping-frag-sep 테스트가 성공하는 경우, 이러한 대체 혼합 키 공격 테스트를 시도하는 것이 좋습니다.일반적인 참고 사항으로, AP를 테스트할 때 혼합 키 공격 테스트에 --rekey-req 매개변수를 추가하면 키 갱신(rekey) 핸드셰이크를 능동적으로 요청할 수 있습니다. 그러면 소수의 AP가 키 갱신 핸드셰이크를 수행합니다. 그러나 대부분의 AP는 이 요청을 무시하며, 세션 키(PTK)를 정기적으로 갱신하도록 명시적으로 구성해야 합니다.
테스트에 관한 몇 가지 참고 사항:
ping I,F,BE,E 및 ping I,E,F,AE: 이 두 테스트는 두 프래그먼트가 서로 다른 시점에 주입되는 비교적 단순한 혼합 키 공격 테스트입니다.
ping I,E,F,AE --rekey-plain: 일부 드라이버(예: MediaTek)는 키 갱신 핸드셰이크를 평문으로 수행합니다. 이러한 드라이버를 사용하는 장치를 테스트하려면 --rekey-plain 매개변수를 추가해야 합니다.
ping I,E,F,AE --rekey-plain --rekey-req: 이 특정 조합은 MediaTek 드라이버를 사용하는 라우터를 테스트하는 데 유용합니다. 이러한 라우터는 키 갱신 핸드셰이크를 평문으로 수행하며, 클라이언트가 키 갱신 핸드셰이크를 능동적으로 요청할 수 있습니다.
ping I,E,F,AE --rekey-early-install: 소수의 클라이언트가 페어와이즈 세션 키 갱신 중에 키를 (잘못) 너무 일찍 설치합니다. 이러한 클라이언트를 확실하게 테스트하려면 --rekey-early-install 매개변수를 추가하세요. 이 테스트는 AP에는 의미가 없습니다.
ping I,E,F,E [--rekey-pl] [--rekey-req]: 이 테스트 변형은 이전의 ping I,E,F,AE * 테스트와 동일하지만, 두 번째 프래그먼트가 4-way 핸드셰이크 1초 후에 전송됩니다. 소수의 장치에서는 새 키가 설치되기 전에 약간의 지연이 있기 때문에 이는 중요할 수 있습니다. --rekey-pl은 --rekey-plain의 약어입니다.
마지막으로, ping-frag-sep 테스트가 성공하지 못한 경우 다음 혼합 키 공격 테스트를 시도해야 합니다:
ping I,F,BE,AE --freebsd: 이 테스트는 본질적으로 데이터 프레임의 역조각화(defragmentation) 과정에 영향을 주지 않으면서 FreeBSD 구현 또는 FreeBSD의 코드를 차용한 드라이버를 대상으로 키 갱신 핸드셰이크를 수행합니다. 자세한 내용은 논문의 부록 E를 참조하세요.ping I,E,R,AE --freebsd --full-reconnect: 이 테스트는 FreeBSD AP 또는 FreeBSD의 코드를 차용한 드라이버가 캐시 공격에 취약한지 확인하는 데 사용할 수 있습니다. 이 테스트가 작동하는 방식에 대한 자세한 내용은 논문의 부록 E를 참조하세요. --full-reconnect 매개변수 없이도 이 테스트를 시도해야 합니다. 이 테스트는 클라이언트를 대상으로도 작동하지만, 클라이언트가 영향을 받을 가능성은 낮습니다.
ping I,E,R,AP --freebsd --full-reconnect: 이 테스트는 FreeBSD AP 또는 FreeBSD의 코드를 차용한 드라이버를 대상으로 하는 변형으로, AP와 재연결한 후 두 번째 프래그먼트를 평문으로 전송합니다. FreeBSD의 일부 동글에서는 이 테스트가 더 신뢰할 수 있었으며, 재연결 후에도 이전 프래그먼트가 AP의 메모리에 남아 있음을 여전히 입증합니다. --full-reconnect 매개변수 없이도 이 테스트를 시도해야 합니다. 이 테스트는 클라이언트를 대상으로도 작동하지만, 클라이언트가 영향을 받을 가능성은 낮습니다.
ping I,E,R,AP [--full-reconnect]: 이 테스트에서는 두 번째 프래그먼트가 평문으로 전송됩니다. 이는 테스트 대상 장치가 4-way 핸드셰이크 후 키를 즉시 설치하지 않는 경우 유용할 수 있습니다. 이 테스트가 성공하면 장치가 네트워크에 (재)연결한 후에도 프래그먼트를 메모리에 보관한다는 것을 보여주며, 이는 캐시 공격에 취약하다는 것을 의미합니다. 위의 두 명령과 달리 이 명령은 클라이언트를 대상으로도 (AP뿐만 아니라) 수행하는 데 유용합니다.
ping I,E,E --amsdu: 이 테스트는 조각화된 A-MSDU 프레임을 전송하며, 모든 장치가 이를 제대로 수신할 수 있는 것은 아닙니다. 이는 취약점을 테스트하는 것이 아닙니다. 대신 이 테스트는 "혼합 평문/암호화 공격"의 실제 악용 가능성을 판단하는 데 유용합니다. 즉, 이 테스트가 성공하면 두 번째 프래그먼트를 평문으로 전송할 수 있을 때(ping I,E,P 테스트) 장치를 공격하기가 더 쉬워집니다. 자세한 내용은 논문의 6.3절을 참조하세요.
ping I,E,P,E 및 linux-plain 3: 다른 모든 혼합 평문/암호화 공격 테스트가 성공하지 못한 경우 이 두 가지 추가 테스트도 시도할 수 있습니다. 이것이 새로운 취약점을 발견할 가능성은 매우 낮다고 생각합니다.
다음 테스트의 대부분은 브로드캐스트 프레임을 전송하며, 브로드캐스트 프레임은 자동으로 재전송되지 않으므로 여러 번 실행하는 것이 좋습니다. 이는 배경 잡음 때문에 테스트 대상 장치가 주입된 브로드캐스트 프레임을 수신하지 못할 수 있기 때문입니다. 제 실험에서는 주로 클라이언트가 영향을 받았습니다. 대부분의 클라이언트는 네트워크에 연결하는 동안(즉, 4-way 핸드셰이크가 실행되는 동안)에만 취약합니다.
ping I,P --bcast-ra: 이 테스트는 평문 브로드캐스트 Wi-Fi 프레임 내부에 유니캐스트 ICMP ping 요청을 전송합니다(CVE-2020-26145). 이 테스트는 클라이언트와 AP 모두를 대상으로 수행할 수 있습니다.
ping BP --bcast-ra: 위의 ping I,P --bcast-ra 테스트와 유사하지만, 클라이언트가 네트워크에 인증하기 전, 즉 4-way 핸드셰이크가 실행되는 동안 ping이 전송됩니다(CVE-2020-26145). 클라이언트가 프레임을 수락하는지 확인하려면 tcpdump 또는 wireshark를 실행해야 합니다. tcpdump에서는 icmp 필터를 사용할 수 있고, wireshark에서는 frame contains "test_ping_icmp" 필터를 사용하여 이 ping 요청을 더 쉽게 감지할 수 있습니다.
ping BP --bcast-ra --bcast-dst: 이 테스트는 이전 테스트와 동일하지만, 대상 AP에서 tcpdump를 실행할 수 없는 경우 유용합니다. 이 테스트는 AP에 대해서만 의미가 있습니다. 이 테스트의 추가 --bcast-dst 매개변수는 취약한 AP가 주입된 ping 요청을 연결된 모든 클라이언트에게 브로드캐스트하도록 합니다. 즉, AP가 취약한지 확인하려면 이 명령을 실행하고, AP에 연결된 두 번째 장치에서 icmp 또는 frame contains "test_ping_icmp" 필터를 사용하여 브로드캐스트 Wi-Fi 프레임을 수신하십시오.
ping BP [--bcast-dst]: 이 테스트는 위의 두 테스트 ping BP --bcast-ra [--bcast-dst]의 변형으로, ping 요청이 브로드캐스트 프레임 대신 평문 유니캐스트 프레임으로 전송된다는 점만 다릅니다(아직 할당된 CVE는 없으며 CVE-2020-26145와 관련이 있습니다). 이 테스트는 클라이언트와 AP 모두를 대상으로 수행해야 합니다. ping은 클라이언트가 네트워크에 인증하기 전(즉, 4-way 핸드셰이크가 실행되는 동안)에 전송되므로, 장치가 이 프레임을 수락하는지 확인하려면 tcpdump 또는 wireshark를 실행해야 합니다. 또는 AP를 테스트할 때 위 테스트와 유사하게 --bcast-dst 매개변수를 추가한 다음, AP에 연결된 두 번째 장치에서 icmp 또는 frame contains "test_ping_icmp" 필터를 사용하여 tcpdump 또는 wireshark를 실행할 수 있습니다.
eapfrag BP,BP: 이 테스트는 클라이언트가 인증하기 전에 수행되는 위 브로드캐스트 프래그먼트 테스트의 특수화된 버전입니다. 유출된 코드 분석에 기반한 매우 실험적인 공격입니다. 먼저 EAPOL 헤더로 시작하는 평문 프래그먼트를 전송하는데, 4-way 핸드셰이크가 아직 실행 중이므로 수락됩니다. 그런 다음 동일한 시퀀스 번호를 가진 두 번째 브로드캐스트 프래그먼트를 전송합니다. 유출된 코드 분석에 따르면 일부 장치는 (이전 프래그먼트가 허용되었으므로) 이 프래그먼트를 수락할 수 있지만, 이후 코드는 (프래그먼트가 브로드캐스트되므로) 이를 일반 프레임으로 처리합니다. 프레임이 제대로 수신되었는지 확인하려면 피해자 장치에서 tcpdump 또는 wireshark를 사용해야 합니다(예: icmp 또는 frame contains "test_ping_icmp" 필터 사용). 일반 변형이 작동하지 않는 경우 대안 변형으로 eapfrag BP,AE가 있습니다.
이 테스트는 eapol-amsdu[-bad] BP 테스트를 실행하려고 하지만 AP에서 tcpdump 또는 wireshark를 실행할 수 없는 경우에 사용할 수 있습니다. 이 테스트는 AP에 대해서만 의미가 있습니다. eapol-amsdu[-bad] BP --bcast-dst 명령은 취약한 AP가 주입된 ping 요청을 연결된 모든 클라이언트에게 브로드캐스트하도록 합니다. 즉, AP가 취약한지 확인하려면 이 명령을 실행하고, AP에 연결된 두 번째 장치에서 icmp 또는 frame contains "test_ping_icmp" 필터를 사용하여 브로드캐스트 Wi-Fi 프레임을 수신하십시오.
eapol-inject 00:11:22:33:44:55: 이 테스트는 AP에 대해서만 의미가 있습니다. 이 테스트를 수행하려면 두 번째 장치를 사용하여 네트워크에 연결하고 MAC 주소 00:11:22:33:44:55를 이 두 번째 장치의 MAC 주소로 바꿔야 합니다. 테스트 도구는 인증 이전에 최종 목적지가 이 두 번째 장치인 EAPOL 프레임을 AP로 전송합니다. AP가 EAPOL 프레임을 두 번째 장치로 전달하면 AP는 취약한 것으로 간주됩니다. AP가 EAPOL 프레임을 전달하는지 확인하려면 두 번째 장치에서 tcpdump 또는 wireshark를 실행해야 합니다. 두 번째 장치의 무선 인터페이스에서 복호화된 트래픽을 모니터링할 때 wireshark 필터 frame contains "forwarded_data"를 사용할 수 있습니다(또는 모든 EAPOL 프레임을 모니터링하려면 tcpdump 필터 ether proto 0x888e 사용). 자세한 내용과 영향은 논문의 6.6절을 참조하세요.
eapol-inject-lage 00:11:22:33:44:55: 위의 eapol-inject 테스트가 성공하면 eapol-inject-large도 시도하여 이 취약점을 악용해 암호화된 프래그먼트의 전송을 강제할 수 있는지 확인할 수 있습니다. 이를 확인하려면 다시 tcpdump 또는 wireshark를 사용해야 합니다. wireshark 또는 tshark 필터 (wlan.fc.frag == 1) || (wlan.frag > 0)를 사용하여 조각화된 프레임을 감지하세요. 이 공격이 작동하는 경우는 매우 드물었습니다.
ping I,D,E: 이 테스트가 성공하면 클라이언트 또는 AP가 (역)조각화를 지원하지 않지만 여전히 공격에 취약하다는 것을 의미합니다. 문제는 수신자가 마지막 프래그먼트를 전체 프레임으로 처리한다는 것입니다. 자세한 내용과 악용 방법은 논문의 6.8절을 참조하세요.
ping I,E,D: 이 테스트가 성공하면 클라이언트 또는 AP가 첫 번째 프래그먼트를 전체 프레임으로 처리한다는 것을 의미합니다. 이 동작은 이상적이지 않지만, 이것만으로 실제로 악용될 수 있는지는 현재 알려져 있지 않습니다.
test-injection.py 스크립트는 주입 모드 사용 시 프레임이 제대로 주입되는지 테스트하는 데 사용할 수 있습니다:
./test-injection.py wlan0 wlan1
여기서는 네트워크 카드 wlan0이 프레임을 제대로 주입하는지 테스트하고, 네트워크 카드 wlan1을 사용하여 프레임이 제대로 주입되는지 모니터링합니다. 이 테스트 스크립트가 작동하려면 두 인터페이스 모두 모니터 모드를 지원해야 합니다.
두 번째 네트워크 카드가 없는 경우 다음을 사용하여 부분 주입 테스트를 실행할 수 있습니다:
./test-injection.py wlan0
안타깝게도 위 테스트는 커널이 주입된 프레임의 필드를 덮어쓰는지만 테스트할 수 있으며, 펌웨어나 무선 칩 자체가 필드를 덮어쓰는지는 테스트할 수 없습니다.
제가 권장하는 모드인 _혼합 모드_에서 네트워크 카드가 프레임을 제대로 주입하는지 테스트하려면 다음 두 명령을 실행할 수 있습니다:
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
여기서는 두 번째 네트워크 카드 wlan1을 사용하여 주입된 프레임을 모니터링함으로써 wlan0이 프레임을 제대로 주입하는지 테스트합니다. 첫 번째 명령은 클라이언트로 작동하면서 혼합 모드를 사용할 때 프레임이 제대로 주입되는지 테스트하고, 두 번째 명령은 AP로 작동하면서 혼합 모드를 사용할 때를 테스트합니다. 테스트를 시작하려면 클라이언트가 네트워크에 연결할 수 있어야 하며, AP는 클라이언트가 연결할 때까지 기다린 후 주입 테스트를 시작합니다(클라이언트와 AP의 연결 설정 구성은 모든 사용 전 참조).
혼합 모드에서 wlan0의 재전송 동작도 테스트하려면 다음을 실행할 수 있습니다:
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
두 번째 네트워크 카드가 없는 경우 다음을 사용하여 부분 혼합 모드 주입 테스트를 실행할 수 있습니다:
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
안타깝게도 위 테스트들은 커널이 주입된 프레임의 필드를 덮어쓰는지만 테스트할 수 있으며, 펌웨어나 무선 칩 자체가 필드를 덮어쓰는지는 테스트할 수 없습니다.
테스트 스크립트는 어떤 테스트가 성공했는지 실패했는지에 대한 자세한 출력을 제공하며, ==> The most important tests have been passed successfully 또는 중요한 테스트가 실패했거나 특정 주입 프레임을 캡처할 수 없음을 나타내는 메시지를 출력하며 종료됩니다.
주입 스크립트는 가장 중요한 동작만 테스트한다는 점에 유의하세요. 주입이 제대로 작동하는지 확인하는 가장 좋은 방법은 취약한 것으로 알려진 장치를 대상으로 취약점 테스트를 수행하고, 도구가 해당 장치(들)를 취약한 것으로 올바르게 식별하는지 확인하는 것입니다.
특정 주입 프레임을 캡처할 수 없는 경우, 이는 배경 잡음 때문이거나 테스트 중인 네트워크 카드가 특정 프레임을 제대로 주입할 수 없기 때문일 수 있습니다(예: Intel AX200의 펌웨어는 조각화된 프레임을 주입할 때 충돌합니다). 또한 프레임이 실제로는 제대로 주입되었지만, 프레임이 제대로 주입되는지 모니터링하는 데 사용된 네트워크 카드(위 예시의 wlan1)가 신뢰할 수 없어 예를 들어 배경 잡음으로 인해 대부분의 프레임을 놓치는 경우일 수도 있습니다. 다른 채널에서도 테스트를 실행해 보세요.
주입 테스트가 작동하지만 공격 테스트를 안정적으로 수행하는 데 문제가 있는 경우, 테스트 중인 장치가 절전 모드로 전환되기 때문일 수 있습니다. 이 문제에 대한 추가 참고 사항은 절전 모드 처리를 참조하세요.
wireshark를 사용하여 장치의 주입 동작을 검사할 때는 모니터 모드의 두 번째 장치를 사용하여 프레임이 어떻게 주입되는지 확인하는 것이 좋습니다.
프레임을 주입하는 데 사용된 인터페이스를 열면 주입된 프레임을 두 번 볼 수 있습니다: (1) 먼저 프레임을 전송하는 도구가 주입한 프레임이 보이고, (2) 두 번째로 드라이버가 프레임을 주입한 방식이 보입니다. 커널이 특정 필드를 덮어쓴 경우 이 두 프레임은 약간 다를 수 있습니다. 주입된 프레임이 한 번만 보인다면 커널에 의해 삭제되었을 수 있습니다.
테스트 중인 장치가 DHCP를 지원하지 않는 경우 테스트 도구가 사용할 IP 주소를 수동으로 지정할 수 있습니다. 예:
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
여기서 테스트 도구는 IP 주소 192.168.100.10을 사용하고 피어 IP 주소 192.168.100.1로 ping 요청을 주입합니다.
테스트가 DHCP를 사용하여 IP 주소를 얻기 전에 IP 패킷을 전송하면 기본 IP 주소 127.0.0.1을 사용합니다. 다른 (기본) IP 주소를 사용하려면 --ip 및 -peerip 매개변수를 사용할 수도 있습니다.
대부분의 공격 테스트는 특수한 방식으로 ICMP ping 요청을 전송하고 ICMP ping 응답을 수신하는지 확인하는 방식으로 작동합니다. 테스트 중인 장치가 ICMP ping을 지원하지 않는 경우 모든 테스트에 --arp 매개변수를 추가하여 ARP 요청을 대신 사용할 수 있습니다. 테스트가 ARP 요청 전송을 지원하지 않는 경우 도구는 Cannot override request type of the selected test 오류를 표시하며, 이 경우 해당 테스트는 ICMP ping 요청으로만 실행할 수 있습니다.
TODO: 클라이언트로 작동할 때 DHCP 요청도 대신 주입할 수 있습니다.
권장되는 무선 네트워크 카드 중 하나를 구할 수 없는 경우, 두 번째 옵션은 Linux에서 동일한 드라이버를 사용하는 네트워크 카드를 구하는 것입니다. 특히 다음을 시도할 수 있습니다:
저는 ath9k_htc 기반 카드를 권장합니다. iwlmvm을 사용하는 모든 카드가 호환되는 것은 아닙니다. 대체 네트워크 카드를 사용할 때는 먼저 주입 테스트를 실행하여 네트워크 카드가 호환되는지 확인하는 것을 강력히 권장합니다.
5 GHz 채널에서 테스트 도구를 사용하려면 사용 중인 네트워크 카드가 5 GHz 채널에서 프레임 주입을 허용해야 합니다. 안타깝게도 규제 제약으로 인해 이것이 항상 가능한 것은 아닙니다. 어떤 채널에서 프레임을 주입할 수 있는지 확인하려면 iw list를 실행하고 Frequencies에서 disabled, no IR 또는 radar detection으로 표시되지 않은 채널을 찾아보세요. 이러한 조건은 네트워크 카드, 현재 구성된 국가, 그리고 연결된 AP에 따라 달라질 수 있습니다. 자세한 내용은 예를 들어 Arch Linux 문서를 참조하세요.
장치가 2.4 GHz 및 5 GHz 대역을 처리하는 데 서로 다른 드라이버를 사용할 수 있습니다. 결과적으로 어떤 주파수 대역이 사용되는지에 따라 장치가 다르게 동작할 수 있으므로 두 대역 모두에서 장치를 테스트하는 것이 중요합니다.
혼합 모드에서는 Linux 커널이 일반 프레임 전송을 허용하더라도 프레임 주입을 허용하지 않을 수 있습니다. 이는 ieee80211_monitor_start_xmit 함수에서 커널이 cfg80211_reg_can_beacon이 false를 반환할 때 프레임 주입을 거부하기 때문입니다. 결과적으로 Linux는 실제로 허용됨에도 불구하고 프레임 주입을 거부할 수 있습니다. 올바른 조건에서 cfg80211_reg_can_beacon이 true를 반환하도록 하면 이 버그를 방지할 수 있습니다.
실제로 일부 사람들은 먼저 무선 네트워크 카드를 AP가 작동 중인 5GHz 채널로 수동 설정해야 한다는 것을 발견했습니다. 자세한 내용은 이 GitHub 이슈를 참조하세요.
휴대폰이나 IoT 기기와 같은 장치는 에너지 사용을 줄이기 위해 Wi-Fi 라디오를 절전 모드로 전환할 수 있습니다. 절전 모드에서는 이러한 장치가 Wi-Fi 프레임을 수신할 수 없으므로 테스트에 방해가 될 수 있습니다. 이 문제를 완화하기 위해 시도할 수 있는 몇 가지 옵션이 있습니다:
테스트 중인 장치에서 절전 모드를 비활성화해 보세요. 이것이 가장 확실한 해결책이지만 안타깝게도 항상 가능한 것은 아닙니다.
테스트 도구를 혼합 모드로 실행하세요. 그러면 대부분의 네트워크 카드가 테스트 중인 장치가 다시 깨어날 때까지 주입된 프레임을 대기시킵니다.
테스트를 수행할 다른 네트워크 카드를 시도해 보세요. 서로 다른 네트워크 카드는 (약간) 다른 시점에 프레임을 주입하며, 이것이 주입된 프레임이 제대로 도착하는지 놓치는지의 차이가 될 수 있습니다. 예를 들어 Pixel 4 XL을 대상으로 할 때 TL-WN722N을 사용하면 테스트 도구가 신뢰할 수 없었지만 Intel 8265에서는 안정적으로 작동했습니다.
테스트 대상 장치에 고정 IP를 할당하고 테스트 도구가 고정 IP를 사용하도록 하세요(고정 IP 구성 참조). 많은 테스트에서 테스트 도구가 먼저 DHCP를 사용하거나 대기하는 대신 즉시 테스트 프레임을 보낼 수 있으므로 더 안정적일 수 있습니다.
이로 인해 자동 테스트가 더 어려워지며, 일반적으로 테스트 대상 기기에서 tcpdump 또는 유사한 도구를 실행해야 합니다. 그러나 AP는 tcpdump를 실행하지 않고도 테스트할 수 있습니다. 특히 브로드캐스트 프래그먼트 공격 테스트(CVE-2020-26145)와 A-MSDU EAPOL 공격 테스트(CVE-2020-26144)는 테스트 대상 기기에서 tcpdump를 실행하지 않고도 수행할 수 있습니다. 대신, AP에 연결된 다른 클라이언트에서 tcpdump를 실행해야 합니다. 구체적으로 다음 명령을 사용할 수 있습니다.
ping I,P --bcast-ra --bcast-dst 및 ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst 및 eapol-amsdu-bad BP --bcast-dst
이 명령들을 사용하면 AP에 연결된 다른 클라이언트에서 ping 요청을 모니터링할 수 있습니다. ping 요청이 이 독립적인 클라이언트에서 수신되면 테스트 대상 AP는 취약한 것입니다. 불행히도, 현재 클라이언트에서 tcpdump를 실행하지 않고 이러한 공격 변형에 대해 클라이언트를 테스트하는 것은 어려워 보입니다.
어떤 이유로 Linux가 이 동글을 자동으로 인식하지 못하면 sudo modprobe mt76x2u를 실행하여
드라이버를 수동으로 로드하십시오. 이 동글은 최신 드라이버에서 안정적으로 작동하는 것으로 보입니다. 동글이 불안정하다면,
다음 내용으로 /etc/modprobe.d/mt76.conf 파일을 생성하십시오:```
options mt76_usb disable_usb_sg=1
그런 다음 머신을 재부팅하세요. 또한 이 동글과 함께 좋은 USB 케이블을 사용해야 합니다! 저는 이전에 이 동글에서
불안정한 동작을 겪은 적이 있는데, 그 원인은 불량한 USB 3.0 케이블이었습니다. 따라서 문제가 발생한다면
케이블 없이 동글을 직접 연결하는 것이 도움이 될 수 있습니다.
VirtualBox를 사용할 때는 동글이 인식되도록 USB3.0을 활성화해야 합니다. 자세한 내용은
[이 이슈](https://github.com/vanhoefm/fragattacks/issues/22)를 참조하세요.
AWUS036ACM은 내부적으로 MT7612U 칩셋을 사용합니다. 현재는 MT7612UN 칩셋을 사용하는 동글도 있으며, 이 역시
당사의 테스트 도구와 안정적으로 작동합니다. 예를 들어 [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20)가 있습니다.
### ath9k_htc
Technoethical N150 HGA, TP-Link TL-WN722N v1.x 및 Alfa AWUS036NHA는 모두 `ath9k_htc` 드라이버를 사용합니다.
제 경우 이러한 기기들은 가상 머신에서 꽤 잘 작동했습니다. 다만 모든 기기와 마찬가지로 네이티브로 사용할 때
더 안정적입니다. VM을 사용할 때는 VM이 USB2.0 컨트롤러를 사용하도록 구성하는 것을 권장합니다.
(적어도 VirtualBox에서는) 그쪽이 더 안정적으로 보였기 때문입니다.
최근 커널에는 `ath9k_htc` 드라이버가 작동하지 않게 만드는 ([현재는 수정된](https://www.spinics.net/lists/linux-wireless/msg200825.html))
회귀(regression) 문제가 있었습니다. 이 문제를 피하려면 최신 커널이나 당사의 패치된 드라이버를
사용하면 됩니다.
#### AWUS036ACH
이 기기는 대부분의 Linux 배포판에서 기본적으로 지원되지 않으며, 드라이버를 수동으로 설치해야 합니다.
Kali Linux에서는 `sudo apt install realtek-rtl88xxau-dkms` 명령으로 드라이버를 설치할 수 있습니다.
다른 배포판에 드라이버를 설치하려면 패키지 관리자를 확인하거나 [GitHub](https://github.com/aircrack-ng/rtl8812au)의
설치 지침을 따르세요. 기기를 연결하기 전에 `modprobe 88XXau rtw_monitor_retransmit=1`을 실행하는 것이
좋습니다.
안타깝게도 이 기기는 권장 모드인 혼합(mixed) 모드에서 작동하지 않으며, 당사의 수정된 드라이버와
함께 사용하기 어렵습니다. 실제로는 수정된 드라이버를 제거한 다음 `--no-drivercheck` 매개변수를
사용하고 `--inject wlan0`(여기서 wlan0은 AWUS036ACH 카드를 의미함)을 사용하여 테스트 도구를 실행해야
합니다. 이러한 제한 때문에 이 기기는 권장되지 않습니다.
### Intel AX200
Intel AX200을 테스트해 보았고, 테스트 도구와 _호환되지 않는_ 것을 발견했습니다. More Fragments 플래그가
설정된 프레임을 주입한 후 펌웨어가 크래시됩니다. 이 글을 읽고 있는 Intel 개발자가 있다면 펌웨어를
업데이트하여 조각화된 프레임을 주입할 수 있게 해주시기 바랍니다.
### RT5572 기반 칩셋
이 칩셋은 일반적인 [CSL USB 2.0 WLAN Adapter 300Mbit 어댑터](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20)를
사용하여 테스트했습니다. `disable-hwcrypto.sh` 스크립트를 실행하여 하드웨어 암호 해독을 비활성화한 후
기본 ping 테스트(`ping`)를 수행할 수 있었습니다. 조각화된 ping 테스트(`ping I,E,E`)는 매우 불안정했지만 가끔 작동했습니다.
현재 결론은 RT5572 칩셋이 하드웨어 암호화를 비활성화한 후 테스트 도구와 작동할 _가능성이 있다는_
것입니다. 그러나 이를 확인하려면 추가 실험이 필요합니다(피드백은 환영합니다).
<a id="id-hwsim-details"></a>
## 9.9. Hwsim 모드 세부 사항
**경고**: *현재 이 모드는 실험적인 모드이므로 연구 목적으로만 사용하십시오.*
이 모드에는 모니터 모드를 지원하는 네트워크 카드 하나만 필요하며, 혼합 모드와 달리 네트워크 카드가
가상 인터페이스를 지원할 필요가 없습니다. 단점은 이 모드에서 프레임이 처리되는 속도가 다소 느리고,
네트워크 카드가 프레임을 확인(Ack)하지 않을 때는 신뢰할 수 없다는 것입니다:
- 커밋 1672c0e31917("mac80211: start auth/assoc timeout on frame status")으로 인해 클라이언트로서의
인증이 즉시 타임아웃됩니다. 즉, 현재 hwsim 모드를 클라이언트로 사용할 수 없습니다.
_TODO: 이 타임아웃을 방지하려면 커널을 패치해야 합니다._
- 커밋 1672c0e31917("mac80211: start auth/assoc timeout on frame status")을 사용하는 클라이언트를 테스트한다면
(AP로서) 우리에게 전송된 프레임을 확인(Ack)해야 합니다. 그렇지 않으면 테스트 중인 클라이언트가
연결할 수 없습니다.
_TODO: 모니터 모드에서 프레임을 확인하는 기기를 테스트하고 `iw set wlanX monitor active`를 테스트하세요._
- 특정 AP는 인증 및 연관(association) 프레임을 클라이언트가 확인(Ack)하도록 요구하기도 합니다.
즉, (클라이언트로서) 우리에게 전송된 프레임을 다시 확인해야 합니다.
_TODO: 모니터 모드에서 프레임을 확인하는 기기를 테스트하고 `iw set wlanX monitor active`를 테스트하세요._
- 이상한 이유로 Intel/mvm은 4-way HS 이후에 Android/iPhone/iPad의 데이터 프레임을 수신할 수 없습니다?
이것은 매우 이상한 버그입니다. _TODO: 더 조사하세요._
이 모드를 사용하기 전에 두 개의 가상 네트워크 카드를 생성하세요:
./hwsim.sh
그러면 생성된 두 개의 가상 "hwsim" 인터페이스(예: wlan1 및 wlan2)가 출력됩니다. 이 모드에서
AP를 테스트할 때는 먼저 AP의 채널을 검색한 다음 실제 네트워크 카드를 해당 채널에
맞춰야 합니다:
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Pick the channel that the AP is on (in this example 11)
iw wlan0 set channel 11
여기서 wlan0은 _실제_ 네트워크 카드를 의미합니다(`hwsim.sh`로 생성된 인터페이스가 아님).
클라이언트를 테스트할 때는 먼저 채널을 구성할 필요가 없습니다(`hostapd.conf`에서 가져옵니다).
이제 다음과 같이 테스트 도구를 시작할 수 있습니다:
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
도구 실행이 완료된 후에는 새로운 `$COMMAND`로 바로 다시 실행할 수 있습니다.
<a id="id-wpa3-sae"></a>
## 9.10. WPA3 및 SAE 기기 테스트
`client.conf`에 다음 두 줄을 포함하면 WPA3/SAE AP를 테스트할 수 있습니다:
key_mgmt=SAE
ieee80211w=1
WPA3/SAE 클라이언트를 테스트하려면 `hostapd.conf`를 수정하고 다음 매개변수를 설정하면 됩니다:
wpa_key_mgmt=SAE
ieee80211w=2
위 내용을 Intel 8265, Intel 3160, Netgear WN111v2 (`carl9170`),
TP-Link TL-WN722N (`ath9k_htc`) 및 WNDA3200 (`ath9k_htc`)으로 테스트했습니다. 이 기기들로
AP에 연결하여 몇 가지 테스트를 실행할 수 있었습니다. 따라서 이미 지원되는 모든 동글에서도
작동할 것으로 보입니다. 참고로 이 부분은 자세히 테스트하지 않았습니다.
제 가정은 기기가 WPA2 모드에서 작동하는지 WPA3 모드에서 작동하는지가 테스트 결과에
영향을 미치지 않을 것이라는 것이었습니다.
제공된 `client.conf`는 기본적으로 hunting-and-pecking 방식과 hash-to-element 방식을 모두 활성화합니다.
hash-to-element를 지원하는 AP를 설정하려면(그리고 이를 통해 최신 WPA3/SAE 클라이언트를 테스트하려면)
`hostapd.conf`를 수정하고 다음 매개변수를 설정하면 됩니다:
sae_pwe=2
이 값을 설정하면 AP가 hunting-and-pecking 방식과 hash-to-element 방식을
모두 수용합니다.
<a id="id-live-image"></a>
## 9.11. 라이브 USB 이미지
[라이브 USB 이미지](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)를
다운로드하여 다음 명령으로 USB에 기록하세요:
# Unmount in case there's an old partition on the USB
sudo umount /dev/sdb*
# Copy the image
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
이미지의 sha256sum은 `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`입니다. `/dev/sdb`를
자신의 USB 스틱으로 바꾸세요. Linux를 사용하지 않는 경우 온라인에서 ISO 이미지를 USB 스틱에 기록하는 방법을 검색하세요.
라이브 이미지를 시작할 때 부팅 중에 "Try Ubuntu"를 클릭하세요. 바탕 화면을 마우스 오른쪽 버튼으로
클릭하고 "Open in Terminal"을 선택하여 터미널을 시작한 후 다음을 실행하세요:
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
이제 `./fragattacks.py`를 실행하고 이 README의 일반적인 지침을 따르면 됩니다.
위에 표시된 대로 `nmcli radio wifi off`를 사용하여 Wi-Fi를 비활성화해야 합니다. 그렇지 않으면
Ubuntu의 네트워크 관리자가 테스트 도구를 방해할 수 있습니다. 이 README는 라이브 이미지의
`~/fragattacks/README.md`에도 있습니다.
라이브 이미지에서는 airmon-ng가 불안정할 수 있으므로 [iw](https://github.com/vanhoefm/fragattacks/issues/36)를 사용하는 것이 좋습니다.
<a id="id-design-notes"></a>
# 10. 설계 노트
ping 명령에 전달되는 인수는 테스트 도구가 어떤 동작을 수행할지, 그리고 이러한 동작이 언제 수행될지를
정의합니다. 각 동작은 쉼표(`,`)로 구분됩니다. 기본적으로 동작은 클라이언트가 연결된 후에 수행되며,
이 경우 단일 문자가 수행할 동작을 나타냅니다. 이는
[`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23)
함수에 구현되어 있습니다.
가능한 동작은 다음과 같습니다:
- `I`: IP 주소를 획득합니다. `--ip` 및 `--peerip` 인수로 IP 주소를 명시적으로 제공하지 않는 한
기본적으로 DHCP를 통해 수행되며, 이 경우 아무 것도 수행되지 않습니다.
- `E`: ping 요청의 암호화된 패킷/조각을 주입합니다.
- `P`: ping 요청의 평문 패킷/조각을 주입합니다.
- `F`: (AP로서) 4-way 핸드셰이크를 시작하거나 (클라이언트로서) 4-way 핸드셰이크를 기다리는
방식으로 세션 키를 갱신합니다.
- `R`: 클라이언트가 네트워크에 다시 연결하도록 합니다.
- `D`: 이것은 특별한 "메타 동작"입니다. 실제로 전송되지 않는 ping 요청의 빈 조각처럼
취급합니다.
`E` 또는 `P` 동작이 하나만 있으면 ping 요청은 단일 프레임으로 주입됩니다.
`E`, `P` 동작이 여러 개 있으면 ping 요청은 조각화되며, 조각 수는 `E` 또는 `P` 동작의 수와
같습니다. 특별한 `D` 동작이 있으면 ping 요청은 나머지 `E` 또는 `P` 동작에 걸쳐 조각화됩니다
(표의 예시 참조). 이 조각화 동작은
[PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47)
클래스에 구현되어 있습니다.
동작이 수행될 시점을 변경하려면 위 동작 앞에 문자를 붙일 수 있습니다:
- `S`: 4-way 핸드셰이크의 1번째 또는 2번째 메시지에서 동작을 수행합니다.
- `B`: 4-way 핸드셰이크의 3번째 또는 4번째 메시지에서 동작을 수행합니다.
- `A`: 4-way 핸드셰이크가 완료된 직후에 동작을 수행합니다.
- `C`: 4-way 핸드셰이크가 완료된 1초 후에 동작을 수행합니다. 대기할 시간(초)은
`--connected-delay` 매개변수를 사용하여 변경할 수 있습니다.
예를 들어, 위의 두 명령 표를 참조하세요.
<a id="id-change-log"></a>
# 11. 변경 로그
**버전 1.3.4 (진행 중):**:
- --rekey-plaintext를 사용하는 경우에도 EAPOL(Rekey) Request 프레임을 항상 암호화합니다.
- 클라이언트는 이제 재생된 EAPOL 프레임을 수락합니다. 이로써 테스트 중인 AP가 rekey를 잘못 구현하더라도 rekey가 작동함을 보장합니다.
- MS-CHAPv2를 사용하는 Enterprise 네트워크에 다시 연결할 수 있도록 wpa_supplicant를 업데이트했습니다. 이전에는
OS가 OpenSSL 3.0 이상을 사용할 때 MD4가 기본적으로 비활성화되어 MS-CHAPv2를 사용할 수 없었습니다.
- `--pre-test-delay` 매개변수를 추가했습니다. IP 주소를 얻은 후 첫 번째 조각/프레임을 전송하기 전에
지연을 추가합니다. Michael Trimarchi와 Angelo Compagnucci의 [pull request](https://github.com/vanhoefm/fragattacks/pull/44)를
참조하세요.
- Linux 커널 5.13에서도 컴파일되도록 수정된 드라이버를 업데이트했습니다. 이는 실험적입니다.
- reorder 테스트에서 프레임을 더 오래 기다리도록 하여 주입 테스트를 더 안정적으로 만들었습니다.
- 구형 플랫폼(구형 Python 버전과 OpenSSL 라이브러리를 가진)에서 코드를 더 쉽게 컴파일할 수 있도록
몇 가지 사소한 변경을 했습니다.
- Ubuntu 20.04에 지원
| 네트워크 카드 | USB | 5GHz | 혼합 모드 | 주입 모드 |
|---|
| Technoethical N150 HGA | 예 | 아니요 | 패치된 드라이버/펌웨어 | 패치된 드라이버/펌웨어 |
| TP-Link TL-WN722N v1.x | 예 | 아니요 | 패치된 드라이버/펌웨어 | 패치된 드라이버/펌웨어 |
| Alfa AWUS036NHA | 예 | 아니요 | 패치된 드라이버/펌웨어 | 패치된 드라이버/펌웨어 |
| Intel Wireless-AC 8265 | 아니요 | 예 | 패치된 드라이버 | 예 |
| Intel Wireless-AC 3160 | 아니요 | 예 | 패치된 드라이버 | 예 |
| Alfa AWUS036ACM | 예 | 예 | 패치된 드라이버 | 예 |
| Netgear WN111v2 | 예 | 아니요 | 패치된 드라이버 | 예 |
| Alfa AWUS036ACH | 예 | 예 | 아니요 | 예 |
| 명령 | 간단한 설명 |
|---|
ping | 일반 핑을 보냅니다. |
ping I,E,E | 일반적인 분할(fragmented) 핑을 보냅니다. |
ping I,E,E --delay 5 | 프래그먼트 사이에 5초 지연을 두고 일반적인 분할 핑을 보냅니다. |
ping-frag-sep | 다른 프레임으로 분리된 프래그먼트로 일반적인 분할 핑을 보냅니다. |
ping-frag-sep --pn-per-qos | 위와 동일하지만 대상이 연속적인 PN만 허용하는 경우에도 작동합니다. |
ping I,E --amsdu | 일반적인 (SPP 보호가 아닌) A-MSDU 프레임에 캡슐화된 핑을 보냅니다. |
amsdu-inject | 공격 시뮬레이션: 시작 부분이 유효한 rfc1042 헤더이기도 한 A-MSDU 프레임을 보냅니다. |
amsdu-inject-bad | 위와 동일하지만 프레임을 잘못 파싱하는 대상을 상대로 합니다. |
ping I,F,BE,AE | 서로 다른 키로 암호화된 두 개의 프래그먼트를 주입합니다. |
ping I,F,BE,AE --pn-per-qos | 위와 동일하지만 대상이 연속적인 PN만 허용하는 경우에도 작동합니다. |
ping I,E,R,AE | 프래그먼트를 주입하고 재연결(reassociation) 을 유발한 다음 두 번째 프래그먼트를 주입합니다. |
ping I,E,R,E | 위와 동일하지만 두 번째 프래그먼트를 보내기 전에 더 긴 지연이 있습니다. |
ping I,E,R,AE --full-recon | 프래그먼트를 주입하고 인증 해제(deauthenticate) 후 재연결한 다음 두 번째 프래그먼트를 주입합니다. |
ping I,E,R,E --full-recon | 위와 동일하지만 두 번째 프래그먼트를 보내기 전에 더 긴 지연이 있습니다. |
ping I,E,E --inc-pn 2 | 비연속 패킷 번호로 분할 핑을 보냅니다. |
ping I,E,P | 분할 핑을 보냅니다: 첫 번째 프래그먼트는 암호화, 두 번째 프래그먼트는 평문. |
ping I,P,E | 분할 핑을 보냅니다: 첫 번째 프래그먼트는 평문, 두 번째 프래그먼트는 암호화. |
ping I,P | 평문 핑을 보냅니다. |
ping I,P,P | 분할 핑을 보냅니다: 두 프래그먼트 모두 평문으로 전송. |
linux-plain | Linux 특유의 혼합 평문/암호화 분할 공격. |
ping I,D,P --bcast-ra | 연결 후 평문 브로드캐스트 2번째 프래그먼트에서 유니캐스트 핑을 보냅니다. |
ping D,BP --bcast-ra | 위와 동일하지만 4-way 핸드셰이크 중에 프레임을 보냅니다(tcpdump로 확인). |
eapol-amsdu I,P | EAPOL 프레임으로 위장한 핑 요청이 포함된 평문 A-MSDU를 보냅니다. |
eapol-amsdu BP | 위와 동일하지만 핸드셰이크 중에 프레임을 보냅니다(tcpdump로 확인). |
eapol-amsdu-bad I,P | EAPOL 프레임으로 위장한 핑 요청이 포함된 잘못된 형식의 평문 A-MSDU를 보냅니다. |
eapol-amsdu-bad BP | 위와 동일하지만 연결 중에 프레임을 보냅니다(tcpdump로 확인). |
IP 주소 획득과 첫 번째 단편/프레임 전송 사이에 지연을 추가하는 것이 도움이 될 수 있습니다. 이는 --pre-test-delay 매개변수를 사용하여 수행합니다.
| 명령 | 간단한 설명 |
|---|
ping I,E --amsdu-fake | 이 테스트가 성공하면 A-MSDU 플래그가 무시됩니다 (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | A-MSDU 플래그가 인증되었지만 무시되는지 확인합니다 (§3.5). |
ping I,F,BE,E | 새 키가 비교적 늦게 설치되는 경우. |
ping I,E,F,AE | 재키 핸드셰이크 중에 데이터 프레임이 수락되지 않는 경우의 변형. |
ping I,E,F,AE --rekey-plain | 장치가 재키 핸드셰이크를 평문으로 수행하는 경우. |
ping I,E,F,AE --rekey-plain --rekey-req | 위와 동일하지만 클라이언트로서 적극적으로 재키를 요청합니다. |
ping I,E,F,AE --rekey-early-install | 4-way 핸드셰이크의 메시지 3 전송 후 새 키를 설치합니다. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | 위 4개 테스트와 동일하지만 두 번째 단편 전 지연이 더 깁니다. |
ping I,F,BE,AE --freebsd | FreeBSD 또는 유사한 구현체에 대한 혼합 키 공격. |
ping I,E,R,AE --freebsd [--full-reconnect] | FreeBSD 구현체에 특화된 캐시 공격. |
ping I,E,R,AP --freebsd [--full-reconnect] | FreeBSD 구현체에 특화된 캐시 공격. |
ping I,E,R,AP [--full-reconnect] | 두 번째 단편이 평문으로 전송되는 캐시 공격 테스트. |
ping I,E,E --amsdu | 단편화된 A-MSDU 프레임으로 일반 핑을 전송합니다. |
ping I,E,P,E | 첫 번째 단편은 암호화, 두 번째는 평문, 세 번째는 암호화된 핑. |
linux-plain 3 | linux-plain과 동일하지만 유인 단편이 QoS 우선순위 3으로 전송됩니다. |
ping I,P --bcast-ra | 4-way HS 후 평문 브로드캐스트 프레임으로 핑. |
ping BP --bcast-ra [--bcast-dst] | 4-way HS 중 평문 브로드캐스트 프레임으로 핑 (tcpdump 사용). |
ping BP [--bcast-dst] | 4-way 핸드셰이크 중 평문 프레임으로 핑 (tcpdump 사용). |
eapfrag BP,BP | 실험적 브로드캐스트 단편 공격 (tcpdump 사용). |
eapol-amsdu[-bad] BP --bcast-dst | eapol-amsdu BP와 동일하지만 AP에 대해 확인하기 더 쉽습니다 (tcpdump 사용). |
eapol-inject 00:11:22:33:44:55 | AP가 인증 전에 EAPOL 프레임을 전달하는지 테스트 (tcpdump 사용). |
eapol-inject-large 00:11:22:33:44:55 | EAPOL 주입으로 AP가 단편화된 프레임을 보내게 합니다 (tcpdump 사용). |
ping I,D,E | 암호화된 두 번째 단편 안에서 핑 전송 (첫 번째 단편 없음). |
ping I,E,D | 암호화된 첫 번째 단편 안에서 핑 전송 (두 번째 단편 없음). |