Наша практика показывает, что почти в 100% случаев злоумышленник может украсть у клиентов банка деньги и при этом остаться незамеченным, используя исключительно уязвимости системы ДБО. Даже если клиент имеет у себя на компьютере обновлённое программное обеспечение, современный антивирус, соблюдает рекомендации банка по безопасности, из-за недостатков самого банковского программного обеспечения он может стать жертвой – у него могут украсть деньги.
Почему же отрасль находится в таком состоянии?
ОБЩАЯ ПРАКТИКА РАЗРАБОТКИ ДБО
В различных программных продуктах (браузеры, плагины, офисные продукты, OS, различные CMS) уязвимости обнаруживаются ежедневно. Уязвимости – это естественный побочный продукт процесса разработки ПО.
И чем сложнее продукт, чем больше различных технологий он в себе соединяет, тем больше в нём, вероятно, кроется различных уязвимостей. Это общеизвестно. Существуют, разумеется, и средства борьбы с ними.
Одним из основных методов является внедрение в процесс разработки программного обеспечения этапов, посвящённых анализу кода и архитектуры, стресс-тестированию (фаззингу). Но у нас сложилось впечатление, что большинство производителей ДБО в нашей стране либо не знают о подобной практике, либо намеренно пропускают эти этапы.
Пример. Компоненты ActiveX очень часто используются в так называемых тонких клиентах систем ДБО для доступа к токенам и ЭЦП. Достаточно часто нам хватало простейшего фаззинга – автоматического тестирования с использованием стандартных и общеизвестных инструментов – и мы находили уязвимость, приводящую к выполнению произвольного кода на стороне клиента. Злоумышленник, используя такую уязвимость в компоненте ActiveX, может незаметно для клиента заразить его банковским «трояном» со всеми печальными последствиями. Такие уязвимости систематически находятся у различных производителей ДБО. Но именно они и должны выявляться и устраняться ещё на стадии разработки!
Дальше – больше. Мы находим у того или иного производителя ДБО уязвимость, сообщаем о ней, разработчик её исправляет. Через год мы тестируем новую версию ActiveX-компонента – и находим уязвимость, аналогичную старой, в другом месте. Выходит, что производитель поправил конкретную ошибку, но не решился проанализировать своё ПО на наличие аналогичных проблем в других местах.
В нескольких ActiveX-компонентах присутствовали разнообразные «логические» уязвимости, потенциально приводящие к краже ЭЦП. Некоторая часть функционала компонента, которая использовалась, например, для обновления ЭЦП, была реализована небезопасно, и злоумышленник легко мог скопировать ЭЦП с компьютера клиента на свой.
Вывод: функционал этих компонентов у производителя ПО до нас не видел ни один специалист по информационной безопасности.
Даже такие базовые вещи, как защита от CSRF-атак, отсутствуют в некоторых системах ДБО. И это в 2012 году! Нечего и говорить о том, что, хотя в течение 4 лет мы систематически рекомендуем производителям ПО использовать различные методы защиты и смягчения последствий, такие как встроенные в ОС механизмы защиты памяти (DEP, ASLR и т. д.), заголовки веб-сервера (X-Frame-Options) и параметры Cookie (Secure, HTTPOnly) для снижения риска XSS-атак, никаких массовых изменений нет и не предвидится. Эти методы внедрены только в отдельных банках.
ПРОБЛЕМЫ РАСПРОСТРАНЕНИЯ ОБНОВЛЕНИЙ
Коммуникация между банками и разработчиками ПО напоминает испорченный телефон. Например, мы проводим тестирование определённой систем ДБО в банке А. По итогам передаём список найденных уязвимостей банку, тот передаёт его, в свою очередь, производителю ПО. Через некоторое время банк внедряет у себя обновления, присланные от производителя ПО. Проходит год, мы приходим в банк Б, использующий такую же систему ДБО, и обнаруживаем там наряду с новыми и старые уязвимости, знакомые нам по аудиту в банке А. И при этом банк Б уверен, что у них стоит новейшая версия ПО.
Вывод: производитель ДБО разработал исправления только для банка, запросившего их, вместо того чтобы сделать универсальный патч для всех своих клиентов. Иногда это обоснованное решение: системы ДБО различных банков у одного производителя ДБО могут значительно отличаться, но это скорее исключение. Скорее причина в том, что производитель ДБО не видит в такой работе особой прибыли для себя.
Подчеркнём, что это не проблема конкретного производителя ДБО, а общая практика производителей в данной сфере (хотя, конечно, есть и исключения).
ВНЕДРЕНИЕ − ДЕЛО ТОНКОЕ
Хотелось бы отметить и позитивные тенденции этого года. Банки нашей страны всё лучше понимают свою ответственность перед клиентами и те риски, что несут для них хакерские атаки, а потому стараются каким-то образом защититься.
Но здесь у них возникают проблемы, так как зачастую производители ДБО не хотят бесплатно дорабатывать своё ПО, даже если это важная и полезная доработка, которая повысит защищённость системы. Впрочем, после проведения аудита ДБО, имея на руках список уязвимостей в качестве аргумента, банк всё же может заставить производителя ДБО внести необходимые корректировки.
Теперь о самих банках. Хотя улучшения есть, ситуация далека от совершенства. Казалось бы, система ДБО – это один из критичных компонентов инфраструктуры банка: через неё проводятся денежные операции, и при этом она доступна из сети Интернет (то есть атаки могут быть полностью анонимными). В то же время многие банки полагаются лишь на «защищённость» систем ДБО (которая, увы, далека от совершенства) и не используют каких-либо сторонних средств защиты или снижения последствий от атак. Так, меньше половины банков, в которых мы проводили аудит ДБО, используют межсетевые экраны для веб-приложений или системы обнаружения вторжений. Ещё хуже ситуация со сбором логов (даже из стандартных мест) и их анализом.
Кроме того, системы защиты зачастую внедряются некорректно. Так, мы несколько раз видели ситуацию, когда IPS была, но своих владельцев, к сожалению, никак не защищала. Проблема была в том, что она отслеживала только зашифрованный SSL-трафик систем ДБО и таким образом игнорировала все реальные атаки.
Другой пример – защита от CSRF с помощью одноразовых токенов для каждого запроса. Мы сталкивались с ошибками внедрения такой защиты. Например, сам механизм защиты присутствовал, и токены были, но по какой-то причине совсем не проверялись на серверной стороне. Или защита была реализована только для «критичных», по мнению банка, то есть финансовых операций, хотя, используя «некритичные», а потому не защищённые от CSRF операции, злоумышленник легко мог скомпрометировать клиента банка.
Если же продолжить тему внедрения и перейти на более высокий, программный уровень, то стоит отметить ещё более опасные ситуации, которые встречались в нашей практике. Так, несколько раз мы обнаружили, что административная панель системы ДБО по тем или иным причинам доступна из сети Интернет, причём без пароля! А через такую панель злоумышленник может сделать всё что угодно с любым из клиентов системы.
ИТОГИ ДЛЯ БАНКОВ И ИХ КЛИЕНТОВ
Как это ни странно, в результате всех вышеописанных проблем больше всех страдает клиент банка. Из-за уязвимостей в ДБО и ошибок внедрения ДБО в банке именно клиент банка может стать жертвой, то есть потерять деньги. И это даже при условии, что клиент соблюдает все стандартные меры предосторожности...
ДЕЙСТВИЯ ЗЛОУМЫШЛЕННИКА
Если говорить о примерах способов кражи денег только с помощью уязвимостей в ДБО, то, кроме уже описанного простейшего примера с ActiveX-компонентом, где само присутствие установленного компонента даёт злоумышленнику возможность заразить компьютер «трояном», можно выделить ещё несколько типичных сценариев.
Во-первых, межсайтовый скриптинг (XSS). Используя XSS, злоумышленник может внедрить в страницу свой JavaScript-код. На практике это означает возможность полностью контролировать то, что отображается у клиента, и то, что отправляется на сервер. Кроме того, злоумышленник сможет полностью эмулировать действия клиента в ДБО.
Пользователь, ставший жертвой XSS, будет видеть привычный интерфейс ДБО. Но когда он попробует отправить куда-то свои деньги и станет вводить необходимые данные, то внедрённый злоумышленником JavaScript заменит эти данные номером счёта и суммой, указанными злоумышленником, перед тем как платёжное поручение будет подписано валидной ЭЦП (или подтверждено одноразовым паролем) и отправлено в банк. Кроме того, после отправки в банк тот же код будет визуально производить обратную подмену данных, которые отображаются у клиента. Поэтому в выписке по счёту клиент увидит, будто всё хорошо!
Распространена ещё более опасная ситуация, когда для доступа к токену, который используется для подписи платёжных поручений, требуется ввести пароль, но только при входе, а потом он запоминается. Тогда злоумышленник, используя XSS или CSRF-атаки, имеет возможность получить доступ к токену, подписать и отправить в банк любое платёжное поручение. Такая атака происходит в считанные секунды и может проводиться неоднократно. Что особенно трагично для клиента, доказать, что эту операцию совершил не он, нет никакой возможности.
Случается даже, что за счёт совмещения нескольких уязвимостей (хранимые XSS и отсутствие разграничения доступа между пользователями) злоумышленник может встроить вредоносный JavaScript-код во все аккаунты ДБО и атаковать любого клиента или всех сразу.
Тренд этого года – SSRF-атаки, про которые Александр Поляков рассказывал на крупнейшей хакерской конференции BlackHat в Лас-Вегасе в прошедшем году. В ходе наших аудитов мы выявили, что приблизительно треть банков уязвима к этой атаке: нам удавалось скомпрометировать серверную часть ДБО. Важно отметить, что SSRF-атаки очень специфичны для каждого банка и зависят от внутренней организации инфраструктуры.
Отказ в обслуживании из-за DDoS-атаки, видимо, кажется банкам ближе и понятнее, чем уязвимости самой ДБО и хищение денег у их клиентов, потому что здесь они видят прямые убытки для себя. Многие из них настраивают по несколько каналов связи от различных провайдеров, некоторые применяют дорогостоящее специализированное оборудование.
Желание правильное, вот только от проблем самой системы ДБО такие устройства не помогут. Очень часто получается, что сервер ДБО можно отключить, используя программные уязвимости систем ДБО или её компонентов, с помощью всего нескольких специально сформированных запросов. Распространена ситуация, когда производитель ДБО вынуждает банк использовать устаревшую и уязвимую версию веб-сервера, так как более современная версия им не поддерживается. На «дырявой» основе непросто построить защищённую систему.
ВЫВОДЫ
Создание защищённой системы ДБО – это комплексный процесс. И именно процесс.
Вот несколько примеров. В одном банке решили внедрить дополнительную систему аутентификации вдобавок к стандартной от производителя ДБО. Производитель реализовал и внедрил её для этого банка. А после аудита оказалось, что именно этот дополнительный компонент и сделал в безопасности систем ДБО большую дыру, с помощью которой можно было атаковать клиентов этого банка.
В другом банке, уже после аудита, добавили «ещё одну страничку» в интернет-банк. Благодаря ей некорректно проверялись пользовательские данные, можно было добавить свой JavaScript-код и провести XSS-атаку.
И под конец небольшая общая статистика.
Примерно в 95% случаев в системах ДБО различных разработчиков были найдены уязвимости, позволяющие проводить XSS-атаки. Так же часто мы находили уязвимости компонентов ActiveX, позволяющие либо полностью скомпрометировать компьютер клиента, либо незаметно украсть его ЭЦП. Около 30% банков подвержены атакам класса SSRF. Меньше половины банков используют WAF и системы IDS/IPS.
В любом случае нам удавалось найти векторы атак, с помощью которых злоумышленник имел возможность незаметно украсть деньги со счетов клиента (а в некоторых случаях у всех клиентов сразу). Что ещё хуже, с учётом того, как банки относятся к сбору логов и их аудиту, банк просто не в силах будет обнаружить такие атаки, а значит, пострадавших клиентов будет со временем становиться всё больше.
- Стоимость медиауслуг (открыть PDF) -
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
