mpgn/beast-poc💪 SSL/TLS CVE-2011-3389에 대한 BEAST 공격의 개념 증명 💪
이 개념 증명은 2011년 9월 23일 Thai Duong과 Juliano Rizzo가 발표한 BEAST(Browser Exploit Against SSL/TLS) 공격의 배후에 있는 암호학에 초점을 맞춥니다. 이는 선택 평문 공격이며, 사용된 전송 계층 보안이 TLS1.0 또는 SSLv3인 경우 민감한 정보를 검색할 수 있습니다. 원래 개념 증명은 여기에서 찾을 수 있습니다: 닌자들이 온다
참고: 이는 원래 Phillip Rogaway가 발견한 취약점의 구현이기도 합니다. 2002년에 발견되었지만 2011년 BEAST까지 공격 코드가 공개되지 않았습니다. OpenSSL은 이미 이 문제를 알고 있었고, 이것이 2006년 4월에 TLS1.0을 TLS1.1로 업데이트한 이유입니다.
2 첫 번째 레코드를 제외한 각 레코드의 CBC IV는 이전 레코드의 마지막 암호문 블록입니다. 따라서 적응적으로 평문을 선택할 수 있는 공격자에 대해 암호화는 안전하지 않습니다;
SSLv3/TLS1.0은 데이터를 암호화/복호화하고 보호하기 위한 프로토콜입니다. 우리의 경우, 둘 다 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.
다음 항목에서 IV를 소개하겠습니다. 이러한 모든 속성이 공격을 수행하는 데 도움이 된다는 점을 기억하세요.
CBC를 사용할 때 IV라고 하는 초기화 벡터가 필요합니다. 이 IV는 무작위(또는 고정)이지만 어떠한 경우에도 누구도 예측할 수 없어야 합니다. TLS1.0 및 SSLv3에서 요청의 첫 번째 IV는 무작위이며, 좋습니다. 그러나 매번 새로운 무작위 IV를 생성하지 않아 시간을 절약하기 위해 TLS1.0 및 SSLv3의 구현은 이전 암호문의 마지막 블록을 IV로 사용했습니다. 다시 말해, 이제 IV를 추측할 수 있게 되었습니다. 각 블록의 길이가 8(DES)이라고 가정하고, 공격자는 모든 암호문을 획득하기 위해 MiTM을 보유하고 있다고 가정합니다.
예:
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
이제 흥미로운 부분입니다. 다음은 한 바이트를 검색하기 위한 공격의 다양한 암호화 단계입니다:
bbbbbbbTHIS_IS_A_SECRET_COOKIE 메시지를 보낼 수 있습니다.비밀 쿠키 앞에 일곱 개의 b가 있는 것을 확인할 수 있습니다. 블록의 길이가 8이라면 알려진 7바이트를 밀어 넣어야 합니다. 이 정보는 매우 중요합니다. 공격자는 첫 번째 블록의 처음 7바이트를 알게 됩니다.
하지만 왜 그럴까요? 이렇게 하면 8바이트를 찾기 위해 256^8이 아니라 한 바이트를 찾기 위해 256가지 가능성만 시도하면 됩니다!
이제 피해자가 요청을 보내면 다음과 같이 암호화됩니다:
C0 | C1 | C2 | C3 | C4
여기서 C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
유일하게 알 수 없는 요소는 X이며, 256가지 가능성이 있으므로 최대 256자를 시도할 것입니다.
요청은 다음과 같이 전송되고 암호화됩니다:
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') 또는 C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
이제 그는 C'0과 C0을 비교합니다. 만약 같다면 방금 8번째 위치의 바이트 X를 찾은 것입니다. 일치하지 않으면 다른 문자로 다시 시도하고 다시 비교하는 식입니다.
이제 한 바이트를 얻었으므로 이전 요청을 왼쪽으로 한 칸씩 이동하여 다른 바이트를 얻을 수 있습니다: bbbbbbTHIS_IS_A_SECRET_COOKIE. 이제 여섯 개의 b가 있고 T도 알고 있으므로 모르는 문자가 하나 있습니다. 새로운 P'0 = C0 ⊕ C4 ⊕ bbbbbbTX 등을 만듭니다...
참고: 요청 두 개만 사용하는 또 다른 방법은 평문의 첫 번째 블록을 설정하고 이 정보를 세 번의 XOR에 사용하는 것입니다. 이제 C²의 마지막 블록이 더 이상 필요하지 않습니다. C1 = Ek(C0 ⊕ bbbbbbbT)이고 그런 다음 P'0 = C0 ⊕ C4 ⊕ bbbbbbbX입니다. 또한 C'0과 C1을 비교해야 합니다. 이것은 또 다른 방법이며, PoC에서 두 가지 가능성을 모두 코딩했음을 확인할 수 있습니다 :)
이제 모든 문자를 검색할 수 있습니다!
python BEAST-poc.py
공격자는 HTTP 프로토콜을 사용할 수 없습니다. 첫 번째 블록이 GET / HTTP/1.1\r\n로 채워지기 때문입니다.
... 각 요청의 처음 몇 바이트를 제어할 수 없습니다. 왜냐하면 항상 GET /, POST / 등과 같은 고정 문자열로 설정되기 때문입니다. 대신 소켓을 사용할 수 있습니다.
또한 악성 페이지에 자바스크립트를 주입해야 합니다. 피해자는 이 페이지에 연결되어 공격이 완료될 때까지 머물러 있어야 합니다. 이것은 선택 평문 공격이므로 공격자는 자바스크립트 코드를 통해 원하는 모든 평문을 보내고 중간자(Man in The Middle)로 결과를 가로챌 수 있습니다. 다음은 공격 다이어그램입니다:
이 공격이 성공하려면 중요한 조건들이 필요합니다(TLS1.0 이하, CBC 암호 모드, MiTM, 악성 자바스크립트). 그러나 Thai Duong과 Juliano Rizzo는 이것이 가능함을 증명했고 Paypal 웹사이트에서 쿠키를 훔쳐 익스플로잇을 시연했습니다.
이제 모든 것이 수정되었으며 이 공격이 실제로 발생할 확률은 낮습니다.