Чёрный рынок утечек данных в России схлопнулся из-за телеграм-ботов

Чёрный рынок утечек данных в России схлопнулся из-за телеграм-ботов

Чёрный рынок утечек данных в России схлопнулся из-за телеграм-ботов

Российский сервис разведки утечек данных и мониторинга даркнета DLBI подвёл итоги 2025 года — и картина получилась неожиданной. Полуоткрытый чёрный рынок утечек данных в России фактически схлопнулся. Но не потому, что утечек стало меньше.

По данным DLBI, за год в открытый и ограниченный доступ — включая даркнет-форумы и телеграм-каналы — попала 61 утечка, содержащая 36,5 млн уникальных телефонных номеров и 28,7 млн адресов электронной почты.

Это почти в семь раз меньше по числу утечек и в десять раз меньше по объёму, чем в 2024 году.

Лидерами по утечка в 2025 году стали логистика — на неё пришлось почти 60% всех данных, затем ретейл (18%) и электронная коммерция (6,5%). Для сравнения: год назад рынок выглядел иначе — тогда доминировала e-commerce, а в топ также входили развлекательные и медицинские сервисы.

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

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

По оценке DLBI, в 2025 году произошло ещё как минимум 40 значимых утечек, которые не попали даже в ограниченный доступ. Все они были выкуплены владельцами телеграм-ботов для дальнейшей розничной перепродажи. А на открытом рынке остались в основном «второстепенные» базы — доставка, программы лояльности, покупки в интернет-магазинах. То есть данные, за которые никто не готов платить эксклюзивно.

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

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

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

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

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

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru