Тишина в канале - значит, идет оффлайн-исследование. Где-то на Кольском полуострове.
9 дней без связи для того, чтобы продолжить поиск идеального спорта для ИТшника и выяснить ключевые навыки для успешной ловли на спиннинг:
* Стратегическое планирование: определить список мест для ловли с берега и в акватории, составить маршрут продвижения. Лучше такой, чтобы не пришлось нырять или сплавляться по реке.
* Тактическое планирование: подготовить снасти и экипировку для данного маршрута. Точно пригодятся вейдерсы. А правильно подобранная «полезная нагрузка» определят успех мероприятия в конкретном месте и конкретную погоду.
* Умение фаззить те самые места, где обитает хищник: забрасывать снасть так, чтобы не зацепиться за ветку или камень, и не отправиться в неуправляемый заплыв к ближайшему водопаду.
Результаты фишинга: сломанный спиннинг, потраченные ботинки для вейдерсов, 4 вида пойманных хищников.
9 дней без связи для того, чтобы продолжить поиск идеального спорта для ИТшника и выяснить ключевые навыки для успешной ловли на спиннинг:
* Стратегическое планирование: определить список мест для ловли с берега и в акватории, составить маршрут продвижения. Лучше такой, чтобы не пришлось нырять или сплавляться по реке.
* Тактическое планирование: подготовить снасти и экипировку для данного маршрута. Точно пригодятся вейдерсы. А правильно подобранная «полезная нагрузка» определят успех мероприятия в конкретном месте и конкретную погоду.
* Умение фаззить те самые места, где обитает хищник: забрасывать снасть так, чтобы не зацепиться за ветку или камень, и не отправиться в неуправляемый заплыв к ближайшему водопаду.
Результаты фишинга: сломанный спиннинг, потраченные ботинки для вейдерсов, 4 вида пойманных хищников.
🔥17👍4❤2👾1
Платформа разработки - зачем?
В 2023 году аналитики Gartner разогнали идею Platform Engineering, и уже в 2024 крупные компании с мульти-продуктовым портфелем начали трансформировать свои команды разработки в «платформу». Чуть позже к кому-то прийдет идея сделать security-платформу из специалистов, которые обеспечивают безопасность процессов разработки.
Зачем создавать группы, которые унифицируют процессы, называть их «Platform Engineering Team» и в итоге получать команду разработки, которая один в один похожа на команду конкурента? Есть ли бизнес-причины для повторения одних и тех же технологических решений?
Специфичные для конкретного бизнеса проблемы требуют уникальных решений. Платформа должна создаваться для работы над подобными задачами. Для решения всех остальных проблем есть более короткие и дешевые пути. Примеры исключительных сценариев, когда бизнесу действительно нужно повторить опыт конкурента и создать свою платформу разработки:
* случай, когда бизнес может создать платформу дешевле, чем предлагают поставщики;
* когда у поставщиков есть проблемы с качеством и безопасностью, с которыми бизнес не может мириться;
* единственный поставщик платформы - это конкурент, которому не хочется отдавать деньги;
* продукт поставщика не может масштабироваться под инфраструктуру бизнеса;
* есть риск, что бизнес привяжется к одному поставщику и в будущем сильно будет от него зависеть.
Если в стратегии развития ИТ-инфраструктуры бизнеса нет ни одного из перечисленных сценариев, то не нужно изобретать велосипед и создавать команду Platform Engineering, которая не создаст ни одной инновации.
В 2023 году аналитики Gartner разогнали идею Platform Engineering, и уже в 2024 крупные компании с мульти-продуктовым портфелем начали трансформировать свои команды разработки в «платформу». Чуть позже к кому-то прийдет идея сделать security-платформу из специалистов, которые обеспечивают безопасность процессов разработки.
Зачем создавать группы, которые унифицируют процессы, называть их «Platform Engineering Team» и в итоге получать команду разработки, которая один в один похожа на команду конкурента? Есть ли бизнес-причины для повторения одних и тех же технологических решений?
Специфичные для конкретного бизнеса проблемы требуют уникальных решений. Платформа должна создаваться для работы над подобными задачами. Для решения всех остальных проблем есть более короткие и дешевые пути. Примеры исключительных сценариев, когда бизнесу действительно нужно повторить опыт конкурента и создать свою платформу разработки:
* случай, когда бизнес может создать платформу дешевле, чем предлагают поставщики;
* когда у поставщиков есть проблемы с качеством и безопасностью, с которыми бизнес не может мириться;
* единственный поставщик платформы - это конкурент, которому не хочется отдавать деньги;
* продукт поставщика не может масштабироваться под инфраструктуру бизнеса;
* есть риск, что бизнес привяжется к одному поставщику и в будущем сильно будет от него зависеть.
Если в стратегии развития ИТ-инфраструктуры бизнеса нет ни одного из перечисленных сценариев, то не нужно изобретать велосипед и создавать команду Platform Engineering, которая не создаст ни одной инновации.
👍5🔥3🤣2
Побег из контейнера: обзор техник
Исследователи Unit42 собрали актуальные техники побега из контейнеров и подготовили обзор. Инженеры DevOps и аналитики Blue Team забирают этот материал в свою коллекцию для защиты облачных сред.
В материале рассмотрены системы контейнеризации на основе изоляции пользовательского пространства (user-space), и техники не применимы для систем, которые работают на основе виртуализации. Почти все рассмотренные атаки используют два базовых механизма Linux: capabilities и namespaces.
Атрибут capabilities определяет набор действий, которые процесс может выполнить в системе. Атрибут namespaces определяет набор ресурсов, с которыми может работать процесс. Другими словами, capabilities определяет что процесс может сделать в контейнере, а namespaces - где процесс может выполнять эти действия.
Используя неправильные конфигурации этих атрибутов, атакующий может не только выполнять свои процессы в основной операционной системе (которая управляет контейнером) или читать там ценные данные, но повышать свои привилегии внутри контейнера.
Исследователи Unit42 собрали актуальные техники побега из контейнеров и подготовили обзор. Инженеры DevOps и аналитики Blue Team забирают этот материал в свою коллекцию для защиты облачных сред.
В материале рассмотрены системы контейнеризации на основе изоляции пользовательского пространства (user-space), и техники не применимы для систем, которые работают на основе виртуализации. Почти все рассмотренные атаки используют два базовых механизма Linux: capabilities и namespaces.
Атрибут capabilities определяет набор действий, которые процесс может выполнить в системе. Атрибут namespaces определяет набор ресурсов, с которыми может работать процесс. Другими словами, capabilities определяет что процесс может сделать в контейнере, а namespaces - где процесс может выполнять эти действия.
Используя неправильные конфигурации этих атрибутов, атакующий может не только выполнять свои процессы в основной операционной системе (которая управляет контейнером) или читать там ценные данные, но повышать свои привилегии внутри контейнера.
👍7🔥1🤔1😱1
Критическая уязвимость в сетевом стеке Windows
Критическая проблема обнаружена в парсере IPv6 ядра Windows и позволяет злоумышленникам удаленно выполнить произвольный код без какого-либо взаимодействия с пользователем.
Похоже, что локальный файрволл не поможет, потому что разбор вредоносного IPv6-пакета происходит до его попадания к встроенному средству защиты.
Уязвимы все поддерживаемые версии Windows. Ставим обновления.⚡️
Критическая проблема обнаружена в парсере IPv6 ядра Windows и позволяет злоумышленникам удаленно выполнить произвольный код без какого-либо взаимодействия с пользователем.
Похоже, что локальный файрволл не поможет, потому что разбор вредоносного IPv6-пакета происходит до его попадания к встроенному средству защиты.
Уязвимы все поддерживаемые версии Windows. Ставим обновления.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡3👾3🔥2
Платформа разработки: гайдлайны
Тому, кто ответил на вопрос «зачем?» нужна своя платформа, и решил трансформировать свои процессы, инструменты и команду в Платформу Разработки, предстоит определиться с подходом и ответить на вопрос «как?».
Заряжаемся материалами, в которых утверждается, что методология ускоряет производство продуктов и снижает когнитивную нагрузку на разработчика. Затем погружаемся в создание Internal Developer Platform:
Этап 1: разработчики бизнес-функций работают с Платформой как клиенты с витриной в магазине - обслуживают сами себя. Поэтому определяем путь разработчика «от запроса до результата», разделяем этот путь на функциональные слои и собираем технологии, которые помогут этот путь пройти.
Этап 2: создаем референсную архитектуру.
Этап 3: описываем MVP (Minimum Viable Platform).
Этап 4: определяем роли и экспертов для команды разработки.
И не забываем про Этап 0.
Тому, кто ответил на вопрос «зачем?» нужна своя платформа, и решил трансформировать свои процессы, инструменты и команду в Платформу Разработки, предстоит определиться с подходом и ответить на вопрос «как?».
Заряжаемся материалами, в которых утверждается, что методология ускоряет производство продуктов и снижает когнитивную нагрузку на разработчика. Затем погружаемся в создание Internal Developer Platform:
Этап 1: разработчики бизнес-функций работают с Платформой как клиенты с витриной в магазине - обслуживают сами себя. Поэтому определяем путь разработчика «от запроса до результата», разделяем этот путь на функциональные слои и собираем технологии, которые помогут этот путь пройти.
Этап 2: создаем референсную архитектуру.
Этап 3: описываем MVP (Minimum Viable Platform).
Этап 4: определяем роли и экспертов для команды разработки.
И не забываем про Этап 0.
👍3🔥1
Доступ к данным из удаленных и приватных репозиториев GitHub
Когда одна ветка репозитория позволяет получить ценные данные из другой удаленной или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).
По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удаленном или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?
GitHub позволяет использовать короткие значения хэшей SHA-1, которые можно просто подобрать методом простого перебора. К примеру, вместо длинной ссылки:
Можно использовать короткую ссылку:
где
GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.
Когда одна ветка репозитория позволяет получить ценные данные из другой удаленной или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).
По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удаленном или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?
GitHub позволяет использовать короткие значения хэшей SHA-1, которые можно просто подобрать методом простого перебора. К примеру, вместо длинной ссылки:
github.com/<user>/<repo>/commit/
07f01e8337c1073d2c45bb12d688170fcd44c637Можно использовать короткую ссылку:
github.com/<user>/<repo>/commit/07f01eгде
07f01e - короткий хэш. Его можно подобрать через пользовательский интерфейс GitHub. А уже после получения доступа к коммитам, атакующий приступает к поиску секретов.GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.
🔥4👍2👾2
ИИ ассистент для security-аналитика
Продолжаем собирать и применять сценарии использования ИИ для задач безопасности. Новый кейс использования для разработки правил выявления угроз:
* Аналитик загружает в LLM техники атак, описанные в формате блогпоста или отчета об угрозе.
* В запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта.
* Модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промпт).
Самый ресурсоемкий для аналитика этап - это составление точного промпта. Поэтому важно отработать навык prompt engineering.
Так как написание правил - это процесс, который зачастую происходит в свободное от обработки инцидентов время, то данный сценарий залетает в бэклог к лидеру Security Operations.
Продолжаем собирать и применять сценарии использования ИИ для задач безопасности. Новый кейс использования для разработки правил выявления угроз:
* Аналитик загружает в LLM техники атак, описанные в формате блогпоста или отчета об угрозе.
* В запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта.
* Модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промпт).
Самый ресурсоемкий для аналитика этап - это составление точного промпта. Поэтому важно отработать навык prompt engineering.
Так как написание правил - это процесс, который зачастую происходит в свободное от обработки инцидентов время, то данный сценарий залетает в бэклог к лидеру Security Operations.
5👍2🔥2
Подборка исследований с Black Hat 2024
В августе прошли крупнейшие ИБ-мероприятия, и уже можно встретить обзоры наиболее «громких» исследований с точки зрения медиа.
Возьмем доклады Black Hat, изучим материалы и самостоятельно выделим перспективные направления. Моя подборка:
* “From Weapon to Target: Quantum Computers Paradox” - исследование вопросов безопасности квантовых компьютеров и процесса квантовых вычислений. Несмотря на активное обсуждение влияния квантовых вычислений на классическую криптографию, вопросы безопасности самих квантовых систем остаются малоизученными. Авторы анализируют уязвимости и возможные векторы атак на квантовые вычислительные инфраструктуры, включая программное обеспечение и облачные сервисы. Примеры выявленных проблем: кража токенов аутентификации, изменение квантовых цепочек программ в SDK, а также атаки на квантовые процессоры.
* “SnailLoad: Anyone on the Internet Can Learn What You're Doing” - интересная техника составления профиля пользователя без каких-либо вспомогательных инструментов посередине (без агентов на его рабочей станции или прокси-серверов в его сети). Канал утечки данных находится в задержках сети, которые появляются, когда пользователь взаимодействует с онлайн-контентом. Анализируя эти задержки, злоумышленник может точно определить действия пользователя, что может привести к раскрытию конфиденциальной информации и деанонимизации. Эта техника подчеркивает уязвимость даже защищенных сессий браузера перед сложными атаками на основе временных характеристик (timing-атаки).
* “Listen to the Whispers: Web Timing Attacks that Actually Work” - и еще одно исследование timing-атак, но уже в контексте безопасности веб-приложений. Приведены примеры ситуаций, когда атакуемая система раскрывает конфиденциальные данные из-за разных временных задержек при обработке запросов. Техника пригодится для обнаружения скрытой поверхности атаки и определения некорректных настроек прокси-серверов.
* “Deep Backdoors in Deep Reinforcement Learning Agents” - техника интеграции «вредоносных нейронов» в нейронную сеть. В исследовании описаны сценарии компрометации ИИ-агентов на этапе их обучения и последствия неправильных решений, которые эти агенты могут принимать в промышленности, автономном транспорте и кибербезопасности.
⭐️ Подборка исследований Black Hat 2023.
#дайджест @makrushin
В августе прошли крупнейшие ИБ-мероприятия, и уже можно встретить обзоры наиболее «громких» исследований с точки зрения медиа.
Возьмем доклады Black Hat, изучим материалы и самостоятельно выделим перспективные направления. Моя подборка:
* “From Weapon to Target: Quantum Computers Paradox” - исследование вопросов безопасности квантовых компьютеров и процесса квантовых вычислений. Несмотря на активное обсуждение влияния квантовых вычислений на классическую криптографию, вопросы безопасности самих квантовых систем остаются малоизученными. Авторы анализируют уязвимости и возможные векторы атак на квантовые вычислительные инфраструктуры, включая программное обеспечение и облачные сервисы. Примеры выявленных проблем: кража токенов аутентификации, изменение квантовых цепочек программ в SDK, а также атаки на квантовые процессоры.
* “SnailLoad: Anyone on the Internet Can Learn What You're Doing” - интересная техника составления профиля пользователя без каких-либо вспомогательных инструментов посередине (без агентов на его рабочей станции или прокси-серверов в его сети). Канал утечки данных находится в задержках сети, которые появляются, когда пользователь взаимодействует с онлайн-контентом. Анализируя эти задержки, злоумышленник может точно определить действия пользователя, что может привести к раскрытию конфиденциальной информации и деанонимизации. Эта техника подчеркивает уязвимость даже защищенных сессий браузера перед сложными атаками на основе временных характеристик (timing-атаки).
* “Listen to the Whispers: Web Timing Attacks that Actually Work” - и еще одно исследование timing-атак, но уже в контексте безопасности веб-приложений. Приведены примеры ситуаций, когда атакуемая система раскрывает конфиденциальные данные из-за разных временных задержек при обработке запросов. Техника пригодится для обнаружения скрытой поверхности атаки и определения некорректных настроек прокси-серверов.
* “Deep Backdoors in Deep Reinforcement Learning Agents” - техника интеграции «вредоносных нейронов» в нейронную сеть. В исследовании описаны сценарии компрометации ИИ-агентов на этапе их обучения и последствия неправильных решений, которые эти агенты могут принимать в промышленности, автономном транспорте и кибербезопасности.
#дайджест @makrushin
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5🥱2
Вместе с командой ИУ10 МГТУ им. Баумана мы накатили обновление в образовательную программу кафедры «Защита информации» и подготовили проект, который добавит разработчику новые суперспособности.
Перевернем календарь и запустим трансформацию⚡️
Перевернем календарь и запустим трансформацию
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥8❤5🤪1
Запуск security-проекта: шаблоны и чеклисты для быстрого старта
Встретил полезный ресурс с шаблонами для запуска security-проектов. Программа багбаунти, тестирование на проникновение, процедуры реагирования на инциденты и управления уязвимостями - документы пригодятся новой команде безопасности, владельцу продукта или начинающему CISO в каком-нибудь стартапе.
В репозитории содержатся:
* чеклисты для подготовки к запуску;
* описание процессов и плейбуки;
* примеры метрик и шаблоны документов.
Встретил полезный ресурс с шаблонами для запуска security-проектов. Программа багбаунти, тестирование на проникновение, процедуры реагирования на инциденты и управления уязвимостями - документы пригодятся новой команде безопасности, владельцу продукта или начинающему CISO в каком-нибудь стартапе.
В репозитории содержатся:
* чеклисты для подготовки к запуску;
* описание процессов и плейбуки;
* примеры метрик и шаблоны документов.
❤2✍1👍1
Августовский #дайджест: топ постов
* Как оценить возможности ИИ в обнаружении уязвимостей?
* Побег из контейнера: обзор техник
* Платформа разработки: гайдлайны
* Доступ к данным из удаленных и приватных репозиториев GitHub
* ИИ ассистент для security-аналитика
* Подборка исследований с Black Hat 2024
* Запуск security-проекта: шаблоны и чеклисты для быстрого старта
@makrushin
* Как оценить возможности ИИ в обнаружении уязвимостей?
* Побег из контейнера: обзор техник
* Платформа разработки: гайдлайны
* Доступ к данным из удаленных и приватных репозиториев GitHub
* ИИ ассистент для security-аналитика
* Подборка исследований с Black Hat 2024
* Запуск security-проекта: шаблоны и чеклисты для быстрого старта
@makrushin
1👍3🐳1
Моделируем угрозы по-быстрому: STRIDE
Бывают ситуации, когда необходимо быстро подготовить модель угроз. Например, внезапно команда разработки решила самостоятельно провести Security Design Review для новой фичи. Или только что образованной команде безопасности продукта потребовалось определить приоритеты в анализе защищенности. А еще бывает так, что в стартапе, где все занимаются всем, потребовалось выстроить процесс безопасной разработки, и нужно с чего-то начать.
Рецепт быстрой подготовки модели угроз:
1. берем методологию STRIDE;
2. садимся вместе со всеми причастными командами и совместно заполняем шаблон;
3. получаем таблицу угроз и действий для их устранения;
4. опционально: к обнаруженным угрозам добавляем оценку рисков по модели DREAD;
5. опционально: автоматизируем процесс с помощью инструмента STRIDE GPT.
Бывают ситуации, когда необходимо быстро подготовить модель угроз. Например, внезапно команда разработки решила самостоятельно провести Security Design Review для новой фичи. Или только что образованной команде безопасности продукта потребовалось определить приоритеты в анализе защищенности. А еще бывает так, что в стартапе, где все занимаются всем, потребовалось выстроить процесс безопасной разработки, и нужно с чего-то начать.
Рецепт быстрой подготовки модели угроз:
1. берем методологию STRIDE;
2. садимся вместе со всеми причастными командами и совместно заполняем шаблон;
3. получаем таблицу угроз и действий для их устранения;
4. опционально: к обнаруженным угрозам добавляем оценку рисков по модели DREAD;
5. опционально: автоматизируем процесс с помощью инструмента STRIDE GPT.
1👍4🤣2🐳1
GitHub-звезды могут обмануть разработчика
Как мы обычно оцениваем репутацию какого-нибудь GitHub-репозитория? Чаще всего на основе количества звезд и активности в этом репозитории. Для кого-то из разработчиков число звезд напрямую определяет степень доверия к этому репозиторию.
В связи с этим растет количество фейковых звезд на GitHub: их уже насчитывается более 3,7 миллионов. Эти звезды создают ложное впечатление популярности проектов, которые на самом деле скрывают вредоносное ПО или какой-либо мошеннический контент. Злодеи используют их для обмана разработчиков, маскируя опасные репозитории под успешные проекты.
Чтобы защитить себя от этого вида мошенничества анализируем всю активность в проекте. Например, изучаем обсуждения в репозитории и репутацию авторов.
Как мы обычно оцениваем репутацию какого-нибудь GitHub-репозитория? Чаще всего на основе количества звезд и активности в этом репозитории. Для кого-то из разработчиков число звезд напрямую определяет степень доверия к этому репозиторию.
В связи с этим растет количество фейковых звезд на GitHub: их уже насчитывается более 3,7 миллионов. Эти звезды создают ложное впечатление популярности проектов, которые на самом деле скрывают вредоносное ПО или какой-либо мошеннический контент. Злодеи используют их для обмана разработчиков, маскируя опасные репозитории под успешные проекты.
Чтобы защитить себя от этого вида мошенничества анализируем всю активность в проекте. Например, изучаем обсуждения в репозитории и репутацию авторов.
🔥4👍3
Отравление пайплайна разработки
Мы уже изучали, как злоумышленник может навредить разработчику и заразить зависимости в цепочке поставок. А вот сам CI/CD-пайплайн - дирижёр конвейера разработки - мы ещё не рассматривали. При этом GitLab и GitHub всё чаще закрывают уязвимости в своих продуктах, что говорит о внимании злодеев к ключевым технологиям в инфраструктуре.
OWASP давно опубликовал документ CICD Top 10 Risks. Значительная часть рекомендаций по защите отдана на сторону разработчика и владельца репозитория: не доверяй pull request от сторонних контрибьюторов, аккуратнее прописывай правила автоматического слияния веток кода, не запускай сборку недоверенных обновлений кода рядом со сборками основной ветки и так далее. Однако злодей активно использует уязвимости в самих CI/CD-платформах для внедрения имплантов, поэтому одних рекомендаций, требующих внимания разработчика - недостаточно.
Можно изучить подборку актуальных методов эксплуатации GitHub Actions, чтобы понять типичный сценарий атаки на CI-окружение (который также был замечен в дикой природе):
1. Атакующий изменяет конфигурационный файл CI в репозитории, к которому у него есть доступ, и внедряет в этот файл команду «отдай мне переменные окружения с ценными данными».
2. Затем заносит изменения непосредственно в основную ветку репозитория или отправляет pull request с изменениями из ветки или форка.
3. Если у атакующего нет возможности вносить изменения напрямую в файл конфигурации CI, то он может внедрить вредоносный код в файлы, на которые ссылается CI-конфиг.
4. Далее атакующий отправляет pull request, который заставляет CI-платформу запустить процесс сборки на основе вредоносного конфига.
5. Так как процесс сборки практически всегда обращается к чувствительным данным и привилегированным учётным записям, то в итоге атакующий выполняет команду «отдай мне переменные окружения» на хосте, где выполняется сборка.
🤔 Как защищаемся?
Мы уже изучали, как злоумышленник может навредить разработчику и заразить зависимости в цепочке поставок. А вот сам CI/CD-пайплайн - дирижёр конвейера разработки - мы ещё не рассматривали. При этом GitLab и GitHub всё чаще закрывают уязвимости в своих продуктах, что говорит о внимании злодеев к ключевым технологиям в инфраструктуре.
OWASP давно опубликовал документ CICD Top 10 Risks. Значительная часть рекомендаций по защите отдана на сторону разработчика и владельца репозитория: не доверяй pull request от сторонних контрибьюторов, аккуратнее прописывай правила автоматического слияния веток кода, не запускай сборку недоверенных обновлений кода рядом со сборками основной ветки и так далее. Однако злодей активно использует уязвимости в самих CI/CD-платформах для внедрения имплантов, поэтому одних рекомендаций, требующих внимания разработчика - недостаточно.
Можно изучить подборку актуальных методов эксплуатации GitHub Actions, чтобы понять типичный сценарий атаки на CI-окружение (который также был замечен в дикой природе):
1. Атакующий изменяет конфигурационный файл CI в репозитории, к которому у него есть доступ, и внедряет в этот файл команду «отдай мне переменные окружения с ценными данными».
2. Затем заносит изменения непосредственно в основную ветку репозитория или отправляет pull request с изменениями из ветки или форка.
3. Если у атакующего нет возможности вносить изменения напрямую в файл конфигурации CI, то он может внедрить вредоносный код в файлы, на которые ссылается CI-конфиг.
4. Далее атакующий отправляет pull request, который заставляет CI-платформу запустить процесс сборки на основе вредоносного конфига.
5. Так как процесс сборки практически всегда обращается к чувствительным данным и привилегированным учётным записям, то в итоге атакующий выполняет команду «отдай мне переменные окружения» на хосте, где выполняется сборка.
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥2
О чем может рассказать тень на фото?
Ответ:о твоем местоположении.
Полезный инструмент в коллекции OSINT-исследователя. Позволяет определить примерные координаты места, где была сделана фотография. Утилита использует параметры высоты объекта, длины его тени, дату и время, и затем проводит оценку мест, где могла появиться тень с такими параметрами.
Те, кто не хочет раскрывать свое местоположение - начинают блюрить тени на фотках. И перестают их постить.
Ответ:
Полезный инструмент в коллекции OSINT-исследователя. Позволяет определить примерные координаты места, где была сделана фотография. Утилита использует параметры высоты объекта, длины его тени, дату и время, и затем проводит оценку мест, где могла появиться тень с такими параметрами.
Те, кто не хочет раскрывать свое местоположение - начинают блюрить тени на фотках. И перестают их постить.
3👍10😁1
Провинциальный OSINT: где я?
Продолжаем отрабатывать навыки определения места по фото.
⭐️ На этот раз задача со звездочкой: определить город, где сделано это фото, и мероприятие по информационной безопасности, которое меня сюда привело.
Фото сделал специально без явных теней. Если среди нас не окажется местных жителей, то в комментариях добавлю больше локаций.
Продолжаем отрабатывать навыки определения места по фото.
⭐️ На этот раз задача со звездочкой: определить город, где сделано это фото, и мероприятие по информационной безопасности, которое меня сюда привело.
Фото сделал специально без явных теней. Если среди нас не окажется местных жителей, то в комментариях добавлю больше локаций.
🤔2❤1