Уязвимости MagicDot в Windows открывают дорогу руткитам

Уязвимости MagicDot в Windows открывают дорогу руткитам

Уязвимости MagicDot в Windows открывают дорогу руткитам

Некорректные DOS-пути в номенклатуре имен файлов в Windows могут быть использованы для сокрытия вредоносного содержимого, файлов и процессов. Исследователь из SafeBreach Ор Яир обозначил проблему, связанную с процессом преобразование DOS-пути в NT-формат в Windows.

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

Ор Яир сделал акцент на четырёх уязвимостях, связанных с проблемой, которую исследователь назвал "MagicDot". Группа проблем MagicDot существует из-за того, что Windows заменяет пути DOS на пути NT.

Для того чтобы пользователь смог открыть файл или папку на своём компьютере, Windows использует путь, по которому существует файл. Таким путём обычно является путь DOS, который представлен в формате "C:\Users\User\Documents\example.txt". Однако для выполнения операции открытия файла используется другая базовая функция под названием NtCreateFile. Именно она запрашивает путь NT, а не DOS. Поэтому Windows преобразует привычный путь DOS, видимый пользователям, в путь NT, прежде чем вызвать NtCreateFile для выполнения операции.

В процессе преобразования путей, Windows автоматически удаляет все точки и лишние пробелы в DOS-пути, из-за чего и возникает проблема.

DOS-пути выглядят следующим образом:

  • C:\example\example.
  • C:\example\example…
  • C:\example\example<пробел>    

Все они преобразуются в "\??\C:\example\example" в качестве NT-пути.

Ор Яир указал, что автоматическое удаление символов даёт возможность киберпреступникам создавать специально разработанные пути DOS, которые будут преобразованы в NT-пути по их выбору для сокрытия вредоносного содержимого или действий либо для приведения файлов в негодность. 

Ряд техник постэксплуатации могут быть применены злоумышленниками из-за проблем “MagicDot”, которые позволят хакерам сохранить скрытность.

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

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

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

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

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

Исследователь сообщил, что данные манипуляции с путями MagicDot могут предоставить злоумышленникам руткит-способности без прав администратора и без вмешательства в цепочку вызовов API.

Киберпреступники получают возможность скрывать файлы и процессы, прятать файлы в архивах, влиять на анализ файлов с предварительной выборкой, заставлять пользователей диспетчера задач и Process Explorer думать, что файл зловреда является проверенным исполняемым файлом, опубликованным Microsoft, выводить из строя Process Explorer с помощью уязвимости отказа в обслуживании (DoS) и многое другое.

Ор Яир предупредил о значимости угрозы в мире кибербезопасности и напомнил о важности разработки методов и правил обнаружения непривилегированных руткитов.

Исследователь в области безопасности Ор Яир обнаружил в ходе своего исследования путей  "MagicDot" четыре различные уязвимости, связанные с основной проблемой. Три из них уже исправлены Microsoft.

С помощью уязвимости удаленного выполнения кода (RCE) (CVE-2023-36396, CVSS 7,8) в новой логике извлечения архивов Windows для всех новых поддерживаемых типов архивов злоумышленники создают вредоносный архив, который после извлечения записывается в любое место на удаленном компьютере, что приводит к выполнению кода.

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

Следующий баг — это уязвимость повышения привилегий (EoP) (CVE-2023-32054, CVSS 7,3), которая позволяет злоумышленникам записывать в файлы без привилегий, манипулируя процессом восстановления предыдущей версии из теневой копии.

Третья уязвимость — это непривилегированный DOS для антианализа Process Explorer, для которого зарезервирован CVE-2023-42757.

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

Представленные исследователем уязвимости компания Microsoft устранила, но всё же автоматическое удаление точек и пробелов при преобразовании путей из DOS в NT сохраняется. А именно это и является первопричиной уязвимости.

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

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

Специалист порекомендовал разработчикам программного обеспечения использовать NT-пути вместо DOS, так как они позволяют избежать процесса преобразования и гарантируют, что предоставленный путь — это тот же путь, который используется на самом деле.

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

CodeScoring запустила собственное хранилище программных артефактов Save

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

Save ориентировано на корпоративный сегмент и компании любого масштаба, которым необходим предсказуемый и отказоустойчивый репозиторий артефактов.

Об этом Anti-Malware рассказал руководитель разработки продуктов CodeScoring Дмитрий Ключников на конференции CodeScoring Masters. По его словам, разработка Save велась на языке Go с прицелом на современные Kubernetes-среды и стандарты безопасной разработки.

«Мы привлекли к тестированию доверенных партнёров и заказчиков, готовых проверять решение на практике с самых ранних этапов. Их регулярная обратная связь помогает нам калибровать архитектуру и функциональность Save под реальные рыночные требования», — рассказал Дмитрий Ключников.

Хранилище артефактов используется разработчиками как централизованная точка для получения, хранения и распространения компонентов ПО. В эту категорию входят, например, Sonatype Nexus Repository, JFrog Artifactory и Harbor. При этом Save поставляется с готовым инструментом автоматической миграции с открытых репозиториев.

CodeScoring.Save рассчитано одновременно на размещение собственных артефактов и работу с внешними репозиториями через прокси. В продукте заявлена поддержка Maven, npm, NuGet, PyPI, Go Modules, Docker/OCI, DEB, RPM и RAW-файлов.

Save разработано на Go, разворачивается в Kubernetes и поставляется через Helm. В систему встроены ролевая модель, отдельные аккаунты для автоматизированных систем, аудит систем, аудит действий пользователей и API. Вычислительная часть приложения отделена от слоя хранения, что позволяет масштабировать их независимо.

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

При этом CodeScoring не собирается привязывать новое хранилище к покупке основной платформы.

«Это абсолютно отделяемое решение. Оно может продаваться вместе с CodeScoring, а может продаваться отдельно», — подчеркнул Дмитрий Ключников.

Продукт поставляется как самостоятельное локальное решение для развёртывания в инфраструктуре заказчика. Ключевые корпоративные возможности включены в базовую функциональность продукта. Запуск собственного репозитория усиливает возможности всей платформы безопасной разработки CodeScoring.

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

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

«Интеграция модулей позволит выстроить бесшовный контроль: Save становится единой доверенной точкой входа, предотвращая попадание вредоносных пакетов в контур разработки», — рассказал Ключников.

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

Ещё одним направлением развития продукта станет работа с моделями искусственного интеллекта как с отдельным типом артефактов.

На первом этапе речь идёт о хранении и распространении моделей. Среди экосистем, поддержку которых рассматривают разработчики, Дмитрий Ключников назвал Hugging Face.

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

Более сложные возможности, в том числе инфраструктура для обучения моделей, пока находятся на стадии изучения спроса.

CodeScoring также планирует сертифицировать Save с учётом российских требований безопасной разработки.

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

Таким образом, после запуска Save линейка CodeScoring выйдет за пределы анализа и проверки сторонних компонентов: компания добавляет собственную инфраструктуру для их хранения и распространения.

RSS: Новости на портале Anti-Malware.ru