Платежные страницы банков и их анализ

Введение

В одной из почтовых рассылок мне случайно попался на глаза список IP адресов “всех платежных страниц банков мира”. По своей профессии я тесно связан с платежными системами и эта информация зацепила мое внимание на некоторое время.

По факту в рассылке оказались адреса опубликованные компанией FONDY (https://fondy.eu/), которые свободно доступны тут:
https://github.com/cloudipsp/all_banks_ips

Я давно искал нечто подобное и был очень рад находке, за что отдельная благодарность ребятам из Fondy. Они об этой статье не знают, это не реклама.

Бегло пробежавшись по адресам я решил посмотреть, чем банки “заряжают” свои системы, дабы прокачать дзен и применить лучшее в собственных продуктах.
Моей первой целью был поверхностный сбор и анализ публично доступных данных за URL адресом банка, которые я взял из вышеуказанной ссылки из GIT. Я не пытался добиться каких-либо конкретных целей, основной интерес был в том, чтобы сгруппировать собранную статистику.

Для рабочего стенда я не задумываясь взял последнюю версию Kali Linux, который стал на Virtual Box.
В оригинальном файле со списком адресов, на тот момент, находилось более 8000 строк, каждая из которых несла адрес, порт, страну, IP
www.deforestbank.com 443 us [‘23.96.208.210’]
Суммарно, по признаку страны “us”, по логике это США, составляет 54% процента от всех ресурсов.
https://app.powerbi.com/view?r=eyJrIjoiMDI1NjA5MzEtMGQxMC00NzFiLWI0MTktZjNiMjNlMWFhZDc1IiwidCI6Ijc4ZjRlY2I5LTUxZTUtNDllZi05YzNhLWFkNDk1MGY3YzZkZCIsImMiOjh9

Даже поверхностный осмотр привел к ситуации, когда некоторые ссылки не открывались. Чтобы не проверять все руками и не тратить время на исследование заведомо “мертвых” ресурсов я воспользовался сервисом URLITOR (http://www.urlitor.com/), который в пакетном режиме попытался открыть каждую из ссылок.

В результате “прогона” из первоначальной выборки 1138 ресурсов выдали “Connection time out”, еще 624 выдали “Site not available”. Я решил исключить их из рабочего списка и оставить эти ресурсы “на потом”, возможно сканер не в состоянии был “переварить” множественные переадресации. В дальнейшую обработку пошли те адреса, которые нормально открывались и отвечали.

Итого из 8648 адресов осталось 6885.

SSL провайдеры

Первое что мне стало интересным, это выяснить какие SSL сертификаты используются на банковских ресурсах.

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

Для этого исследования я решил сильно не заморачиваться и сделать проверку одним из популярнейших инструментов на эту тему – SSLSCAN (https://github.com/rbsec/sslscan) который идет в пакете с Kali Linux.
Я взял файл, который получил после обработки URLITOR, направил его на вход сканера и стал ждать. К сожалению, при обработке некоторых адресов сканер завершал работу в аварийном режиме и приходилось вручную исключать те сайты, которые вызывали такие ошибки.
После получения результатов работы в виде XML файла, я сконвертировал его в CSV файл и после этого смог воспользоваться магией Microsoft PowerBI.

https://app.powerbi.com/view?r=eyJrIjoiM2Q4YTJkNjAtNTUwYy00NWY2LWI3ZDMtOGI4OGFkZWFjMjAzIiwidCI6Ijc4ZjRlY2I5LTUxZTUtNDllZi05YzNhLWFkNDk1MGY3YzZkZCIsImMiOjh9

SSL Issuers
SSL Issuers

Из анализа по полю Issuer стали сразу понятны лидеры. Power BI расценил Issuers по разным типам, но я свел их воедино и получились следующие результаты.
Symantec оказался откровенным лидером, оставив далеко позади основного конкурента GeoTrust. В принципе, это не удивило. Symantec всегда хорошо себя чувствовал в Enterprise секторе.
Большой вопрос в том, как теперь на это повлияет то, что крупнейший центр выдачи SSL Verisign/Symantec попал под санкции производителей браузеров за ненадлежащую проверку данных клиентов.
Также, в результатах анализа часто встречался (Blank), незаполненный параметр. Это значит, что в ответе вообще не указан Issuer. Странно, почему такой ключевой параметр оказался не заполнен у большого количества ресурсов.

Symantec – 22.64%
GeoTrust – 9,45%
GoDaddy – 7.25%
Comodo – 10.22%
RapidSSL – 7.09%
Entrust – 5.42%
Thawte – 5.25%
GlobalSign – 5.15%
DigiCert – 4.87%
Let’s encrypt Authority – 2.15%
Starfield Secure – 1.71%
cPanel – 1.2%
(Blank) – 8.74%

Коды ответов серверов

Посмотрев на полученные результаты SSL, начал смотреть в коды ответов серверов, которые поддерживают эти сертификаты. Получилась достаточно интересна картина. Много ресурсов не обслуживали запросы напрямую, а переадресовывали их куда-то дальше. И вообще коды ответов были чаще не стандартным “200”, который я ожидал увидеть, а целый диапазон кодов, которые я раньше не часто встречал.
Список кодов вы можете также рассмотреть ниже. В результате мы видим, что только каждый четвертый запрос отрабатывался напрямую, а все остальные – “со спецэффектами”.

Site not available – 7,15%, 544
Connection time out – 8,34%, 635

Moved Permanently (301) – 36,3%, 2763
The request has succeeded (200) – 24.51%, 1866
200 (Meta refresh) – 0,58%, 44
Found (302) – 20,2%, 1538
See Other (303) – 0,93%, 71
Forbidden (403) – 0,88%, 67
Not Found (404) – 42
Temporary Redirect (307) – 25
Service Unavailable (503) – 7
Internal Server Error (500) – 4
Bad Request (400) – 3
Bad Gateway (502) – 2
Not Acceptable (406) – 1

Серверы приложений

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

Вооружившись nmap, и направив его только на 443 порт (выделен для работы с SSL), я активировал сбор “баннеров” которые позволяют с высокой точностью получить наименование и версию сервера приложений, который обслуживает конкретный сайт.
Я не сильно удивился, увидев не менее трети (33.69%) в виде (Blank), потому что это нормально скрывать версию и баннер, чтобы не облегчать взломщику жизнь.
Я не сильно удивился когда увидел что лидером является Apache со всеми возможными подверсиями, с результатом в почти 24%.
Также ожидаемо было увидеть NGINX с 12.41%
Что действительно меня удивило – это Microsoft, с 18.67%, заняв второе место из трех призовых.

И теперь – внимание. IBM, Oracle и прочие основные игроки Enterprise сектора серверов приложений, вообще не показали серьезных результатов равно как и остальные компании, которых я ожидал увидеть.

https://app.powerbi.com/view?r=eyJrIjoiNGIyODMyYmItM2VjOS00NzEyLWE1MWEtNzAxZTZhOTIwYTUxIiwidCI6Ijc4ZjRlY2I5LTUxZTUtNDllZi05YzNhLWFkNDk1MGY3YzZkZCIsImMiOjh9

HTTP Servers
HTTP Servers

APACHE
Total 1651 23.97%

MICROSOFT
Total 1286 18.67%

NGINX
Total 855 12.41%

Остальные по убыванию:
AkamaiGHost – 282
F5 BIG-IP load balancer http proxy – 187
HAProxy http proxy – 182
Incapsula CDN httpd – 165
OpenResty web app server – 59
Amazon CloudFront httpd – 28
BigIP – 19
Citrix NetScaler httpd – 17
LiteSpeed httpd – 17
Dweb – 11
IBM HTTP Server – 11
Varnish http accelerator – 11

“Хьюстон, у нас проблемы”

Одним из параметров сканирования, включенных по default в SSLSCAN, была проверка на такую нашумевшую уязвимость как HEARTBLEED, которая несколько лет назад наделала много шума. Напомню, эта уязвимость как раз эксплуатировала уязвимость в обработке SSL сертификатов и позволяла получить контроль над удаленным сервером с уязвимой версией SSL.
В результате анализа, оба сканера, SSLSCAN и NMAP, выявили наличие ресурсов, подверженных уязвимости HEARTBLEED, что совсем не радует.
И это была только простая “ковровая бомбардировка”, направленная на проверку только одного сервиса – SSL.
Естественно я не пытался их эксплуатировать – что было бы расценено как факт попытки взлома.

Выводы

Если подвести краткие итоги моего исследования сертификатов, то получим несколько фактов.

Существует явный лидер рынка который поставляет SSL сертификаты банковскому сектору и это Symantec.

Существует явный лидер корпоративного сектора которым является Microsoft, но при этом занимает лишь второе место, на первом Apache, на третьем NGINX. При этом остальные “лидеры” даже рядом не стоят с вышеперечисленной тройкой.

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

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

22.08.2017

Pavlo Sidelov