Как хакеры готовят атаки на банки

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

Шаг 1. Определение целей

В офлайновом мире бывает нелегко выяснить, какие сервисы и сети принадлежат конкретной организации. Однако в интернете существует множество специальных инструментов, позволяющих без особого труда определить сети, подконтрольные интересующим нас компаниям, и при этом никак не засветиться перед ними. Для пассивной разведки в рамках сбора статистики по сетевым периметрам финансовых организаций мы использовали:

1. Поисковые системы (Google, Yandex, Shodan).
2. Отраслевые сайты для финансового сектора — banki.ru, rbc.ru.
3. Whois-сервисы 2ip.ru; nic.ru.
4. Поисковые системы по базам данных интернет-регистраторов — Hurricane Electric BGP Toolkit, RIPE.
5. Сервисы визуализации данных по доменному имени сайта — Robtex.
6. Сервис для анализа доменных зон dnsdumpster, который содержит исторические данные по доменным зонам (изменения IP-адреса), чем сильно помогает собирать данные. Похожих сервисов много, один из самых известных аналогов — domaintools.com.

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

1. Поиск проектов на GitHub. Часто бывает, что на GitHub выложен тестовый проект, бэкап или рабочий код, доступ к которому забывают ограничить или неправильно ограничивают. Исследование таких проектов требует высокой квалификации, но дает практически 100%-ный шанс проникнуть в сеть, используя ошибки исследованного приложения или вшитые учетные данные.
   
2. Сервисы онлайн-проверок на уязвимости, такие как HeartBleed, Poodle, DROWN. Эти сервисы с высокой степенью вероятности позволяют обнаружить конкретные уязвимости, если они есть, но на эти проверки уходит очень много времени.
   
3. Bruteforce DNS. Данная техника является активным вмешательством. Она позволяет перебирать DNS-имена систем, определяя доступные. Это происходит через DNS-запросы к целевому DNS-серверу, при этом трафик можно направить, например, через Google DNS, и с точки зрения атакуемой организации эти запросы будут выглядеть легитимно. Для реализации таких техник обычно используется инструментарий KaliLinux или похожей сборки. К сожалению, на практике DNS-логи не смотрят или даже не ведут их, пока что-нибудь не произойдет.

Итак, для начала определяем список организаций, которые мы собрались «поставить на контроль». Для этого можно воспользоваться поисковыми системами, профильными сайтами и другими агрегаторами профильной информации. Например, если мы хотим собрать статистику по финансовым организациям, идем на banki.ru и забираем готовый топ банков и страховых компаний. Сбор списка практически не требует времени. Мы выделили следующие категории организаций:

• банки (с 1-го места по 25-е),
• банки (с 26-го по 50-е),
• банки (с 51-го по 75-е),
• банки (с 76-го по 100-е),
• микрокредитные организации,
• платежные системы,
• страховые компании (с 1-го по 50-е),
• страховые компании (с 51-го по 100-е).

Теперь определяем сети, которыми владеют организации. Находим в поисковой системе сайты организаций, для определения их адресов используем веб-сервис whois. Этот ресурс позволяет узнать по доменному имени сайта IP-адрес, а также другие важные данные для поиска сетей. В этой работе к важным данным относятся:

1. Netname (сетевое имя, очень полезно при поиске по БД Ripe);
2. Descr (описание может быть применено для поиска с использованием фантазии);
3. Address (поиск сетей, зарегистрированных на этот же физический адрес);
4. Contact (возможен поиск в БД Ripe по людям, которые также могли регистрировать сети);
5. другая информация, по которой можно идентифицировать организацию.

Всю эту информацию можно получить и через Unix-команду whois. Что использовать — дело вкуса. Чтобы не компрометировать конкретные банки, мы покажем этот поиск на примере нашей компании:



Используя собранную информацию об организациях, мы осуществили поиск их адресных диапазонов в базе данных регистратора Ripe. Сервис Ripe дает возможность свободного поиска по всем зарегистрированным в нем сетям. Также стоит обращать внимание на поле Country: мы выбирали исключительно российский сетевой сегмент.



Этот этап работ потребовал от нас большого количества ручного труда, ведь какие-то адреса могут быть отданы партнеру, сданы в аренду или не принадлежать искомой организации. Поэтому для повышения точности результатов нам пришлось провести дополнительные проверки, чтобы с максимально возможным уровнем достоверности выделить только необходимые сети или хосты. Для верификации сетей мы использовали общедоступный онлайн-сервис американского оператора связи Hurricane Electriс, который по IP-адресу сайта может выдать информацию о сети, в которой он располагается. На этом этапе работ оказался также очень полезен сервис Robtex. Он показывает все связи для указанного доменного имени, это позволило нам найти сети, которые не удалось обнаружить при поиске в базе Ripe. Кроме того, Robtex позволяет увидеть другие сайты, расположенные по данному IP-адресу, а эта информация тоже может оказаться не лишней. Пример поиска:



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

Шаг 2. Выявление доступных сервисов

Для этого можно использовать один из двух наиболее известных инструментов, призванных сделать интернет безопаснее: Shodan или Censys. Они имеют схожие возможности, поддерживают работу с API, а также могут дополнять друг друга. Для полноценного поиска оба сервиса требуют регистрации. Censys более требователен: чтобы снять в нем ограничения на выдачу результатов поиска, придется написать разработчикам, убедить их в этичности исследования и ответственном использовании полученных данных. Аргументом при этом будет сертификат CEH или подробная информация об исследовании.

Мы использовали сервис Shodan, поскольку он более удобен. Кроме того, Shodan сканирует аналогично сканированию Nmap с флагом «-sV», что является плюсом в нашем исследовании: так привычнее обрабатывать результаты. Наверное, наиболее интересен процесс автоматизации, однако подробно расписывать его нет смысла, потому что все, включая примеры кода на Python, уже описано его создателем Джоном Матерли (John Matherly), также известным как @achillean, в весьма удобной форме. Более того, есть репозиторий на GitHub, где можно познакомиться с официальной библиотекой Shodan для Python.

Подробная информация о запросах к Shodan может быть получена по ссылке. Пример запроса через веб-интерфейс выглядит вот так:



На примере видно, что на адресе 8.8.8.8 доступен UDP-порт 53, сервис DNS, находящийся в США и принадлежащий Google, а также видна версия операционной системы, используемая на этом IP-адресе. Запросами к Shodan можно выявить гораздо более специфичные сервисы, к которым забывают ограничить доступ из интернета, хотя это следовало бы сделать. Поскольку можно получить различные баннеры и версии этих сервисов, то можно и сопоставить полученные данные с различными базами уязвимостей.

Однако получается, что нам нужно прогнать через Shodan каждый обнаруженный IP-адрес, а их у нас получилось, на секундочку, около 100 000 — многовато для ручной проверки… Что там про API?

Мы написали собственный сборщик информации. Запустили — и спустя неделю работы программы получили картину распределения доступных сервисов в финансовом секторе, абсолютно никак не взаимодействуя с ними! Отслеживать таким способом изменения в инфраструктурах вполне реально. Вот что мы нашли:





Из самого «ужасного» на периметрах финансовых организаций найдены:

• СУБД (ради справедливости, отметим, что у некоторых в баннере содержалась запись «is not allowed to connect to this SQL server»);
• службы каталогов (по баннерам можно узнать LDAP);
• сервисы, предоставляющие доступ к ФС (такие как SMB и FTP);
• принтеры (и тут, судя по пейлоаду, нет ошибки!), которые могут иметь самые драматические уязвимости и вообще признаны наименее защищенными устройствами. Да-да, уязвимости старые. Но когда вы в последний раз обновляли свои принтеры на периметре?
• Небезопасные сервисы удаленного управления, такие как Telnet, RDP;
• Сервисы RPC;
• Системы виртуализации;
• Мультимедийные сервисы.

Эти сервисы распределились по организациям следующим образом:





Полученные результаты нас не удивили: чем больше размер организации, тем больше сервисов размещено на сетевом периметре, а с ростом числа сервисов увеличивается вероятность ошибки конфигурации.

Шаг 3. Определение уязвимых сервисов

Полученные результаты нас не удивили: чем больше организация, тем больше сервисов размещено на ее сетевом периметре, а с ростом числа сервисов увеличивается вероятность ошибки конфигурации.

• IP — уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP;
• Port — цифровой номер, являющийся параметром транспортных протоколов (таких как TCP и UDP);
• Protocol — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами;
• Hostname — это символическое имя, присвоенное сетевому устройству, которое может быть использовано для организации доступа к этому устройству различными способами;
• Service — название определенного сервиса;
• Product — название ПО, с помощью которого реализован сервис;
• Product_version — версия определенного ПО;
• Banner — приветственная информация, отдаваемая сервисом при попытке подключения к нему;
• CPE — Common Platform Enumeration, стандартизированный способ именования программных приложений, операционных систем и аппаратных платформ;
• OS — версия операционной системы.

Далеко не для всех открытых портов Shodan может отдать полный набор информации, но если это удается, то данные (в примере выбраны результаты, уже обработанные в нашей системе) выглядят следующим образом:



Из всего признакового пространства были выделены поля, по которым может быть найдена информация об уязвимости данного хоста. Для этого отлично может подойти связка Product + Product_version либо CPE. В нашем случае мы решили воспользоваться связкой Product + Product_version, а поиск осуществлялся по внутренней базе уязвимостей Positive Technologies.

В сети существует немалое количество общедоступных источников для поиска уязвимостей, вот некоторые из них:

• SecurityLab.ru — это не только новости по ИБ и форум, это еще и база данных по уязвимостям! Пример вывода информации:

• БДУ ФСТЭК – база данных угроз информационной безопасности, отличающаяся от других подобных ресурсов возможностью найти уязвимости для ПО и ПАК отечественного производства;
• nvd.nist.gov – национальная база данных уязвимостей Института стандартов и технологий США, которая объединяет общедоступные государственные ресурсы США по поиску и анализу уязвимостей;
• vulners.com — — большая обновляемая база данных ИБ-контента, позволяет искать уязвимости, эксплойты, патчи, результаты bug bounty;
• cvedetails.com – удобный веб-интерфейс для просмотра данных об уязвимостях. Вы можете просматривать список поставщиков, продуктов, версий и CVE связанных с ними уязвимостей;
• securityfocus.com – один из топовых общедоступных источников, особенно в части наполнения данными по эксплойтам.

Все приведенные выше ресурсы позволяют осуществлять быстрый поиск уязвимостей по различным признакам, в том числе и по CPE. Также эти ресурсы в той или иной мере позволяют автоматизировать процесс поиска. В результате можно обнаружить очень много полезной информации: подробные описания уязвимостей, информацию о наличии PоC или зафиксированных фактах эксплуатации, а порой и ссылки на эксплойты:



Набор сервисов и их баннеров у нас уже есть, осталось только прогнать эту информацию через базу уязвимостей. Конечно, вручную этим заниматься совсем не хотелось, да и времени это заняло бы много. Поэтому, написав простенький скрипт, мы довольно быстро обработали все полученные сервисы, сопоставили их с нашей базой уязвимостей (то же самое легко делается и через названные сервисы) и получили следующую статистику распределения уязвимостей по сервисам:





Результаты получились следующие: из общего количества сервисов, найденных Shodan, уязвимости были обнаружены в 5%. Эта цифра мала: для сравнения, по данным наших собственных автоматизированных сканирований периметров, обычно уязвимости встречаются в 20–50% сервисов. Но теоретически процент обнаружения уязвимостей можно увеличить. Посмотрим, как это можно сделать.



К примеру, для ROSSSH (на скриншоте 4-я строка снизу) можно предположить доступность уязвимости ROSSSH Remote Preauth Heap Corruption. Несмотря на то что уязвимость совсем не новая, вероятность встретить ее в этом сервисе значительно выше нуля. Напомним наши предыдущие исследования,, в которых мы говорили, что порядка 30% систем, доступных из интернета, содержат уязвимости старше 5 лет. Похожие цифры в своих исследованиях приводит Cisco, по данным которой средний срок присутствия известных уязвимостей составляет более пяти с половиной лет. Эти результаты сопоставимы с нашими, а небольшое отличие обусловлено разными выборками и методами исследований.

По примеру, приведенному выше, можно предположить наличие в RDP-сервисе уязвимостей CVE-2015-0079, CVE-2015-2373, CVE-2015-2472, CVE-2016-0019. Это неполный список возможных уязвимостей, во всех открытых источниках эти уязвимости привязываются по CPE к версии ОС, игнорируя привязку к RDP. Наиболее ярким примером являются громкие эксплуатабельные уязвимости, к которым мы вернемся чуть позже. По многим другим сервисам тоже можно построить подобные предположения о возможном наличии уязвимостей.

Шаг 4. Поиск эксплойтов

Следующим шагом является поиск эксплойтов для определенных уязвимостей. В описанных выше поисковиках удается найти эксплойты в малом количестве, но никто не мешает использовать для этого специальные утилиты, ведь ящик Пандоры уже открыт. Например, существует свободно распространяемая утилита PTEE. О ней очень подробно написано другой статье. А еще существует Metasploit, который хоть ничего и не собирает, но…

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

• 88 из 559 уязвимостей с высоким уровнем риска по шкале CVSS имеют доступные эксплойты;
• 178 из 733 уязвимостей со средним уровнем риска имеют доступные эксплойты;
• 8 из 309 уязвимостей с низким уровнем риска имеют доступные эксплойты.

Одна из старых догм информационной безопасности гласит: уровень защищенности системы равен уровню защищенности самого слабого звена. Действительно, при планировании атаки, как показывает практика, потенциальный злоумышленник выберет наиболее незащищенную систему. Если внимательно рассмотреть результаты, видно, что вероятность найти такие системы высока для всех категорий организаций:





Имеется простое объяснение полученным результатам: с ростом инфраструктуры следить за ней все сложнее. Больше хостов — больше старого софта и больше уязвимостей, в том числе эксплуатабельных. В крупных компаниях периметр крайне динамичный: даже в пределах одной недели на границе сети может появиться до нескольких десятков новых хостов, столько же может уйти, мы показывали это предыдущих исследованиях. Если эти изменения — лишь результат ошибки, то вероятность того, что на одном из таких узлов будет «открытая дверь», очень велика. Именно по этой причине периодический контроль состояния периметра в режиме, максимально приближенном к реальному времени, очень важен для обеспечения безопасности.

Сколько времени займет поиск уязвимых сервисов, если информация об уязвимости только что появилась на просторах интернета? В нашей системе поиск по заданным уязвимостям занимает менее секунды. Больше времени уходит на анализ полученных результатов, но это тоже довольно быстро: в рамках этого исследования анализ по одной уязвимости занимал не более 15 минут.

Шаг 5. Собственно атака

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

В нашем исследовании, конечно же, не проводились реальные атаки. Но оценить возможности хакеров на последнем этапе мы можем. Рассмотрим для примера последнюю часть известного эксплойт-пака, слитого группой The Shadow Brokers. В этом паке присутствовало множество интересных эксплойтов, к примеру набор для взлома SMB, ставший общеизвестным после вирусной эпидемии WannaCry.. В нашей выборке этот эксплойт подошел для 36 систем (данные об исследуемом периметре были собраны до публикации архива с эксплойтами). На тот момент содержащиеся в паке эксплойты были применимы ко всем версиям Windows. Следовательно, их с большой вероятностью можно было взломать. Именно это и показал WannaCry. И это только вершина айсберга, в паке были и другие интересные эксплойты:

1. Esteemaudit (эксплойт для RDP). Мы считаем размещение сервисов RDP на периметре без ACL (access control list) ошибкой. В нашей выгрузке было определено 44 системы с наличием данного сервиса. По описанию, эксплойт применим только к старым версиям Windows Server 2003. По этой причине мы исключили 10 адресов с баннерами более новых версий Windows — осталось 3 системы, для которых эксплойт мог быть применим, и 31 без подтверждения.
2. Набор эксплойтов для веб-серверов. Для 37 систем было построено предположение о применимости эксплойтов, нацеленных на взлом веб-серверов.
3. Набор эксплойтов для почтовых серверов. На 13 системах были обнаружены почтовые серверы, версии которых подходили для эксплуатации.

В итоге из всех 3764 доступных адресов были определены 111 с потенциально уязвимыми сервисами. И с большой вероятностью их можно было взломать с помощью этого эксплойт-пака.

В начале исследования уровень опасности нам казался ниже полученного, но потом пришел WannaCry и не согласился с нами. Причиной высокого уровня опасности стал недостаточный контроль внешнего периметра в организациях. При этом даже после публикации предупреждений и рекомендаций экспертов не произошло значительного повышения уровня защищенности. Это наглядно показала эпидемия следующего криптолокера Petya/NotPetya, который использовал ту же самую уязвимость (хотя его вектор распространения и не относится к сетевому периметру). Для заражения инфраструктуры достаточно одной уязвимой системы, а для преодоления периметра злоумышленнику достаточно одного уязвимого сервиса.

Выводы и рекомендации по защите

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

1. для подготовки целенаправленной атаки на финансовый сектор не требуется особых финансовых затрат;
2. подготовка может быть незаметной для атакуемых организаций и для тех, кто их защищает;
3. для реализации атаки необязательно обладать эксплойт-паком от АНБ, хотя и его компоненты тоже попадают в открытый доступ.

Безопасность периметра — один из базовых векторов защиты. Но защищать, не зная, что именно защищаешь, — занятие сложное и, откровенно говоря, бессмысленное. Если вы не знаете границы защищаемого вами периметра, вы можете воспользоваться методами анализа сетей, описанными в этой статье. А если внешних подсетей много (к примеру, распределенная по всей стране инфраструктура с множественными выходами в интернет) и периметр сложно инвентаризировать, то можно обратиться за помощью к специалистам. Например, к экспертам Positive Technologies ([e-mail]). От вас потребуется лишь список выделенных сетей от оператора и согласие на сканирование.

Получив представление о том, из чего состоит периметр, займемся его защитой. Достижение максимально безопасных конфигураций информационных систем ― трудная задача, так как именно люди отвечают за программное обеспечение, его настройку и сопровождение, а где-то приходится делать допущения в угоду бизнесу. Информационная безопасность всегда балансирует между функциональностью системы и ее защищенностью. Ошибки конфигурации присутствуют и в сетевых периметрах: как показывает наше исследование, в интернет выставляется много лишних, в том числе уязвимых, сервисов, что облегчает злоумышленнику возможность проникновения в сеть организации. Рекомендуемый план по защите периметра может выглядеть следующим образом:

1. Определить те активы, доступ к которым из интернета обоснован.
2. Сервисы без обоснования доступа вывести с периметра.
3. Документировать и внедрить процедуру размещения новых систем на внешнем периметре.
4. Составить ACL, ограничивать доступ к административным интерфейсам, сервисам удаленного доступа, БД и другим важным сервисам минимально возможным списком лиц.
5. Ввести процедуру установки обновлений и определить метрики успешности ее выполнения.
6. Проводить работы по анализу защищенности, такие как сканирование специализированными инструментами в режиме аудита (из внутренней сети), а также сканирование на уязвимости в режиме пентеста (сканирование с внешней площадки, чтобы понимать, как ваша инфраструктура выглядит для потенциального нарушителя), с регулярностью не реже раза в месяц.
7. Определить список лиц, ответственных за активы (как со стороны бизнеса, так и со стороны IT). Это позволит снизить трудозатраты и время реакции при срочном обновлении систем.
8. Для приоритизации устранения уязвимостей — определить значимость активов.
9. Составить план реакции на случай обнаружения критически опасных уязвимостей в системах, расположенных на периметре. В плане необходимо учесть, как действовать в случае обнаружения критически опасной уязвимости; какие действия должны предпринять администраторы систем и специалисты по информационной безопасности; согласованы ли эти действия с бизнес-владельцами систем.

Конечно же, следует помнить, что для противодействия угрозам необходим комплексный подход к обеспечению ИБ, а начинать стоит со своих «сетевых границ».

Авторы: эксперты Positive Technologies Владимир Лапшин, Максим Федотов, Андрей Куликов