mpgn/poodle-poc🐩 Poodle (패딩 오라클 기반 다운그레이드된 레거시 암호화) 공격 CVE-2014-3566 🐩
Poodle 공격(Padding Oracle On Downgraded Legacy Encryption)의 개념 증명:
man-in-the-middle 익스플로잇으로, 인터넷 및 보안 소프트웨어 클라이언트의 SSL 3.0으로의 폴백을 이용합니다.
Poodle 공격을 통해 클라이언트가 서버로 전송한 암호화된 데이터를 검색할 수 있습니다(단, 사용된 전송 계층 보안이 SSLv3인 경우). 이 공격으로 요청을 암호화하는 데 사용된 개인 키를 검색할 수는 없습니다.
SSLv3은 데이터를 암호화/복호화하고 보호하기 위한 프로토콜입니다. 여기서는 CBC 암호화 모드 체인닝을 사용합니다. 평문은 암호화 알고리즘(AES, DES, 3DES)에 따라 블록으로 나뉘며 길이는 8 또는 16의 배수입니다. 평문이 길이를 채우지 못하면 누락된 공간을 채우기 위해 패딩이 끝에 추가됩니다. 이 README를 읽기 전에 암호화 및 복호화 이미지를 열어 보시기를 강력히 권장합니다.
| 암호화 | 복호화 |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
기본적으로 이것은 단순한 XOR입니다. 이 비디오도 시청할 수 있습니다(제가 만든 것은 아닙니다) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
SSLv3를 사용하여 HTTPS를 통해 전송되는 요청은 CBC 모드의 AES/DES로 암호화됩니다. TLS1.x와 비교한 SSLv3의 특성은 패딩입니다. SSLv3에서 패딩은 마지막 바이트가 패딩의 길이와 같은 것을 제외하고 무작위 바이트로 채워집니다.
예시:
T|E|X|T|0xab|0x10|0x02 여기서 0xab|0x10|0x02는 패딩입니다.
T|E|X|T|E|0x5c|0x01 여기서 0x5c|0x01는 패딩입니다.
또한 마지막 블록은 패딩의 전체 블록으로 채워질 수 있습니다. 즉, 마지막 블록은 마지막 바이트를 제외하고 무작위 바이트로 가득 찰 수 있습니다.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 여기서 |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07는 패딩이며, 0x07만 공격자가 알 수 있습니다. 따라서 공격자가 패딩 블록에 영향을 줄 수 있다면, 마지막 블록의 마지막 바이트가 블록의 길이와 같다는 것을 알 수 있습니다.
공격자는 피해자에게 요청을 보내도록 할 수 있어야 합니다(예: XSS를 악용하여 JavaScript 사용). 그런 다음 각 요청의 경로와 데이터를 제어할 수 있습니다:
예시: 요청 경로에 "A" 바이트 추가
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
이 기술로 패딩에 영향을 줄 수 있습니다.
SSLv3는 또한 평문의 무결성과 인증을 확인하기 위해 HMAC을 사용합니다.
키 해시 메시지 인증 코드(HMAC)는 암호화 해시 함수(따라서 'H')와 비밀 암호화 키를 결합한 특정 유형의 메시지 인증 코드(MAC)입니다.
이를 통해 공격자는 요청을 가로채서 변경한 후 다시 보낼 수 없습니다. 서버에 문제가 발생하면 HMAC 오류를 보냅니다.
SSLv3 프로토콜은 다음 루틴을 사용합니다: 클라이언트로부터 데이터를 받아 복호화하고 HMAC으로 무결성을 확인합니다.
MAC-Then-Encrypt: 암호문에 대한 무결성을 제공하지 않습니다. 메시지가 실제로 진짜인지 위조된 것인지 복호화할 때까지 알 수 있는 방법이 없기 때문입니다. 평문 무결성. 암호 체계가 가변적이라면 메시지를 변경하여 유효하게 보이고 유효한 MAC을 가질 수 있습니다. 이는 실질적으로 MAC 비밀이 보호를 제공해야 하므로 이론적인 지점입니다. 여기서 MAC은 평문에 대한 정보도 제공할 수 없습니다. 암호화되어 있기 때문입니다.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
이는 서버가 알지 못하게 암호문을 변경할 수 있음을 의미합니다. 정말 좋습니다. :)
먼저 마지막 블록이 패딩으로 가득 차야 합니다. 이전에 본 것처럼 공격자는 요청 경로를 사용하고 요청 길이를 확인합니다.
마지막 블록은 마지막 바이트를 제외하고 무작위 바이트로 가득 차 있으므로, 이 마지막 블록 Cn을 복호화하려는 블록 Ci로 대체할 수 있습니다. 변경된 요청이 서버로 전송됩니다.
서버:
마지막 블록을 대체함으로써 공격자는 마지막 블록의 마지막 바이트(패딩의 길이)도 변경합니다. 대체된 패딩 블록의 마지막 바이트가 원본과 같을 확률은 1/256입니다. 이 경우 패딩 오류가 발생하지 않으며, 공격자는 다음 XOR 연산을 사용하여 블록 Ci의 마지막 바이트를 검색할 수 있습니다:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 또는 xxxxxxx15 및 x 무작위 바이트)
블록의 마지막 바이트를 검색할 수 있습니다: Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] 패딩의 경우 공격자는 SSL 세션을 닫아 다른 핸드셰이크(새 AES 키)를 수행하고 새로운 암호문을 얻은 다음 마지막 블록을 대체해야 합니다(일반적으로 300회 이상의 핸드셰이크 필요).
한 바이트가 검색되면 경로에 바이트를 추가하고 데이터에서 한 바이트를 제거하여 블록의 다른 모든 바이트를 얻습니다.
| 바이트 E,I,K,O를 검색하기 위한 요청 |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
TLS 사양에서는 서버가 패딩을 확인하도록 요구하지만, 일부 구현에서는 제대로 검증하지 않아 SSL 3.0을 비활성화하더라도 일부 서버가 POODLE에 취약해집니다.
TLS는 일반적으로 Poodle에 안전하지만, 일부 구현에서는 패딩을 확인하지 않아 SSLv3를 사용하는 것과 같습니다. 이것이 일부 TLS 버전이 취약한 이유입니다.
이 저장소에는 세 개의 파일이 있습니다:
이 PoC는 공격의 암호학적 원리를 탐구합니다. 이 파일을 통해 공격이 간단한 방식으로 어떻게 작동하는지 이해할 수 있습니다.
python3 poodle-poc.py
parallelization-poodle.py 파일은 프로젝트이자 아이디어입니다. :) https://github.com/mpgn/poodle-PoC/issues/1 확인
python3 parallelization-poodle.py
이것이 실제 익스플로잇입니다. 오래된 서버와 브라우저를 사용하는 고객을 대상으로 침투 테스트 중 Poodle 공격에 대한 개념 증명을 만들고 싶다면 매우 유용합니다. 악성 프록시의 IP를 올바른 포트와 함께 브라우저 구성에 설정하면 프록시가 나머지를 처리합니다.
필요 사항:
security.tls.version.min: 0을 사용하여 SSLv3만 강제합니다. 또는 클라이언트가 TLS도 사용하는 경우 다운그레이드를 강제할 수 있습니다.
💀 위 사전 요구 사항을 충족하면 공격을 시작할 수 있습니다 💀:
이 익스플로잇에는 두 가지 옵션이 있습니다:
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof, ettercap 또는 bettercap 도구를 사용하여 ARP 스푸핑 공격을 실행합니다$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
[--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
proxy port server rport
Poodle Exploit by @mpgn_x64
positional arguments:
proxy ip of the proxy
port port of the proxy
server ip of the remote server
rport port of the remote server
optional arguments:
-h, --help show this help message and exit
--start-block START_BLOCK
start the attack at this block
--stop-block STOP_BLOCK
stop the attack at this block
--simpleProxy SIMPLEPROXY
Direct proxy, no ARP spoofing attack
$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
블록 선택: 블록 옵션을 지정하지 않으면 모든 블록이 복호화되지만 시간이 오래 걸릴 수 있습니다. 요청이 어떻게 구성될지 '알고' 있다면 request-splitter.py 스크립트를 사용하여 복호화하려는 블록(이상적으로는 쿠키 블록!)을 파악하는 것이 좋습니다.
그런 다음 XSS 등을 사용하여 취약한 웹사이트에 악성 JavaScript 코드(poodle.js)를 삽입합니다. Python 스크립트를 실행하고 help를 입력한 다음 search, 마지막으로 active를 입력합니다. 그동안 JavaScript와의 상호 작용은 두 번만 필요합니다(search 및 active 명령).
업데이트 2018/01/04: 익스플로잇에 다운그레이드 옵션이 추가되었습니다. 익스플로잇이 TLS 프로토콜을 감지하면 downgrade 명령을 입력하여 SSLv3.0으로 다운그레이드합니다.
작동 방식: 핸드셰이크 중(헬로 클라이언트 이후) 익스플로잇이 handshake_failure 15030000020228을 보내면 브라우저는 기본 프로토콜로 SSLv3.0을 사용하여 다시 헬로 클라이언트를 보내야 합니다. Chrome 버전 15에서 테스트했지만 Firefox에서는 작동하지 않습니다(프로토콜 재협상을 지원하지 않는 것으로 보입니다). #4 확인
익스플로잇 전체 영상:
Asciinema:
