Выявлена MITM-атак, основанная на подстановке фиктивных BGP-маршрутов

Выявлены MITM-атаки, основанные на подстановке фиктивных BGP-маршрутов

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

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

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

В качестве примера подобных атак приводятся перенаправление трафика некоторых жертв из США, Южной Кореи, Германии, Чехии, Литвы, Ливии и Ирана на оборудование одного из белорусских провайдеров за счёт подстановки маршрута на оборудовании Level3-оператора Global Crossing. Кроме Белоруси 17 фактов перенаправлений было выявлено на некоторые ISP из Исландии. Всего за текущий год зафиксировано 38 подобных перенаправлений. Мотивы, инициаторы атаки и детали совершения атак пока не ясны. По мнению исландского оператора Síminn, перенаправление вызвано уже исправленной программной ошибкой, появление которой они не связывают с проведением злонамеренной атаки.

Рынку DevSecOps не хватает специалистов, а зарплаты идут вверх

На российском рынке безопасной разработки становится всё заметнее перекос между спросом и предложением. По данным совместного анализа HH.ru и ГК «Солар», специалистов в этой области сейчас требуется примерно в три раза больше, чем реально есть на рынке.

Аналитики отмечают, что в 2025 году вакансии по безопасной разработке составили 4,8% от общего числа предложений в сфере ИБ, тогда как резюме таких специалистов — только 1,5%. Иными словами, бизнесу нужны DevSecOps- и AppSec-специалисты, но найти их всё сложнее.

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

На этом фоне ожидаемо ускоряется и рост зарплат. По итогам 2025 года начинающим специалистам по безопасной разработке с опытом от года до трёх лет предлагали от 107 тыс. до 140 тыс. рублей. Специалисты среднего уровня могли рассчитывать уже на 193–260 тыс. рублей, а опытные профессионалы — на 330–420 тыс. рублей.

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

Расходы бизнеса на такие команды тоже быстро растут. По оценке HR-специалистов «Солара», годовой фонд оплаты труда команды безопасной разработки даже в относительно компактной конфигурации начинается примерно от 9,3 млн рублей. А более сильные и опытные составы уже требуют 25–26 млн рублей в год и выше.

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

По оценке «Солара», использование специализированных LLM-моделей в закрытом контуре может сократить годовой ФОТ AppSec-команд на 20–50% — в зависимости от масштаба разработки. Но это не отменяет главного: окончательное решение всё равно должно оставаться за инженером, а не за моделью.

В целом рынок движется к довольно понятной точке. DevSecOps и AppSec перестают быть чем-то факультативным или «для крупных компаний». Безопасность всё чаще встраивают прямо в процесс разработки, потому что исправлять уязвимости на ранних этапах заметно дешевле, чем разбираться с последствиями уже после запуска.

По приведённым оценкам, стоимость устранения уязвимости может вырасти в 10 раз на поздних этапах разработки, в 640 раз — на этапе запуска приложения и в 1000 раз, если проблема уже привела к ИБ-инциденту в работающем продукте.

На этом фоне растёт и спрос на специалистов, которые умеют работать не только с классическими ИБ-задачами, но и с инструментами автоматизации анализа кода — SAST и DAST, а также понимают саму разработку. Всё более ценными становятся инженеры с опытом в Python, Go, Java, а не только с администраторским или инфраструктурным бэкграундом.

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