mpgn/poodle-poc🐩 Атака Poodle (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
Концепт-доказательство атаки Poodle (Padding Oracle On Downgraded Legacy Encryption):
эксплойт типа «человек посередине», использующий откат клиентов интернет- и охранного ПО к SSL 3.0
Атака Poodle позволяет восстановить зашифрованные данные, отправленные клиентом на сервер, если используется протокол защиты транспортного уровня SSLv3. Она не позволяет восстановить закрытый ключ, используемый для шифрования запроса.
SSLv3 — это протокол для шифрования/дешифрования и защиты ваших данных. В нашем случае он использует режим сцепления блоков шифра CBC. Открытый текст делится на блоки в зависимости от алгоритма шифрования (AES, DES, 3DES), а длина кратна 8 или 16. Если открытый текст не заполняет длину, в конец добавляется padding для заполнения недостающего пространства. Настоятельно рекомендую открыть изображения шифрования и дешифрования, чтобы читать этот 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.
Запрос, отправленный по HTTPS с использованием SSLv3, шифруется с помощью AES/DES в режиме CBC. Особенность SSLv3 по сравнению с TLS1.x — это padding. В SSLv3 padding заполняется случайными байтами, кроме последнего байта, который равен длине padding.
Пример:
T|E|X|T|0xab|0x10|0x02, где 0xab|0x10|0x02 — это padding.
T|E|X|T|E|0x5c|0x01, где 0x5c|0x01 — это padding.
Кроме того, последний блок может быть полностью заполнен padding, то есть последний блок может быть заполнен случайными байтами, кроме последнего байта.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07, где |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 — это padding, из которого атакующему известен только 0x07. Поэтому если атакующий может влиять на блок padding, он сможет узнать, что последний байт последнего блока равен длине блока.
Атакующий должен иметь возможность заставить жертву отправлять запросы (например, с помощью JavaScript при эксплуатации 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
С помощью этого приёма он может влиять на padding.
SSLv3 также использует HMAC для проверки целостности и аутентичности открытого текста.
код аутентификации сообщений на основе хеш-функции с ключом (HMAC) — это особый тип кода аутентификации сообщений (MAC), использующий криптографическую хеш-функцию (отсюда «H») в сочетании с секретным криптографическим ключом
Благодаря этому атакующий не может перехватить и изменить запрос, а затем отправить его обратно. Если сервер столкнётся с проблемой, он отправит ошибку HMAC.
Протокол SSLv3 использует следующую процедуру: получает данные от клиента, расшифровывает данные, проверяет целостность с помощью HMAC.
MAC-then-Encrypt (MAC затем шифрование): Не обеспечивает никакой целостности шифротекста, поскольку до расшифровки сообщения невозможно узнать, было ли оно подлинным или подделанным. Целостность открытого текста. Если схема шифрования пластична (malleable), возможно изменить сообщение так, чтобы оно выглядело валидным и имело корректный MAC. Это, конечно, теоретический момент, поскольку на практике секрет MAC > должен обеспечивать защиту. Здесь MAC также не может предоставить никакой информации об открытом тексте, поскольку он зашифрован.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Это означает, что мы можем изменять зашифрованный текст без ведома сервера. Это здорово, правда :)
Сначала последний блок должен быть полностью заполнен padding, как мы видели ранее: атакующий использует путь запроса и проверяет длину запроса.
Поскольку последний блок, кроме последнего байта, заполнен случайными байтами, он может заменить этот последний блок Cn на блок, который хочет расшифровать, Ci. Изменённый запрос отправляется на сервер.
Сервер:
Заменяя последний блок, атакующий также изменяет последний байт последнего блока (длину padding). Существует вероятность 1/256, что последний байт, заменённый в блоке padding, совпадает с исходным; в этом случае ошибки padding не будет, и атакующий может использовать операцию 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] В случае ошибки padding атакующему нужно закрыть 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 требуют от серверов проверки padding, некоторые реализации не проверяют его должным образом, из-за чего некоторые серверы уязвимы к POODLE, даже если SSL 3.0 отключён.
TLS обычно безопасен против Poodle, но некоторые реализации не проверяют padding — это как если бы мы использовали SSLv3, поэтому некоторые версии TLS уязвимы.
В этом репозитории три файла:
Этот PoC исследует криптографию, лежащую в основе атаки. Этот файл позволяет простым способом понять, как работает атака.
python3 poodle-poc.py