Информационная безопасность *

В каждой профессии есть ритуал инициации, о котором не принято говорить вслух. У хирургов — первая ночная смена с тяжёлым пациентом. У пилотов — посадка вслепую на тренажёре. У багхантеров и пентестеров есть Карлос. Да, тот самый Carlos, чей пароль или токен вы будете выгрызать из экзаменационного приложения PortSwigger, пока где-то на фоне тикает таймер, а Burp Collaborator хранит гробовое молчание.

Меня зовут Султан. Первая попытка, два часа — экзамен сдан.

Я знаю, о чём вы подумали: сдать BSCP с первого раза удаётся очень немногим, даже опытным специалистам. Так почему у меня получилось? Ответ — в методологии.

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

Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE.

Copy Fail как примитив Process Injection через Page Cache

Оригинальный PoC модифицирует setuid binary перед execve и получает root.
Второй публичный PoC подменяет id у текущего юзера на 0000.

Хорошие, рабочие LPE, дающие рута.

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

Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.

Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.

Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.

Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.

Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.

«Мне прислали фишинг под MAX. Внутри оказался MITM в их API» «Не ты ли на фото?» — пришло поздно вечером, в обычной переписке, от знакомого, который пишет редко. К сообщению приложена короткая ссылка. Я понял, что у него увели аккаунт, и захотел разобраться, что внутри. Через пять дней я смотрел на инфраструктуру из 179 фишинговых доменов, четырёх хостингов, через которые оператор переезжал каждые сутки, и обнаружение, что фишинг-кит работает не как сборщик паролей, а как MITM-прокси к настоящему API мессенджера MAX. Жертва получает реальный SMS от реального MAX и не может распознать атаку. CVSS 8.8. VK молчит уже неделю.

MCP-серверы не умеют в авторизацию, n8n не умеет в per-user токены, а OAuth-клиенты говорят на разных диалектах. Рассказываем, как один Auth Proxy перед FastMCP Gateway закрыл все три проблемы — и почему в итоге бот переехал на LangGraph

Выявить уязвимость до того, как ею воспользуются злоумышленники, разобраться в тонкостях безопасности информационных систем, освоить инструменты пентестеров под руководством опытных наставников — всё это можно попробовать на практике на стажировке в DSEC by Solar. Ждем ваши заявки до 10 мая!

30 апреля в сети появилась информация, что глобальная IT-компания и оператор крупной интернет-инфраструктуры Cloudflare присвоила домену национального мессенджера Max классификацию Spyware (шпионское ПО). Прежде чем мысленно ухмыльнуться и подумать «а я же говорил», давайте объективно разберемся, что это за шум.

В этой статье мы расскажем: кто такая компания Cloudflare, почему она ставит подобные метки, что значит «spyware», на основании каких признаков Cloudflare принимает такие решения, а также какие последствия такая метка может иметь.

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

У ransomware-операторов теперь есть план: сначала они охотятся за бэкапами, потом — за продакшеном. Перевод технического разбора правила 3-2-1 — что в нём всё ещё работает, что нет и зачем над ним надстроили «1-0».

Привет, Хабр! Находясь на мероприятии BI.ZONE Day, я слушал доклады и ходил между стендами, думая, чтобы такого спросить, не связанного с продуктами и технологиями компании, чьё было мероприятие. И тут меня привлекла презентация про фишинг, я не мог отказать себе в удовольствии задать несколько вопросов специалистам по фишингу. Тем более тема всегда актуальная и интересная. Поэтому я поговорил с руководителем BI.ZONE AntiFraud Алексеем Лужновым и руководителем BI.ZONE Digital Risk Protection Дмитрием Кирюшкиным. Встречайте интервью Алексея и Дмитрия о том, как ИИ изменил методы фишинга, какие приёмы социальной инженерии до сих пор работают в 2026 году, насколько велик рынок понятия «фишинга как услуги» (Phishing as a Service, PHaaS) и не только. Приятного чтения!

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

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

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

Всем привет, меня зовут Михаил Сухов, я участник команды PT SWARM. Нам в команде все чаще встречается инфраструктура, построенная на базе альтернативных реализаций службы каталога Microsoft Active Directory. Одной из таких реализаций, заслуженно получившей большое распространение является FreeIPA.

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

Так появился IPAHound — наш аналог BloodHound для FreeIPA. За основу был взят проект BloodHound Legacy с поддержкой PKI.

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

Автор: B0rn2beR00T (специалист по тестированию на проникновение web-приложений)

Приветствую, коллеги!

Форма аутентификации присутствует во многих ПО. Она встречается в web-приложениях, интерфейсах сетевых железок, виртуализации, БД, файловых хранилищах, CRM и многом другом. Пользователь в такой системе предоставляет такую информацию, как пароли, кодовые фразы, PIN-коды или ответы на секретные вопросы, чтобы подтвердить, что он привилегированный.

Частые случаи, когда система аутентификации настроена или написана недобросовестно, что позволяет обходить её за счёт таких ошибок. Обычно эти ошибки — это неправильная конфигурация, ошибка в логике аутентификации или отсутствие санитаризации ввода пользователя. Даже популярные вендоры допускают баги аутентификации, что приводит к её обходу (bypass). Критичность при обходе такой системы может вылиться в неприятные последствия, например: получение прав админа на сайте. Именно поэтому, для тестировщиков важно понимать как следует проверять такую точку входа в систему.

В новой статье мы разберём Skills Assessment в модуле Broken Authentication платформы Hack The Box Academy, где и протестируем уязвимую систему аутентификации.

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

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

В этом материале соберём такой сценарий на Python, используя вместо базы данных Битрикс24. Решение берёт контекст из CRM в момент звонка и через МТС Exolve соединяет клиента, исполнителя или поддержку. 

Почему для некоторых GitHub перестал быть безопасным дефолтом, и что с этим делать - если вы, конечно, не хотите узнать об этом в день блокировки аккаунта или когда ваши закрытые репозитории могут общественным достоянием?

Думаю, для многих GitHub почти стал именем нарицательным. Помню, как я не знал, что такое git, но уже публиковал исходный код маленькой игры на GitHub через загрузку файлов. Многое было другим на тот момент: ИТ не был на пике мейнстрима, ИИ казался чем-то очень далеким и GitHub был де-факто стандартом.

Времена меняются и довольно быстро: теперь многие задаются вопросом так ли перспективен ИТ, появились LLM, которые используются ежедневно, GitHub уже не справляется с нагрузкой, а его приватные репозитории оказывается не такие уж и приватные.

28 апреля 2026 года стало по-настоящему плохим днём для GitHub. Утром CTO платформы опубликовал длинное извинение за кризис стабильности - 8 серьёзных сбоев за два месяца. Этим же днём Wiz Research опубликовал детали критической уязвимости CVE-2026-3854: один обычный git push мог выполнить произвольный код на серверах GitHub.

По порядку разберём и свежие, и давние события с точки зрения обычного разработчика, которые происходят с GitHub сейчас

Мы искали уязвимости в RAG-платформе с десятками тысяч пользователей — а нашли доступ ко всей инфраструктуре и API-ключам с бюджетом в сотни тысяч долларов. Две недели мы строили сложные цепочки: SSRF через LangChain, инъекции в промпты, HTTP smuggling, CVE в десериализации. Ни одна не дала результата. А потом мы сделали один curl к открытому порту — и получили все ключи за 5 минут.

Эта статья — не гайд по взлому. Это разбор того, почему LLM-инфраструктура создаёт принципиально новые риски, какие ошибки мы раз за разом видим в AI-стартапах, и на что стоит обратить внимание, если вы строите что-то похожее.

RAG часто воспринимают как аккуратный способ «заземлить» LLM на документах и снизить риск галлюцинаций. Но у этой архитектуры есть менее очевидная проблема: контекст из базы знаний обычно считается доверенным, хотя именно через него в модель могут попасть вредоносные инструкции.

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

В 2026 для VPN нужна маскировка. А нет никакой лучшей маскировки, чем уже работающий легитимный сервис. Силами NGINX-streams и HTTP2 это сделать довольно легко.

В предыдущей статье "Сканеры ML-моделей: разбор инструментов и некоторых методов обхода их проверок" был представлен обзор основных статических сканеров артефактов ML-моделей. В выводах сканер ModelAudit был выделен как наиболее зрелое решение среди проанализированных конкурентов по следующим критериям:

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

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

- сканирование подмножества моделей из Hugging Face, сериализованных в виде наиболее опасных форматов хранения моделей;
- сканирование таких моделей из Hugging Face, помеченных самими авторами как зловредные (в названии или описании), с последующим сравнением сработок ModelAudit с результатами проверок встроенных в Hugging Face инструментов.

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.