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

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

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

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

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

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

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

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

Уникальные аспекты этого вектора атаки

Форматы файлов

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

Плотность и размер содержимого данных

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

Поток данных и сетевой поток

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

Нет конвейеров данных кода и ETL

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

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

Атака с отравлением данных с использованием уязвимости Log4j

Почему Log4jShell?

Мы использовали уязвимость Log4jShell и общедоступный эксплойт, чтобы продемонстрировать конкретный вариант использования более общего вектора атаки с отравлением данных. Хотя мы считаем, что вектор атаки Log4jShell, описанный в нашем исследовании, ранее не публиковался, цель исследования — продемонстрировать реальный пример гораздо более широкого обобщенного вектора атаки и его последствий для безопасности ИИ. Этот конкретный вектор атаки Log4jShell, уязвимость и эксплойт RCE позволили нашей исследовательской группе получить удаленный доступ к серверам с частными IP-адресами в частной подсети внутри виртуального частного облака («VPC») поставщика общедоступных облачных служб. Хотя в нашем исследовании для реализации и демонстрации этого вектора атаки использовалась облачная инфраструктура, мы считаем, что вектор атаки не ограничивается облачными инфраструктурами и что локальные инфраструктуры могут быть столь же уязвимыми в зависимости от безопасности их конвейеров данных.

Что уникального в этом векторе атаки Log4jShell?

Почти во всех ранее опубликованных отчетах, описывающих уязвимость Log4jShell и вектор атаки, использовалась специально созданная текстовая строка, включенная в заголовок HTTP-запроса User-Agent, чтобы воспользоваться уязвимостью и запустить эксплойт.

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

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

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

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

Вектор атаки встроенной полезной нагрузки Log4jShell показан на диаграмме ниже. Конвейер данных передает содержимое форматов файлов больших данных, таких как CSV/TSV, JSON, Apache Parquet, Apache Avro и т. д., по их пути извне предприятия к месту назначения в озере данных организации. . В одном из этих файлов, упакованных миллионами точек данных, будет специально созданная текстовая строка, готовая воспользоваться уязвимостью и запустить эксплойт RCE. Эти конвейеры и их содержимое не всегда проходят через брандмауэры приложений или другие устройства сканирования содержимого.

Многие распределенные программные системы больших данных, которые обеспечивают конвейеры данных и анализируют данные, которые они предоставляют (то, что мы называем в рамках метафоры цепочки поставок данных заводским программным оборудованием), уязвимы для Log4jShell. Министерство внутренней безопасности (DHS), Агентство кибербезопасности и безопасности инфраструктуры (CISA) ведет список этих систем. [1] Для систем, используемых в нашей демонстрации, исправления специально для уязвимости Log4jShell были выпущены в дней сразу после объявления об открытии в декабре 2021 года.

Сравнение векторов атак Log4jShell

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

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

Выявление уязвимой системы

В нашем исследовании мы использовали очень известную систему распределенной обработки с «миллионами загрузок» с момента ее создания. Мы использовали версию этого программного обеспечения, выпущенную несколько месяцев назад в ноябре 2021 года — до объявления об уязвимости Log4jShell. В ходе нашего исследования мы определили, что около 2,5 лет выпусков программного обеспечения для этого конкретного программного компонента были уязвимы — временные рамки напрямую коррелировали с включением и удалением уязвимой зависимости Java log4j2. Следует отметить, что для каждого аспекта уязвимости, которая была использована, есть соответствующее исправление, которое может предотвратить работу этой уязвимости и эксплойта.

Обнаружение вредоносной нагрузки с помощью Zectonal Deep Data Inspection™

Zectonal внедрила в свои возможности мониторинга программного обеспечения метод обнаружения этих типов вредоносных полезных нагрузок. Мы называем эту технику Zectonal Deep Data Inspection™. Глубокая проверка пакетов предназначена для сетевой безопасности, а глубокая проверка данных предназначена для безопасности данных и ИИ. В приведенном ниже примере наше программное приложение Zect™ находит конкретный эксплойт в сжатом CSV-файле GZIP.

[1] https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Программные системы, использованные в нашем исследовании

Чтобы продемонстрировать конкретную атаку и эксплойт, мы решили использовать стек ELK с открытым исходным кодом, который представляет собой набор из трех (3) проектов с открытым исходным кодом, включая Elasticsearch, Logstash и Kibana.

Хотя нам не удалось определить распространение версий ELK, развернутых по всему миру (что дает нам некоторое представление о поверхности атаки), мы нашли соответствующую информацию в статье Elasticsearch Wikipedia о том, что она используется Google Cloud Platform, Alibaba Cloud и AWS. Согласно Logz.io, который отслеживает журнал, метрику и аналитику трассировки для любого стека:

Благодаря миллионам загрузок различных компонентов с момента первого появления ELK Stack является самой популярной в мире платформой управления журналами. Напротив, Splunk — исторический лидер в этой области — сообщает о 15 000 клиентов в общей сложности.[2]

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

Мы использовали несколько версий стека ELK, включая версию 7.15.2, выпущенную 10 ноября 2021 г., и версию 5.6.16, выпущенную 19 марта 2021 г. Хотя мы не тестировали каждый выпуск в период с марта 2019 г. по 10 ноября 2021 г. ( в течение 2,5 лет), мы предполагаем, что каждая версия будет одинаково уязвима при определенном наборе условий окружающей среды, поскольку все они содержат уязвимую версию библиотеки ведения журналов Apache Log4j 2.

Мы намеренно выбрали эти версии, выпущенные непосредственно перед раскрытием уязвимости Log4jShell 10 декабря 2021 года и совпадающие с использованием скомпрометированных версий библиотек log4j 2. Поэтому мы считаем, основываясь на этих разумных предположениях, что все версии Logstash в течение этого 2,5-летнего периода будут уязвимы.

Наконец, мы намеренно использовали конкретную версию Java 8, выпущенную и не исправленную до раскрытия информации Log4jShell 10 декабря 2021 года. Учитывая, что 60% разработчиков Java по-прежнему используют Java 8 в рабочей среде, согласно отчету Synk JVM Ecosystem Report 2021[3], мы определили, что это вполне реалистичное предположение для использования в нашем исследовании. Он также обеспечивает некоторый охват общей поверхности атаки.

[2] https://logz.io/learn/complete-guide-elk-stack/

[3] https://snyk.io/jvm-ecosystem-report-2021/

Вкратце

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

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

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

Реальным примером уязвимости цепочки поставок данных является вектор атаки Log4jShell. Наша исследовательская группа получила удаленный доступ к серверу (серверам) с частными IP-адресами в частной подсети внутри виртуального частного облака («VPC») поставщика общедоступных облачных служб.

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

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

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

Знайте свои данные с Zectonal. https://www.zectonal.com