Павел Блинников, BI.ZONE: Гипервизоры будут оставаться ключевым элементом инфраструктуры

В рамках конференции OFFZONE 2025 редакция Anti-Malware.ru взяла интервью у Павла Блинникова — эксперта, который в компании BI.ZONE возглавляет группу исследования уязвимостей. В беседе Павел поделился опытом анализа защищённости гипервизоров, рассказал, почему они являются ключевым объектом исследования и какие методы анализа наиболее эффективны, а также перечислил трудности, с которыми приходится сталкиваться исследователям. 

Павел, в докладе на OFFZONE 2025 вы рассказывали о подходе к анализу безопасности гипервизора. Хотелось бы развить эту тему. Почему именно гипервизоры?

П. Б.: Главная причина в том, что сегодня весь мир работает с облаками, а облака — это в первую очередь гипервизоры. Фактически 99 % виртуальных машин запускаются именно на них. Это может быть QEMU, Oracle VirtualBox, VMware ESXi, но суть одна — это гипервизоры.

Мне эта тема особенно интересна, потому что мой опыт связан с бинарной эксплуатацией, а гипервизоры написаны на «небезопасных» языках — C / C++, с ассемблерными вставками. Сейчас не существует популярных гипервизоров, написанных на «безопасных» языках вроде Rust. Такая ситуация сохранится минимум на ближайшие десять лет. Гипервизоры будут оставаться ключевым элементом инфраструктуры, ведь это удобный инструмент для развёртывания и тестирования систем. Поэтому они представляют собой важную цель для анализа безопасности.

Согласен. Здесь ещё и цена ошибки высока. Если злоумышленник находит уязвимость в гипервизоре, то при определённых условиях он может получить доступ ко всей инфраструктуре. Достаточно компрометации одной виртуальной машины, чтобы пробиться дальше.

П. Б.: А если речь идёт о вымогателях, то они способны зашифровать все виртуальные машины и потребовать выкуп.

Звучит угрожающе. А какие подходы в целом сегодня используются для анализа защищённости гипервизоров?

П. Б.: В целом те же, что и при исследовании других программ на небезопасных языках. Это статический анализ с помощью разных движков — например, CodeQL. Можно разрабатывать собственные анализаторы. Используется фаззинг — как простейший, без сбора покрытия, так и более сложный, когда в гипервизор внедряется код для анализа покрытия.

Современные решения идут дальше: они с помощью статического анализатора сканируют ядро Linux, собирают информацию о взаимодействии драйверов с виртуальными устройствами гипервизора. На основе этих данных выполняется фаззинг, направленный на наиболее сложные компоненты — виртуальные устройства с большим объёмом кода и сложной логикой.

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

То есть, чтобы серьёзно заниматься анализом защищённости гипервизоров, надо хорошо знать, как работает «железо»?

П. Б.: Я бы сказал, что наоборот. В моём случае гипервизоры стали удобной входной точкой для понимания «железа». Изучать код проще, чем прошивки или спецификации оборудования, особенно если речь идёт об опенсорсных гипервизорах. Разобравшись в их коде, можно напрямую применять знания к тому, как работает хостовая операционная система с реальными устройствами.

За время анализа гипервизоров у вас сложился какой-то рейтинг? Где они более защищены, а где чаще всего допускают ошибки? Что можно было бы выделить для заказчиков?

П. Б.: У меня есть внутренний рейтинг, но делиться им я не хочу, это скорее мои личные ориентиры для выбора целей. Если говорить объективно, то одним из наиболее изученных является QEMU — гипервизор с открытым кодом, один из старейших. Большинство научных работ, на которые я ссылаюсь в докладах, изначально делались именно на QEMU.

Причина проста: значительная часть облаков работает именно на нём. QEMU легко ставится, хорошо документирован, и с ним просто работать. Например, Proxmox, популярный высокоуровневый гипервизор, изначально тоже построен на QEMU. Поэтому для тех, кто хочет развернуть облако, QEMU — самое доступное решение. Существует множество фаззеров под него, и в целом платформа очень проработана. При этом уязвимости продолжают находить, несмотря на глубину анализа, с которой его изучали. Сравнимых примеров среди других гипервизоров нет.

Самым сложным направлением остаются гипервизоры с закрытым кодом, такие как VMware ESXi. Их приходится исследовать, тратить много времени, и всегда есть отставание от тех, кто начал заниматься этим раньше: у них могут быть исходники или готовые наработки.

В сообществе исследователей закрытого кода есть негласное правило: никто не делится своими наработками. Уязвимость могут задокументировать и приложить демонстрационный эксплойт, но декомпилированный код, над которым работали месяцами, никто публиковать не будет. Поэтому информации для новых исследований мало. В этой области я бы рекомендовал начинать с QEMU или VirtualBox.

Вопрос, может быть, спорный, но всё же: что надёжнее и безопаснее — открытый код или закрытый?

П. Б.: Связь между открытостью / закрытостью кода и количеством уязвимостей отсутствует. На GitHub можно найти отличные библиотеки, в том числе для веба, с десятками тысяч звёзд. Но бывает так, что наш специалист по анализу веб-приложений тратит полчаса на анализ библиотек и находит в одной из них критическую уязвимость. Это довольно частая история: библиотекой пользуются все, но глубоко её не проверяют. 

Есть и другой пласт — очень популярные проекты, где находить уязвимости престижно. Например, ядро Linux. Там крупные вознаграждения: у Google есть kernelCTF, где за найденную ошибку можно получить до 300 тысяч долларов. Найти брешь «нулевого дня» (0-day) в ядре Linux — это уже событие. Похожая ситуация с QEMU: проект массово используется, за уязвимости там тоже хорошо платят. В закрытых продуктах исследователей меньше. Чтобы целенаправленно искать в них уязвимости, нужно буквально сделать это своей основной работой.

Хороший пример — VMware: Workstation или ESXi. Они существуют давно, ещё с конца 90-х, когда процессоры даже не поддерживали виртуализацию (Intel VT-x, AMD SVM). У них уже тогда была идея запускать компьютер внутри компьютера. За это время продукт сильно развился, и сказать, что он устарел, нельзя. Зато он очень хорошо исследован. Причин несколько. Во-первых, компания крупная, с сильной командой специалистов, которые сами анализируют свой софт. Во-вторых, комьюнити тоже давно и активно этим занимается.

Поэтому деление на открытый и закрытый код не так принципиально. Гораздо важнее — насколько продукт популярен и насколько престижно для исследователя найти в нём уязвимость.

Насколько я понял, работать с опенсорсом проще и порог входа там ниже. Логично предположить, что вероятность найти критический баг или эксплойт там меньше, чем в проприетарном софте, где, условно, может скрываться что угодно. Это правильно?

П. Б.: Отчасти да, но не совсем. Возьмём Log4j: это опенсорс, им пользовались по всему миру, но глубоко никто не смотрел. Как только начали анализировать — сразу нашли 0-day, который использовался «в дикой природе». Так что и в опенсорсе такое случается. Это не был бэкдор. Если говорить именно о закладках, то внедрить их в открытый код действительно сложнее.

Хороший пример — кейс с XZ годичной давности. Там совпало сразу несколько факторов. В Microsoft сотрудник тестировал производительность и заметил, что система стартует чуть медленнее, буквально на миллисекунды. Это и позволило выявить проблему. Иначе она вполне могла дойти до продакшена.

А если взять последние найденные уязвимости в гипервизорах — их можно как-то классифицировать, выделить категории? И какие выводы из этого следуют?

П. Б.: Глобально там такие же уязвимости, как в обычном софте на небезопасных языках: некорректное использование динамической памяти (use-after-free), переполнение буфера на куче, путаница типов (type confusion) — ничего принципиально нового. Отличие заключается в том, что обработка данных здесь происходит иначе: не через стандартный ввод, а через сложные каналы передачи, часто аппаратные.

Есть нюанс — уязвимости между уровнями привилегий (security rings). В обычных атаках мы идём, например, из пользовательского режима (user mode, третий уровень) в ядро (kernel mode, нулевой уровень). А здесь цель — уйти из нулевого в минус первый, где работает гипервизор. Это тоже повышение привилегий. Проблема в том, что у нас уже есть исполнение кода на каком-то уровне, и начинаются гонки: гипервизор обрабатывает данные, мы подменяем указатель, а ядро успевает его изменить обратно. И если мы сначала записали одни значения, затем изменили их обратно, а код уже использует небезопасные или непроверенные данные, система может выйти из строя.

Есть ли среди недавних примеров какая-то отдельная уязвимость, которую ваша команда нашла в гипервизоре и которую вы бы выделили особо?

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

Сейчас идёт активное импортозамещение, в том числе в системах виртуализации. Российских решений уже десятки, но часто процесс их создания выглядит так: берут готовое зарубежное, быстро «приземляют» на нашу базу, добавляют что-то своё — и сразу в продуктив. У меня возникает вопрос: не создаёт ли это дополнительных рисков, что плохо проверенный код начнёт широко использоваться? Или ядро всё-таки более-менее проверено, и риски не такие большие?

П. Б.: Ключевой компонент — гипервизор. Вокруг него можно написать веб-интерфейс или прикрутить свои драйверы, но ядро остаётся QEMU. Я смотрел несколько российских решений — это по сути аналог Proxmox: QEMU как ядро и обвязка вокруг. Это не даёт полной гарантии отсутствия ошибок. Закрытый код делает анализ сложным: мы не можем просто скачать дистрибутив и посмотреть. Для независимого исследования это проблема.

Хорошая новость: вероятность, что кто-то найдёт 0-day именно там, мала. Под силу это только высококвалифицированным группировкам, которые нацелены на госструктуры и крупные корпорации. Для обычных пользователей и компаний риски невелики. 

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

П. Б.: По моему опыту, всё зависит от компании и от обстоятельств, при которых была найдена уязвимость. Если она обнаружена в софте крупной компании и клиент узнаёт о 0-day, начинается сильное давление: «Ребята, срочно ставьте патчи, мы боимся».

В целом, если есть поддержка со стороны «большого брата», процесс идёт легко. Всё зависит от компании: кто-то говорит, что это вообще не уязвимость, а фича. В целом это не российская специфика, а мировая. Зрелость процессов и готовность признать, что код может быть небезопасным, играют ключевую роль.

А есть белые пятна в безопасности гипервизоров? Что ещё мало исследовано?

П. Б.: Хорошая новость для специалистов по безопасности: есть несколько сильных исследователей, которые занимаются гипервизорами, в основном в трёх вузах — в Бостонском университете, EPFL в Швейцарии и KAIST в Южной Корее. Они запускают умные средства для анализа безопасности софта, которые находят десятки «ноликов» за 24 часа на университетских серверах, без подстройки под конкретный гипервизор. 

Хороший пример — решение Morphuzz 2022 года, вошедшее в состав Google OSS-Fuzz, где средства для анализа работают непрерывно на огромных кластерах. Оно стало первым серьёзным инструментом для анализа защищённости гипервизоров, который в непрерывном режиме ищет и патчит уязвимости.

Белые пятна ещё остаются. Например, недавно вышел Truman, который анализирует код драйверов ядра Linux для построения модели поведения устройства (device behavior model). В перспективе умные ребята смогут совместить Truman, HyperPill, ViDeZZo и Morphuzz. Если у них будут ресурсы, они смогут запустить это в режиме нон-стоп, и инструмент для автоматического тестирования будет работать очень эффективно.

Сейчас в качестве площади атаки рассматриваются виртуальные устройства — это большая часть багов. Но остаются ещё гипервызовы (hypercalls), которые похожи на системные вызовы с третьего уровня на нулевой, только здесь выполняется переход с нулевого на минус первый. Это пока слабо исследованная тема. Есть HyperPill, но он пока не учитывает структуру данных и плохо работает с их внутренним устройством. Инструмент запускается легко, буквально по кнопке, всё работает, но его нужно дорабатывать, чтобы он функционировал как Syzkaller. У нас, кстати, Андрей Коновалов выступает по теме Syzkaller. Это, наверное, вообще самый крутой инструмент для ядра Linux. Андрей его написал, когда работал в Google. Если сделать аналогичный для гипервизоров, будет реально круто. Это ещё предстоит сделать.

Ещё есть специфичные каналы для конкретных гипервизоров. Например, механизмы Extended Page Table и Shadow Page Table, которые управляют трансляцией виртуальных адресов в физические на хосте. На хосте мы не управляем таблицей трансляции страниц, а на виртуальной машине она находится под нашим контролем. Виртуалка думает, что она хост, и транслирует виртуально-физический адрес. Там много нюансов, в том числе процессорные кеши. Это сложно, предстоит ещё долго анализировать.

Ещё есть операции с таймерами. Это не виртуальный девайс, а отдельный компонент гипервизора. Его почти никто не анализировал, поэтому стоит попробовать.

Связка «железо плюс гипервизор» фактически может быть любой. Существуют разные конфигурации, и на практике трудно предугадать, что может возникнуть на этом стыке. То есть может быть какое-то недостаточно защищённое «железо», даже если гипервизор у нас относительно защищённый и проанализированный.

П. Б.: Да, на самом деле всё сводится к двум моделям атак. Первая модель — когда мы сами хост. Например, если говорить о гипервизорах первого типа (Type 1), то при желании как-то повлиять на одно из установленных устройств это будет делаться примерно так же, как при атаке на гипервизоры: ломаем устройство и его прошивку, после чего можем получить исполнение кода внутри девайса. Это существующая модель атаки.

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

В целом атаки возможны в обе стороны, и данные могут быть скомпрометированы в обоих направлениях. Поэтому действительно могут возникнуть сложные ситуации.

Были ли прецеденты, например, с вредоносными прошивками жёстких дисков, которые теоретически могли бы быть на уровне гипервизора? Могло бы возникнуть что-то вроде современной версии вируса Chernobyl: найти уязвимость, повлиять на «железо» и выводить его из строя.

П. Б.: Проще всего, наверное, использовать электромагнитное излучение, и, в общем, этим всё ограничивается. Есть исследования в этом направлении, но они физически сложные. Это не моя область исследований, но знаю, что люди этим занимаются. Пока этот вопрос мало изучен, потому что он действительно находится на стыке физики и ИТ, и мало кто хорошо разбирается одновременно в обеих областях.

Верите ли вы в то, что с помощью наложенных средств можно компенсировать, так сказать, изначальную уязвимость гипервизора? Мы пытаемся накладывать на него дополнительные средства защиты информации, и интересно, возможно ли таким образом компенсировать уязвимость.

П. Б.: Очень сильно зависит от самой уязвимости. Тут вот в чём суть. Возьмём, например, гипервизоры второго типа (Type 2), которые превращают обычный пользовательский хост — Windows, Linux, macOS, неважно — в гипервизор. Они исполняются и на нулевом уровне, и на третьем — одновременно как процесс ядра и как пользовательский процесс. Всё зависит от того, куда мы попадём после эксплуатации уязвимости, — от самой уязвимости и от того, в каком девайсе она проявится. 

Если мы окажемся в пользовательском пространстве (user space) хоста после побега из виртуальной машины (VM escape), то обычные средства защиты, такие как детектирование и реагирование на конечных точках (EDR), могут сработать, потому что процесс фактически становится заражённым, и мы можем с ним работать уже привычными методами. Этот кейс аналогичен, например, Microsoft Word с макросом: процесс захвачен, но можно выполнять вредоносные действия. В целом для гипервизоров второго типа это работает. Если же мы попадём на нулевой уровень, то уже мало что поможет. На нулевом уровне эффективность средств защиты информации крайне ограничена.

На Linux есть хороший проект LKRG — Linux Kernel Runtime Guard. Он опенсорсный и разработан Solar Designer — опытным специалистом, который, кстати, написал программу аудита паролей John the Ripper. LKRG использует множество методов защиты, но самый наглядный — теневые (shadow) структуры. Мы копируем критически важные сущности, например структуру процесса и реквизиты доступа, и ведём свои копии. Если видим, что в оригинале что-то поменялось нелегитимно, процесс сразу же завершает работу.

Авторы LKRG понимают, что это не глобальная защита: многое зависит от мощности уязвимости. Если уязвимость очень серьёзная и может «арбитражить» память мгновенно, то мало что поможет. Но в целом проект защищает от большого числа уязвимостей, и злоумышленники чаще всего даже не знают о его присутствии.

Под Windows, насколько я знаю, ничего похожего нет. Там гораздо сложнее работать с такой защитой, нет аналогов Kprobe для работы с функциями. В общем, многое зависит от конкретной ситуации.

Например, на прошлом Pwn2Own участники проэксплуатировали уязвимость в ESXi — гипервизоре первого типа. Им понадобилась только одна уязвимость, чтобы выйти в ядро хоста. Это настолько мощно, что мало что помогает. Фактически ничего, кроме изоляции самого хоста: сетевая безопасность, VLAN-изоляция, возможно, сетевые анализаторы. Всё остальное уже не работает — хост точно скомпрометирован.

Хотел спросить о планах на будущее. Сейчас понятно, что есть определённое технологическое развитие. Я вижу, что многие больше увлекаются не серверной или хостовой виртуализацией, а контейнерной. Не планируете ли вы с командой заняться изучением Docker, Kubernetes и подобных решений? Говорят, там действительно есть чем заняться, потому что пространство для манёвра в этих технологиях колоссальное.

П. Б.: Да, тут важно понимать, что безопасность Docker на самом деле эквивалентна безопасности ядра Linux. Если есть уязвимость в ядре, мы спокойно можем выйти из контейнера и попасть в главное пространство имён (имеется в виду namespace), фактически сбежав. Архитектурно это всегда так работает, это концепция конструктивной безопасности (security by design). Но при неправильной конфигурации контейнеров могут возникать ошибки — кто-то может примонтировать туда лишнее, и атакующий получит доступ к хосту, к диску, к сокетам. Пентестеры об этом прекрасно знают — это не новость.

Архитектура по сути строится на ядре Linux. Ядро Linux активно исследуется, это один из самых престижных проектов в плане безопасности. Есть множество хороших инструментов для анализа. Например, Syzkaller, который работает нон-стоп. Каждый час бот, запускающий Syzkaller для поиска уязвимостей, фиксирует примерно 20–30 сбоев. За сутки их количество будет огромно, их просто не успевают разбирать. Хорошая новость в том, что эти баги сложно эксплуатировать. На различных конференциях показывают, как кто-то исследовал баги с помощью бота. Некоторые оказались неэксплуатируемыми, их оставили. Но некоторые разобрали — поняли, что эксплуатируемые, и на kernelCTF получили деньги.

Но глобально проблема не решается. Ядро Linux написано на C, а переход на Rust пока крайне медленный. Сам Линус Торвальдс не особо стремится переписывать на Rust.

C и C++ — очень небезопасные языки. Даже опытный программист может допустить по десять ошибок за день. Поэтому здесь стоит думать в сторону микроядер. Например, «Лаборатория Касперского» разрабатывает KasperskyOS, и это шаг в правильном направлении с точки зрения конструктивной безопасности.

В ядре минимальная площадь атаки, почти ничего нельзя сломать напрямую, драйверы находятся в пользовательском пространстве, что снижает риски. Если атакующий ломает драйвер, новые привилегии не появляются. Это правильное направление. Но очевидно, что весь мир привык к существующим операционным системам, их трудно менять, и весь софт нужно портировать на KasperskyOS или аналогичные платформы, если мы хотим его запускать. В общем, это сложно.

Спасибо большое за интересное интервью! Мне кажется, аудитории будет полезно. Желаю успехов в поиске новых уязвимостей и развитии проектов!