Что взлом Xbox говорит о моделях безопасности железа

Microsoft проектировала систему безопасности Xbox One так, чтобы её нельзя было взломать. Аппаратный корень доверия. Собственный гипервизор. Зашифрованное хранилище с ключами для каждой консоли. Цепочка подписанной загрузки, где каждый этап проверяет следующий. Это был не театр безопасности, а по-настоящему продвинутая многоуровневая защита, созданная одной из лучших команд инженеров безопасности в индустрии. Они назвали её неприступной.

Её взломали. Группа, называющая себя «Bliss», получила полное выполнение кода на Xbox One, обойдя гипервизор, проверку цепочки загрузки и аппаратный процессор безопасности. Детали эксплойта увлекательны, но важнее то, что он показывает о фундаментальных пределах аппаратной безопасности и о том, почему слово «неприступный» всегда опасно.

Архитектура безопасности Xbox

Чтобы понять, почему этот взлом важен, нужно разобраться, что именно он обошёл. Модель безопасности Xbox One — одна из самых тщательных реализаций аппаратной безопасности в потребительских устройствах из когда-либо выпущенных.

Процесс загрузки начинается с аппаратного корня доверия — кода, прошитого в SoC, который нельзя изменить. Этот код проверяет и запускает следующий загрузчик, тот проверяет и запускает гипервизор, а гипервизор проверяет и запускает ОС. Каждый этап подписан ключами Microsoft. Если проверка любого этапа не проходит, консоль не загрузится. Это классическая цепочка безопасной загрузки, похожая на то, что предлагают ARM TrustZone и Intel Boot Guard.

Гипервизор — собственный компонент, работающий на уровне привилегий выше операционной системы — обеспечивает изоляцию памяти, контролирует доступ к железу и не даёт ОС менять критичное системное состояние. Игры и приложения работают в виртуальных машинах, которые не видят и не могут менять память друг друга. Даже если найти эксплойт ядра в ОС Xbox, вы всё равно останетесь внутри песочницы гипервизора.

Кроме того, хранилище консоли зашифровано ключами, получаемыми из аппаратного процессора безопасности. Вытащить жёсткий диск, подключить его к другой машине и извлечь что-то полезное нельзя. Ключи привязаны к конкретному железу. Это схема device-specific sealing, которую также используют TPM и Apple Secure Enclave.

Где броня треснула

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

Эксплойт Bliss не атаковал криптографию (AES и RSA в порядке), не нашёл ошибку в ROM корня доверия (он крошечный и хорошо проаудирован) и не перебирал ключи. Вместо этого он использовал интерфейс между доменами безопасности, узкий канал, через который доверенный и недоверенный миры общаются.

Аппаратные модели безопасности сильнее всего, когда поверхность атаки между уровнями доверия минимальна. Но «минимальная» не значит «нулевая». Гипервизор должен открывать гостевой ОС какой-то интерфейс: системные вызовы для управления памятью, доступа к устройствам и межвиртуальной коммуникации. Каждый из них — потенциальный вектор атаки. Команда Bliss нашла последовательность вызовов гипервизора, которые при определённых параметрах и в определённом порядке повредили внутреннее состояние гипервизора настолько, что удалось перенаправить выполнение кода.

Общая закономерность

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

• Взлом PS3 (2010) использовал катастрофическую ошибку реализации в генерации подписей ECDSA у Sony: для каждой подписи применялось фиксированное случайное число вместо нового, а это раскрывает приватный ключ. Математика была верной. Реализация — нет.
• Взлом Nintendo Switch (2018) использовал баг в boot ROM NVIDIA Tegra: режим восстановления по USB принимал полезную нагрузку, которая переполняла буфер и давала выполнение кода до того, как сработала хоть одна программная проверка безопасности. Цепочка загрузки была хорошо спроектирована. Режим восстановления просто не входил в модель угроз.
• Атаки на Intel SGX неоднократно показывали, что сторонние каналы (Spectre, Meltdown и их многочисленные варианты) могут утекать данные из защищённых анклавов, хотя модель изоляции архитектурно верна. Логика верна. Микроархитектура утекает информацию.

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

Почему «неприступный» — всегда ошибка

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

Когда Xbox One вышла в 2013 году, Spectre и Meltdown ещё не были открыты. Rowhammer был теоретическим. Атаки с глитчингом напряжения на современные SoC были мало изучены. Разработчики не могли защититься от атак, которые ещё не изобрели. А некоторые атаки, которые они всё же предвидели, тогда могли казаться непрактичными, но стали реализуемыми по мере развития инструментов и техник.

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

Что это значит для разработчиков

Большинство разработчиков не проектирует архитектуру безопасности консолей, но уроки применимы широко.

Интерфейсы между границами доверия — самый рискованный код. Граница между вашим бэкендом и публичным интернетом, между приложением и сторонними плагинами, между базой данных и пользовательскими запросами. Именно здесь живут баги, которые действительно важны. SQL-инъекция — это не баг в SQL или в вашей базе данных, а баг на стыке доверенной (ваша логика запросов) и недоверенной (пользовательский ввод) зон. Направляйте внимание к безопасности именно на эти границы.

Эшелонированная защита — не опция. У Xbox было несколько слоёв: аппаратный корень доверия, безопасная загрузка, изоляция гипервизором, шифрование хранилища. Взлома одного слоя было недостаточно. Атакующим пришлось связать несколько эксплойтов, чтобы получить полный контроль. Если бы система полагалась на одну границу безопасности, первый же эксплойт стал бы концом игры.

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

Парадокс открытой безопасности

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

Практический ответ в том, что оба подхода в конце концов дают сбой. Закрытые системы подвергаются реверс-инжинирингу (взлом Xbox это подтверждает). Открытые системы изучают и атакуют (постоянный поток CVE в ядре Linux это подтверждает). Разница в том, что открытые системы чинят быстрее, потому что у защиты такая же видимость, как у атаки. Уязвимость Xbox, какими бы ни были детали, будет сложнее закрыть, потому что модель безопасности зашита в железо, которое нельзя поменять в полевых условиях.

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

Что дальше

Взлом Xbox не положит конец безопасности консолей. Microsoft изучит эксплойт, закроет то, что можно закрыть программно, и спроектирует железо следующего поколения так, чтобы убрать этот класс уязвимостей. Атакующие найдут что-то другое. Это цикл: защита и атака эволюционируют вместе, а безопасность каждого поколения учитывает уроки провалов предыдущего.

Полезный вывод не в том, что аппаратная безопасность бессмысленна. Она существует как спектр, а не как бинарность. Защита Xbox сильно усложнила взлом: на него ушло больше десяти лет. Это огромный успех, даже если это не идеал. Цель не в неприступной системе. Цель — система, где стоимость атаки превышает ценность цели на весь срок, пока её нужно защищать. По этой мерке безопасность Xbox One была поразительно эффективной. Просто она не была бесконечной.