Нежелезное «железо»

Мы привыкли к противопоставлению ненадёжного программного обеспечения надёжному аппаратному. На английском языке антонимичность названий software/hardware ещё очевиднее, так как корни soft и hard значат «мягкий» и «твёрдый» соответственно. В программах часто находят уязвимости, и считается, что в аппаратуре уязвимости обнаруживаются гораздо реже - хотя фирма Intel и «прокололась» с архитектурой процессоров.

На самом деле, разумеется, противопоставление не вполне корректно, и не стоит недооценивать роль прошивок, которые тоже являются программным обеспечением, просто очень низкого уровня и мало кому доступным для внесения изменений. Но, тем не менее, ошибки при создании безопасных устройств случаются даже у крупных производителей.

Начнём с криптографических токенов фирмыYubico. Криптографические токены — небольшие устройства, как правило, в форм-факторе брелока, содержащие не извлекаемый без специального оборудования (а иногда и с ним) криптографический ключ. Продукция Yubico — разнообразные токены Yubikey — использовались для двухфакторной аутентификации в сервисах Google и, что более критично, в правительственных сервисах США. Компания выпустила подробное сообщение об уязвимости в продукции. В ключах Yubikey FIPS версий 4.4.2 и 4.4.4 из-за ошибки при генерации секретного ключа часть буфера, выделяемого под случайные числа, содержала одни и те же данные. По иронии судьбы, эти константные байты оставались от запуска тестов на соответствие стандартам FIPS. Тем самым стойкость полученных ключей снижалась при использовании алгоритмов, основанных на эллиптических кривых, с 256 бит до 176. Надо понимать, что каждый предсказанный бит — это ослабление ключа в два раза, то есть общее ослабление составило миллион миллиардов раз. Это позволяло, получив несколько подписей, выполненных с помощью токена, вычислить исходный секретный ключ и тем самым, теоретически, установить личность его владельца. Для алгоритма RSA, где длина ключа составляет не меньше 2048 бит, ситуация несколько лучше. Пользователям ключей предложена программа замены уязвимых устройств.

В этой истории сравнительно понятно всё происходящее. Есть устройство, есть его производитель, и даже природу бага достаточно легко объяснить. Вторая история в сегодняшней подборке пока остаётся куда более загадочной. Изначальная публикация была сделана на французском языке (что уже оценено криптографами как грамотный с точки зрения защиты информации ход), и поэтому обсуждение оказалось куда более ограниченным, чем событие того заслуживает. Чуть позже появился англоязычный пересказ исходной статьи, а пока мы ждём конференции Black Hat, которая пройдёт в США в августе 2019 года – скорее всего, подробности по поводу обнаруженных уязвимостей будут обнародованы там.

Очень долгое время не назывались ни модель устройства, ни его производитель. В публикациях на тему найденной уязвимости высказывалось предположение, что речь идёт о фирме Gemalto, выпустившей некоторое время назад обновление для своей продукции. Через некоторое время выяснилось, что догадка была верна, и речь идёт об устройстве Gemalto Safenet Protect Server PSI-E2/PSE2. В отличие от предыдущего случая речь идёт о куда более защищённом (теоретически) устройстве, относящемся к классу HSM — Hardware Security Module. Про устройство сейчас известно, что оно применялось множеством крупных банков, облачных провайдеров, правительственными агентствами и другими коммерческими и государственными структурами. Известно, что удалённый пользователь может взять под контроль криптомодуль, а значит, получить возможность выполнения множества неавторизованных операций.

Непосредственной причиной уязвимостей устройства оказалось использование в HSM ядра Linux 2.26 — возрастом старше 10 лет и без дополнительных мер по увеличению защиты. Кроме того, были выявлены ошибки в реализации протокола PKCS#11 — он применяется для взаимодействия с устройствами такого класса. Самой язвительной в обсуждениях, пожалуй, можно счесть формулировку «это не HSM, а устройство из мира IoT с прикрученным криптоакселератором». Сама атака состояла из нескольких этапов. Для начала с помощью легального SDK — инструментария для разработки взаимодействия с устройством, предоставляемым вендором — авторы из фирмы Ledger получили доступ на устройство. Дальше были найдены ошибки переполнения буфера в модуле PKCS#11. Для этого использовался так называемый фуззер (fuzzer) — набор утилит, предназначенный для поиска уязвимостей путём малой модификации входных параметров различных функций. Потом выяснилось, что добраться до этих ошибок можно без использования SDK, специально сконструированными вызовами с хост-машины. Под занавес выяснилось, что на устройство можно загрузить не подписанный криптографически модуль, который доберётся до «ядра» устройства и сдаст наружу все секреты. Наиболее серьёзной уязвимостью выглядит не сама возможность доступа к секретам, а «дыры» в прошивке, позволяющие залить зловредный код без проверки его происхождения.

Последний разбираемый сегодня казус происходит из уже знакомой категории процессорных уязвимостей. На этот раз в фокусе оказалась фирма AMD с процессорами Epyc. Компания выпустила патч для прошивки процессоров, исправляющих уязвимость в механизме Secure Encrypted Virtualization technology (SEV), который должен защищать память виртуальных машин KVM на процессорах Epyc. Память каждой машины шифруется собственным ключом. Исследователь из Google Cloud Security Цфир Коэн (Cfir Cohen) продемонстрировал уязвимости в этом механизме защиты. Дело в том, что ключи шифрования создавались по схеме Диффи-Хеллмана, умножая на секретные параметры точки, принадлежащие стандартной кривой. Коэн сумел продемонстрировать атаку, отправляя специально подобранные точки, принадлежащие эллиптическим кривым с другими параметрами, и тем самым вычислить секретный ключ процессора, после чего у него получалось восстановить вычисления ключей для отдельной виртуальной машины. В зависимости от настроек системы, для этого могло хватить привилегий соседней виртуальной машины.

Все рассмотренные примеры в очередной раз показывают, что грань между «твёрдым» и «мягким» в современных компьютерных средах достаточно условна и преодолима, а значит, разработчикам устройств приходится учитывать всё те же угрозы, что и разработчикам программ.


Автор:  Дмитрий Белявский (ТЦИ)

Возврат к списку