cisco-talos/mutiny-fuzzer네트워크 프로토콜 퍼저로, PCAP 트래픽을 변이 엔진(Radamsa)을 통해 재생하여 사용자 정의 가능한 메시지 프로세서와 모니터를 통해 대상 호스트의 취약점을 신속하게 발견합니다.
블로그 게시물:
이 YouTube 동영상 데모 링크:
퍼징 캠페인/피드백/하네스에 특화된 더 많은 기능을 보려면:
Mutiny 퍼징 프레임워크는 변이 퍼저를 통해 PCAP을 재생하여 작동하는 네트워크 퍼저입니다. 목표는 철저함을 다소 희생하더라도 가능한 한 빠르게 네트워크 퍼징을 시작하는 것입니다.
Mutiny의 일반적인 워크플로는 브라우저 요청과 같은 합법적인 트래픽 샘플을 가져와 준비 스크립트에 입력하여 .fuzzer 파일을 생성하는 것입니다. 그런 다음 이 .fuzzer 파일로 Mutiny를 실행하여 대상 호스트에 대한 트래픽을 생성하고 사용자가 원하는 패킷을 변이시킬 수 있습니다.
입력/출력에 따라 메시지 변경, 네트워크 오류에 대한 Mutiny의 응답 방식 변경, 별도 스레드에서 대상 모니터링 등 Mutiny의 동작을 변경할 수 있는 확장 기능이 있습니다.
Mutiny는 Radamsa를 사용하여 변이를 수행합니다.
Decept 프록시는 다목적 네트워크 프록시로, 일반 텍스트 또는 TLS TCP/UDP/도메인 소켓 연결의 트래픽을 다른 일반 텍스트 또는 TLS TCP/UDP/도메인 소켓 연결로 전달할 수 있습니다. .fuzzer 파일을 직접 생성할 수 있어 TLS 연결을 퍼징할 때 특히 유용하며, Mutiny가 TLS 호스트와 통신할 수 있도록 하여 Mutiny의 훌륭한 동반자가 됩니다.
sample_apps는 퍼저로 할 수 있는 몇 가지 작업에 대한 기본적인 아이디어를 제공하며, 테스트할 수 있는 몇 가지 다양한 애플리케이션/클라이언트가 포함되어 있습니다.
작성자: James Spadaro ([email protected]) 및 Lilith Wyatt ([email protected])
Python과 Scapy가 설치되어 있는지 확인하십시오.
Radamsa의 압축을 풀고 make를 실행하십시오. (install을 할 필요는 없습니다. /usr/bin에 설치하려는 경우가 아니라면 로컬 Radamsa를 사용합니다.) Radamsa 경로를 변경한 경우 mutiny.py를 업데이트하십시오.
pcap을 폴더에 저장합니다. <XYZ>.pcap에 대해 mutiny_prep.py를 실행합니다. (선택적으로 사용자 정의 프로세서의 디렉토리를 전달할 수도 있습니다. 자세한 내용은 아래 참조). 질문에 답하면 pcap과 같은 폴더에 <XYZ>.fuzzer 파일이 생성됩니다.
mutiny.py <XYZ>.fuzzer <targetIP>를 실행합니다. 그러면 퍼징이 시작됩니다. 로그는 동일한 폴더의 <XYZ>_logs/<time_of_session>/<seed_number> 디렉토리에 저장됩니다.
.fuzzer 파일은 사람이 읽을 수 있고 주석이 포함되어 있습니다. 이를 통해 각 퍼저 파일별로 다양한 옵션을 변경할 수 있으며, 어떤 메시지 또는 메시지 부분이 퍼징될지도 포함됩니다.
.fuzzer 파일 내에는 메시지 내용이 있습니다. 이는 'inbound' 또는 'outbound'로 시작하는 줄로, 메시지의 방향을 나타냅니다. Python 문자열 형식이며, '\xYY'는 출력 불가능한 문자에 사용됩니다. 이는 'mutiny_prep.py'와 Decept에 의해 자동 생성되지만, 때로는 수동으로 수정해야 할 수도 있습니다.
메시지에 'outbound' 다음에 'fuzz' 키워드가 있으면 Radamsa를 통해 퍼징되어야 함을 나타냅니다. 주어진 메시지는 새 줄에 인용 부호로 추가 메시지 데이터를 넣어 줄 연속을 가질 수 있습니다. 이 경우 두 번째 줄은 첫 번째 줄과 병합됩니다.
또는 'sub' 키워드를 사용하여 하위 구성 요소를 나타낼 수 있습니다. 이렇게 하면 메시지의 별도 구성 요소를 지정하여 특정 부분만 퍼징하고 메시지 프로세서 내에서 편리하게 사용할 수 있습니다.
다음은 임의의 메시지 데이터 세트 예시입니다:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
이렇게 하면 Mutiny가 say hi and fuzz this but not this(0xdeadbeef)를 전송하게 됩니다. 0xdeadbeef는 4개의 16진수 바이트로 전송됩니다. and fuzz this는 퍼징을 위해 Radamsa를 통과하지만, say hi와 but not this(0xdeadbeef)는 그대로 남습니다.
'inbound' 줄로 인해 Mutiny는 위의 단일 메시지를 전송한 후 서버의 응답을 기다립니다. 서버의 예상 응답은 this is the server's expected response입니다. Mutiny는 서버가 실제로 보낸 내용이 이 문자열과 일치하는지 확인하는 것 외에는 이 데이터로 많은 작업을 수행하지 않습니다. 충돌이 발생하면 Mutiny는 서버의 예상 출력과 서버가 실제로 응답한 내용을 모두 기록합니다.
mutiny_classes/에는 메시지 프로세서, 모니터 및 예외 프로세서의 기본 클래스가 포함되어 있습니다. 이러한 파일 중 하나는 .fuzzer와 동일한 폴더(기본값)나 .fuzzer 파일 내에서 'processor_dir'로 지정된 별도의 하위 폴더에 복사할 수 있습니다.
이 세 가지 클래스는 서버 응답 저장 및 발신 메시지 변경, 별도 스레드에서 대상 모니터링, Mutiny가 예외를 처리하는 방식 변경을 가능하게 합니다.
메시지 프로세서는 퍼징 실행 중에 호출되는 다양한 콜백을 정의합니다. 이러한 콜백 내에서 모든 Python 코드를 실행할 수 있습니다. 일반적으로 이는 주로 세 가지 방식으로 사용됩니다.
가장 일반적인 경우는 서버가 향후 발신 메시지에 추가해야 할 토큰을 보낼 때입니다. 예를 들어, Mutiny의 첫 번째 메시지가 로그인하고 서버가 세션 ID로 응답하는 경우 postReceiveProcess() 콜백을 사용하여 해당 세션 ID를 저장할 수 있습니다. 그런 다음 preSendProcess()에서 발신 데이터를 해당 세션 ID로 수정할 수 있습니다. 이에 대한 예는 sample_apps/session_server에 있습니다.
메시지 프로세서의 또 다른 일반적인 용도는 퍼징된 메시지를 제한하거나 변경하는 것입니다. 예를 들어, 서버가 항상 1000바이트보다 큰 메시지를 삭제한다면 큰 메시지를 보내는 것이 가치가 없을 수 있습니다. preSendProcess()는 퍼징 후 전송 전에 메시지를 단축하거나 예외를 발생시키는 데 사용할 수 있습니다.
예외를 발생시키는 것은 메시지 프로세서가 일반적으로 사용되는 마지막 방법입니다. 콜백 내에서 mutiny_classes/mutiny_exceptions.py에 정의된 모든 사용자 정의 예외를 발생시킬 수 있습니다. 여러 예외가 있으며 모두 주석 처리되어 있으며, Mutiny에서 다양한 동작을 유발합니다. 이는 일반적으로 현재 실행을 로깅, 재시도 또는 중단하는 것을 포함합니다.
모니터에는 기본 Mutiny 퍼저와 별도의 스레드에서 실행되는 monitorTarget() 함수가 있습니다. 목적은 어떤 방식으로든 호스트를 모니터링할 수 있는 장기 실행 프로세스를 구현할 수 있도록 하는 것입니다. 이는 대상에서 실행 중인 모니터 데몬과 통신하거나, 긴 파일을 읽거나, 퍼징 세션의 요구 사항에 따라 호스트를 반복적으로 ping하는 것 등 Python으로 할 수 있는 모든 것이 될 수 있습니다.
모니터가 충돌을 감지하면 언제든지 signalMain()을 호출할 수 있습니다. 그러면 기본 Mutiny 스레드에 충돌이 발생했음을 알리고 충돌을 기록합니다. 이 함수는 일반적으로 무한 루프에서 작동해야 합니다. 반환하면 스레드가 종료되고 다시 시작되지 않기 때문입니다.
예외 프로세서는 퍼즈 세션 중 주어진 예외에 대해 Mutiny가 수행해야 할 작업을 결정합니다. 가장 일반적인 의미에서 processException() 함수는 Python 및 OS 수준 예외를 가능한 최선으로 Mutiny 오류 처리 동작으로 변환합니다.
예를 들어, Mutiny가 'Connection Refused'를 수신하면 기본 응답은 대상 서버가 복구 불가능하게 다운되었다고 가정하여 Mutiny가 이전 실행을 기록하고 중단합니다. 이는 대부분의 경우에 해당하지만, 이 동작은 필요에 따라 mutiny_classes/mutiny_exceptions.py의 예외 중 하나로 변경할 수 있어 충돌 감지 및 오류 수정을 맞춤화할 수 있습니다.