Исследователи Aqua Nautilus выявили проблему безопасности, возникающую из взаимодействия пакета command-not-found Ubuntu и репозитория пакетов snap. В то время как command-not-found служит удобным инструментом для предложения установки для неустановленных команд, злоумышленники могут непреднамеренно манипулировать им через репозиторий snap, что приводит к рекомендациям вредоносных пакетов.
Кроме того, наши исследования показывают, что до 26% команд, связанных с пакетами APT (Advanced Package Tool), подвержены подделке злоумышленниками. Эта проблема может открыть путь для атак на supply chain, затрагивающих пользователей Linux и пользователей Windows с запущенным WSL. В данной статье рассматриваются операционные детали команды command-not-found, риски, связанные с установкой компрометированных пакетов snap, а также различные векторы атак, которые могут быть использованы.
Пакет command-not-found
Пакет command-not-found по умолчанию устанавливается на Ubuntu и оказывает неоценимую услугу пользователям Linux: он предлагает установить пакеты, когда они пытаются выполнить команду в оболочке Bash или Zsh, которые отсутствуют в их системе. Это достигается за счет реализации функции command_not_found_handle, которую Bash вызывает при обнаружении нераспознанной команды.
Пакет command-not-found предлагает рекомендации как для пакетов APT, так и для snap. Например, если пользователь пытается выполнить команду ifconfig и она не установлена, пакет будет рекомендовать установить net-tools через apt:
Аналогично, когда пользователи пытаются запустить команду code, которая связана с Visual Studio Code, они получат рекомендацию установить пакет code через snap.
Если команда соответствует как пакету snap, так и пакету apt, пакет command-not-found предложит оба варианта, как в случае с командой mojo:
Понимание алгоритма рекомендаций в пакете ‘command-not-found’
Пакет command-not-found оборудован внутренней базой данных, которая ассоциирует команды с популярными пакетами APT. Важно отметить, что имя команды может отличаться от имени пакета (как в случае с командой ifconfig и пакетом net-tools, описанным выше). Эта база данных обновляется только во время обновления самого пакета command-not-found.
В отличие от этого, для пакетов snap пакет command-not-found полагается на команду snap “advise-snap”. Эта функциональность, предоставляемая snap, ссылается на свою собственную регулярно обновляемую базу данных, полученную из Snap Store.
Как система решает, какой пакет рекомендовать? Чтобы понять это, мы можем углубиться в код ниже из пакета command-not-found.
Процесс начинается с использования пакетом command-not-found функции get_packages для определения соответствующих пакетов APT и функции get_snaps для получения совпадающих пакетов snap. Затем он оценивает несколько условий, чтобы предоставить наиболее точное предложение. Если в обоих репозиториях snap и APT не найдены точные совпадения, он пытается рекомендовать похожие команды, учитывая возможные опечатки. В случаях, когда точные совпадения существуют, предложение зависит от количества результатов, поскольку может быть несколько пакетов snap или APT, связанных с одной и той же командой.
С учетом нашего понимания механизма рекомендаций, используемого пакетом command-not-found и основанного на репозиториях APT и snap, возникает важный вопрос: насколько реально для злоумышленника манипулировать этой системой, чтобы его вредоносный пакет был рекомендован пакетом command-not-found?
Хотя пакеты APT работают в операционной системе хоста без ограничений, не каждый может внести свой вклад в официальные репозитории APT. Разработчики должны пройти процесс одобрения, прежде чем им будет разрешено загружать пакет.
По этим причинам, и учитывая, что база данных APT пакета command-not-found не обновляется регулярно, наше внимание переключается на потенциал злоумышленников опубликовать вредоносные пакеты в репозитории snap.
Ограничения snap-пакетов
Теперь, когда мы определили наше интерес в изучении snap-пакетов, важно исследовать ограничения, установленные командой snap для издателей и их пакетов.
Сначала нам нужно понять уровень изоляции. Существуют 2 основных уровня изоляции snap:
1. Строгая изоляция (Strict confinement), которая используется большинством snap-пакетов. Строго изолированные snap-пакеты работают в песочнице, они не могут получать доступ к файлам, сети, процессам или другим системным ресурсам.
2. Классическая (Classic), которая запускается на машине хоста так же, как и пакет APT, без каких-либо ограничений.
Здесь возникает вопрос: почему злоумышленник просто не выберет классический snap для распространения? Здесь защитой служит требование ручного рассмотрения командой snap для snap-пакетов, запрашивающих определенные привилегии, такие как классическая изоляция. Однако не все приложения требуют полного набора разрешений, которые обеспечивает классическая изоляция, но при этом нуждаются в доступе к определенным локальным системным ресурсам. Для удовлетворения этого требования был разработан механизм интерфейса.
Интерфейсы snap
Интерфейсы snap служат контролируемыми шлюзами для строго изолированных snap-пакетов, позволяя им взаимодействовать с внешними ресурсами, которые обычно недоступны в среде песочницы. Существует множество интерфейсов, каждый из которых эффективно создает контролируемые «трещины» в стенах песочницы. Через эти отверстия snap-пакеты могут взаимодействовать с ресурсами хоста или средами других запущенных snap-пакетов.
На изображении выше мы можем видеть частичный список доступных интерфейсов snap. Некоторые интерфейсы предоставляют snap-пакетам значительные привилегии, позволяя им получать доступ к и управлять чувствительными системными ресурсами, включая управление учетными записями и запись звука. Другие предоставляют более безобидные возможности, такие как «audio-playback», которая просто позволяет snap воспроизводить звук.
Эти интерфейсы могут быть классифицированы на основе свойства автоматического подключения (auto-connect). Это свойство определяет, какие интерфейсы могут быть автоматически подключены к snap-пакету (обозначены как да), а какие требуют ручного утверждения командой snap, как в классической изоляции, перед тем как они могут быть опубликованы в магазине.
Опасности вредоносных строго изолированных snap-пакетов
Наше исследование сосредоточено на наиболее вероятных тактиках, которые может использовать злоумышленник с помощью вредоносных snap-пакетов. Учитывая это, нас особенно интересуют возможности snap-пакета, который не вызывает ручного рассмотрения. Мы целенаправленно стремимся выяснить, что злоумышленник потенциально может достичь с помощью строго изолированного snap-пакета, который использует только интерфейсы, установленные для автоматического подключения и не требующие ручного утверждения.
Интерфейсы рабочего стола
Хотя большинство разрешительных интерфейсов требуют ручного рассмотрения, интерфейсы рабочего стола могут быть подключены автоматически. Эти интерфейсы позволяют приложениям с графическим пользовательским интерфейсом (GUI) подключаться к серверу отображения и отображать окна на хост-системе.
В Linux, сервер отображения (display server) — это программа, отвечающая за управление графическим выводом и вводом в системе, обеспечивая работу графического пользовательского интерфейса (GUI). Приложения взаимодействуют с сервером отображения с использованием определенных протоколов сервера отображения. Два примера таких протоколов — это X11 и Wayland. Протокол X11 был долгое время стандартным протоколом сервера отображения, в то время как Wayland — это более новый протокол, направленный на предоставление более современной и безопасной системы окон для замены X11.
Основная проблема здесь заключается в том, что сила ограничений песочницы зависит от возможностей сервера отображения. Следовательно, устаревшие серверы отображения, такие как X Window System, который использует протокол X11, лишены реального разделения безопасности между окнами различных приложений. Это позволяет snap-пакетам, подключенным к интерфейсу X11, подслушивать другие окна и потенциально захватывать нажатия клавиш с хост-машин.
Эта проблема известна компании Canonical, и Мэттью Гаррет написал об этом блог в 2016 году, подчеркивая пробелы в безопасности, которые присутствуют в механизме ограничения snap на X11.
Он выпустил открытый инструмент, демонстрирующий этот недостаток. Я скомпилировал этот PoC с небольшими изменениями и запустил его на Ubuntu 22:
Мы можем наблюдать на видео выше, как выполнение snap-пакета под названием friendlyteddy, который строго изолирован, может украсть учетные данные пользователя, набирающего их на хост-машине.
Хотя команда snap заявляет, что они хотят перейти от небезопасного X-сервера к более безопасным протоколам сервера отображения, таким как Wayland, X-сервер по-прежнему широко используется дистрибутивами сегодня. Хотя Wayland является протоколом по умолчанию в Ubuntu 22, X-сервер все еще устанавливается по умолчанию, и существует много статей и постов о том, как переключиться в Ubuntu на использование X-сервера вместо Wayland: https://linuxconfig.org/how-to-use-x-instead-of-wayland-on-ubuntu-22-04.
Уязвимости ядра
Даже если вы избегаете использования небезопасного протокола X11, все еще существуют риски, связанные с установкой вредоносных snap-пакетов. Хост и все другие активные snap-пакеты разделяют одно и то же ядро. Это означает, что если в ядре существует уязвимость, которую может использовать snap-пакет, это может нарушить песочницу и позволить получить полный контроль над системой хоста. Ежегодно в Linux-ядре обнаруживается множество уязвимостей. Только в 2023 году было сообщено о 282 уязвимостях (согласно stack.watch). Хотя каждая уязвимость имеет свою степень серьезности, и не все из них могут быть эксплуатированы через контейнер snap, потенциальная угроза остается значительной.
Более того, у snap-пакетов есть функция автоматического обновления, которая автоматически обновляет версию установленного snap до самой новой доступной. Хотя это полезно для исправления уязвимостей в самом snap-пакете, это также имеет последствия для безопасности. Эту функцию могут использовать злоумышленники для развертывания эксплойтов, направленных на новые уязвимости. Например, злоумышленник может подделать доверенный пакет. При обнаружении критической уязвимости в ядре Linux они могут отправить злонамеренное обновление в репозиторий snap. В результате механизм автоматического обновления автоматически распространит поддельную версию на всех пользователей, эксплуатируя уязвимость ядра до того, как пользователи смогут применить какие-либо обновления безопасности.
Подмена пакетов Command-Not-Found
Получив базовое представление о snap-пакетах и рисках, связанных с установкой вредоносных экземпляров, мы возвращаемся к нашей основной заботе: пакету command-not-found. Наша цель сейчас — исследовать, как злоумышленник может потенциально использовать систему command-not-found, чтобы обмануть пользователей и заставить их устанавливать свой вредоносный пакет.
Псевдонимы команд snap-пакета
Документация Snap уточняет, что чтобы предотвратить конфликты от разных snap-пакетов, которые используют одинаковые имена приложений, формат команд snap-пакетов выглядит как <имя_snap_пакета>.<имя_приложения>. Когда имя snap-пакета совпадает с именем приложения, команда упрощается до просто <имя_snap_пакета>.
Приведу пример сценария, когда snap-пакет называется code, а приложение — vscode. Команда, которую необходимо выполнить, будет выглядеть как code.vscode. Напротив, если имя приложения также совпадает с именем snap-пакета и также называется code, то команда упростится от code.code до просто code.
Если разработчикам нужно, чтобы их snap выполнял команду, отличную от формата <имя_snap_пакета>.<имя_приложения> и не являющуюся просто <имя_snap_пакета>, им необходимо запросить псевдоним. Такой запрос запускает процесс ручного рассмотрения, в ходе которого запрошенный псевдоним подвергается согласованию, чтобы убедиться, что он соответствует приложению.
Однако, поскольку зарегистрированное имя является всего лишь псевдонимом, а не официальным именем snap, фактическое имя snap остается доступным для использования. Это означает, что злоумышленник потенциально может зарегистрировать соответствующее имя snap, тем самым подделав команду.
Рассмотрим пример.
На изображении выше мы видим, что при вводе команды tarquingui пакет ‘command-not-found’ рекомендует установить snap-пакет ‘tarquin’. Команда tarquingui не совпадает точно с именем snap, что указывает на то, что tarquingui является псевдонимом для snap ‘tarquin’ (подробности запроса псевдонима можно найти здесь). Однако, как уже отмечалось, поскольку псевдоним не приравнивается к резервированию имени snap, это дает возможность злоумышленнику зарегистрировать имя snap tarquingui и опубликовать под ним свой собственный snap-пакет.
Ниже приведен вывод команды после того, как мы опубликовали snap с именем tarquingui:
Злоумышленник может систематически просматривать все псевдонимы команд через API Snap Store, чтобы определить любой псевдоним, для которого имя snap все еще доступно. Найдя подходящий вариант, они могут зарегистрировать новый snap под этим именем, создав возможность обмануть пользователей и заставить их установить вредоносный пакет.
Важно отметить, что в документации указывается, что псевдоним не обязательно является уникальным, и могут возникать потенциальные конфликты.
Команды для APT-пакетов
Мы уже рассмотрели, как могут быть подделаны snap-пакеты, но возможность подделки APT-пакетов представляет еще одну проблему. Как уже упоминалось, утилита command-not-found основана на локальной базе данных, расположенной по адресу /var/lib/command-not-found/commands.db, которая связывает команды с соответствующими APT-пакетами, помогая пользователям сделать точные установки.
Мы хотели изучить, сколько команд, перечисленных в этой локальной базе данных, могут быть использованы злоумышленником, зарегистрировав их в качестве имен snap-пакетов. Это потенциально может привести к тому, что утилита command-not-found будет предлагать вместе с легитимными APT-пакетами также и вредоносные snap-пакеты.
После запроса в Snap Store для каждой команды для проверки доступных имен snap-пакетов были обнаружены поразительные результаты. Мы обнаружили, что 26% команд APT-пакетов были доступны, что представляет существенный риск безопасности, поскольку они могут быть зарегистрированы под учетной записью злоумышленника.
Например, одним из таких пакетов является пакет jupyter-notebook:
Создатели APT-пакета jupyter-notebook не зарегистрировали соответствующее имя snap. Это просчет открыл возможность для злоумышленника зарегистрировать его и загрузить вредоносный snap с именем jupyter-notebook. Ниже приведен вывод после регистрации нами имени snap jupyter-notebook и загрузки фиктивного «вредоносного» пакета:
Мы видим, что утилита command-not-found сначала предлагает установить snap-пакет, даже перед оригинальным APT-пакетом. Это поведение потенциально может ввести пользователей в заблуждение и заставить установить snap-пакет.
Реальная опасность заключается в масштабе этой проблемы. Хотя один вредоносный snap-пакет, выдающий себя за легитимный APT- или snap-пакет, является тревожным явлением, перспектива того, что злоумышленник систематически эксплуатирует 26% команд APT-пакетов, включая те, которые имеют псевдонимы в магазине snap, может иметь разрушительные последствия.
Атаки типа “typosquatting”
Помимо точного соответствия точному имени широко используемой команды, злоумышленники также могут использовать тактику типа typosquatting. Это включает в себя использование распространенных опечаток, допускаемых пользователями.
Например, подумайте, что может произойти, если пользователь случайно вводит ifconfigg вместо ifconfig:
В приведенном выше примере пакет command-not-found дружелюбно исправляет пользователя, предлагая пакет net-tools для неправильно набранной команды ifconfig. Однако ситуация становится более проблематичной, когда злоумышленник воспользуется этими общими ошибками, зарегистрировав snap с опечаткой, например, ifconfigg.
Как было продемонстрировано ранее, утилита command-not-found обычно исправляет пользователя, предлагая правильный пакет net-tools для неправильно набранной команды ifconfig. Однако если злоумышленник зарегистрирует snap с именем ifconfigg, утилита command-not-found ошибочно сопоставит его с этой неправильной командой и рекомендует вредоносный snap (как показано на изображении выше), полностью обходя предложение net-tools.
Заключение и меры по снижению рисков
Риск использования злоумышленниками утилиты command-not-found для рекомендации их собственных вредоносных snap-пакетов представляет собой насущную проблему. Истинная опасность заключается в потенциальном масштабе этой проблемы, поскольку злоумышленники могут подделывать тысячи команд из широко используемых пакетов. Прошлые случаи появления вредоносных пакетов в магазине Snap подчеркивают эту проблему (см. ссылки: Snapcraft Forum , The Next Web).
Пока неясно, насколько широко были использованы эти возможности, что подчеркивает неотложность усиления бдительности и принятия активных стратегий обороны.
Для защиты от таких угроз пользователи и разработчики пакетов должны принять несколько профилактических мер:
- Пользователи должны проверять источник пакета перед установкой, проверяя достоверность разработчиков и рекомендованную платформу (snap или APT).
- Разработчики snap-пакетов с псевдонимом должны незамедлительно зарегистрировать соответствующее имя, если оно соответствует их приложению, чтобы предотвратить его неправомерное использование.
- Разработчикам APT-пакетов рекомендуется зарегистрировать соответствующее имя snap для своих команд, заранее защищая их от потенциального подделывания злоумышленниками.
- Клиенты Aqua могут блокировать выполнение APT и snap в контейнеризованных рабочих нагрузках. Runtime решения могут обнаруживать вредоносное поведение, вызванное эксплуатацией этой проблемы.
Источник: https://www.aquasec.com/blog/snap-trap-the-hidden-dangers-within-ubuntus-package-suggestion-system/