За стеклом

Уже c осени прошлого года разработка головного модуля SpyEye остановилась на версии 1.3.48. Эта версия и доминирует в настоящее время в потоке самплов

этого семейства.

Распределение SpyEye по версиям за период с 1 января 2012 г.*
* К другим версиям (7%) относятся 1.2.50, 1.2.58, 1.2.71, 1.2.80, 1.2.82, 1.2.93, 1.3.5, 1.3.9, 1.3.25, 1.3.26, 1.3.30, 1.3.32, 1.3.37, 1.3.41, 1.3.44

То, что автор не развивает платформу, не мешает SpyEye обзаводиться новыми функциями. Все дело в возможности разрабатывать и подключать плагины (библиотеки dll), которые может создать кто угодно. Проанализировав самплы SpyEye с начала года, я насчитал 35 плагинов. Ниже в таблице приведены эти дополнительные модули с указанием количества самплов, в которых они встретились:

customconnector.dll 783
ccgrabber.dll 224
rdp.dll 149
socks5.dll 138
socks.dll 80
keylog.dll 80
ftpbc.dll 78
spySpread.dll 54
webfakes.dll 52
ffcertgrabber.dll 22
emailgrabber.dll 13
ftpgrabber.dll 13
jabbernotifier.dll 10
bugreport.dll 5
flashcamcontrol.dll 5
stb_3_4.dll 4
hookspy.dll 3
f.dll 3
Plugin_USBSpread.dll 3
c.dll 3
ddos.dll 3
save_2_0.dll 1
tgr1.dll 1
mrz_3_5.dll 1
customconector.dll 1
brgr_1_0.dll 1
zuchek2_6.dll 1
creditgrab.dll 1
win_sound.dll 1
dk.dll 1
save_1_0.dll 1
doberman_v_4_7.dll 1
jazz_3_2.dll 1
kill.dll 1
skdv_0_7.dll 1
   

На днях мне впервые попался на глаза плагин flashcamcontrol.dll. Его название заинтриговало меня, и я проверил, что

же он делает. Оказалось, он связан с управлением веб-камерой зараженного компьютера. В настройках к этому плагину я

обнаружил целый список немецких банков. Библиотека flashcamcontrol.dll программно устанавливала настройки

FlashPlayer’а, разрешающие Flash-документу, загруженному с какого-либо сайта из списка банков, использовать веб-камеру

и микрофон без специального запроса, приведенного на скриншоте ниже:

Вот как добивается этого DLL. По пути настроек FlashPlayer’а:

находится каталог, относящийся к определенному банку по маске #, и в нем изменяется файл «settings.sol»:

включая опции «allow always» («разрешать всегда») для работы с веб-камерой и микрофоном.

Это весь функционал библиотеки. Понятно, что это только часть замысла злоумышленника. Но должно быть еще что-то. Это

что-то я нашел в настройках другого плагина под названием webfakes.dll, где прописаны следующие правила:

И если зараженный пользователь зайдет на сайт определенного банка и браузер, обрабатывая странички этого сайта,

запросит flash-документ по адресу из первой колонки, то плагин webfakes.dll (который работает в контексте браузера),

перехватит такой запрос и подменит его на адрес из второй колонки: вместо документа с сайта банка браузер загрузит

вредоносный документ с сервера злоумышленника (statistiktop.com).

Здесь у меня появилось предположение, что банки ввели какой-то новый способ подтверждения легитимности клиента, который

пользуется онлайн-банкингом, с использованием веб-камер, и злоумышленники пытаются эту новую меру безопасности обойти.

Первое, что пришло в голову, – это распознавание клиентов по изображению. Эта идея уже давно витала в воздухе: при

регистрации пользователь онлайн-банкинга фотографируется, биометрические параметры сохраняются на сервере банка, и если

клиент проводит какие-то банковские операции онлайн, текущее изображение, снятое с помощью веб-камеры, сравнивается с

сохраненными при регистрации параметрами. Несмотря на то, что уже есть организации, которые развивают такой подход и

предлагают имеющиеся решения, широкого распространения такая мера безопасности в интернет-банкинге не получила. Мы

обратились к банкам, которые были указаны в настройках к плагинам SpyEye, и нам ответили, что никакие веб-камеры для

проверки клиентов не используются. Более того, адреса, по которым, согласно правилам webfakes.dll, должны были бы

скачиваться flash-документы с сайтов банков, – недействительны, т. е. никаких документов по ним на сайтах нет. Но по

адресам из второй колонки, т. е. на сервере злоумышленника, документы существуют. Оказалось, что оба flash-документа

просто создают окно с изображением с веб-камеры. Один из них направляет видеоряд на сервер злоумышленника:

В другом, если закрыть объектив камеры, flash-документ воспринимал это как проявление неполадок с веб-камерой и

предлагал пути решения на русском языке (впрочем, этот flash-документ, Camera_test.swf, был найден на различных сайтах,

так что это может быть какой-то известный тестовый шаблон для работы с веб-камерой посредством Flash):

Это уже не первый раз, когда злоумышленники, использующие банкеры, пытались получить видео и звук жертвы. Мой коллега

Дмитрий Бестужев вспомнил случай, когда во вредоносной программе, нацеленной на клиентов одного эквадорского банка,

также существовала функция записи видео и звука с зараженного компьютера и пересылки этих данных злоумышленнику. И это

тоже не было связано с видеораспознаванием клиентов — эквадорский банк не принимал таких мер безопасности.

Резонный вопрос: для чего же тогда снимать на камеру жертву? Вероятно, злоумышленники следят за реакцией пользователя,

когда проводится хищение средств с его счета. Как правило, снятие средств происходит по следующему сценарию:

пользователь вводит свои данные авторизации на сайте банка, но код страницы банка изменен вредоносной программой, и

после авторизации пользователю показывается не интерфейс управления счетом, а, например, окошко с надписью «Пожалуйста,

подождите….». В это время внедренный вредоносный код уже подготавливает перевод денег на счет так называемого дропа –

сообщника, который предоставляет свой банковский счет, куда переводятся деньги при краже. Теперь, чтобы подтвердить

транзакцию, мошенники должны вынудить пользователя ввести секретный код, который он получает от банка, например, в виде

SMS по телефону. Тут пускается в ход социальная инженерия: программа злоумышленника показывает в браузере какой-либо

запрос, например сообщение «Мы усилили меры безопасности. Для продолжения, подтвердите, пожалуйста, что вы имеете

правомерный доступ к этой учетной записи, введя секретный код, который мы послали в SMS на ваш номер телефона». Этот

момент как раз и может быть интересен злоумышленнику: как поведет себя пользователь, когда ни с того, ни с сего ему на

телефон приходит SMS от банка, а сайт банка требует ввести код из этого SMS при авторизации? В эквадорском банке, как

пояснил Дмитрий Бестужев, при проведении транзакции пользователю могут позвонить из банка, чтобы тот сообщил свой

секретный код. В этом случае злоумышленник может подслушать этот код, получит возможность по телефону представиться

банку тем клиентом, код которого он знает, и сможет, например, запросить изменение и номера телефона, и данных

авторизации на сайте, т. е. получит абсолютный контроль над банковским счетом жертвы.

Вернемся к схеме, примененной в SpyEye. Как мы поняли, на сайте банков flash-документов, работающих с вебкамерой, нет и

никогда не было. Так с чего бы браузеру запрашивать такие документы? Здесь работает другой базовый механизм SpyEye –

веб-инжекты. Когда пользователь заходит на какой-либо сайт, для которого определено правило в разделе веб-инжектов, то

согласно правилу, в скачанный браузером оригинальный код сайта SpyEye вставляет вредоносный код злоумышленника. В нашем

случае в код сайта банка на определенной страничке вставляется вредоносный кусок, который и ссылается, якобы, на

flash-документ на сайте банка.

Вот как это работает с самого начала и до получения злоумышленником видео с веб-камеры жертвы:

Вот так: злоумышленники посягают уже не только на наши деньги, но и наши эмоции.

Публикации на схожие темы

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *