|
https://forum.antichat.xyz/attachmen...8869171570.png
Конфигурационные чек-листы, политики паролей и стандарты «харденинга» - это лишь верхушка айсберга под названием «безопасность ОС». Настоящая битва происходит в тёмных глубинах: в коде ядра, где один пропущенный байт может обрушить все барьеры; в логике гипервизора, чья абсолютная изоляция иногда оказывается миражом; в механизмах контейнеров, где легковесность часто оплачивается хрупкостью границ. Эта статья - разбор основ, которые предпочитают не трогать. Мы снимаем слои абстракций и показываем, как на самом деле работают и как ломаются ключевые механизмы защиты в ядрах Windows, Linux и macOS. А затем спускаемся ещё ниже - к гипервизорам и контейнерам, чья безопасность полностью зависит от надёжности этих самых ядер. Речь пойдёт не о теориях, а о конкретных атаках: эксплуатация Use-After-Free в драйверах, побег из виртуальной машины через баг в эмуляции устройства, компрометация кластера Kubernetes через уязвимость в kubelet. И о том, как проектировать системы, зная, что фундамент может дать трещину. Краткий экскурс: как мы дошли до жизни такой Давай посмотрим, как эволюционировала защита:
Что значит «низкоуровневая атака» в нашем контексте?
Когда это доверие нарушается, рушится вся пирамида безопасности, построенная сверху. Самый красивый фасад из политик и правил становится бесполезным. 1. Архитектура безопасности современных ядер ОС Ты загружаешь операционную систему. Видишь красивый интерфейс, окна, иконки. Под этой картинкой - дикий, тоталитарный и до безумия сложный мир ядра. Именно здесь, в этом «кольце 0», принимаются окончательные решения: можно ли процессу прочитать эту память? Открыть этот файл? Отправить этот пакет в сеть? Безопасность на этом уровне - это не про политики паролей. Это про архитектурные гарантии и их изъяны. Понимать это - всё равно что знать, где в крепости спроектированы потайные ходы, ещё до того, как по ней начнут бить тараном. https://forum.antichat.xyz/attachmen...8871476103.png 1.1. Windows: Мир объектов, или тотальная диктатура с благими намерениями Объектная модель: Представь, что каждый процесс, поток, файл, ключ реестра, мьютекс и даже семафор в системе -это объект в святая святых, в пространстве ядра. У каждого объекта есть дескриптор - что-то вроде пропуска в казино. Приложение не работает с объектом напрямую. Оно говорит ядру: «Эй, у меня есть пропуск №12345, хочу почитать файл». Ядро смотрит на пропуск, находит объект и проверяет: а есть ли у процесса, который держит этот пропуск, нужные права? Права эти записаны в Access Control List (ACL) объекта. Это суровый список «кто что может». Владелец? Администраторы? Система? Каждой группе или пользователю выставляются битовые маски прав: Код:
FILE_READ_DATA, PROCESS_TERMINATE, THREAD_SUSPENDIntegrity Levels и Protected Processes: война с самим собой Со временем Microsoft поняла, что делить мир только на «пользователей» и «админов» - мало. Так родился Mandatory Integrity Control (MIC). Каждому процессу и объекту присваивается уровень целостности: Low, Medium, High, System. Процесс с низким уровнем (например, браузер в Enhanced Protected Mode) не может писать в объекты с высоким уровнем, даже если в ACL у него есть все права. Это попытка сдержать взломанное приложение в песочнице. Апофеозом этой паранойи стали Protected Processes (PP) и Protected Processes Light (PPL). Это процессы, к которым запрещён доступ извне даже администратору с DEBUG правами. Попробуй запусти Process Explorer и убить антивирусный процесс MsMpEng.exe - не получится. Эта технология, рождённая для защиты DRM в играх, стала основой Credential Guard, который хранит хэши паролей в процессе, недоступном даже для SYSTEM. Обойти это - холи грейл для многих атак на Windows. Virtualization-Based Security (VBS): последний рубеж Когда ты не можешь доверять даже собственному ядру (потому что эксплойты достают до ring0), что делаешь? Правильно, запускаешь ядро внутри виртуальной машины. Так работает Hypervisor-Protected Code Integrity (HVCI) и тот же Credential Guard. Ядро Windows и критические компоненты безопасности запускаются в изолированной виртуальной машине, защищённой гипервизором (Hyper-V). Атаковать их можно только через уязвимости в самом гипервизоре, что на порядки сложнее. PatchGuard и DSE: война с руткитами на поражение Ты - злоумышленник. Ты получил права ядра. Твоя цель - остаться там навсегда, спрятаться. Классический способ - запатчить ядро, изменить его код или структуры данных в памяти. Kernel Patch Protection (PatchGuard) - это часовой внутри ядра, который периодически проверяет критические структуры на целостность. Обнаружив изменения - паникует и перезагружает систему, сбрасывая руткит с доски. Driver Signature Enforcement (DSE) - это контроль на въезде. Только драйверы, подписанные доверенным сертификатом Microsoft, могут быть загружены в ядро. Хочешь загрузить свой руткит? Лиши его доступа к Test Signing, либо найди уязвимость в самом механизме проверки подписи (как это было с CVE-2018-0896). Итог по Windows: Это цитадель, построенная с расчётом на то, что враг уже внутри. Её безопасность - это слои и слои контроля, где каждый следующий призван защищать от падения предыдущего. Взламывать её - значит играть в шахматы с системой, которая знает все твои прошлые ходы. https://forum.antichat.xyz/attachmen...8869996309.png 1.2. Linux: Монолит с модульной свободой. Или анархия? Если Windows - это тоталитарная империя с жёсткими правилами, то Linux - это вольный город с невероятно мощными, но опциональными законами. Его безопасность не диктуется свыше по умолчанию. Её строит сам администратор. И в этом - её сила и её главная слабость. Namespaces и cgroups: песочницы, которые мы заслужили Всё, что ты знаешь о Docker и контейнерах, выросло из двух фундаментальных механизмов ядра Linux.
Capabilities: расчленение всемогущества В мире Linux root - это не единая сущность. Это набор из 40+ привилегий (capabilities), которые можно включать и выключать по отдельности. Процесс может иметь право Код:
CAP_SYS_ADMINКод:
CAP_NET_RAWКод:
CAP_DAC_OVERRIDEКод:
CAP_SYS_BOOTSELinux и AppArmor: принудительный контроль для тех, кто не боится Если capabilities ограничивают процессы, то Security-Enhanced Linux (SELinux) и AppArmor контролируют всё: процессы, файлы, сокеты, IPC. Это реализация модели Mandatory Access Control (MAC). SELinux работает на основе меток (контекстов безопасности), которые присваиваются всем объектам в системе. Правила (политики) в тысячах строк кода определяют, может ли процесс с меткой httpd_t читать файл с меткой user_home_t. Главная проблема SELinux - его адская сложность. AppArmor проще: он описывает профили в виде путей к файлам. Но оба инструмента, будучи правильно настроенными, - это бронежилет для системы. Проблема в том, что 90% админов видят в них врага и отключают. Итог по Linux: Это конструктор безопасности максимальной гибкости. По умолчанию он даёт тебе мощь и свободу зарезать себя об острые углы. Его безопасность - это результат осознанного выбора и кропотливого труда. Здесь нет волшебной таблетки Credential Guard. Есть только grsecurity, PaX (и их потомки), seccomp-bpf и твоя голова. Атаковать Linux - это часто значит не взламывать защиту, а находить системы, где её забыли включить, или где она криво настроена. https://forum.antichat.xyz/attachmen...8870548684.png 1.3. macOS (XNU): Гибрид под диктатурой эстетов macOS - это особый путь. Её ядро XNU - это гибрид: микроядро Mach (отвечает за низкоуровневые вещи вроде IPC и планирования потоков) и тяжёлый монолит BSD (всё остальное: сетевой стек, файловые системы). Безопасность здесь - это жёсткая воля Apple, не терпящая сопротивления. Sandbox Framework (Seatbelt): тюрьма для всего Почти каждое приложение в macOS работает внутри песочницы. Это не опция, это правило. Сетевой доступ? Только через санкционированные API. Доступ к файлам? Только в пределах разрешённых директорий (~/Downloads, ~/Documents) или через диалог выбора файла. Эта песочница, прозванная Seatbelt, - главный ограничитель. Даже если в Safari найдёть RCE, злоумышленник окажется в тесной клетке с сильно ограниченными возможностями. Взлом превращается в поиск способа сломать или обойти саму песочницу. System Integrity Protection (SIP): запрещено даже для Бога Ты -root. Ты - администратор. Ты хочешь записать файл в /System/Library/Extensions или модифицировать системный бинарник. В любой другой системе - без проблем. В macOS с включённым SIP - запрещено. SIP (также известный как rootless) - это набор ограничений на уровне ядра, которые защищают критические части системы даже от суперпользователя. Его можно отключить (зажав клавиши при загрузке), но тогда система громко скажет, что она «может быть повреждена». Это философский подход: целостность системы важнее полномочий администратора. Apple Mobile File Integrity (AMFI) и подпись кода Ни один код не может быть выполнен в системе, если он не подписан доверенным сертификатом от Apple (или Developer ID). Это правило железобетонно. Попытка загрузить неподписанный драйвер ядра (KEXT) или запустить модифицированное системное приложение приведёт к отказу. Это убивает целый класс руткитов и троянов с места в карьер. Атака здесь - это либо кража доверенного сертификата, либо эксплуатация уязвимости в механизме проверки подписи. Итог по macOS: Это «безопасность через диктатуру». Пользователю (и администратору) не дают возможности выстрелить себе в ногу. Система жёстко контролирует всё, от запуска кода до доступа к файлам. Взламывать её - значит воевать не со слабой конфигурацией, а с продуманными, глубоко интегрированными в систему механизмами принудительного контроля, которые Apple совершенствует годами. Это сложный, но высокоценный противник. Все эти ОС объединяет одно: вся их безопасность основывается на непогрешимости ядра. На том, что его код, его механизмы проверки, его изоляция - безупречны. Дальше поговорим о том, почему это опасная иллюзия, и как эти фундаменты дают трещины под давлением низкоуровневых атак. 2. Атаки на механизмы ядра 2.1. Общие векторы атак на пространство ядра: Искусство находить трещины в камне Прежде чем бить в конкретную стену Windows или Linux, нужно понять, из какого материала она сложена и где её структурные слабости. Драйверы: троянский конь в сердце цитадели Самый классический и жирный вектор. Зачем ломать дверь, если можно попросить часового внутри открыть её? Драйверы работают в пространстве ядра (ring 0) с максимальными привилегиями, но часто пишутся третьими сторонами (вендорами железа, периферии) с качеством кода... скажем так, неидеальным. Уязвимость в драйвере сетевой карты, принтера или даже виртуального диска - это прямой пропуск в ядро. Пример? Драйверы Capcom.sys или Intel Audio Drivers в прошлом содержали фатальные дыры, позволяющие из пользовательского режима выполнять произвольный код в ядре. Мораль: Безопасность ОС равна безопасности самого слабого загруженного в неё драйвера. Use-After-Free (UAF) в пулах памяти ядра Представь, что ядро - это отель. Процессы снимают номера (выделяют блоки памяти), живут в них, а потом освобождают. UAF - это ситуация, когда ядро забывает, что номер уже освобождён, и отдаёт ключ от него новому постояльцу, в то время как старый ещё не вернул ключ и может туда зайти. В контексте ядра это выглядит так:
Та же старая песня, но на привилегированной сцене. Если драйвер или системный вызов некорректно проверяет размер копируемых в буфер ядра данных, атакующий может записать за его границы. Это может перезаписать соседние критичные структуры данных, изменить указатели или перезаписать код. В современных ОС с KASLR (рандомизацией адресного пространства ядра) и SMEP/SMAP (защитой от выполнения пользовательского кода в ядре) это сложнее, но не невозможно. Атаки на логику безопасности: Иногда не нужно ничего переполнять. Достаточно понять логику и обмануть её.
Здесь играют по правилам, о которых я писал вначале, но ищут в них изъяны. Win32k.sys - вечная золотая жила Это гигантский драйвер, отвечающий за весь пользовательский интерфейс. Огромная кодовая база, сложная логика, работа с пользовательскими данными. Он был и остаётся рассадником уязвимостей для локального повышения привилегий (LPE). Атаки через Win32k - это часто сложные цепочки использования bitmaps, palettes или других объектов GDI, приводящие к тому самому UAF или переполнению в ядре. Атаки на MSR-регистры и SMEP SMEP (Supervisor Mode Execution Prevention) - аппаратная защита, запрещающая ядру исполнять код, находящийся в пользовательской памяти (например, твой шеллкод). Как обойти? Нужно сделать так, чтобы ядро думало, что исполняет свой код.
Прямая атака на PatchGuard - дело сложное. Чаще ищут уязвимости в механизмах, которые он должен защищать. Например, CVE-2018-0896 позволяла обойти DSE и загрузить неподписанный драйвер, эксплуатируя уязвимость в логике проверки загрузки драйверов с тестовыми подписями в определенных версиях Windows. Другие атаки могут нацеливаться на гипервизор (Hyper-V), который лежит в основе VBS. Уязвимость в гипервизоре (например, CVE-2021-28476 в hvix64.exe или hvax64.exe) - это крах всей модели VBS, потому что доверенная вычислительная база (TCB) оказывается скомпрометированной. 2.3. Linux-specific атаки: Эксплуатация простоты и мощи В Linux многое построено на доверии и аккуратности. Когда это доверие нарушается, последствия масштабны. Dirty Pipe (CVE-2022-0847) - шедевр простоты Недавний, блестящий пример атаки на логику ядра. Уязвимость была в подсистеме pipes и splice(). Из-за ошибки инициализации флагов страниц памяти можно было писать в файлы, открытые только на чтение, обходя все проверки прав. Любой непривилегированный пользователь мог перезаписать root-бинарники вроде su или sudo, моментально получая полный контроль. Гениальность - в использовании легальных, документированных системных вызовов (splice()) для достижения незаконного результата. Атаки на eBPF: Оборотная сторона суперсилы eBPF - это мощнейшая технология для безопасного выполнения пользовательского кода в ядре для мониторинга и фильтрации. Но её верификатор, гарантирующая безопасность этого кода, - сложнейший кусок программы. Уязвимости в верификаторе (например, CVE-2021-31440) позволяли обойти проверки и выполнить произвольный код в ядре. Это идеальный пример: сам инструмент безопасности становится вектором атаки. Обход namespaces и cgroups Контейнеры - это не ВМ. Если в контейнере есть привилегия CAP_SYS_ADMIN (а она часто есть в «привилегированных» контейнерах), процесс внутри может делать страшные вещи:
Здесь атакуют не слабую конфигурацию, а самые сильные, централизованные механизмы. Обход SIP через легитимные компоненты Прямая атака на SIP - это перезагрузка с отключенным SIP. Настоящие атаки хитрее. Они ищут системные процессы или драйверы, которые имеют право писать в защищённые локации. Если такой процесс содержит уязвимость (например, в парсинге входных данных), его можно заставить выполнить работу за злоумышленника. Так работали многие эксплойты нулевого дня: они не ломали SIP, они использовали доверенного посредника, который имел необходимые привилегии. Эксплуатация уязвимостей в IOKit IOKit - это фреймворк для драйверов в macOS, написанный на подмножестве C++. Как и любые драйверы, они содержат ошибки. Уязвимости в драйверах графики, сетевых карт или USB-контроллеров - стандартный путь в ядро XNU. Из-за монолитности BSD-части ядра компрометация через драйвер часто даёт сразу огромную власть. Логические ошибки в Sandbox профилях Песочница (Seatbelt) описывается профилями в формате SBPL (SandBox Profile Language). Если в этом профиле для критичного системного процесса (например, launchd или системного демона) не прописано достаточно строгое правило, процесс может вырваться из изоляции. Или, наоборот, если приложение имеет слишком широкий профиль (например, многие инструменты разработчика), его скомпрометированная версия может натворить дел. Поиск таких логических дыр - целое искусство. https://forum.antichat.xyz/attachmen...8869418598.png 3. Безопасность гипервизоров Мы добрались до святого святых современной инфраструктуры - уровня гипервизора. Если ядро ОС - это закон внутри государства, то гипервизор - это закон мироздания, отделяющий одно государство от другого. Он создаёт и контролирует виртуальные вселенные, каждая со своим ядром, своими процессами, своей иллюзией полного контроля над железом. Доверие к гипервизору - абсолютное. Если ты арендуешь VM в облаке, вся твоя безопасность строится на вере, что сосед по физическому серверу не сможет из своей виртуальной машины прорваться к твоей. VM Escape - это не просто очередная уязвимость. Это крах самой парадигмы. Это вселенский баг, позволяющий вырваться из симуляции. 3.1. Архитектурные основы: как устроена вселенная и кто её смотритель Прежде чем ломать, нужно понять, что именно мы ломаем. Тип 1 (bare-metal) vs. Тип 2 (hosted): разница в доверии
Раньше виртуализация была костылём: гипервизор кропотливо эмулировал все инструкции гостя, что было дико медленно. Появление аппаратной виртуализации изменило всё. Процессор научился работать в двух режимах:
Паравиртуализация (Paravirtualization, PV): гость в курсе, что он виртуальный Чтобы не платить производительностью за каждый чих, гостевой ОС дают специальные паравиртуализованные (PV) драйверы. Вместо того чтобы эмулировать реальную сетевую карту e1000 с кучей VM Exits, гость через быстрый механизм (как virtio в KVM или vmxnet в VMware) напрямую говорит гипервизору: «Эй, отправь этот пакет». Это быстрее, но расширяет поверхность атаки: теперь в гостевом ядре работает сложный код, который активно общается с гипервизором. Баг в PV-драйвере на стороне гостя - прямой путь к атаке на гипервизор. 3.2. VM Escape: искусство сломать симуляцию Цель - получить выполнение кода в контексте гипервизора (или хостовой ОС для Type 2). Оттуда - всё: чтение памяти других ВМ, полный контроль над ними, доступ к сети хоста. Классика: уязвимости в эмуляции виртуального железа Самый жирный и исторически успешный вектор. Гипервизор должен эмулировать для гостя десятки устройств: BIOS, видеоадаптер (VGA), жёсткий диск (IDE/SATA), сетевую карту (E1000/VMXNET), USB-контроллер.
Для ускорения работы гипервизор и гость часто используют общие регионы памяти.
Это системные вызовы гостя к гипервизору. Гость вызывает специальную инструкцию (например, VMCALL в Intel VT-x), которая передаёт управление гипервизору с указанием номера вызова и аргументов.
Современные процессоры позволяют запускать гипервизор внутри виртуальной машины. Это нужно для облачных провайдеров, которые хотят продавать клиентам услугу «твой собственный KVM». Атакующий, арендовав такую VM, запускает внутри неё свой гипервизор и пытается атаковать гипервизор первого уровня со стороны гостя второго уровня. Это дико сложно, но расширяет поле для атаки, особенно на логику обработки вложенных VM Exits. Сценарий реальной атаки: от гостя к кластеру Допустим, ты злоумышленник, который арендовал VM в облаке.
Ирония в том, что сама технология, призванная обеспечить максимальную изоляцию, становится, будучи скомпрометированной, точкой катастрофического отказа всей системы безопасности. https://forum.antichat.xyz/attachmen...8869370344.png 4. Контейнеры: изоляция, которая не является виртуализацией (и почему это опасно) 4.1. Low-level механика изоляции: Иллюзия, создаваемая ядром Погрузимся в ту самую «общую канализацию», которой нет у ВМ. Docker под капотом: что на самом деле происходит, когда ты делаешь Код:
docker run -it alpine
Образ - это не бинарник. Это архив слоёв (тарболлов). Проблемы:
Container Escape: священный грааль Цель - из контейнера получить шелл на хостовой системе. Пути:
Это UNIX-сокет, через который Docker CLI общается с демоном (dockerd). Демон работает от root на хосте. Если ты смонтируешь этот сокет в контейнер ( Код:
-v /var/run/docker.sock:/var/run/docker.sock
K8s - это новый уровень абстракции и новые поверхности атаки.
Это уже не про «плохие образы». Это про:
1. Запуск без root (Rootless Containers) Это фундамент. Docker и Podman поддерживают режим, когда демон и контейнеры запускаются от обычного пользователя. Используется User Namespace для маппинга UID внутри контейнера. Даже если контейнер сбежит, он останется в пределах namespace непривилегированного пользователя на хосте, не сможет читать /etc/shadow или писать в системные директории. 2. Системы hardened ядра для контейнеров
Ни одна из рассмотренных систем не является «безопасной» по умолчанию. Каждая - это компромисс:
Главный вывод этой статьи не в том, какая ОС или технология безопаснее. Он в том, что твоя реальная безопасность равна надёжности самого слабого звена в этой цепочке доверия. Технологии меняются. Сегодня мы говорим о KVM и runc, завтра - о микровиртуализации Firecracker и формально верифицированных микроядрах seL4. Но принципы останутся: сложность - враг безопасности, доверие должно быть проверяемым, а изоляция - абсолютной там, где это критично. Твоя задача - не гоняться за каждой CVE. Твоя задача - спроектировать систему, в которой эксплуатация одной уязвимости не даст злоумышленнику ключей от всего королевства. Систему, где падение одной стены не обрушит весь замок, а лишь загонит атакующего в следующий, лучше укреплённый коридор. Игра в архитектора-параноика не заканчивается. Она просто переходит на следующий уровень. Ты теперь знаешь, где искать трещины в фундаменте. Осталось самое сложное - построить на этом знании что-то, что устоит. |
| Время: 18:44 |