Контакты
Подписка
МЕНЮ
Контакты
Подписка

Эффект дежавю: безопасность банк-клиентов находится на уровне 1990-х годов

Эффект дежавю: безопасность банк-клиентов находится на уровне 1990-х годов

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Эффект дежавю: безопасность банк-клиентов находится на уровне 1990-х годов

Digital Security Research Group опубликовала отчет о результатах исследований защищенности банк-клиентов ведущих российских производителей за период с 2009 по 2011 г. Основной вывод заключается в том, что, несмотря на чрезвычайную критичность программного обеспечения данного класса, общий уровень защищенности систем ДБО, по оценкам исследователей, находится на крайне низком уровне. Банк-клиенты содержат большое количество критичных уязвимостей разных классов, большая часть из которых была свойственна системам, разработанным еще в 1990-е гг.
Алексей Синцов
руководитель департамента
аудита ИБ Digital Security

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

Атака "человек в браузере"

Приведем пример популярной атаки через уязвимости в Web-модулях ДБО (XSS, CSRF), известной как "человек в браузере" (MitB) и приводящей к подделке платежного поручения с валидной ЭЦП пользователя:

Все исследуемые продукты содержали те или иные уязвимости. Инъекция SQL-кода, ошибки авторизации и межсайтовые запросы обнаружились в большинстве систем, а межсайтовый скриптинг (XSS) – во всех. Ситуация с клиентским ПО (ActiveX) аналогична: уязвимости типа "выполнение произвольного кода" и "вызов небезопасных методов" были найдены в 4 из 6 систем.
  • Через уязвимость межсайтового скриптинга подгружается фрейм со страницей ДБО, развернутой на весь экран.
  • Скрипт атакующего в основном окне контролирует все ото бражаемое содержимое во фрейме. При этом пользователь видит только фрейм с интерфейсом ПО.
  • Как только пользователь начинает операции со счетом, в частности создание платежного поручения, скрипт атакующего подменяет реквизиты получателя на реквизиты атакующего. При этом в интерфейсе отображается то, что ввел пользователь.
  • В момент подписи платежного поручения в токен отправляется поддельное платежное поручение. На экране отображается платежное поручение пользователя.
  • Подписанное платежное поручение атакующего отправляется пользователем с валидной ЭЦП. На экране компьютера пользователь видит те данные, что ввел он сам.

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

Для нескольких продуктов удалось реализовать еще более опасный подвид атаки "человек в браузере", где от пользователя не требуется выполнять какие-то действия в ДБО. Используя JavaScript, запускаемый в скрытом для пользователя фрейме, можно имитировать его действия и отправить подписанное платежное поручение. Таким образом, злоумышленник, заманив клиента ДБО на специальный сайт, имеет возможность тайно украсть его деньги.

Контроль безопасности отсутствует полностью

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


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

Digital Security делает вывод: за три года разработчики не изменили своего отношения к производству продукта и уделяют внимание безопасности, только когда их продукт начинают массово взламывать. Контроль качества безопасности кода отсутствует полностью, ни проверка кода, ни стресс-тестирование, ни анализ безопасности на уровне архитектуры разработчиками не проводится. Количество уязвимостей стабильно высокое на протяжении 3 лет по всему рынку.

Многое зависит от клиента

"Если следовать логике Digital Security, то за последние 10–15 лет ничего нового в защите систем ДБО не появилось. А как же возникновение таких инструментов защиты, как USB-токены с неизвлекаемым ЭЦП, внедрение систем аутентификации/подтверждения платежей при помощи ОТП-токенов или одноразовых SMS-кодов, организация защиты от DDoS-атак как на стороне банков, так и на базе разработчиков систем ДБО, разработка специальных программных модулей, направленных на выявление и уничтожение вредоносных банковских программ?" – не соглашается с выводами специалистов Digital Security Research Group начальник управления информационной безопасности "ОТП Банка" Сергей Чернокозинский.


Управляющий директор дирекции информационных и платежных технологий Транскапиталбанка Валерий Шеин замечает: "Эксперты компании Digital Security справедливо считают, что уровень защищенности систем ДБО низкий, но, мне кажется, нужно рассматривать и другие звенья этой цепочки".

По мнению Шеина, наиболее слабым звеном выступает сам клиент – именно он заражает свой компьютер всеми возможными вирусами, не позаботившись о современной лицензионной антивирусной системе; именно клиент оставляет токен с ключами постоянно подключенным к USB-порту компьютера, в то время как и банк, и производитель систем ДБО рекомендуют подключать токен только на сеанс подписи платежа, или просто хранит ключи электронной подписи на жестком диске компьютера.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #1, 2012
Посещений: 7378

Приобрести этот номер или подписаться
  Автор

 

Алексей Синцов

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

Всего статей:  2

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций