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

Цепочка поставок
С чего всё началось
К нам пришёл клиент с уверенностью, что у него всё в порядке. Периметр закрыт, пароли строгие, сотрудники обучены. Мы начали с непривычного вопроса. Не насколько защищены вы, а кому вы доверяете не проверяя. Оказалось, современный продукт почти никогда не пишется с нуля. Он собран из десятков чужих кусков. Сторонние библиотеки, облачные сервисы, платёжные модули, подрядчик на части кода, внешний интегратор с доступом к системе. Каждый такой кусок это дверь, которую вы не контролируете, но которой доверяете по умолчанию. Атакующему необязательно ломать вас, достаточно сломать того, кому вы уже открыли дверь. Ваша безопасность теперь не равна вашим усилиям. Она равна самому слабому звену среди всех, кому вы доверяете, а это звено часто вообще не ваше.
Что насторожило
Мы составили карту доверия. Не список того, что написала команда клиента, а реальный перечень того, что подтягивается в сборку, какие внешние сервисы имеют доступ и кто из людей может писать в систему. Карта вышла шире, чем представляли сами разработчики, и это нормально, такое бывает почти всегда. Часть сторонних библиотек не обновлялась годами. Часть тянула внутри себя другие зависимости, которых никто в команде в глаза не видел, то есть в продукт попадал и выполнялся код, который ни один сотрудник не писал и не читал. Отдельно насторожили доступы людей. Внешний разработчик, делавший когда-то часть функциональности, до сих пор имел доступ к системе с широкими правами, давно ему не нужными. Его собственная безопасность находилась полностью вне зоны контроля клиента. Взломают его рабочую машину, и через неё заходят к вам, а вы об этом даже не узнаете.
Как открылось чужое
Мы аккуратно показали два реальных пути внутрь, не выполняя разрушительных действий, только доказывая, что путь существует. Первый, через зависимость. Среди подтянутых библиотек нашлась устаревшая с публично известной уязвимостью. Опасность тут не абстрактная. Когда дыра в популярной библиотеке становится известной, атакующие массово сканируют интернет в поисках всех, кто её ещё использует. Жертву не выбирают прицельно, под удар попадает каждый, кто не обновился, и попадает быстро. Мы показали, что через эту библиотеку открывается путь к выполнению кода внутри среды продукта, то есть чужой компонент становится точкой входа. Второй путь, через человека. Избыточный доступ внешнего разработчика означал, что компрометация одного подрядчика вне компании даёт вход в систему клиента сразу с серьёзными правами. Атакующему незачем штурмовать ваш периметр, если можно тихо войти через того, кому периметр уже открыт. Сложив это вместе, мы получили картину. Компания, которая всё сделала правильно у себя, оставалась уязвимой через тех, кого впустила. И заметить это в своих логах почти невозможно, потому что снаружи всё выглядит как легитимный компонент и легитимный доступ.
Где была дыра и как закрыли
Корень был не в конкретной библиотеке и не в конкретном подрядчике. Причина системная. Доверие к внешним компонентам и людям выдавалось один раз и навсегда, без проверки, без срока и без ограничения прав. Мы зафиксировали три причины и закрыли каждую вместе с командой. Первая, никто не знал полного состава продукта. Собрали и зафиксировали полную опись всех зависимостей, включая вложенные, и настроили автоматическую проверку каждой сборки на известные уязвимости, чтобы новая опасная зависимость была видна сразу, а не через год. Нельзя защитить то, о существовании чего вы не знаете. Вторая, чужой код выполнялся с полными правами. Почистили и обновили зависимости, лишнее убрали, а оставшимся урезали права, чтобы даже скомпрометированный компонент упирался в узкую песочницу, а не получал доступ ко всему. Третья, доступы людей жили вечно. Провели ревизию всех внешних доступов, ненужное отозвали, оставшимся выдали минимальные права с понятным сроком и регулярным пересмотром. После внедрения мы повторили проверку. Опасных зависимостей не осталось, новые отлавливаются автоматически, забытые доступы закрыты, оба пути внутрь больше не работают.
Что забрать себе
Этот кейс показывает простую и неприятную вещь. Ваша защита заканчивается не на вашем периметре, а на периметре самого слабого из тех, кому вы доверяете. Именно так шли самые громкие взломы последних лет, ломали одного поставщика и через него заходили к сотням его клиентов разом. Проверьте три вещи. Знаете ли вы полный список того, из чего собран ваш продукт, включая зависимости зависимостей. С какими правами выполняется внутри вас чужой код и что он сможет, если в нём окажется дыра. И кто из внешних людей и сервисов до сих пор имеет доступ к вашей системе и нужен ли он там сейчас. Если хоть на один вопрос ответа нет, дверь, про которую вы забыли, уже кем-то найдена.


