17 августа 2012, 16:17
Количество просмотров 172

Эффект дежавю: безопасность систем ДБО находится на уровне 1990-х!

Такой неутешительный вывод сделал Digital Security Research Group, исследовательский центр компании Digital Security, опубликовав отчет о результатах...
Эффект дежавю: безопасность систем ДБО находится на уровне 1990-х!

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


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

Все исследуемые продукты содержали те или иные уязвимости. Инъекция SQL-кода, ошибки авторизации и межсайтовые запросы обнаружились в большинстве систем, а межсайтовый скриптинг (XSS) — во всех.

Ситуация с клиентским ПО (ActiveX) аналогична: уязвимости типа «выполнение произвольного кода» и «вызов небезопасных методов» были найдены в 4 из 6 исследованных систем. Большинство уязвимостей приводят к раскрытию персональных данных, банковской тайны, а также нарушению целостности информации о счетах, то есть, в конечном итоге, к возможности подделки платежных поручений и краже денежных средств. Также существует риск отказа в обслуживании, что может принести большой убыток банку за счет остановки бизнес-процессов. Нельзя также забывать, что успешная мошенническая атака — это, помимо материального ущерба, еще и серьезный репутационный ущерб для банк.

Атака «человек в браузере» (man-in-the-browser)

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

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

 2. Скрипт атакующего в основном окне контролирует все отображаемое содержимое во фрейме. При этом пользователь видит только фрейм с интерфейсом ПО.

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

 4. В момент подписи платежного поручения на токен отправляется поддельное платежное поручение. На экране отображается платежное поручение пользователя.

 5. Подписанное платежное поручение атакующего отправляется пользователем с валидной ЭЦП. На экране компьютера пользователь видит те данные, что ввел он сам.

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

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

 Атака с помощью  SQL-инъекции

Кроме вышеперечисленных недостатков в ряде отечественных систем ДБО были выявлены глобальные ошибки архитектуры. Так, в некоторых системах ДБО отсутствуют повторные проверки ЭЦП на платежных поручениях при выгрузке их в АБС (Автоматизированная Банковская Система). Разработчики системы ДБО понимают, что АБС недоступна из сети Интернет, и считают, что проверку ЭЦП достаточно делать только при приеме платежного поручения. Однако некоторые уязвимости и атаки могут скомпрометировать целостность результата этой проверки и тем самым форсировать выгрузку платежных поручений без ЭЦП в АБС, после чего оператор банка обработает их как нормальные (ведь в АБС не может быть ошибочных документов: они просто не выгрузятся с нужным статусом). Пример такой атаки — SQL-инъекция. Упрощенный алгоритм работы выглядит так:

1. Прием платежного поручения.

2. Выгрузка платежного поручения в базу данных ДБО со статусом «без подписи».

3. Подпись данных платежного поручения.

 4. Проверка ЭЦП платежного поручения открытым ключом клиента с помощью специального ПО.

5. Изменение статуса платежного поручения в базе данных ДБО на «подпись верна».

 6. Подтверждение клиентом отправки платежного поручения.

7. Изменение статуса платежного поручения в базе данных ДБО на «отправлено».

 8. Специальный скрипт или ПО по событию или таймеру выгружает все платежные поручения со статусом «отправлено» из базы данных ДБО в базу данных АБС.

9. Оператор, работая с АБС, обрабатывает платежное поручение.

Атака с применением внедрения SQLкода позволит выполнить шаг 5 без выполнения шага 4, что не нарушит логического хода алгоритма.

Возможные механизмы защиты

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

Защитные механизмы web:

• Флаги защиты cookie: HTTPOnly, Secure

• Поддержка SSL при аутентификации и доступе к системе

 • Контроль загрузки во фрейме (Frame Busting)

• Токены запросов

Защитные механизмы бинарных приложений:

• Защитная метка от переполнения буфера в стеке

• Поддержка работы модуля с использованием флага NX (DEP)

• Поддержка работы модуля со случайными базовыми адресами (ASLR)

• Поддержка защиты от атак на структуры обработки исключительных ситуаций (SafeSEH)

В случае с веб-приложениями лишь один разработчик применил уникальные токены запросов, которые защищают от атак класса «межсайтовые запросы» (CSRF). Почти все системы не поддерживают методики защиты типа Frame Busting и использование флагов cookie, которые снижают риски от атак типа «межсайтовый скриптинг» (XSS).

Бинарные модули также не поддерживают современные защитные технологии. Например, лишь один продукт был скомпилирован с флагом /GS (предупреждение от атаки типа «переполнение буфера в стеке»).

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

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

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

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

Рубрика:
{}
Теги:
#

PLUSworld в соцсетях:
telegram
vk
dzen
youtube