Какой тип кибератак недооценивается компаниями, хотя может привести к серьёзным последствиям
На митапах, конференциях и прочих форумах моё внимание всегда привлекают доклады о современных тенденциях и векторах атак. Обычно самые часто используемые техники атак являются самыми эффективными и простыми. И являются индикаторами недостаточной проработки этих направлений со стороны службы ИБ организаций.
Такая разная статистика
Недавно мне попалась глаза очень интересная тепловая карта MITRE ATT&CK от одной уважаемой компании в мире информационной безопасности. Согласно этой карте, самыми часто используемые и успешными техниками, при первоначальном доступе, являются фишинг и эксплуатация уязвимостей в сервисах (в последнее время в этих уязвимостях недостатка нет). Выглядит логично, эти методы работы легко автоматизируются и могут покрывать большие площади атаки. Соответственно от злоумышленников требуется минимум затрат ресурсов при хорошем результате.
Что меня удивило – так это отсутствие в списке атаки через «доверительные отношение» (Trusted Relationship). Атаки через доверительные отношение — это кибератаки, в ходе которых злоумышленники сначала получают доступ к сети поставщика услуг, а затем, если удаётся скомпрометировать действующие учётные данные для подключения к сети атакуемой компании, проникают в её инфраструктуру. Я всегда считал, что данный тип атак может быть очень эффективным и недостаточно проконтролирован службой ИБ.
Мне стало интересно, с чем это связано. Техника не пользуется популярностью у злоумышленников из-за необходимости более внимательного подхода к подготовке и изучению жертвы? Плохо автоматизируется и требует много ресурсов? Применима только к крупным компаниям, использующие услуги аутсорсинга? Я решил изучить доклады других компаний, занимающихся расследованием компьютерных инцидентов. Открываю отчет другого вендора – те же самые значения: фишинг и эксплуатация уязвимостей в сервисах стоят на первом месте, атаки через «доверительные отношения» отсутствуют. Смотрю отчёт третьего участника моего мини-расследования – а вот тут уже интереснее, атаки через доверительные отношение вошли в топ-4 векторов атак.
Непонятно, с чем связана такая разница в статистике. Возможно, некоторые компании имеют свои правила классификации атак, по которому атаки через доверительные отношение никак не попадают в статистику. Или же данный вид атак плохо детектируется продуктами именно этих вендоров и поэтому не попадает в перечень. В моём списке этот способ находится на особом месте после случая, который произошел несколько лет назад.
Когда бизнес начинает нуждаться в ИБ
Итак, действующие лица:
· А – организация, разместившая тендер на разработку прикладного решения для информационной системы. Контракт на пару лет, суммы контракта соответствуют заданию. С потенциалом дальнейшего сопровождения программного обеспечения.
· B – фирма, выигравшая тендер. Контракт хороший, но под него надо выделить немало ресурсов, чтобы успеть в сроки по этапам.
· С – фирма субподрядчик, привлеченная на определённом этапе выполнения контракта.
Как выглядела ситуация на момент моего появления в этой истории: организация А разместила контракт на разработку прикладного ПО. Фирма B выиграла контракт и начала поиск недостающих специалистов под этот контракт. Для соблюдения сроков контракта в какой-то момент была привлечена фирма С, которой поручили выполнение части задач. Контракт помимо требований к разрабатываемому ПО содержал в себе и требования по информационной безопасности. В организации А безопасность обеспечивалась в соответствии с требованием законодательства для соответствующего класса информационной системы. Фирма B тоже выполняла все взятые на себя обязательства по информационной безопасности.
И вот когда уже было пройдено 2/3 пути, мне поступило предложение от коллег из фирмы B – «Можешь посмотреть систему? Нужен взгляд со стороны, для спокойствия. Проверки кода делаем, средства защиты настроены (IPS, МЭ, АВЗ, СЗИ НСД, WAF, SIEM и т. п). Нужен осмотр методом «чёрного ящика». Что может быть лучшим времяпрепровождением для безопасника, чем проверка свежеразработанного приложения в условиях ограниченного времени? Ну разве можно от такого отказаться? Однозначно нет.
После подписания условий конфиденциальности и определения границ моего возможного вмешательства мне выдали явки и пароли… Нет, не так, рано ещё. Мне выдали IP-адреса тестового контура с промышленной и тестовой средой.
Найти и заэксплуатировать
Я начал подозревать неладное, когда попробовал подключиться к промышленному контуру и выяснил, что даже для доступа к форме ввода логина и пароля мне необходим сертификат. Но унывать было рано, есть же тестовый контур!
В тестовом контуре меня приветливо встречала форма ввода логина и пароля и... всё. Это всё, что было доступно на предлагаемых для исследования ресурсах. Т. е. для атаки было 2 поля для ввода – и на том спасибо.
Далее я исследовал, какие данные могут принимать эти поля. Первые два дня исследования не дали ровным счетом ничего. Единственное, за что уцепился взгляд – на определённой комбинации символов удавалось получить в ответе от сервера ошибку, и там были строки, указывающие на использование каких-то сторонних модулей, не относящихся к известным мне библиотекам. К этому времени я был готов признать, что система неприступна, а моих сил не хватит для взлома этой системы.
Единственный шанс заключался в том, чтобы узнать, что за библиотеки там используются. Оказалось, что эти библиотеки отсылают к названию одной небольшой фирмы. Это была фирма С. Поскольку основная система для меня оказалась недоступна, я решил посмотреть информацию про фирму С. Нашёл её домены и поддомены, прошёлся по ресурсам. Типичные сервисы для небольшой фирмы по разработке софта – системы управления проектами, система управления версиями исходного кода, и т. д. А среди всего прочего — phabricator. Оказалось, что он был некорректно настроен. На определённых страницах я смог найти учётные данные для входа в сервисы, которые относились к исследуемому мной проекту!
Ура, след найден. Оставалось пойти по следу и понять, как близко я смогу подобраться к цели. Но возникла этическая дилемма: в нашем соглашении не было исследования фирмы С, и этот вектор не должен был мной рассматриваться (и вообще знать о нём я не должен).
Если прямые атаки неэффективны, можно поискать обходные пути
На следующий день я связался с коллегами из фирмы B, и заинтриговав их тем, что нашел лазейку, договорился о расширении зоны атаки. Конечно не раскрывая им подробности, иначе они могли бы закрыть лазейку, испортив мне «охоту». Не сомневаюсь, что после общения со мной они провели много времени, изучая логи, накопившихся за последние 2 дня :).
Итак, я вернулся к фирме С, и использовал полученную ранее информацию. У меня не было задачи развивать атаку или закрепиться в системе. Я не прибегал к помощи специальных программ, и оставался незамеченным системами защиты. Обычная работа обычного специалиста субподрядчика. Не буду расписывать весь путь, по результатам я смог получить доступ к исходному коду приложения, к инструкциям по его сборке, к регламенту размещения обновлений, а также к месту, куда выкладывалось приложение перед размещением его на тестовой среде.
Все эти сервисы использовались совместно фирмами B и C для «эффективного взаимодействия». Поскольку целью моей атаки было именно приложение – я не стал затягивать исследования, скачал и немного поправил исходник. Скомпилировал приложение, и стал ждать, когда очередное обновление будет выложено в файловое хранилище, для разворачивания на тестовом сервере. Ждать пришлось недолго, и после легитимного выкладывания я заменил его на свое. А дальше всё произошло по описанным регламентам, и в установленное время собранное мной приложение было развёрнуто и запущено на тестовом сервере. Теперь мне оставалось сообщить коллегам о моей небольшой закладке в приложении, чтобы ее успели проверить, пока не затёрли следующим обновлением.
После рассказа о том, как я смог взломать их приложение, услышал неуверенные оправдания вроде «Ты же должен был ломать нас и наше приложение, а наши субподрядчики тут вообще не при делах. У них отдельная система. Ну ладно, мы поняли, спасибо за работу». Впрочем, найденную мной лазейку закрыли очень быстро.
И тут может возникнуть вопрос – а причём тут атаки через доверительные отношения, если проникновение было через ошибку в настройку сервиса и утёкшие учетные записи? А вот тут мы возвращаемся к вопросу классификации. Моей целью была система фирмы B, у которой были доверительные отношения с фирмой С. Следовательно, как способ проникновения я рассматриваю именно доверительные отношения между B и С.
Как видно, для защиты системы фирмы B были приняты необходимые меры, и в лоб пробиться для меня было невозможно. А вот через субподрядчиков удалось обойти выставленные эшелоны защиты. И даже, возможно, удалось бы через эту цепочку проникнуть и в компанию А. Чаще всего жертвами атаки через доверительные отношение являются небольшие фирмы, начинающие свое становление. Траты на безопасность выглядят нецелесообразными, денег хватает на только на самое необходимое плюс удержание команды. Сами по себе такие фирмы малоинтересны злоумышленникам, и живут по принципу неуловимого Джо.
Доверительные отношения — доверяй, но перепроверяй
Чем же так опасны атаки через доверительные отношения:
1) при условии, что у компании С было бы несколько проектов, над которыми они работают по субподряду – можно было бы осуществить через них атаку на несколько их клиентов.
2) Если злоумышленник будет действовать аккуратно, его присутствие будет очень сложно обнаружить.
После этого случая я стал уделять особое внимание при приобщении субподрядчиков к работам.
Как защититься от этой атаки? Первым делом изучите договор с субподрядчиком. В нём необходимо прописать требования по безопасности. Сформулировать требования к субподрядчику как для своих систем, предусмотреть отчёт о защите информации от субподрядчика. И если получится – возможность проверять выполнения требований по безопасности вашими силами у субподрядчика.
С технической точки зрения нет специальных мер защиты, направленных именно на противодействие атаки через доверительные отношения. Рекомендации стандартные и их хватает в сети. Просто применяйте все меры безопасности, которые действуют у вас в организации, и на ваших субподрядчиков. Это поможет существенно снизить вероятность атаки и уменьшить зону воздействия атакующих.
Опубликовано 08.11.2024
