trycatchhcf/packetwhisperPacketWhisper: DNS 쿼리와 텍스트 기반 스테가노그래피를 사용하여 데이터를 은밀히 유출하고 귀속을 회피합니다. 일반적인 DNS 유출 방법과 관련된 문제를 피하세요. 통신 장치가 서로 또는 공통 엔드포인트에 직접 연결되지 않고 시스템 간에 데이터를 전송합니다. DNS 이름 서버를 제어할 필요가 없습니다.
PacketWhisper - DNS 쿼리와 텍스트 기반 스테가노그래피를 사용하여 데이터를 은밀하게 전송하고 귀속을 회피하며, 공격자가 제어하는 네임 서버나 도메인이 필요 없습니다. DLP/MLS 장치를 우회하고, 데이터 및 DNS 네임 서버 화이트리스트 제어를 무력화합니다. 모든 파일 형식(예: 실행 파일, Office, Zip, 이미지)을 FQDN(완전한 도메인 이름) 목록으로 변환하고 DNS 쿼리를 사용하여 데이터를 전송합니다. 간단하지만 매우 효과적입니다.
(2020년 5월 27일 업데이트: 네, 2020년 여름 동안 모든 Github 프로젝트를 Python3로 마이그레이션할 예정입니다.)
Joe Gervais (TryCatchHCF)
기존의 DNS 유출은 다음 중 하나에 의존합니다: DNS 터널링; DNS 쿼리 필드에 데이터 숨기기; 또는 인코딩/암호화된 페이로드를 분할하여 DNS 쿼리의 하위 도메인으로 사용. 이러한 모든 방법은 공격자가 데이터를 수신할 도메인 및/또는 관련 DNS 네임 서버를 제어해야 하므로 귀속(attribution)으로 이어집니다. 또한 이러한 접근 방식은 DNS 네임 서버 블랙리스트(일반적) 및 화이트리스트(점점 더 일반적)에 취약합니다. 또 다른 문제는 DFIR 분석가들이 이러한 방법에 익숙하며, SIEM 시스템이 이를 탐지하고 경고하는 경우가 많다는 점입니다.
PacketWhisper는 이러한 한계를 극복합니다.
만약 통신 시스템이 서로 직접 연결되거나 공통 엔드포인트에 연결되지 않고도, 대상의 자체 화이트리스트 DNS 서버를 사용하여 데이터를 전송할 수 있다면 어떨까요? 심지어 네트워크 경계가 데이터 유출을 차단하기 위해 데이터 화이트리스트를 사용하더라도 말이죠.
이 모든 것을 가능하게 하기 위해 PacketWhisper는 DNS 쿼리와 텍스트 기반 스테가노그래피를 결합합니다. Cloakify 도구 세트를 활용하여 페이로드를 FQDN 문자열 목록으로 변환합니다. 그런 다음 PacketWhisper는 FQDN 목록을 사용하여 순차적인 DNS 쿼리를 생성하고, 데이터를 눈에 띄지 않게 숨기면서 네트워크 경계를 넘어(또는 내에서) 페이로드를 전송합니다. 두 시스템이 서로 직접 연결되거나 공통 엔드포인트에 연결될 필요가 없습니다. PacketWhisper가 사용하는 암호(cipher)는 경고를 생성하지 않도록 하고 분석 시도를 오도하기 위해 여러 수준의 속임수를 제공합니다.
데이터를 수신하려면 가장 편리한 방법을 사용하여 DNS 쿼리가 포함된 네트워크 트래픽을 캡처합니다. (캡처 지점 예시는 아래 "PCAP 파일 캡처" 섹션을 참조하세요.) 그런 다음 캡처된 PCAP 파일을 PacketWhisper(편리한 시스템에서 실행)에 로드하면, 파일에서 페이로드를 추출하고 원래 형태로 Decloakify합니다.
DNS는 상대적으로 느린 데이터 전송 수단이지만, 가장 민감한 네트워크에서도 거의 항상 네트워크 경계를 넘어 허용되기 때문에 매력적인 프로토콜입니다.
중요 참고사항: 우리는 데이터 전송에 DNS 쿼리를 사용하며, 성공적인 DNS 조회가 아닙니다. PacketWhisper는 DNS 쿼리를 성공적으로 해석할 필요가 전혀 없습니다. 사실 PacketWhisper는 DNS 응답조차 보지 않습니다. 이는 사용 사례를 확장하며, 우리가 쿼리하는 도메인을 제어할 필요가 없고 DNS 요청을 처리하는 DNS 네임 서버를 제어할 필요가 없다는 점을 강조합니다.
따라서 PacketWhisper를 사용하여 다음과 같은 페이로드를:
다음과 같은 FQDN 목록으로 변환합니다:
PacketWhisper가 이를 DNS 쿼리로 변환하면 네트워크 트래픽에 다음과 같이 나타납니다:
DNS 해석 경로의 어디에서든 PCAP 파일로 캡처한 후, 해당 PCAP을 로컬 PacketWhisper 사본에 로드하여 페이로드를 복구합니다:
프로젝트에 포함된 DEF CON 26 슬라이드(프로젝트 내 포함)를 참조하세요. 이 슬라이드는 Packet Hacking Village 발표에서 사용된 것으로, DNS 유출 배경, 텍스트 기반 스테가노그래피/Cloakify 도구 세트, 그리고 PacketWhisper가 이들을 결합하여 데이터 전송 방법을 만드는 방법을 설명합니다. 슬라이드는 독립적으로 유용하게 사용할 수 있도록 특별히 제작되었으므로 배경 정보와 내용이 완전해야 합니다. 하지만 DC26 Packet Hacking Village 발표 비디오를 시청하여 추가적인 맥락을 얻을 수도 있습니다.
프로젝트에 샘플 PCAP 파일(적절히 "sample.pcap"이라는 이름)을 포함시켰으며, 각 암호에 대한 별도의 페이로드가 들어 있습니다. 물론 어떤 파일 형식이든 될 수 있었지만, 여기서는 단순히 텍스트 파일을 PCAP으로 전송했습니다. PacketWhisper에 로드하여 시도해 보세요!
자체 환경에서 간단히 테스트하려면 VM에서 PacketWhisper를 실행한 다음, 호스트 시스템을 통해 VM의 네트워크 인터페이스에서 패킷 캡처를 수행하면서 파일을 전송하세요. 그런 다음 PCAP 파일을 편리한 PacketWhisper 인스턴스에 로드하여 파일을 디코딩할 수 있습니다. 다만 빠른 전송이 아니라는 점을 기억하세요. 작은 파일과 인내심이 필요합니다.
질문: "왜 Scapy나 dnspython 도구 세트를 사용하지 않았나요?"
답변: 운영 도구에서 프로젝트 종속성을 싫어합니다. 특히 환경을 제어할 수 없거나 최소 권한만 가질 수 있는 클라이언트 측에서는 최대한 안정성을 위해 프로젝트를 원자적이고 자급자족적으로 유지합니다. PacketWhisper가 구조화된 방식으로, 프로젝트를 tar로 묶어 대상 호스트에 추출하기만 하면 제한된 쉘 호스트에서도 실행할 수 있습니다.
질문: "왜 PacketWhisper가 Cloakify 도구 세트의 프로젝트 포크가 아닌가요?"
답변: 위와 같은 이유입니다. Cloakify의 기능 중 매우 특정한 하위 집합만 필요하며, 나머지를 모두 PacketWhisper에 추가하면 디렉토리가 복잡해지고 PacketWhisper가 사용할 수 없는 도구/암호만 생깁니다. 두 프로젝트 모두 소유하고 있으므로 변경 사항을 두 프로젝트 간에 동기화하겠습니다.
$ python packetWhisper.py
FQDN 기반 암호는 3가지 범주로 구성됩니다:
고유한 무작위 하위 도메인 FQDN
대부분의 사용 사례에 권장되는 암호 모드
하위 도메인에 무작위 요소가 내장된 FQDN입니다. 이는 DNS 캐싱을 방지하는 데 도움이 되며, DNS 쿼리 경로에 있는 NAT된 네트워크 장치를 넘어 데이터를 전송할 수 있게 합니다. 송신 시스템의 IP 주소가 NAT 장치 너머에서 확인되지 않으므로, 암호에 의해 생성된 하위 도메인에는 패킷 캡처에서 PacketWhisper 페이로드를 식별하는 데 도움이 되는 고유 태그 요소가 포함됩니다.
이러한 암호는 세션, 사용자, 캐시된 콘텐츠 등을 식별하기 위해 복잡한 하위 도메인에 의존하는 다양한 서비스의 형식을 모방합니다. 이 접근 방식은 PacketWhisper의 DNS 쿼리가 네트워크의 나머지 트래픽과 조화를 이루도록 합니다.
하위 도메인 이름의 첫 번째 부분은 암호 목록의 문자열입니다. 나머지 하위 도메인 이름은 각 FQDN을 고유하게 만들기 위해 무작위화되어 DNS 캐싱이 DNS 쿼리 경로를 조기에 차단하는 것을 방지합니다. 그런 다음 도메인 이름을 추가합니다. 선택한 도메인과 관련된 일반적인 FQDN처럼 보이도록 FQDN을 구성하여 모든 네트워크에서 볼 수 있는 일반적인 웹 트래픽과 더 잘 조화를 이룹니다.
고유한 반복 FQDN
네트워크의 다른 모든 DNS 쿼리와 구별되도록 생성되었지만 무작위화는 없습니다. 즉, DNS 캐싱이 방해할 수 있지만, 부수적인 이점으로 가장 큰 멀티클라이언트 pcap 컬렉션에서도 DNS 쿼리를 쉽게 찾을 수 있습니다. 이는 FQDN이 영화 '버카루 반자이 8차원을 넘어서'에 나오는 가상의 Yoyodyne Propulsion Systems의 "Johns"(Red Lectroid 외계인) 목록과 같은 특이한 엔드포인트이기 때문입니다.
일반 웹사이트 FQDN
일반적인 웹사이트 URL로 구성된 FQDN입니다.
참고: 대부분의 환경은 경계에서 NAT되므로(클라이언트 IP 주소 가시성 제거), 이 모드는 일반적으로 동일한 로컬 /24 네트워크에 연결된 시스템 간의 데이터 전송에만 유용합니다(예: 좋아하는 커피숍의 게스트 wifi).
일반 웹사이트 암호는 소스 IP 주소만 네트워크의 다른 유사한 DNS 쿼리와 구별하는 수단으로 사용되므로, PacketWhisper는 페이로드의 시작과 끝에 고유한 "노크 시퀀스" DNS 쿼리를 전송하여 나중에 pcap 파일에서 전송 호스트를 식별하는 데 도움을 줍니다.
FQDN 예: www.github.com
암호를 선택하면 PacketWhisper는 원하는 암호에 따라 페이로드를 FQDN 문자열 목록으로 인코딩(Cloakify)합니다. 그런 다음 순차적으로 DNS 요청을 생성하여 DNS 해석 경로를 따라 데이터를 전송합니다. PacketWhisper는 각 DNS 쿼리 사이에 약간의 지연을 추가하여 DNS 요청이 순서대로 처리되도록 합니다.
물론 핵심 요소는 PacketWhisper가 생성한 DNS 쿼리가 포함된 네트워크 트래픽을 캡처할 수 있는 능력입니다. DNS 쿼리 경로에 대한 가시성만 있다면 어디든지 가능하므로 많은 옵션이 있습니다.
캡처 지점 예시:
상상력을 발휘하세요. DNS 해석 경로의 모든 장치가 옵션이며, 벽면 디스플레이도 포함됩니다. "잠깐만요, 뭐라고요?"
참고: VPN 연결은 호스트와 VPN 종료 노드 간의 가시성을 차단합니다. 전송 중인 클라이언트에 활성 VPN 연결이 있는 경우, VPN 종료 노드 업스트림에서 캡처할 수 없으면 DNS 쿼리를 볼 수 없습니다. 동일한 시스템에서 캡처해도 실패합니다. 많은 분들이 VPN을 사용하고 계실 테니, PacketWhisper를 테스트하려면 호스팅된 가상 머신(VM)에서 전송하고 호스트 시스템의 VM 네트워크 인터페이스에서 트래픽을 캡처해보세요.
pcap 파일을 캡처한 후, tcpdump(Linux 및 MacOS에 포함) 또는 WinDump(Windows)가 설치된 시스템에서 PacketWhisper를 실행하여 페이로드를 복구합니다. PacketWhisper는 사용된 암호를 묻고, pcap에서 페이로드를 추출한 다음 일치하는 암호로 추출된 페이로드를 디코딩합니다.
중요 참고사항: 동일한 PCAP 내에서 사용된 암호당 하나의 페이로드를 전송할 수 있습니다. 동일한 암호를 사용하는 두 개 이상의 페이로드가 포함된 PCAP은 문제를 일으킵니다. 예를 들어 제가 제공한 'example.pcap' 파일에는 현재 사용 가능한 각 운영 암호에 대해 하나씩 총 5개의 페이로드가 포함되어 있습니다. 만약 페이로드 중 하나가 다른 페이로드와 동일한 암호를 사용했다면 PacketWhisper는 둘 중 어느 것도 추출하지 못합니다. 쉬운 해결책은 PCAP 파일을 분할하는 것입니다(이것이 PacketWhisper 전송 코드가 전송 시작 및 종료 시 UTC 날짜-시간을 출력하는 이유입니다). 동일한 암호를 사용하는 여러 페이로드를 허용하는 작업을 진행 중이며, 해결책은 이미 마련되어 있지만 구현할 시간이 필요합니다.
PCAP 파일이 실제로 PCAP 형식인지 확인하세요. tcpdump나 WinDump를 사용하여 파일을 캡처했다면 괜찮습니다. 그러나 Wireshark는 Wireshark 트래픽을 저장할 때 다양한 "다른 이름으로 저장..." 옵션을 제공하며, 그중 하나만 실제로 tcpdump/PCAP 친화적입니다. 오류를 조기에 발견할 수 있도록 더 나은 오류 보고를 작업 중입니다.
안전한 암호화 체계가 아닙니다. PacketWhisper는 안전한 암호화 체계가 아닙니다. 빈도 분석 공격에 취약합니다. '고유한 무작위 하위 도메인 FQDN' 범주의 암호를 사용하여 엔트로피를 추가하고 빈도 분석 공격을 약화시키십시오. 페이로드의 기밀이 필요한 경우, PacketWhisper로 처리하기 전에 반드시 페이로드를 암호화하십시오.
고대역폭 전송 방법이 아닙니다. PacketWhisper는 DNS 쿼리에 의존하며, 이는 UDP 기반이므로 요청의 전달 순서(또는 성공적인 전달)가 보장되지 않습니다. PacketWhisper는 기본적으로 각 DNS 쿼리 사이에 약간의 지연(0.5초)을 추가합니다. 원본 페이로드 크기를 기준으로 시간당 약 7.2KB(분당 120바이트)의 속도로 페이로드를 안전하게 전송할 수 있습니다. 이는 Cloakify된 출력 파일이 아닌 원본 페이로드 크기 기준입니다. 쿼리 사이에 지연을 없애도록 선택할 수 있으며, 이 경우 전송 속도가 크게 빨라지지만 네트워크 노이즈 증가와 페이로드 손상 위험이 있습니다.
그리고 솔직히 말해서, 비 DNS 데이터 전송 수단을 사용할 수 있다면 주요 Cloakify 도구 세트 프로젝트를 사용하여 파일을 눈에 띄지 않게 숨기고(예: 페이로드를 PokémonGo 몬스터 목록과 위도/경도 좌표로 변환) FTP/HTTP 등을 통해 사용 가능한 모든 고대역폭을 활용할 수 있습니다. DNS는 다른 프로토콜이 차단되었을 때 매우 유용하지만, 항상 자신의 옵션을 인지하십시오.
DNS는 DNS입니다. OS마다 DNS 캐싱 정책 등이 다릅니다. 네트워크가 다운되거나 격리되는 등의 문제가 발생할 수 있습니다. PacketWhisper는 일반적인 FQDN을 해석할 수 있는지 빠르게 수동 확인하는 기능을 포함하지만, DNS는 종종 복잡한 문제입니다. 오래된 IT 문제 해결 격언을 기억하세요: "항상 DNS 문제다."
프로젝트에 포함된 DEF CON 26 슬라이드(Packet Hacking Village 발표)를 참조하세요. 완화 전략은 발표 후반부에 다루고 있습니다. 모든 것에서 "심층 방어(Security In Depth)"는 특히 DNS 해석 경로가 조직의 통제 범위를 벗어난 광범위한 영역에 걸쳐 있으므로 친구입니다.
MDNS 및 LLMNR 로컬 네트워크 DNS 브로드캐스트 모드를 추가할 예정입니다. 이는 동일한 로컬 네트워크에 연결된 시스템에서 사용하기 위한 것이며, Wi-Fi 패킷 캡처 시 캡처 장치가 무차별 모드(Promiscuous Mode)에 접근할 필요가 없도록 합니다. (해당 프로토콜은 호스트 네트워크의 x.y.z.255로 트래픽을 전송하여 동일한 로컬 네트워크의 다른 모든 시스템에 브로드캐스트합니다.)
또한 더 많은 암호를 추가할 예정이지만, 일상적인 요구에는 현재 암호 모음만으로 충분했습니다. 잘 활용하실 수 있을 것입니다.
또한 단일 PCAP 파일에서 동일한 암호를 사용하는 여러 페이로드를 허용하는 작업을 진행 중입니다. 해결책은 이미 프로토타입이 완성되었지만, 사용자에게 PCAP 추출 워크플로우가 더 복잡해집니다. 운영상으로는 그만한 가치가 없을 수도 있습니다. 저는 항상 스위스 군용 칼 같은 복잡성보다는 더 깔끔한 운영 기능을 선호합니다.
