[Информационная безопасность] Атака через поставщика или подрядчика глазами пентестера
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Атака на Solar Winds в 2020 году привлекла особое внимание к теме supply chain. Кратко об атаке (ну вдруг кто-то не в курсе): злоумышленники получили доступ к системе сборки SolarWinds Orion и добавили «закладку» в один из DLL-файлов. Затем эта DLL была распространена среди клиентов SolarWinds через платформу автоматического обновления. После загрузки «закладка» подключалась к серверу управления и контроля (C2), чтобы получать «задания» для исполнения на заражённом компьютере.В самой атаке нет ничего нового. Так, в 2016 году был взломан Linux Mint и в дистрибутив была установлена вредоносная закладка. Тогда на это особо не обратили внимание. Однако в случае с Solar Winds пострадало много компаний и организаций. Да и в целом атаки через поставщика или через подрядчика становятся все более популярными. А значит, есть смысл заранее подумать о мерах противодействия.Жертвой подобной атаки вполне можно стать и при установке нелицензионного, взломанного программного обеспечения. Злоумышленники часто включают в дистрибутив закладку, которая будет предоставлять им удаленный доступ к компьютеру, и размещают такой дистрибутив в интернете на площадках, где полно такого нелицензионное ПО, или через торренты. Атаки через поставщика — когда сначала взламывают подрядчика, а затем атакуется связанная с ним целевая организация — можно разделить на два типа:· supply chain — через цепочку поставки (в классификации MITRE ATT&CK — ID:1195);· trusted relationship — через доверительные отношения (в классификации MITRE ATT&CK — ID:1199).Эти атаки очень похожи, но имеют различные способы реализации.Атака через цепочку поставки проводится с помощью программно-аппаратных средств. В само программно-аппаратное средство или в часть обновления внедряется имплант, который предоставляет прямой доступ к серверу, или устанавливает связь с центром управления (Command & Control, C2). Такая атака, как правило, не является целенаправленной – ведь нельзя дать гарантию, что а) целевая организация установит нужное обновление и б) что сервер, на который устанавливается обновление, не имеет выхода в интернет и обновляется вручную. Если сервер получает обновление автоматически и правила файрволла ограничивают доступ только к серверу обновлений, то это не дает гарантий безопасности: злоумышленники могут контролировать этот сервер обновлений и перенаправлять трафик от импланта на C2. Атаки через доверительные отношения связанны с компрометацией доверенных каналов (например, VPN). Многие организации пользуются услугами подрядчиков, в том числе и малых организаций, работающих удаленно (и в подавляющем большинстве случаев слабо защищенных). Злоумышленники могут атаковать одного из подрядчиков и получить в его сеть и в дальнейшем может довольно легко проникнуть в целевую инфраструктуру и, оставаясь незамеченным, развивать свою атаку – ведь никто не ждет подвоха со стороны доверенного партнера (по этой причине большой успех может иметь, например, «внутренний» фишинг). При всем при этом внутренняя инфраструктура обычно менее защищена, что тоже играет на руку хакерам. Как можно себя обезопасить?Выявлять такие атаки непросто. Анализ обновлений на наличие «закладок» — задача трудоемкая и дорогостоящая. Можно использовать поведенческий анализ для выявления аномалий. Сегментирование сети (что в общем-то должно быть нормой) также поможет снизить риски негативных последствий таких атак. Что касается тестирования на проникновение, то будет достаточно сложно договориться между тремя сторонами о проведении таких работ. Подобные проекты могут выполнять головное и дочерние предприятия, но что делать с разными компаниями?Частично проблему может решить тестирование методом предполагаемого нарушения (Assumed Breach). В этом случае легенда подразумевает, что подрядчик был скомпрометирован и целью злоумышленников является компания. Другими словами, предполагается, что у злоумышленников уже есть доступ во внутреннюю сеть организации. Такой вид тестирования способен продемонстрировать, что может произойти в случае наступления реальной атаки.Как организовать тестирование методом Assumed Breach Первое, что необходимо сделать для проведения таких работ — это определиться с типом угрозы, которая будет симулироваться. Для атаки через цепочку поставки заказчику нужно запустить подобие «импланта» на сервере, где стоит ПО разработчика, который, по легенде тестирования, был скомпрометирован. Этот «имплант» организует канал связи с С2 исполнителя тестирования на проникновение. Многие компании используют тестовые среды для проверки обновлений, прежде чем установить их на эксплуатационные серверы. Эти же тестовые среды могут использоваться для проведения тестирования методом предполагаемого нарушения, если их сетевая конфигурация совпадает с эксплуатационной.С симуляцией атак через доверенное отношение все проще: заказчику необходимо предоставить доступ через VPN в тот же сегмент сети, в который имеют доступ подрядчики. Возможно, также заказчику будет необходимо предоставить учетные данные с такими же привилегиями, как и у подрядчиков.Второй шаг – определение целей. Например, получение доступа к базе данных или серверу, находящемуся в закрытом сегменте сети.Возможно несколько вариантов проведения тестирования в зависимости от модели потенциального злоумышленника:ИнсайдерМожет находиться в офисеЕсть доступ к инфраструктуреРаботы могут выполняться удаленноЗаказчик предоставляет учетные данные для доступа в сеть компанииОбслуживающий персоналМожет находиться в офисеНе имеет доступа к инфраструктуреРаботы выполняются на территории компании без предоставления доступа в сетьИсполнитель может использовать сетевые розетки и беспроводную сетьПодрядчикНет доступа в офисЕсть удаленный доступ в сеть компанииРаботы выполняются удаленноЗаказчик предоставляет доступ в сеть компанииФишинг Нет доступа в офисДоступ во внутреннюю сеть получен в результате фишинговой атакиРаботы выполняются удаленноЗаказчик открывает фишинговое письмо и выполняет необходимые действияПосле получения первоначального доступа исполнители пытаются проникнуть в общую внутреннюю сеть и проводят внутреннее тестирование на проникновение с целью продемонстрировать, какие уязвимости и недостатки там есть и как предполагаемые злоумышленники могут их использовать для достижения своих целей. Причем такие работы могут проводиться как с противодействием со стороны службы защиты информации (эдакая краткая версия Red Team), так и без – в режиме обычного внутреннего тестирования на проникновение. В целом в условиях, когда аутсорсинговых взаимодействий становится все больше, а контроль защищенности подрядчиков при этом никак не регламентируется законом и на практике вряд ли возможен, Assumed Breach – пожалуй, один из немногих относительно доступных инструментов, дающих компаниям понимание: 1) что будет в случае атаки через поставщика 2) насколько ИБ-специалисты готовы ее отражать 3) где стоит «подстелить соломку». Дмитрий Неверов, руководитель группы анализа защищенности "Ростелеком-Солар"
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Работа с видео, Машинное обучение, Искусственный интеллект] Бельгийский политический активист научил систему машинного зрения помечать на видео политиков, не слушающих заседание
- [Информационная безопасность, Законодательство в IT, Искусственный интеллект, Социальные сети и сообщества] ИИ помогает полиции мониторить соцсети — правозащитники опасаются, что это приведёт к тотальной слежке
- [Информационная безопасность, Энергия и элементы питания] В России объединили методы защиты инфраструктурных объектов от киберугроз и технологических рисков
- [Информационная безопасность] Nemesida WAF 2021: защита сайтов и API от хакерских атак
- [Информационная безопасность, Криптография] Хакеров из Cozy Bear заподозрили в атаке на нацкомитет Республиканской партии США
- [Информационная безопасность] Отделить зерна от плевел: наши наработки по ранжированию индикаторов компрометации
- [Информационная безопасность, Разработка игр, Игры и игровые приставки] От жёсткого диска на антресолях до Ransomware: как утекает исходный код игр
- [Информационная безопасность, Законодательство в IT] «ЦИАН» запустил прослушку пользователей
- [Информационная безопасность, Законодательство в IT, IT-компании] Twitter потерял иммунитет в Индии
- [Информационная безопасность, Спортивное программирование, IT-инфраструктура, Конференции] Защищаем кибергород с PT Application Firewall: полезные правила для обнаружения хакеров
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_pentest, #_red_teaming, #_supply_chain_attack, #_trusted_relationship, #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Ноя 21:13
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Атака на Solar Winds в 2020 году привлекла особое внимание к теме supply chain. Кратко об атаке (ну вдруг кто-то не в курсе): злоумышленники получили доступ к системе сборки SolarWinds Orion и добавили «закладку» в один из DLL-файлов. Затем эта DLL была распространена среди клиентов SolarWinds через платформу автоматического обновления. После загрузки «закладка» подключалась к серверу управления и контроля (C2), чтобы получать «задания» для исполнения на заражённом компьютере.В самой атаке нет ничего нового. Так, в 2016 году был взломан Linux Mint и в дистрибутив была установлена вредоносная закладка. Тогда на это особо не обратили внимание. Однако в случае с Solar Winds пострадало много компаний и организаций. Да и в целом атаки через поставщика или через подрядчика становятся все более популярными. А значит, есть смысл заранее подумать о мерах противодействия.Жертвой подобной атаки вполне можно стать и при установке нелицензионного, взломанного программного обеспечения. Злоумышленники часто включают в дистрибутив закладку, которая будет предоставлять им удаленный доступ к компьютеру, и размещают такой дистрибутив в интернете на площадках, где полно такого нелицензионное ПО, или через торренты. Атаки через поставщика — когда сначала взламывают подрядчика, а затем атакуется связанная с ним целевая организация — можно разделить на два типа:· supply chain — через цепочку поставки (в классификации MITRE ATT&CK — ID:1195);· trusted relationship — через доверительные отношения (в классификации MITRE ATT&CK — ID:1199).Эти атаки очень похожи, но имеют различные способы реализации.Атака через цепочку поставки проводится с помощью программно-аппаратных средств. В само программно-аппаратное средство или в часть обновления внедряется имплант, который предоставляет прямой доступ к серверу, или устанавливает связь с центром управления (Command & Control, C2). Такая атака, как правило, не является целенаправленной – ведь нельзя дать гарантию, что а) целевая организация установит нужное обновление и б) что сервер, на который устанавливается обновление, не имеет выхода в интернет и обновляется вручную. Если сервер получает обновление автоматически и правила файрволла ограничивают доступ только к серверу обновлений, то это не дает гарантий безопасности: злоумышленники могут контролировать этот сервер обновлений и перенаправлять трафик от импланта на C2. Атаки через доверительные отношения связанны с компрометацией доверенных каналов (например, VPN). Многие организации пользуются услугами подрядчиков, в том числе и малых организаций, работающих удаленно (и в подавляющем большинстве случаев слабо защищенных). Злоумышленники могут атаковать одного из подрядчиков и получить в его сеть и в дальнейшем может довольно легко проникнуть в целевую инфраструктуру и, оставаясь незамеченным, развивать свою атаку – ведь никто не ждет подвоха со стороны доверенного партнера (по этой причине большой успех может иметь, например, «внутренний» фишинг). При всем при этом внутренняя инфраструктура обычно менее защищена, что тоже играет на руку хакерам. Как можно себя обезопасить?Выявлять такие атаки непросто. Анализ обновлений на наличие «закладок» — задача трудоемкая и дорогостоящая. Можно использовать поведенческий анализ для выявления аномалий. Сегментирование сети (что в общем-то должно быть нормой) также поможет снизить риски негативных последствий таких атак. Что касается тестирования на проникновение, то будет достаточно сложно договориться между тремя сторонами о проведении таких работ. Подобные проекты могут выполнять головное и дочерние предприятия, но что делать с разными компаниями?Частично проблему может решить тестирование методом предполагаемого нарушения (Assumed Breach). В этом случае легенда подразумевает, что подрядчик был скомпрометирован и целью злоумышленников является компания. Другими словами, предполагается, что у злоумышленников уже есть доступ во внутреннюю сеть организации. Такой вид тестирования способен продемонстрировать, что может произойти в случае наступления реальной атаки.Как организовать тестирование методом Assumed Breach Первое, что необходимо сделать для проведения таких работ — это определиться с типом угрозы, которая будет симулироваться. Для атаки через цепочку поставки заказчику нужно запустить подобие «импланта» на сервере, где стоит ПО разработчика, который, по легенде тестирования, был скомпрометирован. Этот «имплант» организует канал связи с С2 исполнителя тестирования на проникновение. Многие компании используют тестовые среды для проверки обновлений, прежде чем установить их на эксплуатационные серверы. Эти же тестовые среды могут использоваться для проведения тестирования методом предполагаемого нарушения, если их сетевая конфигурация совпадает с эксплуатационной.С симуляцией атак через доверенное отношение все проще: заказчику необходимо предоставить доступ через VPN в тот же сегмент сети, в который имеют доступ подрядчики. Возможно, также заказчику будет необходимо предоставить учетные данные с такими же привилегиями, как и у подрядчиков.Второй шаг – определение целей. Например, получение доступа к базе данных или серверу, находящемуся в закрытом сегменте сети.Возможно несколько вариантов проведения тестирования в зависимости от модели потенциального злоумышленника:ИнсайдерМожет находиться в офисеЕсть доступ к инфраструктуреРаботы могут выполняться удаленноЗаказчик предоставляет учетные данные для доступа в сеть компанииОбслуживающий персоналМожет находиться в офисеНе имеет доступа к инфраструктуреРаботы выполняются на территории компании без предоставления доступа в сетьИсполнитель может использовать сетевые розетки и беспроводную сетьПодрядчикНет доступа в офисЕсть удаленный доступ в сеть компанииРаботы выполняются удаленноЗаказчик предоставляет доступ в сеть компанииФишинг Нет доступа в офисДоступ во внутреннюю сеть получен в результате фишинговой атакиРаботы выполняются удаленноЗаказчик открывает фишинговое письмо и выполняет необходимые действияПосле получения первоначального доступа исполнители пытаются проникнуть в общую внутреннюю сеть и проводят внутреннее тестирование на проникновение с целью продемонстрировать, какие уязвимости и недостатки там есть и как предполагаемые злоумышленники могут их использовать для достижения своих целей. Причем такие работы могут проводиться как с противодействием со стороны службы защиты информации (эдакая краткая версия Red Team), так и без – в режиме обычного внутреннего тестирования на проникновение. В целом в условиях, когда аутсорсинговых взаимодействий становится все больше, а контроль защищенности подрядчиков при этом никак не регламентируется законом и на практике вряд ли возможен, Assumed Breach – пожалуй, один из немногих относительно доступных инструментов, дающих компаниям понимание: 1) что будет в случае атаки через поставщика 2) насколько ИБ-специалисты готовы ее отражать 3) где стоит «подстелить соломку». Дмитрий Неверов, руководитель группы анализа защищенности "Ростелеком-Солар" =========== Источник: habr.com =========== Похожие новости:
Блог компании Ростелеком-Солар ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Ноя 21:13
Часовой пояс: UTC + 5