Каталог продукции

Juniper Networks заявила, что удалит сомнительный генератор псевдослучайных чисел Dual_EC_DRBG

В конце прошлой недели Juniper Networks заявила, что удалит сомнительный генератор псевдослучайных чисел Dual_EC_DRBG из операционной системы ScreenOS. Это положительный шаг, учитывая неясное происхождение Dual_EC, однако хотелось бы также получить ответы на важные вопросы. Почему Juniper вообще решилась использовать этот ГПСЧ в VPN-службах NetScreen, если давно существуют подозрения, что он содержит бэкдор? Кто и зачем принял столь странные решения по кодировке и проектированию, облегчив расшифровку защищенных соединений?

Гигант сетевой индустрии пообещал, что из ScreenOS будет удален не только Dual_EC, но также алгоритм стандарта ANSI X9.31 и случится это с выпуском нового релиза в первой половине текущего года. Неавторизованный код, позволяющий расшифровывать VPN-трафик на сетевых экранах NetScreen, был обнаружен около месяца назад, как и возможность несанкционированного доступа к этим системам по SSH- или Telnet-каналу. 

Juniper привлекла сторонних экспертов для проведения тотальной ревизии своих кодов; это расследование, по словам представителей компании, не выявило других неприятных находок  в ScreenOS, ни в ОС Junos. «Мы проверили исходный код ОС Junos в «горячих точках», способных обнаружить код, подобный найденному в ScreenOS, — пишет разработчик в информационном бюллетене. — Такими критическими участками являются VPN-код, криптокоды и код аутентификации. Мы также проверили среды сборки на наличие следов вмешательства или неавторизованного доступа».

На конференции Real World Crypto, проведенной на прошлой неделе в Стэнфордском университете, группа специалистов по криптографии раскрыла ряд интересных фактов, в том числе срок присутствия Dual_EC в продуктах Juniper. По их утверждению, этот алгоритм был введен разработчиком в 2009 или даже 2008 году, но как минимум через год после памятной презентации Дэна Шумова и Нильса Фергюсона (Neils Ferguson) на конференции CRYPTO.

Шумов и Фергюсон первыми подтвердили предположение, что Dual_EC содержит бэкдор, установленный с инициативы АНБ. Они также показали, что данный алгоритм работает медленнее других ГПСЧ и содержит подобие отмычки: генерируемые им случайные числа связаны со вторым, секретным набором чисел, зная которые можно предсказать, что выдаст генератор случайных чисел, по первым сгенерированным 32 байтам.

В ответ на запрос Threatpost Стивен Чековэй (Stephen Checkoway), доцент кафедры информатики в Иллинойсском университете в Чикаго, сообщил, что он вместе с коллегами просмотрел десятки версий NetScreen и обнаружил: ANSI X9.31 использовался как единственный алгоритм вплоть до ScreenOS 6.2, в которую был добавлен Dual_EC. С выпуском этой версии ОС Juniper также увеличила длину nonce-кода, используемого ANSI X9.31, с 20 до 32 байт, открыв возможность для прогнозирования итогового выходного значения.

«В то же время Juniper привнесла странный баг, из-за которого ANSI-генератор, по сути, перестал использоваться, вместо него выходные значения выдавал Dual_EC, — поясняет Чековэй. — Все эти изменения были произведены одновременно, с обновлением версии». По словам собеседника Threatpost, этот баг, обнаруженный Виллемом Пинкарсом (Willem Pinckaers), нарушил порядок работы кода, принятый в ScreenOS 6.1 и более ранних версиях.

«Он очень нетривиален, — признает Чековэй. — Я никогда еще не видел, чтобы что-то, исправно работающее и написанное согласно принятым стандартам, так странно вдруг трансформировалось. Именно этим багом воспользовался новый злоумышленник, чтобы заменить константу Dual_EC, предположительно принадлежащую АНБ, своей собственной, чтобы иметь возможность расшифровывать VPN-трафик».

Патч, выпущенный Juniper, восстановил прежнюю константу Dual_EC. «Видимо, Juniper посчитала прежний код заданной функциональностью», — комментирует университетский исследователь. Новую атаку спровоцировало решение Juniper использовать Dual_EC, и Чековэй не видит веской причины для такого решения.

«По большому счету кто бы ни был автором модификации, ему достаточно было изменить лишь небольшой, мельчайший фрагмент кода Juniper, — размышляет эксперт. — Если бы Juniper не использовала Dual_EC, им пришлось бы произвести гораздо более масштабные изменения. Присутствие этого ненадежного ГПСЧ и спровоцировало последующую атаку».

Juniper тем временем быстро запатчила обе уязвимости, удалив то, что она назвала «неавторизованным кодом». Представитель Juniper Даниель Хамель (Danielle Hamel) отказалась сообщить Threatpost какие-либо детали сверх этого факта, предложив ознакомиться с соответствующими записями в блоге компании.

Ситуация с Juniper схожа со многими другими случаями вмешательства АНБ, о которых стало известно благодаря Эдварду Сноудену. Так, согласно раскрытым им данным о секретном проекте BULLRUN, АНБ давно приспособило алгоритм Dual_EC к своим нуждам и даже, по слухам, заплатило RSA Security $10 млн за внедрение этого алгоритма в ее продукты.

«Интересно, что в данном случае бэкдором служил Dual_EC, а не SSH; видимо, выбор был обусловлен чередой ошибок, по всем признакам случайных, которые привели к возникновению уязвимостей в ПО, — заключает Чековэй. — И этих случайных совпадений было немало: реализация Dual_EC, привнесение бага, увеличение nonce с 20 до 32 байт — идеального размера для проведения атаки».


Комментариев к статье: "Juniper Networks заявила, что удалит сомнительный генератор псевдослучайных чисел Dual_EC_DRBG" - 0 (шт.)

Написать комментарий

Ваше Имя:


Ваш комментарий: Внимание: HTML не поддерживается! Используйте обычный текст.

Введите код, указанный на картинке: