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

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

Шаг 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 дня. После завершения этого этапа мы получили список вида «организации-сети».

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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, по данным которой средний срок присутствия известных уязвимостей составляет 5,64 года. Эти результаты сопоставимы с нашими, а небольшая разница в цифрах обусловлена разными выборками и методами исследований.

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

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

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

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

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

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

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

Сколько времени займет поиск уязвимых сервисов, если информация об уязвимости только что появилась на просторах интернета? В нашей системе поиск по заданным уязвимостям занимает менее секунды. Больше времени уходит на анализ полученных результатов, но это тоже довольно быстро: в рамках этого исследования, проведение анализа по одной уязвимости занимало не более 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 (abc@ptsecurity.com). От вас потребуется лишь список выделенных сетей от оператора и согласие на сканирование.

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

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

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

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

Автор: ptsecurity

Источник