Эвакуация в облачных средах или как выйти за пределы контейнера

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

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

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

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

Что такое контейнер: знакомимся с самим понятием

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

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

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

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

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

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

Чтобы минимизировать всевозможные риски и проблемы при работе с контейнерами важно понимать, как они функционируют.

Особенности работы контейнеров: что об этом надо знать

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

• четко не определенные переменные среды;
• разрешения;
• возможности;
• пространства имен.

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

В своем большинстве на практике среда выполнения контейнеров применяется через дополнительные приложения. Это может быть система оркестрации или же CLI. То есть здесь они выступают в качестве дополнительного звена при взаимодействии со средой контейнера. Из наиболее популярных таких решений можно выделить Docker Engine, Dockerfile, Kubernetes. Первые 2 — это CLI, а последние — система оркестрации.

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

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

Атрибут «Возможности»

Атрибут «Возможности», то есть Capabilities — это своего рода диапазон действий, которые сможет выполнить запущенный процесс. Операционная среда Linux способна разделять все привилегии, относящиеся к суперпользователям на отдельные блоки. Это есть атрибут «Возможности». Его вы сможете включать или же отключать по мере необходимости, причем независимо друг от друга. Операционной среде в работе необходимо ограничивать ряд процессов. Здесь используются различные средства, а не только пользователи, группы. Именно для выполнения таких задач и используется атрибут Capabilities. Он способен принудительно ограничивать операции, которые также могут брать на себя все процессы, наделенные root-привилегиями. Среди прочего сюда относятся также такие решения как chown и ptrace — одни из ключевых элементов в массиве корневых операции. Их выполнение на практике можно будет легко держать под контролем благодаря использованию атрибута «Возможности».

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

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

Атрибут «Пространство имен»

Предыдущий атрибут определял то, что может делать тот или иной процесс, а вот «Пространство имен» (Namespaces) уже указывает на то, в каком именно месте все эти действия могут быть реализованы. То есть по своей сути данный атрибут — это то, что обеспечит всем процессам, осуществляющимся на родительском и дочернем уровне, возможность взаимодействовать так, как будто у них есть собственные исключительные экземпляры непосредственно в глобальном ресурсе.

На сегодня выделяют разные виды Namespaces. Причем каждое из них будет отвечать за свой конкретный тип глобального ресурса в операционной системе. Одно из наиболее простых здесь решений с точки зрения понимания будет пространство имен ID процессов, то есть PID. Работает это в следующей последовательности:

1. В то время как администратор либо же программное обеспечение создаст новое пространство имен, операционная система присваивает ответственному за это процессу статус PID 1.
2. После этого статус PID 2 будет присваиваться уже дочернему процессу и т.д.
3. Количество статусов может быть разным: PID 3, PID 4, PID 5 и так далее для каждого из дочерних процессов.

В реальности все будет работать примерно следующим образом. Предположим, что у вас есть процесс, который работает с root-привилегиями и наделен какой способностью, как CAP_KILL (позволяет не выполнять проверки при отправке сигналов). В итоге мы получаем решение, которое позволит данному рабочему сценарию обходить соответствующие проверки разрешений практически в каждом из процессов. Но если все это перенести в новое Namespaces PID, то здесь уже появятся ограничения на завершение процессов в рамках определенного пространства имен. При этом все другие операции за его пределами вовсе не будут существовать для вашего основного процесса, наделенного CAP_KILL.

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

Побег из контейнера: знакомимся с особенности на примерах

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

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

1. Помощники пользовательского режима.
2. Повышение привилегий при помощи SUID.
3. Log Mounts.

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

Что представляет собой выход из контейнера Помощники пользовательского режима

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

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

В рамках подобной атаки также может использоваться еще вспомогательный метод пользовательского режима на основании cgroup и соответствующего ему файла release_agent. Такая тактика также может способствовать выходу из контейнера. В этом случае злоумышленник, обладающий root-правами, может воспользоваться вспомогательным методом пользовательского режима и внести корректировки в ресурсы, характерные для определенного процесса. В результате его действий запускаются ограничения на использование этих самых ресурсов. Здесь применяется та техника, которая была представлена на Black Hat USA еще в 2019 году. И предназначалась она для выхода из cgroup release_agent. Как только злоумышленники включали соответствующего агента, у них появлялась возможность выполнить программу для очистки группы.

Чтобы реализовать подобное, проводятся следующие работы:

• Создается и монтируется каталог. Ему присваивается контрольная группа.
• Внутри cgroup формируется еще один каталог. В итоге создается еще одна новая группа.
• Содержимое файла notify_on_release устанавливается да позицию «1». Благодаря этому в работу запускается специальный механизм пользовательского режима. По умолчанию он будет находиться уже в каждой новой группе.
• Задается абсолютный путь к исполнительным файлам непосредственно через документ release_agent. Он хранится непосредственно в корневом каталоге в рамках каждой группы, но при это будет таким же, как и для всех cgroups. Злоумышленник без проблем сможет получить абсолютный путь к этому каталогу путем запроса соответствующего файла из контейнера.
• Выполняется очистка группы. Для этого достаточно прописать «0» в документ cgroup.procs. Исполняемый файл, который ранее был задан в release_agent все равно будет выполняться даже том случае, если изначально группа была пустой.

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

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

Как можно обнаружить атаки осуществляемые методом помощника пользовательского режима?

Чтобы не пропустить подобную атаку, необходимо будет использовать системный подход, включающий:

1. Полную каталогизацию всех call_usermodehelper-вызовов, что используются ядром. Вам необходимо будет их постоянно сопоставлять, чтобы выявить сторонние.
2. Обратите внимание на то, какие вызовы подверглись программных манипуляциям через файлы, относящихся к пользовательскому режиму.
3. Проверьте, возможно ли в вашем случае измерить все файлы, находящиеся в контейнере для того, чтобы выполнить назначенную программу.
4. Выполняйте регулярный мониторинг файлов. Только так можно будет выявить изменения в связанных файлах, имеющих отношение к каждому из помощников. Особое внимание в данном случае следует обратить на те изменения, которые наблюдаются в программах пользовательского режима контейнера.

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

Что представляет собой выход из контейнера путем повышения привилегий с применением SUID?

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

Основная проблема здесь скрыта в том, что бит SUID/GUID, который необходим для файла, находящегося в контейнере, сможет сохранить свои права и разрешения даже за его пределами. Главное условие здесь — сам контейнер функционирует в одном и том же пространстве пользовательских имен, что и посредственно хост. К сожалению, такая настройка вполне стандартна для большей части современных контейнерных сред.

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

На практике данная технология реализуется следующим образом:

• злоумышленник создает исполняемый файл в том каталоге, который уже существует, непосредственно из контейнера либо через хост;
• изнутри контейнера добавляется бит SUID;
• из внешней среды запускается на выполнение двоичный файл SUID.

Как только данные действия будут выполнены, хакер сможет запустить исполняемый файл на хосте, где предусмотрены root-привилегии. При соблюдении предварительных условий, о которых мы говорили выше, реализовать подобную атаку можно будет достаточно просто. Здесь нет какой-либо технической сложности даже для человека, что не особо хорошо разбирается в программировании. Что уж тогда говорить о хакерах.

Как можно обнаружить атаку, совершаемую при помощи SUID?

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

1. Создать отслеживаемый файл, которой можно будет запустить на исполнение.
2. Модифицировать бит SUID/GUID для того, чтобы получить возможность идентифицировать действия chmod, что будут происходить внутри контейнера.
3. Выполнить исполнительный файл, но уже вне контейнера для того, чтобы идентифицировать в случае исполнения на хосте файла с установленным битом SUID/GUID. Актуально для пользователей без root-прав.

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

Что представляет собой выход из контейнера при помощи атаки Log Mounts?

Первое, на что хотим обратить ваше внимание, так это на то, что реализовать данную атаку можно только в пределах пода Kubernetes. С ее помощью хакер получает доступ к чтению абсолютно любого каталога либо же документа, что хранится на хосте, имеющем root-привилегии. Чтобы применить на практике данную технологию, необходимо:

• обладать доступом к модулю, где выполняется добавление /var/log в каталог хоста;
• обладать способностью при помощи интерфейса Kubernetes читать журналы как обычных пользователей, так и непосредственно через учетную запись службы Pod;
• в своем большинстве получить доступ к журналам можно будет непосредственно изнутри модуля с добавлением хоста /var/log.

Данная технология основывается на том, что Kubernetes способен получить доступ к журналам Pod. Каждый из них будет иметь в /var/log файл журнала, имеющий непосредственную привязку с тем файлом журнала, что размещен в var/lib/docker/containers, то есть непосредственно в каталоге контейнера. Получается, что Kubelet будет считывать содержимое Symlink даже не проверяя его назначение. Именно это и использует хакер для того, чтобы получить доступ к файлу хоста etc/shadow. Он банально манипулирует значениями Symlink из тех файлов журналов, что хранятся в /etc/shadow.

Но и на этом атака не завершается. Далее через инструменты, присутствующие непосредственно в командной строке Kubernetes генерируется запрос HTTP POST на получение доступа к журналам. В итоге хакер может получить доступ к абсолютной всей файловой системе, где присутствуют root-права.

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

Как можно обнаружить атаку, совершенную методом Log Mount?

На сегодня существует 2 действенных способа, при помощи которых можно обнаружить данную атаку:

1. Постоянный мониторинг HTTP-запросов. Здесь необходимо отслеживать все те запросы, которые предполагают получение доступа на чтение журналов. Далее вам необходимо настроить систему фильтров для того, чтобы понимать, откуда они поступают. Благодаря этому вы сможете выявить нехарактерные пути поступления запросов. В том случае, если в рамках данного подхода будут наблюдаться изменения символической законной ссылки журнала, подобная методика обнаружение атак не сработает.
2. Идентификация процесса изменения либо же создания Symlink. Выполняется это на основании данных из каталога хоста /var/log. Изначально вам следует убедиться, что вы работаете непосредственно с хостом, а не с файлами, находящимися внутри контейнера.

На практике наиболее высокие результаты в обнаружении хакерских атак дает объединение обеих методик на практике.

Подводим итоги

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

Также хотим обратить ваше внимание на полезный и удобный в работе инструмент для обеспечения высоких показателей безопасности и конфиденциальности работы в сети — мобильные прокси от сервиса MobileProxy.Space. Пройдите по ссылке https://mobileproxy.space/user.html?buyproxy, чтобы изучить в деталях функциональные возможности данного решения, оценить актуальные тарифы, познакомиться с многообразием доступных геолокаций для обхождения региональных запретов, установленных на законодательном уровне. Также с их помощью вы сможете использовать программы, автоматизирующие действия, в том числе и при работе с социальными сетями без риска нарваться на бам и прочие ограничения со стороны системы.

Также хотим обратить внимание на то, что на сайте MobileProxy.Space вы сможете воспользоваться дополнительными сервисами для того, чтобы узнать свой IP-адрес, проверить скорость интернета доступность портов и пр. Не забудьте воспользоваться бесплатным 2-часовым тестированием, чтобы убедиться в преимуществах данного решения, его широкой функциональности и удобстве в использовании. При возникновении технических сложностей обращайтесь в службу поддержки, которая работает в круглосуточном режиме.

Поделитесь статьёй: