1. Требования Банка России в части проведения тестов на проникновение и как их понимают

Основным нормативным документом для банков и организаций кредитно-финансовой сферы в области информационной безопасности является Положение Банка России №382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств».

1 июля 2018 года вступила в силу новая редакция 382-П (Указание 4793-У). Указание содержит ряд важных уточнений и дополнений в вопросах обеспечения информационной безопасности. В частности, речь идет о вопросах:

1. уведомления об инцидентах информационной безопасности;

2. безопасности прикладного ПО, используемого для перевода денежных средств;

3. разделения контуров у клиент-банка;

4. проведения тестов на проникновение и анализа уязвимостей ИБ объектов информационной инфраструктуры;

5. использования отечественной криптографии.

На вопросе проведения тестов на проникновение хотелось бы остановиться более подробно. Тема достаточно обширная и без определенных требований и детализации может трактоваться по-разному. Если обратиться к самому Указанию 4793-У, то для тестов на проникновение присутствует детализация по периодичности и необходимости привлечения сторонней организации.

Рис. Выдержка из Указания 4793-У

Однако, перечень объектов информационной инфраструктуры, для которых нужно проводить пентест, не указан. Это может послужить источником разночтений данного Указания и выполнением тестов на проникновение формально ответственными лицами некоторых банков.

2. Что такое поверхность атаки и на что она влияет

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

Типовые элементы ИТ-инфраструктуры банков

ИТ-инфраструктуру банков можно условно разделить на две большие группы:

1. информационные системы общего применения;

2. информационные системы для перевода денежных средств и сопутствующих сервисов.

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

Ко второй группе можно отнести решения, которые непосредственно относятся к осуществлению денежных переводов:

1. банковские информационные системы (АБС, системы ДБО для юридических и физических лиц);

2. клиентская часть каналов ДБО (сайт интернет-банка, мобильные приложения под различные платформы);

3. серверная часть каналов ДБО (сервер баз данных и приложений АБС, сервер баз данных и приложений ДБО для юридических и физических лиц, система приема платежей);

4. типовые рабочие места кассира, администратора ИБ, администратора АБС и т.д.

Возвращаясь к вопросу о перечне объектов для тестов на проникновение, нельзя сказать, что надо проводить исследования только для какой-то одной группы или типа. Большинство программных и программно-аппаратных решений тесно взаимосвязаны и доступны для разных категорий нарушителей.

Виды нарушителей и их возможности

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

Внутренний нарушитель действует из пределов корпоративной сети организации. Ему, как правило, доступны интерфейсы банковских информационных систем (АБС, системы ДБО для юридических и физических лиц), серверные части ДБО, типовые рабочие места кассира, администратора ИБ, администратора АБС.

Рис. Типы нарушителей и доступные им ИС

Методика определения поверхности атаки

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

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

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

1. Необходимо определить стек технологий, на которых веб-ресурс функционирует. В первую очередь интересует вопрос - используется ли какая-либо система управления контентом (CMS — Content Management System). Подобные системы представляют собой нечто вроде программного каркаса, который позволяет создать сайт, не прибегая к помощи программистов. Более подробно о CMS и их назначении можно прочитать здесь https://en.wikipedia.org/wiki/Content_management_system. Знание об используемой системе управления позволяет нарушителю проверить доступность панели администрирования (закрытой части сайта, предназначенной для управления его содержимым) и наличие известных проблем безопасности. Для определения CMS можно воспользоваться плагином для браузера Firefox (Wappalyzer) или провести анализ возвращаемых сервером http-заголовков.

2. Определить ip-адрес сайта. Для этого надежнее всего воспользоваться сетевой утилитой nslookup или одним из онлайн-сервисов (например, https://2ip.ru/lookup/).

3. Получив данные об ip-адресе сервера, на котором расположен исследуемый сайт, необходимо установить: расположен ли он на внешнем периметре организации или находится на площадке хостинг-провайдера. Для решения этой задачи подходят онлайн сервисы с данными из Whois (whois.domaintools.com или https://2ip.ru/whois/).

4. Важным моментом при определении поверхности атаки на веб-ресурс является присутствие «сайтов-соседей». Это обычные сайты, которые расположены на том же сервере, что и объект исследования. Если «сайты-соседи» присутствуют и в них есть критические уязвимости, то они несут опасность для всего сервера в целом и в частности для целевого веб-ресурса. Существуют компенсирующие меры, которые применяют, чтобы оградить один сайт от другого, но не во всех случаях они применяются и корректно настраиваются. Для определения «сайтов-соседей» можно воспользоваться сервисов https://2ip.ru/domain-list-by-ip/ или аналогичным.

5. Провести анализ исходного кода главной страницы сайта. Эти сведения могут быть полезны для получения представления об используемых технологиях и наличии дочерних доменов. Анализ можно провести вручную и/или воспользоваться сервисом https://webbez.ru/pagescan.

6. Любой сайт расположен на сервере, который может предоставлять и другие службы (почта, терминальный доступ, база данных и т.д.). Для определения их наличия можно провести его сетевое сканирования. Правда, это уже является нарушением и без разрешения владельца сервера проводиться не может. Для этой цели может использоваться поисковая система Shodan, которая с небольшой периодичностью проводит самостоятельное сканирование всего IPv4-диапазона и предоставляет данные для всех желающих.

7. Если на шаге 3 мы определили, что исследуемый сайт находится на площадке хостинг-провайдера, то для получения объективной картины о поверхности атаки желательно установить факт наличия и границы внешнего периметра организации, сайт которой анализируется. В большинстве случаев почтовые сервера располагают именно на внешнем периметре организации. Для их поиска необходимо воспользоваться утилитой nslookup, установив параметр «set type=MX». В результате будет получена MX-запись почтового сервера. С помощью шагов 2 и 3 определяем границы внешнего периметра.

3. Анализ поверхности атаки для трех произвольных банков

Чтобы показать, как оценка поверхности атаки проводится на практике, были выбраны три произвольных банка. Все представленные материалы обезличены, но без потери сути выполняемого исследования.

Банк №1

Первый банк, для которого определялась поверхность атаки, построен на базе системы управления контентом 1C-Bitrix отечественного производства. Это очень популярная система управления, на базе нее работают многие государственные и коммерческие веб-ресурсы.

Рис. Стек технологий для сайта банка №1

Получив информацию о системе управления контентом, нарушитель может проверить наличие доступа к панели администрирования, которая для 1C-Bitrix расположена по стандартному пути http(s)://веб-ресурс/bitrix/admin/. Для исследуемого банка вход в панель администрирования доступен для любого пользователя из сети Интернет (https://банк-№1/bitrix/admin/index.php#authorize):

Рис. Панель администрирования банка №1

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

Стоит отметить, что веб-сервер, на котором работает веб-ресурс, сконфигурирован таким образом, что все запросы по протоколу http автоматически перенаправляются на https. Это защищает сайт от попыток прослушивания и перехвата сетевого трафика нарушителем.

Веб-ресурс исследуемого банка расположен на территории российского хостинга host4g.ru и имеет ip-адрес 89.253.ХХХ.ХХ4. Сайты-соседи обнаружены не были.

Стоит отметить следующий момент: по всей видимости, конфигурация веб-сервера взята, что называется, «из коробки». Иначе как объяснить количество активных сетевых сервисов на нем (данные получены из поисковой системы Shodan):

Рис. Перечень доступных сервисов на сервере банка №1

Доступны сетевые порты 21, 22, 25, 53, 80, 110, 143, 443, 465, 993, 995, 3306, 8443. Скорей всего администратор сайта банка не уделил достаточно внимания вопросам конфигурирования сервера и не отключил ненужные сервисы, например:

• загрузку файлов на сервер нужно осуществлять по протоколу ssh (22 порт), а ftp сервер выключить (21 порт);

• используется множество почтовых сервисов, хотя MX-сервер расположен в другом месте;

• подключение к базе данных MySQL доступно из сети Интернет (порт 3306).

Также отметим, что многие сервисы раскрывают свои версии:

Рис. Раскрытие версий запущенных сервисов

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

Как мы видим, веб-ресурс банка находится на стороннем хостинге. Важным фактором для нарушителя является наличие внешнего периметра (DMZ) у организации, на котором расположены общедоступные сервисы банка, вроде почтовых серверов, ДБО, VPN-шлюзов и т.д. Классическим способом для обнаружения внешнего периметра является определение MX-записи. Для банка №1 это будет ip-адрес 193.232.ХХХ.Х0. Уточнив у Whois, кому принадлежит данный адрес, убедимся, что это внешний периметр банка (193.232.ХХХ.0 - 193.232.ХХХ.255 Банк OJSC). Нарушитель с большой долей вероятности будет осуществлять попытки проникновения в инфраструктуру банка, через сервисы, расположенные в DMZ.

Банк №2

Как и предыдущий веб-ресурс сайт банка №2 построен на базе системы управления 1C-Bitrix.

Рис. Стек технологий банка №2

Проверяем доступность панели администрирования — она доступна по стандартному пути (http://сайт_банка/bitrix/admin/). Важной отличительной особенностью является работа всего сайта, включая административный раздел, по незащищенному протоколу http.

Рис. Использование небезопасного протокола http на сайте

Это дает нарушителю дополнительные возможности по перехвату сессий пользователей и администраторов для модификации содержимого и/или получению доступа к параметрам аутентификации.

Анализ http-заголовков, которые возвращает веб-сервер, позволил определить точную версию интерпретатора PHP - 5.6.27. Интерпретатор PHP — это технологическая платформа (наверно самая популярная в мире), которая позволяет создавать сайты с динамическим контентом. Если сайт использует 1C-Bitrix, то в обязательном порядке он работает на PHP.

Как мы видим версия 5.6.27 содержит ряд серьезных уязвимостей и может дать возможность нарушителю исполнить сторонний код на веб-сервере или нарушить его работоспособность.

Рис. Уведомление о наличии уязвимостей в PHP

Более детально со списком уязвимостей для этой версии можно ознакомиться по следующим CVE:

Рис. Перечень соответствующих уязвимостей в PHP 5.6.27

IP-адрес сайта банка - 93.95.ХХХ.Х1. Он принадлежит российскому хостинг-провайдеру JSC MediaSoft Ekspert. Вероятно, использование устаревшей и уязвимой версии интерпретатора PHP может быть связано с развертыванием из имевшегося на тот момент шаблона, который впоследствии не обновлялся.

Что касается запущенных служб на веб-сервере, то поисковая система Shodan показывает следующую картину: открыты порты 22, 25, 80, 587, 3306, 9306. Ситуация лучше, чем в предыдущем примере, но все равно оставляет желать лучшего. Порт 3306 скорей всего можно закрыть на внешнем сетевом интерфейсе. Назначение порта 9306 пока не сильно понятно, но у нарушителя точно будет время и желание с ним разобраться.

Рис. Перечень доступных сетевых портов

Что касается порта 22, то по всей видимости используется устаревшая и уязвимая версия OpenSSH — 6.7. Нарушитель, возможно, сможет с помощью нее получить список зарегистрированных пользователей и уже целенаправленно осуществить атаку подбора паролей.

По аналогии с банком №1 была выполнена попытка определения внешнего периметра банка №2 через MX-запись. IP-адрес почтового сервера оказался 194.190.ХХ.Х1, который в базе данных Whois закреплен за сетью 194.190.ХХ.0/24 OJSC "банк №2". Таким образом, поверхность атаки на инфраструктуру банка увеличилась на 254 адреса. Безусловно, не все адреса используются и не все хосты предоставляют сервисы во вне. Но, как правило, 10-15 сервисов будут доступны со стороны сети Интернет. Нарушитель сможет их достаточно легко вычислить при помощи того же сервиса Shodan или обычным сканированием сетевого диапазона.

Стоит отметить, что поверхность атаки для банка №2 увеличивается за счет поддоменов основного сайта и сопутствующих сервисов —— ДБО: https://ib.сайт_банка.ru/, https://retail.сайт_банка.ru/, https://ДБО-банка.ru/. Для них вполне применима используемая для основного сайта методика.

Банк №3

В отличие от двух предыдущих примеров сайт банка №3 построен на системе управления с открытым исходным кодом — Drupal. Эта система входит в так называемую «большую тройку» (CMS Wordpress, Joomla, Drupal). Все эти программные решения написаны на языке PHP и свободно распространяются. По некоторым оценкам на долю этих трех систем суммарно приходится около 30% всех сайтов в сети Интернет.

Рис. Стек технологий для банка №3

Для исследуемого сайта версию CMS Drupal определить не удалось. Администратор веб-ресурса предпринял достаточные усилия, чтобы скрыть даже косвенные признаки, раскрывающие ветку версии. Например, в системе Drupal есть ряд текстовых файлов, которые присутствуют по умолчанию (история изменения продукта, рекомендации по установки и т.д.). В данном случае на сайте их не оказалось.

Рис. Сокрытие служебных данных на сайте

Для CMS Drupal (как и для 1C-Bitrix) характерно наличие панели администрирования по заранее известному пути — http://сайт_на_Drupal/admin/. Администратор и тут постарался — доступ к панели блокировался по ip-адресу источника запроса.

Рис. Ограничение доступа к панели администрирования по ip-адресу

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

IP-адрес сайта был получен с помощью утилиты nslookup - 46.243.ХХХ.Х7. Запись в системе Whois сразу нам показала внешний периметр банка - 46.243.ХХХ.0 - 46.243.ХХХ.255, ХХХ-Bank-NET. Если вы помните, то в предыдущих двух примерах главные сайты располагались отдельно, на выделенных серверах сторонних хостингов.

Сведения из системы Whois

Данные с ресурса whois.domaintools.com показали, что к этому ip-адресу относится 6 доменов, включая сайт нашего банка. К сожалению, список сайтов быстро не удалось получить (использовался сервис на ресурсе 2ip.ru), но есть и аналогичные способы.

Анализ в системе Shodan ip-адреса сайта показал наиболее сложную картину для нарушителя — на сервере открыты только два порта (80 и 443). Причем все запросы по протоколу http автоматически перенаправлялись на защищенный протокол https. В отличии от двух предыдущих примеров поверхность атаки существенно меньше.

Рис. Доступные сервисы на сервере банка №3

MX-запись (почтовый сервер) имеет ip-адрес 46.243.ХХХ.Х3 и расположен на том же внешнем периметре, что и основной сайт. Помимо почтового сервиса на этом сервере было обнаружено веб-приложение для доступа к корпоративной почте (https://46.243.ХХХ.Х3/m/webmail/).

Рис. Панель входа в корпоративную почту

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

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

https://ib.сайт_банка3.ru/ — самописный интернет-банк, 46.243.ХХХ.Х6

https://ibank.сайт_банка3.ru/ — ДБО, 46.243.ХХХ.Х9.

Они также расположены на том же внешнем периметре банка.

4. Заключение и выводы

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

Для повышения уровня защищенности собственной ИТ-инфраструктуры администраторам и специалистам по информационной безопасности рекомендуется:

• проводить периодическую оценку поверхности атаки собственных ресурсов согласно представленной методике. Так вы сможете устранить и минимизировать ряд существенных рисков самостоятельно;

• объективно составить перечень информационных систем, для которых требуется выполнить тестирование на проникновение;

• использовать возможности и опыт сторонних организаций, которые специализируются на проведении пентестов и анализу защищенности;

• при необходимости расширять парк средств защиты для актуальных угроз информационной безопасности.