В конце мая 2024 года курьерская компания СДЭК приостановила работу: её серверы были взломаны, а данные, включая бэкапы, зашифрованы злоумышленниками. Мы решили пообщаться с компанией Start X (бывшая «Антифишинг»), которая занимается кибербезопасностью. Наши собеседники — Сергей Волдохин, директор компании, и Артемий Богданов, Chief Hacking Officer, он занимается исследованиями в области безопасности.
Полная версия интервью:
На момент публикации статьи работа СДЭК восстановлена, и мы очень рады, что им удалось справиться с проблемой.
Что могло произойти в СДЭК в теории
Сергей: У нас нет доступа ни к инфраструктуре СДЭК, ни к материалам расследований. Мы желаем ребятам как можно скорее всё восстановить — и ИТ-команде, и команде безопасности. Наверняка коллеги опишут по результатам расследования, что было. Мы можем только судить по нашему практическому опыту, что может происходить в компаниях такого размера. Есть несколько направлений, по которым чаще всего происходят такие инциденты.
Одно из них — так называемый фишинг, когда сотрудникам компании присылают какие-то вирусы. Например, сотрудник открывает их как файлы во вложении или как ссылки на такие файлы, которые где-то размещены. И эти файлы-шифровальщики заражают систему. Если у сотрудника есть права администратора, то вредоносный код уже идёт по сети с этими правами. Он шифрует не только отдельный компьютер, но и серверы, и всё, до чего может дотянуться с правами пользователя.
Здесь важно понимать разницу между тем, что люди знают, и тем, что они делают. Ты можешь выучить правила дорожного движения и знать их во всех деталях, но когда ты в первый раз садишься за руль, то вряд ли ты способен доехать хоть куда-то. То же самое с навыками в подобных ситуациях. Люди могут знать правила безопасности, но то, как они поступят, зависит не от их знаний, а от их навыков и культуры, которая сформирована в компании.
Артемий: Похоже, что случай со СДЭК более сложный, чем публично рассылаемый вирус. В Твиттере были скриншоты интерфейса гипервизора — это ПО, которое используется для запуска виртуальных машин. Часть этих машин, видимо, отвечала за бэкапы, и там они формировались и хранились. Это означает, что злоумышленник явно знал, какие в компании виртуальные машины и где они крутятся, и занимался шифровкой именно их. Если бы это был файл-шифровальщик, всё не привело бы к таким серьёзным последствиям. То есть это явно не автоматизированная атака. Кто-то готовился, проводил разведку внутри и следовал своей цели — навредить так, чтобы было сложно восстановиться.
Сергей: Если шифровальщик отправляется рандомно и массово, то обычно он запускается сразу, как только человек его открыл, и это приводит к последствиям на локальной системе и, может быть, на соседних. Но то, о чём говорит Артемий, похоже на то, что кто-то действовал более прицельно: имея уже заражённую машину, может быть, какой-то сервер, он не запустил этот шифровальщик сразу, а воспользовался своим доступом к системе и посмотрел, что происходит вокруг.
Если хакеры оказались там, где есть доступ к этой системе виртуализации, то, скорее всего, у них было время посмотреть вокруг, на серверы, на то, что происходит в компании, на какой инфраструктуре они оказались и так далее.
Получается, что у этой атаки было несколько векторов: нужно было получить доступ к внутренней сети, потом пробросить этот доступ наружу, чтобы они могли со своих серверов что-то с ним делать. Параллельно уже загружен шифровальщик, который можно запустить в нужный момент, и ещё нужно найти сервер, да, где всё дело крутится. Как проводятся атаки подобного рода и что хакеру для этого нужно выяснить?
Сергей: Одна из очень больших проблем крупных компаний в том, что когда у тебя много организаций и подрядчиков и всё это объединено в большую ИТ-инфраструктуру, то некоторые удалённые части такой системы могут остаться менее защищёнными. В итоге через такие хосты, серверы или сервисы можно пройти с административными правами до центра всей инфраструктуры.
Связанная сеть и, скорее всего, единое управление означают, что те учётные записи, с которыми есть доступ на отдалённые от центра компьютеры, могут использоваться и для доступа к основным сетям. И возможно, если что-то подобное было скомпрометировано, то с этими доступами вся инфраструктура тоже могла быть скомпрометирована.
Социальный инжиниринг
Артемий: Помимо IT-систем, внешний периметр, который защищает компанию снаружи, — это также и люди. Информация о людях, которая доступны в интернете, является также вектором атаки на компанию.
Ты сейчас говоришь про социальный инжиниринг?
Артемий: Да, это тоже один из векторов. Есть единая поверхность атаки, она состоит и из людей, и из сервисов, которые доступны снаружи. В случае если это быстрорастущая организация, то и внешний периметр может очень быстро и сильно меняться и в плане IT-систем, и в плане людей.
Какие-то люди могут появляться, в том числе с какими-то довольно высокими привилегиями, но их могут ещё не успеть обучить, например, правилам безопасной работы. В то же самое время для их корректной работы внутри компании им уже выдали все доступы. Таким образом, могут появляться администраторы систем, которые ещё недостаточно обучены и могут по случайности совершить какую-то глупость.
Сергей: Это очень похоже на то, как в Средние века понимали безопасность. Если мы говорим про крепость, то там есть стена и ров с водой — тот самый периметр, который мы защищаем. Но в реальной жизни происходит то, о чём сейчас сказал Артемий. Есть термин «поверхность атаки» — это не только те серверы и сервисы, которые стоят у тебя в инфраструктуре и про которые ты знаешь, но это и люди, которые работают сейчас где угодно, это и данные, которые публикуются в разных местах, это и тестовые среды, которые могут находиться в облачных сервисах. Всё это связано между собой и имеет ценность для хакера с точки зрения доступов к основным активам.
Социальная инженерия вообще сейчас используется при взломах в кибербезопасности? Этому уделяется сейчас сильное внимание или это уже ушло и времена Кевина Митника давно прошли?
Артемий: На самом деле ответ очень прост. Атакующему можно очень много времени потратить на поиск уязвимостей в системах, которые доступны снаружи, а можно просто написать одно письмо, которое позволит тут же пробраться во внутренний периметр компании.
Про шифрование и незаметность атаки
Вы наверняка видели скриншоты, которые выложила хакерская группировка в Твиттере, что там изображено и так далее. Как долго длится такая атака? Сколько времени нужно для того, чтобы запустить какой-то необратимый процесс? Там же многогигабайтные файлы шифровались, почему не сработали системы безопасности?
Сергей: В современном мире кажется, что цифровая атака происходит как в фильме «Хакеры». В тот момент, когда какой-то злой хакер нажимает на кнопочки, быстро печатает, запускается вирус — и всё пропало. Но отчёты разных компаний о расследованиях таких атак говорят о том, что продвинутые хакеры могут находиться в инфраструктуре компаний годы, и рекорд был около 10 лет — хакеры были внутри, и никто их не видел.
Есть такое мнение, что лучшие вредоносные программы — это те, которые не обнаруживаются антивирусом. Если антивирус обнаружит вредоносную программу, значит, её плохо сделали. И те инструменты, которые используют продвинутые атакующие, они, как правило, легитимные: обычные мирные инструменты для удалённого доступа и всех прочих операций.
Получается, что вредоносный код и шифровальщик — это уже последняя стадия, когда ничего уже с компанией делать не нужно, всё уже изучено и всё из неё извлечено. И тогда можно запустить шифровальщик, чтобы это стало заметно, что система взломана.
Тогда если бы они не запустили шифровальщик, то никто мог бы и не узнать, что был взлом?
Сергей: Да, это чаще всего так.
Но почему не сработали системы мониторинга безопасности, когда начался процесс шифрования всего?
Сергей: Системы есть, их очень много, но проблема как раз в том, что мы сильно рассчитываем на системы и на технологии. Мы думаем о системах, мы думаем о технологиях, мы думаем, какую бы очередную систему поставить, чтобы она мониторила другие системы, которые у нас уже стоят и так далее. Правда в том, что чуть больше внимания нужно уделять процессам и людям. Проще всего это показать на примере с забытыми сервисами.
Пример атаки через забытые сервисы
Артемий: Забытые сервисы — одна из самых частых проблем, которые мы видим на внешнем периметре. Например, в рамках маркетинга понадобилось развернуть какой-то небольшой ресурс. Его развернули, маркетинговая акция прошла, но ресурс никто не убил и не утилизировал. Это может быть сайт или простая страница на Тильде. При этом остался домен, который ссылается на этот сайт, но на Тильде уже закончились деньги, сайт удалён — и любой человек может зарегистрировать уже свой сайт по тому же самому домену. Так на одном из поддоменов компании появляется уже другой контент, например фишинговый ресурс.
Сергей: Это как раз забытый сервис, потому что в DNS он всё ещё прописан, но он не оплачен на хостинге, и на этом хостинге можно разместить что угодно, потому что DNS туда уже направляет трафик.
Артемий: Мы сейчас самые простые примеры смотрели, когда сайт вообще вышел из строя, потому что хостинг закончился. Но это может быть любой другой сервис, например тестовый Jenkins. У этих сервисов часто находятся какие-то уязвимости, которые становятся публично известными, и к ним выпускаются обновления. Но если этот сервис кто-то когда-то использовал, а потом о нём забыли, его явно уже никто давно не обновляет.
Это может быть лёгкой целью хакера в данном случае. То есть хакер, конечно же, может попытаться пойти в лоб и попытаться взломать самые защищённые системы, но в большинстве случаев он всё проанализирует и пойдёт самым простым путём.
Про бэкапы
Сергей: Если мы говорим про бэкапы, то можно задать вопрос, а какие процессы, связанные с бэкапами, хорошо бы организовать? Делаем ли мы бэкапы только данных или образов всех систем, которые работают, чтобы их можно было быстро развернуть?
Есть ли в компании процесс, когда мы, понимая все наши системы и сервисы, знаем список нужных файлов, и вовремя ли они попадают в систему, которая делает эти бэкапы? Это процесс, это не технология. Система может работать, и с ней всё хорошо, но если в неё не включены важные активы, то от бэкапа не будет толку в момент инцидента.
Если мы говорим про нормальный процесс, то там, где я в своё время отвечал за безопасность, процесс был такой, что бэкапы какое-то время могли храниться на отдельных сервисах. Потом нужно было регулярно эти бэкапы записывать на ленты и отвозить их в хранилище, которое должно было находиться минимум в 50 километрах от дата-центра или офиса. Большинству людей, которые занимались этим процессом несколько лет вместе со мной, казалось, что это просто какая-то тупость. Мы записываем ленты, снимаем банковские ячейки и отвозим эти ленты, условно, из центра Москвы в Домодедово.
Но в момент, когда нужно было эти данные восстановить, это бы очень сильно помогло. И если мы говорим про процессы, мало эти бэкапы делать — важно уметь их быстро восстанавливать. У одной компании случилась проблема с данными, у них были бэкапы, но время восстановления данных из бэкапов оказалось просто огромным. Им проще было собрать всё заново с нуля, и это вышло бы быстрее, чем восстанавливать данные из бэкапов.
Ещё один нужный процесс — это учения, в ходе которых IT-команда, которая делает бэкап, пробует их восстановить. У них по сценарию происходит виртуальный инцидент, и, допустим, дата-центра, где хранились данные или бэкапы, больше нет.
Не очень давно были пожары в дата-центрах в Москве. Но что делать, если этого дата-центра больше нет? Можем ли мы восстановить систему? Есть ли у нас какой-то ЦОД, в котором данные восстанавливаются сами? Или у нас есть лента с этими бэкапами? И способны ли мы забрать её, восстановить эти системы и восстановить данные за приемлемое время? И это тоже не вопрос не к ленточным накопителям, не к системам бэкапа — это вопрос к процессам и к людям. Могут ли они это сделать?
Безопасность на рабочем месте и безопасный код
Как компаниям и самим сотрудникам можно защитить своё рабочее место, чтобы через них хакеры не проникли в систему или не взломали конкретно их?
Сергей: Смотри, здесь снова нужно поговорить не про технологии, а про процессы. Сотрудник должен понимать, что такое может случиться. Если ему приходит голосовое сообщение от имени начальника с его голосом, но с просьбой сделать что-то даже минимально выходящее за рамки обычного, у него должно быть понимание, что это может быть инцидент. И у сотрудника должен быть чёткий алгоритм, по которому он будет действовать.
Если ему приходит такое письмо, он отправляет его в команду безопасности. Техническая защищённость у нас в России на высоте, без шуток, у нас лучшие безопасники в мире. Я работал в глобальной компании, я могу честно об этом сказать, но с точки зрения людей, ясности и понимания, что делать в разных ситуациях, — вот это нужно немного докрутить.
Но как найти баланс между удобством работы сотрудника и безопасностью? Часто бывает такое, что на рабочий компьютер, который тебе выделили, ты ничего не поставишь, потому что у тебя нет администраторского доступа, даже обои поменять нельзя.
Сергей: Часто бывает именно так, как ты говоришь, но это миф, что безопасность и удобство противоположны, противоречат друг другу. Хорошая команда безопасности думает о том, как можно работать и выполнять все бизнес-функции и при этом делать это безопасно и удобно. Они умеют думать о том, как человек работает.
Но если мы говорим о более конкретном примере, то часто безопасность занимается тем, что контролирует наличие каких-то уязвимостей, встраивает security-гейты, quality-гейты и понимает свою работу как проверку. По сути, они проверяют, безопасный ли получился продукт на разных этапах: на этапе сборки, доставки и так далее.
Артемий: Начну с того, откуда берутся уязвимости. Причин может быть несколько, но практически все они сводятся к одному и тому же: разработчик просто не знал, что так можно обращаться с его продуктом. Например, многие все уязвимости связаны с инъекциями. Это SQL-инъекции, XSS-инъекции, common-client-инъекции. Это происходит на стыке технологий, например кода программы и базы данных, которая получает запросы. Программа должна обратиться в базу данных, они общаются на своём языке, например SQL, и в рамках этого запроса туда также подставляется пользовательский ввод (имя, адрес, номер заказа и тому подобное).
И если эта подстановка произошла небезопасным образом, то злоумышленник может повлиять на этот запрос. Например, дополнить его каким-то зловредным кодом, и вместо списка постов такой код вернёт список паролей администраторов на веб-странице сайта.
Сергей: Или если это XSS, то JavaScript-код, например, может выполниться в браузере у пользователя и дать злоумышленнику какую-то информацию, например куки, с помощью которых злоумышленник сможет зайти на сервис, маскируясь под этого пользователя.
Артемий: Да, всё так. Но почему разработчики делают такой код, чтобы это было возможно? Конечно же, они всё это делают не специально, они просто не знают о том, что такое возможно. Они никогда не видели, как именно это может произойти.
Разработчики могут знать, что XSS есть, и у них есть базовые понятия о том, как здесь защищаться, например использовать шаблонизатор, который сам обезопасит все данные. Многие разработчики считают, что если они используют шаблонизатор, то всё будет работать безопасно, но это не так.
Злоумышленник может использовать псевдопротокол JavaScript, вставить туда свою инъекцию XSS и произвести атаку. Либо пользовательские данные могут попадать в сложные контексты, например, в HTML-код, где у одного из тегов есть обработчик событий onclick. Для работы с ним используется JavaScript-код, внутри которого подставляются нужные пользовательские данные. Шаблонизатор не определит такой сложный контекст и не выберет нужную стратегию защиты. В итоге у нас есть одна стратегия защиты, когда мы выводим данные на страницу, другая стратегия защиты, когда мы выводим данные в контекст значения параметра тега, и третья стратегия защиты, когда мы выводим данные в контекст JavaScript. Таких контекстов довольно много, и очень важно в них разбираться.
Начинающим разработчикам
Что вообще нужно знать разработчику, чтобы научиться писать безопасный код?
Сергей: Когда мы говорим о том, что нужно знать разработчику, чтобы написать безопасный код, можно спросить: а что вообще нужно знать, чтобы быть хорошим разработчиком? Чаще всего на этот вопрос отвечают карты компетенции и планы развития. Значит, нужно взять и сделать карту компетенции в контексте безопасной разработки.
В зависимости от того, кто перед нами — джун, мидл или синьор, в каких технологиях и что конкретно он делает, будут разные конкретные знания, конкретные навыки.
Дайте совет начинающим разработчикам, которые только приходят в профессию, с чего начать и как развиваться?
Артемий: Я бы посоветовал больше изучать технологии, потому что, чтобы быть специалистом, хорошо бы изучить не только базовые концепции, но технологии, с которыми работаешь.
Сергей: Чем отличается метод GET от метода POST и почему на самом деле изменять состояние на сервере через GET-метод — это плохая идея? Кто из разработчиков, вошедших в IT, это может объяснить? Если вы понимаете, если вы можете это объяснить, то, скорее всего, вы поймёте, какие есть уязвимости и как могут работать атаки.
А как стать ИТ-безопасником?
Артемий: Тут возможны варианты, потому что безопасников бывает несколько видов. Есть люди, которые занимаются практической безопасностью. Это вот больше про меня, когда знаешь про код, про уязвимости, про то, как их эксплуатировать или обойти текущие системы защиты. А бывает безопасность более бумажная — ей занимаются люди, которые знают, как налаживать безопасные процессы в компании. И часто именно такие процессы помогут в действительности нормально защититься от хакеров.
Безопасность личных устройств
На телефон нужно ставить антивирус?
Сергей: У меня нет на телефоне антивируса :-)
Артемий: Ну на айфон тяжеловато антивирус сделать, просто потому, что там закрытая файловая система и не получится проверить соседние приложения.
А на Андроид, получается, будет полезно поставить?
Артемий: А на Андроид полезно, да. Некоторые банки уже встраивают в свои приложения функционал антивирусов и стараются обеспечить защищённость пользователей сами.
Сергей: Если у вас Андроид и если вдруг он не обновляется, потому что его производитель решил, что у него своя ветка и всё там он делает сам, то, наверное, такой телефон стоит поменять на другой, который обновляется почаще.
Когда компьютер предлагает обновиться — обновляться сразу или лучше подождать, пока из обновления уберут все новые ошибки?
Сергей: Если ты обычный пользователь, обновляйся как можно чаще. Если ты отвечаешь за безопасность и доступность крупной компании с тысячами хостов, то твоё обновление проходит через процесс change management. Ты обязательно должен проверить, как работает это обновление или как работают системы с этим обновлением на тестовой группе, затем ты должен раскатывать это на все остальные машины. Хорошие айтишники знают эти процессы и применяют обновления, но делают это немного более аккуратно, чем обычные пользователи.
Если коротко — обновляйтесь сразу, как только устройство вам это предложит. Но мы ещё несколько лет назад в одном издании писали статью на тему обновлений, под видом которых мошенники могут прислать вирус. Поэтому лучше бы знать, чем фейковое обновление отличается от настоящего и как выглядит и то и другое.
Артемий: Если мы говорим про обычного пользователя, лучше обновиться. Многие производители предлагают обновляться на бета-версии продуктов, но если ты переживаешь за какие-то ошибки, лучше не включать такую опцию и переходить сразу на релизные обновления.
