Общий расклад.

Все платежи делятся на онлайн и оффлайн. Онлайн - это платеж, который поступает до поставщика услуг незамедлительно, через Интернет. Оффлайн - это платежи, которые накапливаются в базе данных платежной системы, и, в определенные промежутки времени отправляются на сервер поставщика услуг. Кроме того, некоторые поставщики принимают только бумажные реестры. То есть обмен происходит непосредственно при участии человека и поставщика услуг. Онлайн-платежами, как правило, оперируют операторы сотовой связи, в то время как коммунальщики предпочитают получать платежи «оптом» один раз в сутки-двое. Сама по себе концепция онлайн-платежа уже небезопасна, потому как, проводя такие платежи в большом количестве, работникам платежных систем меньше всего их получается разгребать. Зато в случае коммунальных платежей, перед отправкой их гораздо проще проверить на существование соответствующего запроса на терминале.

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

Как правило, начинающие платежные системы подходят к вопросу безопасности в последнюю очередь, делая акцент на скорости и удобстве сервиса. Поэтому, при выборе жертвы, стоит в первую очередь обратить внимание на молодые компании. Хотя никто не говорил, что Гиганты платежной индустрии не содержат ошибок в системах безопасности. Очень часто происходит как раз наоборот... Возьмем, к примеру, недавний случай с небезызвестной конторой «ОСМП» (Объединенная Система Моментальных Платежей). Центральный сервер, к которому обращаются тысячи терминалов России, Казахстана, и, возможно, других стран был обезоружен на несколько суток банальной DOS/DDOS-атакой. Я, правда, не в курсе, воспользовался ли кто-нибудь ситуацией в своих корыстных целях или просто похулиганили, но атака была и это остается фактом.

Связь терминала с сервером происходит по GPRS/GSM-каналу и, как правило, посредством технологии XML-RPC. Некоторые даже додумываются навешивать SSL-защиту, но чтобы она действительно оправдывала себя, протокол, во-первых, должен быть закрытым, во-вторых – передаваемый пакет должен шифроваться также средствами программы, а в-третьих, сервер должен не только предоставлять свой корневой сертификат, но также требовать клиентский. Не буду голословным и приведу примеры.

У того же ОСМП протокол передачи открыт, то есть, шифровать пакет на выходе из программы уже не имеет смысла. Получать его реверс-инженерингом будет только извращенец. Но их сервер не требует клиентского сертификата, то есть отправить запрос может любой желающий, правильным образом сформировавший пакет. Да, твой канал при передаче будет защищен, но кого это интересует, если для взлома нужны только идентификационные данные. Ведь получить их при большом желании не составит труда. Здесь и Социальная Инженерия и НЛП и банально Хакинг тебе в помощь.

Еще одну интересную брешь я нашел сразу в двух молодых конторах. В ответ на мой POST-запрос, сервер послал меня в сторону HTTPS явным проявлением в содержимом ошибки IIS-ного акцента. Как известно, по умолчанию IIS-сервер устанавливает центр выдачи сертификатов в каталог /CertSrv/Default.asp, последовав в который, я, в три клика, получил свой собственный клиентский сертификат. Кстати, после этого мне удалось получить доступ даже к ASPX-страница для проведения платежей и их просмотра, правда на одном из ресурсов страница была защищена паролем, получить который мне так и не посчастливилось.

Большинство платежных систем ставят на свои серверы Windows 2000/2003 Server, чем уже совершают большую ошибку. Но те, кто принимает платежи в MySQL-базу на Linux-сервере, при этом, держа на борту Apache+PHP, совершают еще большую ошибку. Не мне тебя учить, как пользоваться SQL-Injection, а ведь это очень простой и верный способ получить огромное количество необходимых данных для проведения платежей, имитируя платежный терминал.

Ищем дыры

При поиске дыр в защите платежной системы- жертвы первое, что стоит сделать – это сканирование портов и web-контента. На открытых портах зачастую можно найти интересные самописные сервисы для проведения платежей, администрирования терминалов. Ведь ни один работник не будет работать круглосуточно вместе с платежными терминалами. Программеры и сисадмины придумывают различные примочки удаленного управления для собственного удобства. Зачастую они даже не задумываются о защите, надеясь, что никто не подумает их ломать.

К некоторым портам можно попробовать ломануться по telnet, но как показывает практика, в основном такие сервисы работают по технологии XML-RPC, а это означает, что порт может только принимать и отправлять POST-запросы. Как узнать структуру запроса и его содержимое? Можно попробовать просканить веб-содержимое на чтение. Многие пишут свои сервисы с использованием asp-страниц, которые требуют своих исходников в тех же каталогах. Если администратор в последнюю очередь думает о правах доступа, есть большая вероятность прочитать исходники asp-сценариев, что при грамотном использовании может помочь составить XML-запрос. Кстати, подобные дыры были зафиксированы даже у достаточно крупных платежных систем!

Web-контент лучше исследовать вручную + сканером. В качестве сканера лично мне больше всего нравится XSpider. Открою секрет, совсем недавно мне по спутниковой рыбалке прилетела бесплатная версия 7.5 от Zeromag Lab, так что ищите да обрящите :).

Три реальных взлома

Взлом CyberPlat

Как показало исследование, платежная система CyberPlat принимает платежи во многих странах, и, их сайты хостятся на одном сервере. Проверить это достаточно просто. Достаточно ввести доменное имя или IP-адрес в поисковый запрос на www.domainsdb.net.

Интересная картина получается:

1. cybercheck.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | proxy.cyberplat.com
2. cyberplat.ru [whois] IP: 213.33.161.9 dns: ns.demos.su | ns.cyberplat.ru
3. cyberpos.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | proxy.cyberplat.com
4. cybercard.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru
5. gribov.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru
6. pinsale.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru
7. platina.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | ns.platina.ru
8. rodnoe-pole.ru [whois] IP: 0.0.0.0 dns: ns.demos.su | ns.cyberplat.ru
9. rodnoepole.ru [whois] IP: 0.0.0.0 dns: ns.demos.su | ns.cyberplat.ru

Домены зарегистрированы, но недоступны. Скорее всего, их оставили для личного пользования. Но это не так важно. Остальные сайты в других странах показали в роли первичного DNS – cyberplat.com, а вторичным стоял cyberplat.ru. Это могло означать только то, что центральный сервер один, но на нем хостится несколько CyberPlat-сайтов для разных стран. Пинговались они, кстати, тоже по одному айпишнику.

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

Нагуглив в кармане немного денежных средств, я дошел до ближайшего CyberPlat-овского терминала, закинул на мобильник чисто символическую сумму и получил квитанцию. Оказалось, что владельцем терминала был далеко не CyberPlat, а совсем левая контора, которая выступала просто-напросто дилером. Дилерские программы – это основа распространения платежных терминалов. Контора покупает автомат, ставит на своей территории и, с проведенных платежей, получает свой процент.

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

Через несколько минут письмо от администрации сервиса CyberPlat полетело жертве на ящик (не для кого ведь не секрет, как подделывается адресат). В письме не было ничего особенного. Стандартная история о смене оборудования на сервере и т.п., в связи с чем, просим выслать ваши регистрационные данные, которые нам просто жизненно необходимы, чтобы ваш терминал не заткнулся :).

Послушные овцы прислали мне все свои регистрационные данные через пару часов. После этого был сгенерирован XML-файл, который полетел POST-запросом на сервер платежной системы.

Кстати, на их сайте лежит не только все описание протокола, но и исходники программы устанавливаемой на стороне терминала, а также ее скомпилированная версия.

Взлом QuickPay

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

1. Click on touch
2. Click on release
3. Drag and click
4. Drag and double click

Это как минимум… То есть, сам понимаешь, что можно отключить все возможности кроме простого нажатия по нарисованным кнопкам. Но ведь нет же! Квалифицированные мастера сервисного обслуживания и не подумали ничего отключать. Наверное, посчитали, что тогда им будет неудобно обслуживать терминалы!

Таким образом, мне удалось на разных терминалах этой конторы получить доступ к рабочему столу (да, не удивляйся, там стоит обычная винда, вопреки тому, что на сайте написано Linux), Моему Компьютеру и, каталогу с программой со всеми вытекающими последствиями.

Взлом ОСМП

С этой конторой пришлось немного попотеть. Просканировав порты, nmap нащупал открытый и нефильтруемый pptpd-демон на стандартном 1723 порту. Так как для подбора пароля у нас существует “THC Hydra”, дело оставалось за именами пользователей. База данных пользователей PPTP очень часто не имеет ничего общего с базой данных пользователей сервера, но далеко не всегда. Зачастую Василий Пупкин создает одного и того же пользователя vasya везде, где только возможно. Поэтому, получив версию Apache-демона, я вспомнил про старую уязвимость с определением имен пользователей через web-доступ. Через несколько минут эксплойт был готов к работе.

Эксплойт отработал удачно и нашел двух пользователей – root и alex. Дальше за дело принялась Hydra. Я зарядил несколько увесистых словарей и подготовил скрипт для генерирования словарей имитирующих посимвольный перебор, но до них дело так и не дошло. Все вышло как нельзя проще. Пароль для alex-а был очень простой и даже находился где-то в начале словаря.

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

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

Стоит ли овчинка выделки?

Сам факт получения чего-то нахаляву уже заставляет человека совершать какие-то телодвижения. Главное в этом деле не жадничать и помнить про Уголовный Кодекс. Но зато какой результат... Я думаю, оно стоит того. Подумать только - ты можешь проводить практически любые платежи абсолютно бесплатно нажатием нескольких кнопок в твоей самописной программе.

Хочу сразу предупредить - все вышеописанное в статье было заранее сообщено администраторам платежных систем, которые в свою очередь поспешили прикрыть дыры.

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