Простой удалённый POC для CVE-2022-0778

Зачем

При попытке проверить, уязвимы ли серверные реализации на нашей стороне для CVE-2022-0778, удалённое выполнение этой проверки оказалось крайне обременительным. Инструкции по созданию вредоносных сертификатов для запуска ошибки парсинга в BN_nod_sqrt() уже давно доступны, но основная проблема в том, что большинство клиентских реализаций пытаются разобрать клиентский сертификат, чтобы использовать его в TLS-рукопожатии. Это, в свою очередь, означало, что

• если реализация была уязвима, ошибка срабатывала, и клиент загружал процессор на 100% и зависал.
• если реализация не была уязвима, сертификат не мог быть разобран, и клиент, справедливо, завершал работу.

Что

На самом деле нужно было иметь возможность внедрить сообщение в TLS-рукопожатие, чтобы заменить содержимое сообщения Certificate, которое клиент отправляет серверу в ответ на сообщение CertificateRequest.

Как

Это зависит от tlslite-ng и переопределяет метод TLSConnection._clientKeyExchange, чтобы во время TLS-рукопожатия с возможно уязвимым сервером:

1. Мы отправляем сообщение ClientHello, как обычно.
2. Мы потребляем ServerHelloMessage и проверяем, содержит ли он CertificateRequest.
3. Если да, мы формируем произвольное сообщение Certificate, загружая DER-кодированный вредоносный сертификат с диска.
4. Отправляем подготовленное сообщение серверу и ожидаем, что он его разберёт, возможно вызывая CVE-2022-0778.

Файл crafted.crt создаётся на основе инструкций по адресу https://github.com/drago-96/CVE-2022-0778#using-asn1-templates, не стесняйтесь воссоздать его, если хотите.

Использование

usage: main.py [-h] [--server SERVER] [--port PORT]

Parameters

optional arguments:
  -h, --help       show this help message and exit
  --server SERVER  Name of the server to connect for the TLS handshake,
                   defaults to "localhost"
  --port PORT      Port where server listens for TLS connections, defaults to
                   "443"