🟧Сдвиг безопасности влево (Shift Security Left)
Практика предполагает интеграцию инструментов безопасности на начальных этапах разработки. Статический анализ безопасности приложений (SAST) выявляет уязвимости (например, SQL-инъекции) непосредственно в исходном коде, а анализ компонентов ПО (SCA) проверяет сторонние библиотеки на известные уязвимости до сборки артефакта.

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

🟧Автоматизация процессов безопасности (Automate Security Processes)
Для соответствия скорости CI/CD-пайплайнов необходима полная автоматизация проверок. Интеграция сканирования инфраструктуры как код (IaC) на этапе планирования развертывания предотвращает создание небезопасно сконфигурированных ресурсов. Автоматическое обнаружение секретов в каждом коммите минимизирует риски утечки учетных данных.

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

🟧Приоритизация на основе рисков (Risk-Based Prioritization)
В условиях ограниченных ресурсов важно фокусироваться на наиболее значимых угрозах. Использование метрик EPSS позволяет оценить вероятность эксплуатации уязвимости, а анализ достижимости определяет возможность активации уязвимого кода в рабочей среде.
Например, уязвимость в недоступном извне административном интерфейсе будет иметь более низкий приоритет по сравнению с уязвимостью на публичной странице аутентификации.

Это позволяет командам оптимально распределять усилия по устранению недостатков.

🟧Автоматическая защита секретов (Automated Secrets Management)
Проактивное управление секретами включает сканирование репозиториев на наличие учетных данных и их автоматический отзыв.

Например, интеграция с системами типа

HashiCorp Vault

позволяет не только выявить случайно закоммиченный токен

API

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

🟧Контроль безопасности инфраструктуры как код (IaC Security)
Безопасность инфраструктуры должна проверяться на стадии разработки конфигураций. Сканирование шаблонов Terraform или Kubernetes выявляет мисконфигурации, такие как: излишне разрешительные политики безопасности или нешифруемые хранилища данных.

Исправление ошибок на этапе кода предотвращает создание уязвимых сред и обеспечивает соответствие стандартам комплаенс.

🟧Формирование культуры безопасности (Cultivating a Security-First Culture)
Успех DevSecOps зависит от вовлеченности всей команды. Регулярные тренировки по безопасному программированию, внедрение практик code review с фокусом на безопасность и предоставление разработчикам оперативной обратной связи через инструменты способствуют повышению коллективной ответственности.

Когда разработчик сразу видит результаты проверки

SAST

, это ускоряет внедрение лучших практик безопасности.

🟧Повышение видимости с помощью дашбордов и отчетности (Enhanced Visibility and Reporting)
Централизованные дашборды обеспечивают единую точку мониторинга метрик безопасности для всех стейкхолдеров. Например, они могут отображать динамику обнаружения уязвимостей, их критичность и скорость устранения.

Интеграция с системами управления задачами (

Jira

) автоматизирует создание тикетов на исправление, обеспечивая прозрачность процесса управления рисками.

🟧Непрерывный мониторинг пайплайнов (Continuous Pipeline Monitoring)
Практика направлена на обнаружение аномалий в процессах CI/CD. Мониторинг на основе поведенческого анализа выявляет подозрительную активность, например, запуск сборок из неавторизованных источников.

Отслеживание дрейфа конфигураций обеспечивает соответствие пайплайнов политикам безопасности на протяжении всего жизненного цикла.

☎️ Хакеры обманом заставляют загружать вредоносную версию Microsoft Team

👩‍💻 Атакующие пользуются доверием пользователей к популярному программному обеспечению, обманным путем заставляя их загружать модифицированную версию Microsoft Team для получения удаленного доступа.

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

🎩 Компания Blackpoint выявила новую волну атак, при которой пользователи, ищущие «скачать Microsoft Teams», видят вредоносную рекламу, перенаправляющую их на поддельные веб-сайты. Пользователи переходили на "teams-install[.]top", в котором располагался вредоносный файл "MSTeamsSetup.exe"

✍️ Чтобы выглядеть как настоящие, эти поддельные установщики часто подписываются ненадёжными цифровыми сертификатами от таких эмитентов, как «4th State Oy» и «NRM NETWORK RISK MANAGEMENT INC.». Этот приём помогает обойти базовые проверки безопасности, которые выявляют неподписанное ПО.

📌 ВПО помещала в папку %APPDATA%\\Roaming зараженный DDL с именем CaptureService.dll и тем самым обеспечивала закрепление в инфраструктуре жертвы.

🔐 Данный комплекс вредоносной активности назвали бэкдор Oyster, который обеспечивал удаленный доступ и взаимодействие с C2-сервером. В ходе анализа были выявлены такие индикаторы компрометации, как nickbush24[.]com и techwisenetwork[.]com.

⚠️ Будьте внимательны и проверяйте, какие ресурсы посещаете.

Скучали по неформальным встречам? Тогда вам на Security DrinkUp 15 октября от Авито! ☄️

Некоторые из тем, которые будут там обсуждать в неформальной обстановке:

➡️ WAF или POH? Стоит ли WAF своих денег;
➡️ Нужны ли «апруверы» в заказе доступов;
➡️ DLP: фикция или реальное средство защиты данных организации;
➡️ AI в безопасности и безопасность в AI.

Будет ли что-то кроме дискуссий?

Конечно! Можно будет сыграть в кастомную настолку «Киберлабиринт» и максимально продуктивно понетворкать.

Так что если давно искали, как познакомиться поближе с комьюнити — велком по ссылке на регистрацию!

Исследователь из команды Google Project Zero детально описал новый метод удаленной утечки адресов памяти в операционных системах macOS и iOS. Этот подход позволяет обойти ключевую технологию безопасности — рандомизацию макета адресного пространства (ASLR), — не используя традиционные уязвимости повреждения памяти или атаки по боковым каналам, основанные на времени.

🟧 История открытия
Исследование было инициировано в 2024 году в рамках внутренней дискуссии в Project Zero о поиске новых способов удаленного обхода ASLR на устройствах Apple. Хотя в ходе работы не была выявлена конкретная уязвимая система или приложение в реальном мире, исследователь создал работающий прототип (proof-of-concept) на основе искусственного тестового случая с использованием фреймворка сериализации NSKeyedArchiver в macOS.

Полученные выводы были ответственно раскрыты компании Apple, которая изучила проблему и устранила ее в своих обновлениях безопасности, выпущенных 31 марта 2025 года.

🟧 Механизм атаки
В основе техники лежит предсказуемое поведение процессов сериализации и внутренняя работа объектов NSDictionary (которые, по сути, являются хэш-таблицами) в среде Apple.

Цель атаки

— утечка адреса памяти системного синглтона (уникального объекта)

NSNull

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

ASLR

для общей области памяти (кэша), в которой он находится.

🟧 Процесс атаки имеет несколько этапов:
🟧Злоумышленник создает сериализованный объект NSDictionary. Этот словарь содержит комбинацию ключей NSNumber (хэш-значения которых можно контролировать) и один ключ NSNull.
🟧Ключи NSNumber подбираются таким образом, чтобы они заняли конкретные «сегменты» (bucket) внутри хэш-таблицы, создавая заранее известную схему заполненных и пустых слотов.
🟧Приложение-жертва десериализирует присланный объект, создавая его копию в своей памяти. Когда это приложение повторно сериализирует объект (например, чтобы отправить его обратно), оно перебирает сегменты хэш-таблицы в предсказуемом порядке.
🟧Позиция, которую ключ NSNull занимает в возвращенных сериализованных данных, указывает на тот сегмент хэш-таблицы, в который он был помещен. Это раскрывает частичную информацию о его адресе в памяти, а именно результат вычисления адрес modulo размер_таблицы.
🟧Для реконструкции полного 64-битного адреса памяти в этой технике применяется китайская теорема об остатках. Злоумышленник отправляет жертве множество словарей разного размера (каждый — с разным простым числом сегментов). Это позволяет собрать несколько различных «остатков» от адреса.

Комбинируя эти результаты, можно вычислить точное местоположение синглтона

NSNull

в памяти, что эффективно обходит защиту

ASLR

для этой области.

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

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

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

🚩 Новые задания на платформе HackerLab!

👩‍💻 Категория Pentest Machines — Аромат
——————————————

🗂 В архив добавлены задания с прошлых соревнований + райтапы:

🟠Веб - Микробаг
🟠Реверс-инжиниринг - Три Лика Тени

Приятного хакинга!