Скучали по неформальным встречам? Тогда вам на 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 — Аромат
——————————————

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

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

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

Nuclei: Автоматизация безопасности через шаблоны

Nuclei — инструмент командной строки с открытым исходным кодом для масштабируемого сканирования безопасности на основе шаблонов. Принцип работы основан на использовании централизованной базы шаблонов (формат YAML). Каждый шаблон содержит инструкции для проверки одной конкретной уязвимости, небезопасной конфигурации или технологии.

✅Преимущества
- Шаблоны позволяют минимизировать ложные срабатывания за счет точного описания условий обнаружения
- Сообщество безопасности регулярно создает и обновляет шаблоны для новых уязвимостей
- Поддерживает проверки HTTP, DNS, TCP и рабочих процессов

✨Устанавливаем

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
nuclei -update-templates

✨Проверяем

nuclei -h

✨Сканируем

nuclei -u example.com -severity critical,high
nuclei -list targets.txt -o results.json -json

🟣Для проверки цели на конкретную уязвимость (например, Log4Shell (CVE-2021-44228)), укажем путь к конкретному шаблону:

nuclei -u https://example.com -t /path/to/nuclei-templates/cves/2021/CVE-2021-44228.yaml

Получаем такой результат:

[CVE-2021-44228] @ https://example.com/api/login
[info] The target is vulnerable to Log4Shell (CVE-2021-44228).
[template] cves/2021/CVE-2021-44228.yaml
[severity] critical

📎Полезные команды
✨Объединение с subfinder и httpx

echo "domain.com" | subfinder | httpx | nuclei -silent

✨Оптимизация скорости

nuclei -list targets.txt -rate-limit 50 -concurrency 10

✨Лимиты для избежания блокировок

nuclei -u example.com -rate-limit 10 -timeout 20

❎Недостатки
- Высокая нагрузка на сеть при агрессивном сканировании
- Риск блокировки IPS/WAF системами при отсутствии настройки лимитов

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

🔺Хронология инцидента
Инцидент берет начало не с технического взлома, а с многоэтапной атаки методом социальной инженерии. Злоумышленники, используя методы манипуляции, смогли обманом получить доступ к учетной записи одного из сотрудников сторонней службы поддержки. Это произошло до 5 мая 2023 года, когда команде безопасности Discord официально стало известно о произошедшем.

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

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

🔺Реакция и предпринятые меры
Узнав об инциденте, Discord немедленно приступил к серии действий по устранению угрозы и минимизации последствий.
🟣Первым действием стала полная блокировка скомпрометированной учетной записи сотрудника сторонней службы поддержки для предотвращения дальнейшего несанкционированного доступа.
🟣В срочном порядке обслуживание клиентов было переведено на нового поставщика услуг для обеспечения непрерывности работы.
🟣Была запущена целевая рассылка всем пользователям, чьи данные могли быть затронуты инцидентом. Каждому такому пользователю было направлено персональное сообщение с описанием ситуации и рекомендацией проявлять повышенную бдительность к фишинговым письмам, которые могут прийти на адрес электронной почты, указанный в обращении в поддержку.
🟣Компания инициировала работу по усилению систем безопасности и пересмотру процессов взаимодействия с третьими сторонами для предотвращения подобных инцидентов в будущем.

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

💬А что думаете вы о данном инциденте?