Безопасность банк-клиентов

Алексей Синцов
ведущий аудитор по информационной безопасности,
специалист исследовательского центра DSecRG

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

На фоне этой ситуации интересен подход разработчиков ДБО к безопасности своих продуктов. Производителей систем интернет-банкинга на практике не волнует безопасность их продукции. Ответственности перед банком или клиентом они не несут. И все, что касается безопасности, они наивно пытаются переложить на плечи криптографии – секретного ключа ЭЦП (если мы говорим о юридических лицах), то есть разработчик реализует аутентификацию пользователя в системе и алгоритмы работы с ЭЦП. Однако, учитывая специфику системы, необходимо помнить и о других, гораздо более важных векторах атак на системы ДБО. Для начала рассмотрим классическую ситуацию.

Клиент

Самый популярный вектор атаки – проникновение на компьютер клиента банка с последующим хищением или использованием ключа ЭЦП и перехватом логина и пароля учетной записи в системе интернет-банкинга. Ситуацию усугубляет использование однотипного программного обеспечения для доступа к ДБО. Большинство банков логично не хотят тратить силы и средства на разработку собственной системы "банк-клиент" и покупают готовое ПО. Такой подход на руку хакерам, поскольку резко сокращает их трудозатраты. При этом ряд банков и их клиентов имеют практически одинаковое ПО, поэтому для осуществления мошеннических операций, как правило, применяется универсальное вредоносное ПО.

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

ActiveX

В прошлом году исследовательский центр DSecRG провел исследования, посвященные качеству программирования клиентской части ПО систем ДБО. Были взяты три популярные системы интернет-банкинга, использующие ActiveX-технологию для организации работы с ЭЦП, и проведен анализ безопасности клиентских компонентов системы ДБО. В результате было обнаружено, что все ActiveX-объекты содержат уязвимости, позволяющие захватить контроль над системой. В каждом из трех компонентов были обнаружены ошибки переполнения буфера. В результате злоумышленник может выполнять произвольный код от имени пользователя, а этого достаточно для установки вредоносного ПО.

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

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

Сервер

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

При атаках из сети Интернет известны две типовые модели поведения нарушителя. "Классический" хакер сканирует сервисы, ищет устаревшую версию используемого ПО, слабости и уязвимости в системе аутентификации и, конечно же, уязвимости в доступных Web-приложениях – самом слабом, по статистике, звене системы дистанционного банковского обслуживания. Но от такого нарушителя довольно легко защититься, да и обнаружить его деятельность также не проблема. Гораздо опаснее вторая модель, когда нарушитель является законным пользователем системы и имеет собственные учетную запись, счет и все права на него.

Cross-Site Scripting

По статистике, самый популярный класс уязвимостей – это Cross-Site Scripting (XSS). Такая уязвимость позволяет атакующему влиять на генерируемое содержимое Web-страницы системы интернет-банкинга. Таким образом злоумышленник может использовать ресурс банка для атаки на клиента, например изменив страницу так, как если бы она выглядела при аутентификации в системе. Но если пользователь введет данные своей учетной записи, они будут отправлены злоумышленнику, ведь код страницы подделан. Такая атака называется "фишинг" и обычно используется для хищения данных учетной записи путем покупки злоумышленником похожего домена и вывешивания на главную страницу копии дизайна страницы аутентификации системы "банк-клиент".

В сочетании с уязвимостью XSS эта атака становится более опасной, так как домен и IP-адрес действительно принадлежат банку. Кроме того, XSS-уязвимости могут использоваться для атаки на ПО клиента с целью эксплуатации уязвимости в браузере или ActiveX – надстройке для браузера, вследствие чего у клиента будет установлено вредоносное ПО. При использовании XSS-уязвимости злоумышленник должен спровоцировать переход жертвы на специально сформированную гиперссылку в домене системы ДБО. Выглядеть URL такой ссылки может так: bank-client.moibank.ru/login.asp?color=SESSION_CODE%3a%3b%3c. Атака скрыта в последовательности символов параметра color.

SQL-инъекция

Другой популярной уязвимостью является возможность SQL-инъекции. Она позволяет злоумышленнику общаться с базой данных системы "интернет-клиент" в обход правил системы, что в итоге может привести к утечке или изменению базы клиентов, их счетов, номеров пластиковых карт, платежных поручений, паролей от системы и т.п. Это возможно, так как обеспечение безопасности и разделение доступа часто лежит на Web-приложении, имеющем единственную учетную запись в базе данных. Когда злоумышленник эксплуатирует SQL-инъекцию, то он обходит все уровни защиты Web-приложения и работает с базой данных под учетной записью этого приложения, вследствие чего у него появляется доступ ко всем таблицам системы. Кроме того, критичная информация в базе данных шифруется не всегда.

Ошибки бизнес-логики

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

Точка кипения

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