навигатор на просторах интернет и реального мира

Киберпреступность — это не вымысел и не пугалки для различных клиентов с целью развести их на покупку чего-либо (IPS, AntiVirus, пентест); к сожалению, в нашей стране это объективная реальность, которую нужно воспринимать как есть. Сегодняшняя статья будет посвящена киберпреступникам и их методам увода денег. Мы не будет говорить о кредитках, Webmoney и Paypal, а поговорим о другом департаменте киберпреступности, который опустошает счета в банках. Весь текст основан на личном опыте автора, когда он работал в банке, а именно — проводил расследования инцидентов, и просто на опыте различных пен-тестов банков и анализе банковского ПО.

Банк-Клиент

Тут в дело вступает наше законодательство и правила Центробанка (самый главный банк страны). В частности, при работе с юридическими лицами (фирмы, компании, корпорации и т.д.) требуется, чтобы платежные поручения были заверены цифровой подписью. Но не простой, а единственно правильной — на ГОСТ’овском алгоритме.

Процесс формирования электронной подписи ГОСТ Р 34.10 2001 (Автор: Алексей Бузмаков)

В итоге операционист получает только те платежки, подпись которых проверена, далее он смотрит назначение платежа, его описание и жмет "ОК". После этой фазы можно не сомневаться — деньги дойдут куда нужно. Итак, как это выглядит:
Аутентификация в системе Банк-Клиент;
Формирование платежного поручения;
Подпись (часто подписи надо ставить две — от бухгалтера и директора);
Отправка в банк;
Подтверждение платежки операционистом в банке;
Банк осуществляет операцию.

Это общее условное описание действий. На самом деле многое зависит от типа банк-клиента, от правил банка и т.д. и т.п.
Классификация

Системы ДБО бывают разными, и поэтому работа с ними тоже протекает по-разному. Проведу быструю классификацию:
Толстый Банк-Клиент
Тонкий Банк-Клиент
Интернет-Клиент
Мобильный-Клиент
ATM-Клиент
Толстый

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

Клиент работает со счетом из браузера. Это означает, что он работает уже через веб-интрефейс (иногда через специальный интерфейс на Java) и локальной базы у него нет, но, тем не менее, ему накатываются плагины к браузеру в виде Java-апплетов или ActiveX, чтобы делать подписи (электронная подпись ставится локально, так как секретный ключ находится у клиента). Зачем ActiveX? Затем, что в Windows по умолчанию нет криптопровайдера для подписи согласно ГОСТ. Поэтому необходимо дополнительное ПО, которое будет ставить подпись по всем законам.
Интернет-Клиент

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

То же, что и интернет, только подтверждение платежа происходит с помощью мобильного телефона. Например, с помощью посылки на телефон одноразового пароля.
АТМ

Работа со счетом осуществляется через банкомат.

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

Итак, почему юридические лица? Во-первых, у них большой поток денег и множество переводов в сутки. Если добавить одну маленькую платежку, ну, скажем, на один-два миллиона рублей, то такая платежка на фоне остальных не вызовет подозрения у операциониста. И потом, у юридических лиц нет подтверждения через мобильники и прочей лабуды, что напридумывали для физических лиц взамен электронно-цифровой подписи (ЭЦП) на платежку (у них только ЭЦП). Следующий фактор — больше возможностей для маневра и взлома. Фактически, взламывая ЛЮБУЮ фирму или компанию, можно смело утверждать, что где-то там в локалке есть компьютер с установленным банк-клиентом. Более того, в действительно больших фирмах финансисты, которые от имени фирмы осуществляют платежи, имеют договоры сразу с НЕСКОЛЬКИМИ банками и БК соответственно, более того, они же не придумывают и, тем более, не знают, что именно они делают. Что я сейчас сказал? :) Вот именно — не знают. В большинстве случаев такие операторы просто получают ТЕКСТОВЫЙ ФАЙЛ без подписи из 1С или из ERP-системы со списком, куда, сколько отправить, что они уже и выполняют в БК.
ЭЦП

Вкратце: подпись — это результат хеш-функции от текста платежки, "зашифрованной" на закрытом ключе клиента. Банк, получая платежку, проверяет хеш от текста полученной платежки, потом "расшифровывает" подпись открытым ключом клиента и сверяет результат. Если хеши совпали, значит, это действительно платежка от клиента, и текст платежки достоверен. Решаются задачи целостности, идентификации клиента и, кроме того, сам клиент потом НЕ МОЖЕТ отказаться от этой платежки, так как она подписана верным ключом. Дело в том, что между банком и клиентом подписывается договор, согласно которому все платежки с верной ЭЦП банк должен отправлять. Поэтому, если кто-то украдет ключ пользователя, подпишет платежку, то банк обязан исполнить ее, выполняя денежный перевод, куда сказано. И если клиент потом пойдет с претензиями, что, мол, это не я отправлял, банк покажет договор, покажет бумажки о генерации ключа, о признании этого ключа клиентом, о том, что ключ был верный, и что денег клиенту он не должен. Короче, сам потерял ключ — сам и виноват, банк ничего возмещать не обязан (хотя может, если клиент ему дорог и сумма небольшая). ПО, работающее с ЭЦП по ГОСТу, у нас гордо зовется "Система Криптографической Защиты Информации" (СКЗИ). Такое ПО проходит проверку ФСБ, и на него выдаются соответствующие сертификаты! Алгоритм подписи — ГОСТ Р 34.10 2001. При этом алгоритм хеш-функции — ГОСТ Р 34.11-94. Разбирать и ломать криптографию никому не надо, ведь ключ можно украсть или использовать прямо на месте.
USB-Token

Многие банки, интеграторы-безопасники и т.д. говорят, что USBToken защитит всех нас от хищения ЭЦП. Что же такое USB-Token? Это железка в виде USB-устройства, внешне похожего на обычную флешку. Внутри этой "флешки" прошит секретный ключ и микросхема, которая принимает на вход данные, подписывает их по ГОСТу внутри себя (с помощью ключа) и на выход обратно кидает уже подпись. Это достаточно круто, ведь тогда ключ нельзя скопировать и украсть. Но, к сожалению, можно просто подменить входные данные или вообще поставить жертве R-Admin, а можно и туннелировать трафик USB на машину злого хакера. В общем, все это — не панацея, а недавние реализации зловредов уже включали в себя такой функционал. Так что USB-Token просто снижает риски. Это все, что про него можно сказать. Хотя есть более крутые Token’ы с одноразовыми паролями и т.д., но массового внедрения пока нет, да и слабые места в виде перехвата ввода пароля и использование его для подложной платежки также возможны. Защита клиента должна включать в себя целый комплекс мер: сегментация физическая, логическая, удаление ненужного функционала, ограничение доступа в интернет, ключевая политика, парольная политика, патч-менеджмент, антивирусная защита и все в таком духе.
Грабим караваны

Зная, как вся это каша работает, рассмотрим теперь, как нехорошие люди уводят деньги.

История номер один:
Береги WiFi смолоду

Срочное расследование инцидента показало, что в среду утром (на более ранее число логов не сохранилось) к офису одной компании в Петергофе подключились по WiFi (шифрование WEP, так что я использовал слово "подключились"… о том, что по WiFi, ясно из MAC-адреса, который говорил о 3Com-устройстве, а в компании нет ни одной 3Com-карточки, что говорит о том, что нарушитель скорее внешний, так как внутри офиса заметили бы новый девайс или ноут). Далее злоумышленник что-то делал, но что — не ясно, ибо логи были в очень ограниченном числе с определенных серверов, но буквально к вечеру с этого IP-адреса уже использовалась админская учетная запись домена (не сильный админский пароль -> ARP-SPOOF -> HASH+CONST handshake -> Ranibow-Table -> profit!). За это время ребята смогли найти машины, работающие с банком, что было несложно, ибо netbios и доменные имена машин в локалке были вида: BANK01, BANK02. Имея админскую учетку, нетрудно захватить контроль над тачкой, установить кейлогер и стырить ключи от банка, ведь ключи-то были на флэшке… Через день негодяи попытались осуществить перевод денег. Они нашли WiFi-точку, поднятую без шифрования в жилом доме, в квартире. Злоумышленники вышли в интернет, подключись к нескольким системам банк-клиент, ввели логины и пароли, которые добыли с кейлогера — вошли в систему. Далее они набили платежки (практически одновременно, что говорит о том, что злоумышленники действовали в числе 2-3 человек с одного WiFi-шлюза, видимо, из автомобиля) и подписали их ключами, которые прихватили с собой позавчера с флехи. Только чудом удалось избежать потерь — один из банков что-то заподозрил и сообщил клиенту, клиент тут же проверил остальные БК, нашел левые платежки и успел их отменить. Но такое случается не всегда.

Выводы: безопасность внешнего периметра, парольная политика, сегментация сети, неиспользование прозрачных имен машин, вывод критичных машин из общего домена, неиспользование флешек и HDD для хранения ключевой информации. Про антивири, IDS и привязку IP компании к счету я молчу, ибо это полезно, но не всегда действенно.
История номер два

В небольшой компании бухгалтер сам отправляет платежки. Он любит это делать с ноута, а также этот ноут он использует как домашний и рабочий компьютер. Однажды, проверяя почту, он увидел письмо, в котором говорилось, что они что-то там не уплатили по счету некой строительной компании. И вроде да… недавно они что-то заказывали по ремонту, но наш герой уже не помнит деталей. Письмо составлено нормально, нигде нет ничего палевного, что и логично, автор письма знаком с основами СИ. Так вот, бухгалтеру нашему надо вспомнить, что это за строительная компания такая, а то подозрительно как-то. О, да тут в письме, в подписи, есть линк на сайт компании… Дальше все понятно, exploit-pack, Acrobat Reader, спец-троян для БК. Дальше история может быть аналогична предыдущей. Социальная инженерия, отсутствие патч-менеджмента и отсутствие правил безопасности и простейших политик. Такие истории случаются довольно часто. Добавлю еще один, как мне кажется, интересный вариант — внедрение платежки в БД или в экспорт из БД.

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

Понятное дело, что для банк-клиентов используются специализированные трояны, которые умеют работать с ЭЦП (с USB-токенами), с одноразовыми паролями, виртуальными и обычными клавиатурами и т.д. и т.п. Трояны эти так просто с Сети не скачать — их приобретают у "производителя" и затачивают под конкретные банки (подробнее о рынке можно было прочитать в ][ #112, статья "Услуги кардеров"). К примеру, троян/руткит не только тырит все, что введено, но и подменяет контент сайта банка. То есть, забиваешь ты платежку, жмешь кнопку "подписать", а на самом деле в USB-Token уходит другая платежка с другим получателем, которую ты и подписал, однако на экране компьютера все по-прежнему выглядит невинно и отображены все те данные, что ты ввел (однако в банк уходят другие данные). Такие трояны стоят очень дорого и применяются конкретно под определенную цель. Как правило, те, кто ломают клиента и воруют, и те, кто пишут троян — разные люди. Кроме прочего, после перевода деньги еще надо снять. Самый простой вариант увода — попросить каких-нибудь студентов зарегистрировать счет и карту, скажем, за пять тысяч рублей. Правильно выбранный студент не откажется от такого. Далее забираешь карточку и пин-код, потом, в выбранный день N, осуществляются переводы со взломанных клиентов на счет, который зарегистрировал студент. Далее ездишь по банкоматам и сливаешь с карточки наличные. Это, конечно, грубая и не всегда эффективная модель вывода, но при маленьких суммах или большом количестве студентов и дропов — реальная. В общем-то наши доблестные органы ловят в основном дропов, до организаторов сложно добраться, и они могут находиться очень далеко, скажем, на Украине или в Польше :). Или наоборот, дропы сливают нал в Болгарии, а хакеры (злые, плохие ребята, а не крутые добрые белые шляпы) работают в Новосибирске. При таком географическом разбросе вычислить следы сложно, особенно если у организаторов есть крыша. Ну, ты понял, что дело это опасное и нехорошее, у каждого в нем своя роль, но все это уголовно наказуемо!
Не клиентом единым

К слову, ломать могут не только клиентов, но и сам банк. Казалось бы, это нереально, но тут есть, где развернуться — последний опыт пен-тестов показал, что нашим разработчикам систем есть куда развиваться. В разное время и в разных системах был найден классический набор ошибок: XSS-, SQL-инъекции, логические ошибки доступа, отсутствие шифрования критичных данных и т.д., и т.п. Примеры векторов атак при этом могут быть разными, но основа все-таки почти всегда полу-инсайдерская. Дело в том, что если у тебя уже есть доступ к БК, то есть, фактически, ты — клиент банка, то возможностей по взлому самого банка у тебя на порядок больше, нежели ты был бы простым внешним пользователем. Мой любимый пример логической ошибки: хочешь ты перевести рубли в доллары, БК предоставляет такой функционал, у тебя, соответственно, два счета — валютный и наш, деревянный. Скрипт перевода выглядит так: на вход сумма в рублях и валюта. На выходе — сумма в рублях, текущий курс, сумма в долларах и хеш. После подтверждения пользователем, что он согласен на перевод, это все кидается в третий скрипт, который проверяет хеш (это от CSRF) и обрабатывает ввод, делая update в БД. Так вот, на втором шаге можно изменить курс доллара на более выгодный, а второй скрипт уже не проверяет курс… Это пример логической ошибки. Описывать SQL-инъекции и XSS не смысла — все уже знакомы с таким видом дырок…
0day

Но вернемся к клиенту, так как он все-таки более частая жертва. Два года назад, когда я работал в одном питерском банке, мне было так скучно, что я решил поковырять ActiveX популярного банк-клиента на предмет уязвимостей (BSS). Фаззинг ничего не дал, так как формат принимаемых данных был сложным, но так как время у меня было, я просто медленно и верно восстанавливал формат входных данных. Когда формат был восстановлен, я указал очень большой параметр в текущем формате. Итог банален — переполнение буфера. Тогда я проверил еще два популярных коробочных продукта (Inist, R-Style). И там уже банальным фаззингом нашел как переполнения буфера, так и небезопасные методы в ActiveX (вспоминаю сейчас доклад на CC’10 Алексея Трошичева про фаззинг в процессе разработки и вопросы программистов из зала на тему "нафиг это надо?". Вот ответ. Хотя анализ исходных кодов — также вещь необходимая и важная). И вот прошло два года, и я решил просмотреть еще один ActiveX, который не досмотрел тогда, естественно, отечественный и популярный — Faktura.ru от ЦФТ :). Фаззинг ничего не дал (как и два года назад). Но в этот раз я привлек банальную внимательность, которая никогда не повредит. И вуаля — было найдено переполнение буфера в одном свойстве, которое эксплуатировалось только в связке с другими свойствами и методами...

Понятное дело, что фаззеры неэффективны, когда формат данных или последовательность вызовов нетривиальна. Так получилось, что четыре из четырех ActiveX, которые я посмотрел "чисто из любопытства", содержали критические уязвимости (сейчас все исправлено, слава DSecRG, политика которых заключается в бесплатном уведомлении отечественных разработчиков без распространения технических деталей в публикациях). При этом стоит учесть, что два банк-клиента сдались простейшему фаззеру ActiveX, что говорит о том, что злые парни тоже могли бы их найти (в отличие от других двух, где фаззеры не дали результатов).

Inter-PRO от Сигнал-КОМ — локальный BoF

Но это еще не все — я решил глянуть на СКЗИ и его окружение, вернее, на Inter-PRO от Сигнал-КОМ — клиент-серверное приложение, отвечающее за передачу данных по сети. Само приложение содержит вшитый модуль СКЗИ, который сертифицирован ФСБ (чтобы шифровать, не нарушая закон). Так вот, данное ПО содержало аж три уязвимости (и мы уже говорим не про ActiveX, а про полноценное клиент-серверное ПО). Одна из ошибок удаленная (в серверной части) и фактически позволяет "отключить" любой банк, который использует у себя Inter-PRO (DoS). Риски снижаются за счет того, что "отключить" банк может только законный пользователь банка, имеющий валидный ключ (любой клиент), а не каждый встречный-поперечный. Одна из уязвимостей была и в клиенте - переполнение буфера с возможностью выполнения произвольного кода (для этого вектора атаки надо иметь доступ на запись к файлам клиента или подсунуть свой файл, что, опять-таки, сильно снижает вероятность реальных атак). В любом случае, такие ошибки в критическом продукте - неприятность. Добавлю, что из всех производителей лишь ПО от Сигнал-КОМ использовало защитные механизмы компилятора — /GS (понятно, что есть пути обхода GS, но в данном билде они были неприменимы, и это позволило лишь выполнить удаленный DoS вместо Code Execution). Было бы хорошо, если бы такие слова, как Permanent DEP, ASLR, SEHOP, GS были знакомы всем программистам, ведь в связке эти штуки способны сильно-сильно поломать планы злым хакерам. Пример — все тот же Inter-PRO — если бы не GS, то была бы печальная история, а так — просто невнимательность и неприятность.

Добавлю, что пользователь может знать об уязвимостях во Flash, Acrobat Reader, Windows и т.д., но про уязвимости в отечественном продукте он не узнает - никто этим не занимается, на этом баг-хантерам денег не сделать (бывают исключения, но они скорее другого рода).
Финиш

Каковы же правила выживания? Да просты они, как и всегда, многое уже прозвучало и не один раз в тексте статьи, многое итак очевидно, но кое-что и не особо, так что я соберу все в одном абзаце.
Сегментация — компы с БК в отдельной подсетке;
Политика пользования — должны быть правила по работе с этими ПК;
Антивирусная защита;
Ключевая политика — использование USB-тoken’ов и правила их использования также важны — не оставлять токен все время в системнике — это приводит к хищению денег!
Парольная политика — разные юзеры — разные сложные пароли и все в таком духе;
ПК, его софт, процессы и порты должны быть обоснованы для использования. Все лишнее — в топку;
Фильтрация доступа на сетевом уровне — с БК машин могут ходить только на IP банков и на определенные порты, входящий трафик запрещен (динамическая фильтрация входящих пакетов);
Патч-менеджмент;
Аудит — важный шаг, чтобы понять, можно ли в БД или в выгрузочном файле подсунуть платежку. БД тут — вообще тонкий момент;
Проверка внешнего периметра;
— проверка, что локальная БД не светится в локалку, нет паролей по умолчанию.

Для банков я ничего писать не буду, они там сами умные — разберутся, в любом случае всегда страдает пользователь, поэтому он должен сам беспокоиться о своем БК, ключах, паролях и безопасности. Не было сказано про интернет и мобильные клиенты, а также АТМ-клиенты, но для первых двух атаки почти идентичны, за исключением некоторых деталей, а АТМ-клиент — совсем другая история. Отдельной проблемой стоят вопросы об ошибках в отечественном ПО. Как показали мои опыты, уязвимости можно найти даже в банковском ПО, которое изначально должно было разрабатываться с учетом вопросов безопасности...

Взято с http://www.xakep.ru