Уязвимости гипервизора – угроза виртуальной инфраструктуре и облаку

    При переходе от физической инфраструктуры к виртуальной возникает множество новых угроз. При расширении виртуализации до облака их список расширяется, а возможный ущерб от их эксплуатации многократно возрастает. В этой статье хотелось бы поговорить про одну из основных «новых» угроз в виртуальной среде – уязвимости гипервизора.
    Рассмотрим основные классы уязвимостей гипервизоров на примере VMware vSphere и возможные пути защиты от их эксплуатации.

    Переполнение буфера и вызов произвольного кода

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

    Примеры известных уязвимостей:
    CVE-2012-1516...1517, CVE-2012-2448...2450 – VMX-процесс в ESXi 4.0-5.0 и ESX 3.5-4.1 уязвим из-за ошибки в обработке RPC-команд, при эксплуатации уязвимости, возможно переполнение памяти и выполнение произвольного кода на хостовой операционной системе из гостевых операционных систем.

    CVE-2013-3657 – Удаленный пользователь может отправить специально сформированный пакет на ESX 4.0-4.1 и ESXi 4.0-5.0 и вызвать переполнение буфера с запуском произвольного кода или отказом в обслуживании.

    CVE-2013-1405 – Удаленный пользователь может отправить специально сформированный пакет авторизации в ESX 3.5-4.1, ESXi 3.5-5.0 и vSphere Server 4.0-4.1, который вызовет переполнение буфера и запуск произвольного кода.

    CVE-2012-2448 – Удаленный пользователь может отправить специально сформированный NFS-пакет на ESX 3.5-4.1 и ESXi 3.5-5.0 и вызвать переполнение буфера с запуском произвольного кода или отказом в обслуживании.

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

    Повышение прав пользователя внутри виртуальной машины

    Целый класс уязвимостей гипервизора позволяет нарушить работу гостевой операционной системы виртуальной машины и повысить права пользователя в ней. В среде ESX/ESXi такие атаки реализуются обычно через два основных направления – эксплуатация уязвимостей в VMware Tools (набор утилит и драйвером для гостевой операционной системы) или через прямой доступ к памяти виртуальной машины через гипервизор в обход механизмов доступа гостевой операционной системы.

    Рассмотрим на примерах:
    CVE-2012-1666 – уязвимость VMware Tools в ESX 4.0-5.0 позволяет повысить права доступа пользователю гостевой операционной системы внутри неё с помощью заражения вредоносным кодом файла tpfc.dll.

    CVE-2012-1518 – уязвимость ESXi 3.5-5.0 и ESX 3.5-4.1, позволяющая повысить права доступа пользователю гостевой операционной системы внутри неё с помощью переполнения буфера в VMware Tools, если права доступа для директории с VMware Tools настроены неправильно.

    Защититься от данного класса уязвимостей можно путем отказа от установки VMware Tools и применяя классические средств защиты информации от несанкционированного доступа внутри гостевой операционной системы, аналогично физическому компьютеру.

    Отказ в обслуживании

    В конце списка идет наименее опасный в плане компрометации информации класс уязвимостей, однако подобные уязвимости влияют на другой показатель – доступность. И их реализация негативно сказывается на качестве услуг облачного провайдера, репутацию сервиса и, в конечном итоге, на прибыли. Речь идет об ошибках гипервизора, используя которые злоумышленник может привести к отказу в обслуживании, не затрачивая при этом больших усилий. Отказ в обслуживании путем генерации большого объема мусорного трафика не рассматривается как специфичная для гипервизора угроза. Речь идет об уязвимостях, при которых один или несколько простых сетевых пакетов или команд приводят к остановке в работе гипервизора целиком или отдельных его служб.
    Как и в случае с переполнением памяти эти ошибки могут содержаться и во внешних интерфейсах, и во внутренних функциях виртуальных машин.

    Примеры подобных уязвимостей:
    CVE-2013-5970 – сервис hostd-vmdb в ESXi 4.0-4.1 и ESXi 4.0-5.0 может быть выведен из строя путем отправки специально подготовленного сетевого пакета.

    CVE-2012-5703 – API для работы внешних служб (vSphere API) в ESXi 4.1 и ESXi 4.1 содержат ошибку, которая может вызвать падение и отказ в обслуживании службы, принимающей запросы API, в случае отправки неверного значения параметров команды RetrieveProp и RetrievePropEx.

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

    Заключение

    Есть и универсальный способ защиты от известных атак, например, применение обновлений безопасности («патчей») самого производителя и обновление версий программного обеспечения до последних.
    Однако у такой защиты есть два недостатка. Во-первых, существует большое множество уязвимостей, известных только узкому кругу злоумышленников, но пока неизвестных производителю и, соответственно, неучтённых им. Во-вторых, при использовании сертифицированного ФСТЭК гипервизора его обновления запрещены, так как нарушают целостность бинарных файлов.
    Поэтому рекомендуется использовать сертифицированные наложенные средства защиты виртуальной инфраструктуры и по возможности применять не сертифицированный гипервизор последней версии с последними обновлениями безопасности. Только этот способ позволяет максимально нейтрализовать угрозу, связанную с наличием уязвимостей в программном обеспечении гипервизора.
    Код Безопасности
    44,00
    Компания
    Поделиться публикацией

    Комментарии 10

      0
      Заключение: нельзя использовать VMWare, он дырявый?
        0
        Можно использовать. Уязвимости есть в любом продукте, главное оперативно применять обновления и использовать дополнительные наложенные средства защиты, которые будут первым эшелоном защиты.
        +5
        Прошу в заголовке уточнить что дело идет о VMware ESX only, а другие гипервизоры не рассматриваются в принципе.
        Более того разговор идет не о обзоре уязвимостей и видах атак, но происходит перечисление известных недостатков устаревших версий конкретной платформы.
          0
          Тема затронута правильная. Сейчас все больше хостингов предоставляют выделенные гипервизоры (ESXi и Xen чащe всего), которые, будучи поставленными из коробки и видимые извне, выглядят весьма голыми и незащищенными. Последнее время я активно использую ESXi на толстых хостингах и первой командой обычно прописываю на командном интерфейсе route на свои выделенные адреса и дропаю default )
            0
            Как защититься от атак на «помогающие защититься» наложенные средства защиты виртуализации?
              0
              Тут два аспекта. Первый — подобные средства проектируются с учетом требований к высокой степени защиты, разработка ведется по методологиям защищенного программирования и, как следствие, актуальных угроз для этих средств гораздо меньше. Второй — эшелонирование обороны, для реализации атаки нужно найти такой вектор, который позволит пробить и наложенное средство защиты и встроенные механизмы среды виртуализации, что усложняет задачу многократно.
                0
                Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования» — неразумно.

                Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
              0
              Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования».

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

                По второй части — всё верно, от закладок в ПО и аппаратной части таким методом не защититься. Для этого предусмотрены сертификации по «РД НДВ» и т.д., но сертифицированных по этим требованиям гипервизоров нет. Поэтому можно говорить о невозможности универсальной защиты от данной угрозы, с другой стороны, риск реализации достаточно низкий, пока эти закладки не становятся публично известными.
                  +1
                  Это вы утверждаете, что процедура прохождения сертификации по «РД НДВ» гарантирует отсутствие закладок? Смешно.

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

              Самое читаемое