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

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

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

Клиент

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

Само проникновение осуществляется, например, через рассылку по электронной почте. В рассылке указывается ссылка либо на файл, который надо скачать, либо на сайт, либо на PDF-документ. Уязвимости в ПО (Acrobat Reader, Internet Explorer, Java VM и т.д.) эксплуатируют данные документы или сайты и пытаются установить вредоносное ПО.

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

ActiveX

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

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

Сервер

Впрочем, не только клиентам требуется защита. Серверы банка также могут стать объектом атак злоумышленников, причем источником таких атак могут быть не только инсайдеры, но и взломщики из внешнего мира. Кроме того, такие атаки могут быть использованы для последующих атак на клиентов банка. Обеспечение безопасности банковских серверов системы банк-клиент, казалось бы, задача несложная -- необходимо лишь правильное использование межсетевого экрана, настройка ДМЗ, парольной политики, регулярные обновления ОС и сервисов. Но, увы, этого недостаточно. Программное обеспечение, используемое банками, содержит уязвимости, приводящие как к возможности атаки на клиентов, так и к компрометации базы данных системы «банк-клиент». Причем уязвимости характерны для всех систем ДБО. При атаках из сети Интернет известны две типовые модели поведения нарушителя. "Классический хакер" сканирует сервисы, ищет устаревшую версию используемого ПО, слабости и уязвимости в системе аутентификации и, конечно же, уязвимости в доступных 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%3с. Атака скрыта в последовательности символов параметра «color».

SQL-инъекция

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

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

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

Ошибки в серверном ПО

Так же возможны ошибки и в серверном ПО. К примеру, используется не обновленный сервер IIS, содержащий в себе ряд уязвимостей. Такие проблемы решаются банальным обновлением. Однако хотелось бы опять указать в сторону российских разработчиков. К сожалению, все из-за той же проблемы – отсутствия процедур для тестирования безопасности кода разработчики не замечают явных ошибок, которые приводят к уязвимости в продукте. Доказывая вышесказанное - нами были обнаружены сразу две уязвимости переполнения буфера в популярном отечественном средстве шифрования HTTP трафика между клиентом и банком. В итоге, любой клиент, мог одним TCP-пакетом «уронить» серверную часть ПО банка и тем самым вызвать отказ в обслуживании.

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

В целом по результатам наших работ по анализу защищенности банковского ПО и систем ДБО в 2009-2010 г. нами было обнаружено три уязвимости типа SQL-инъекции, шесть уязвимостей типа XSS, четыре уязвимости переполнения буфера в ActiveX, два небезопасных метода в ActiveX и два переполнения буфера в отечественной системе шифрования HTTP трафика между банком и клиентом. Добавлю, что во всех продуктах, практически, не применялись защитные механизмы ОС, вроде DEP и ASLR, и только в одном продукте в прокси-сервере для шифрования HTTP трафика использовался механизм защиты от переполнения буфера, что спасло его от выполнения произвольного кода (в итоге реальна была только DoS атака). Проблема усугубляется тем, что злоумышленники также могут проводить подобные исследования, ведь большинство систем ДБО доступно в режиме демо-версии, а ActiveX-элементы можно установить с сайта любого банка. Кроме того, для некоторых банков компании-разработчики пишут специализированные спроектированные под их нужды версии ПО. В таком коде также могут быть ошибки, которых нет в стандартной версии. Поэтому такие версии необходимо анализировать отдельно. Таким образом, для обеспечения безопасности ДБО на стороне клиента необходимо применить серьезные организационные меры. Для защиты серверной части системы необходимо применять четкие требования к ПО, которое использует банк. Например, для платежных приложений, используемых для работы с банковскими картами, существует обязательный стандарт безопасности PA-DSS. Этот стандарт разработан регулятором в лице PCI SSC, куда входят крупнейшие международные платежные системы (VISA, MasterCard, JSB, American Express и т.д.). Этот стандарт требует проведения независимого анализа безопасности приложения, проводимого сертифицированными компаниями и благодаря которому безопасность ПО, выпускаемого разработчиками, заметно повышается, особенно если аудит безопасности не превращается в формальную процедуру, а содержит серьезные проверки, включающие в себя поиск уязвимостей, анализ процедур разработки, используемых средств шифрования и т.д. Для систем дистанционного банковского обслуживания таких стандартов не существует, однако независимый анализ защищенности систем «банк-клиент» необходим как самим банкам, так и разработчикам этих систем. В настоящий момент ситуация приближается к критической отметке. Инциденты информационной безопасности, связанные с системами дистанционного банкинга, происходят все чаще, и если отношение к этому вопросу не изменится, то в ближайшее время мы придем к ситуации, когда пользователи будут отказываться от услуг ДБО, что уже происходит в некоторых банках.

наверх