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

Сценариев, когда с банкоматом может пойти что-то не так — множество, и большинство основаны далеко не на теоретическом анализе потенциальных уязвимостей, а на практике разбора реальных атак. Банковская сфера в целом гораздо более защищена, чем другие индустрии, но и внимания у киберпреступников к ней больше: на кону реальные деньги. Тем не менее, неплохо было бы как-то систематизировать слабые места банковской инфраструктуры, чем и занялись недавно специалисты «Лаборатории» Ольга Кочетова и Алексей Осипов.

Как и в случае с историей расследования кампании Lurk, данный текст представляет собой вольный пересказ первоисточников. За деталями отправляю к ним: это обзорная статья на Securelist на русском, исследование «Будущие сценарии атак на коммуникационные системы, взаимодействующие с банкоматами» на английском, краткая выжимка оттуда — только описание атак и методов противодействия, а также более ранние публикации: описание вредоносной программы Skimer и целевой атаки на банкоматы Tyupkin.

Ты помнишь как все начиналось


Атаки на банкоматы — не совсем новая тема. Первая версия вредоносной программы Skimer появилась в 2008-2009 годах. Атака направлена непосредственно на банкоматы: в одной из актуальных версий (Skimer существует и развивается поныне) после заражения банкомата им можно управлять, вставив в банкомат подготовленную карту с «ключом» на магнитной полосе.


Его ворсейшество!

В соответствии со своим названием, Skimer может активировать сбор данных с вставляемых в банкомат карт, но его также можно использовать для прямой кражи наличных — соответствующая команда предусмотрена в меню управления. Skimer встраивается в легитимный процесс SpiService.exe, в результате чего получает полный доступ к XFS — универсальной клиент-серверной архитектуре для финансовых приложений для Windows-систем.



В отличие от Skimer, атака Tyupkin, исследованная в «Лаборатории» в 2014 году, не использует подготовленные карты. Вместо этого предусмотрена активация вредоносного кода в определенное время суток, причем даже в это время перехватить управление банкоматом можно только после ввода динамического кода авторизации. Последствия успешной атаки, впрочем, примерно те же:



Carbanak и компания


Собственно, наиболее интересным в этих двух примерах является процесс заражения, который подчас приходится восстанавливать по записям камер видеонаблюдения. В случае с Tyupkin вредонос устанавливался с компакт-диска (!), то есть имелся физический доступ к внутренностям банкомата. Это очевидный вектор атаки с не менее очевидными недостатками. Но он и не единственный.

В кампании Carbanak, детали которой раскрыли эксперты «Лаборатории» в феврале прошлого года, банкоматы используются в последнюю очередь, безмолвно отдавая кэш по команде из центра, без каких-либо манипуляций на месте. Скомпрометирована была инфраструктура жертв, благодаря которой основной ущерб наносился, что называется, по безналичному расчету. Когда убытки измеряются сотнями миллионов долларов, наличные перестают играть значимую роль.



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



Киберпреступники будут атаковать корневую инфраструктуру финансовых организаций, пока у них будет такая возможность, то есть пока она будет уязвимой. Как показывает история с грабежом через систему межбанковских переводов SWIFT, даже критически важные элементы финансовой инфраструктуры не всегда защищены должным образом (не получается ли так, что защита банкоматов подчас лучше?). Хочется верить, что это ненадолго. Учитывая то, что киберпреступность про банкоматы и не думает забывать, именно они претендуют на сомнительную привилегию долгосрочной головной боли фининдустрии.

В какую сторону бояться?


В своем анализе будущих векторов атак на банкоматы, наши эксперты не ограничиваются непосредственной кражей наличности. К этой понятной цели добавим кражу данных о клиентах для последующего увода средств в бОльших объемах с меньшими шансами засветиться на камеру наблюдения. Но и это не все. Если присмотреться внимательно, то во всей IT-«обвязке» сети банкоматов не получится найти такое место, которое нельзя было бы атаковать.

Интересным примером является биометрическая идентификация клиентов — относительно новая технология, позволяющая либо заменить, либо дополнить стандартные средства авторизации — по пин-коду, с помощью NFC и так далее. Кража биометрических данных теоретически возможна через соответствующим образом допиленные скимеры (в случае если биометрия наступит еще раз на грабли, пройденные ранее с ридерами карт), через атаку типа Man-in-the-middle (когда банкомат начинает слать данные на чужой процессинговый сервер), либо через атаку на инфраструктуру финансовой организации.



Дальнейшее использование биометрии для кражи средств пока под вопросом, и детально не описывается. Но есть важный нюанс: если киберпреступники научатся это делать, мы получим аналог ситуации с клонированными кредитными картами, но без возможности «перевыпуска» (отпечатков пальцев, голоса и прочего). Не факт, что придется изобретать симуляторы отпечатков: в отдельной главе исследования приводятся сценарии атак на PIN-пады, в ходе которых данные могут быть перехвачены, а могут быть и подменены, с принудительным отключением шифрования. Возможно ли реализовать такое для биометрического датчика? Почему бы и нет.



Что делать?


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


Угадай ось по версии Adobe Reader

Хотя некоторые показанные в отчете сценарии атак (пока) являются теоретическими, вместе с «практическими» они складываются в интересную картину. Финансовым организациям приходится бороться как со специфическими угрозами (атака на SWIFT, Carbanak — взлом со знанием внутренних процессов), так и с общеупотребительными (фишинг, эксплуатация уязвимостей, ошибки конфигурации и так далее). Добавим сюда традиционные скимеры, физический взлом банкоматов, сложности с обновлением софта и железа (мой собственный пруф — на фото выше). С одной стороны из всего этого получается одна гигантская уязвимость. С другой — ресурсов на защиту, хоть денежных, хоть экспертных, тоже немало. Так что финансовая сфера в будущем может принести нам как новые примеры громких кибервзломов, так и действительно инновационные модели защиты.

Disclaimer: Данная колонка основана на реальных событиях, но все еще отражает только частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Поделиться с друзьями
-->

Комментарии (12)


  1. Cobolorum
    03.10.2016 20:06
    +7

    Это статья для домохозяек?


  1. collerperm
    03.10.2016 21:47
    +2

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


    1. Vjatcheslav3345
      04.10.2016 12:41

      А болгарка?


      1. collerperm
        07.10.2016 18:56

        А это уже взлом банкомата )


  1. helg1978
    04.10.2016 00:33
    -2

    если б я делал банкомат, у меня было б самописное ядро, несовместимое со стандартными загрузчиками исполняемых программ. Не панацея, но запуск чужого софта затруднило бы.
    P.S. Всегда было интересно, почему старая WinOS в подобных устройствах часто оправдывается, как неизбежная необходимость, т.к. драйвера железа под WinX. А зачем они?
    Мне по работе приходится использовать купюро/монетопремники, диспенсеры, кард-ридеры, и ни разу не приходилось использовать драйвера. NDA с произведителем->получение pdf со стеком команд->написание своего API. Чем плох такой метод?


    1. soniq
      04.10.2016 01:43

      Если б вы делали банкоматы, вы бы наверняка захотели продавать их банкам. А банки бы вас попросили добавить в софт всяких очень им нужных штук, типа рекламных заставок на флеше и java-апплетов для связи с процессингом. И вот тогда бы вы задумались, что проще: запилить в свою ось флеш, перерисовать все их ролики (и будущие тоже) под свою систему анимации, или просто быть как все.


      1. helg1978
        04.10.2016 02:01

        Думаете аргумент «этот банкомат на 98% защищен от запуска вредоносного кода» не убедил бы комерсов банка выкинуть кривой и уязвимый флеш и переписать свои плюшки на HTML5? Ну, можно было бы наступить себе на горло, и собрать версию Хромиума где флеш еще включен.
        Не знаю как с возможностью (и лицензированием) сборки Java, но исходники вроде доступны, и от Sun и от OpenJDK


        1. soniq
          04.10.2016 08:25

          А Ваши конкуренты бы сказали: «У него там 98% защита от запуска любого кода. У нас от вредоносного тоже есть защита, зато свой софт можете использовать любой»


        1. qwertEHOK
          04.10.2016 10:45

          Не забывайте так же про стоимость обслуживания — с банкоматов не зря убрали OS\2 в угоду Windows XP.


    1. Jesting
      04.10.2016 08:55

      Метод плох, тем что не универсален. Только Ваше приложение, только Ваш стек ПО, только Ваши самописные драйвера под этот стек. Вендорлокед, да ещё и с тучей багов, потому как человек с подобным подходом программистом хорошим быть не может.


      1. frol_aleksan
        04.10.2016 11:03

        Хорошо, а почему бы тогда не использовать Linux-решения? Их сейчас разве что в чайники не встраивают. Запустить можно много чего, но в то же время безопасность выше на голову, при этом не надо тратить деньги на закупку Windows, учитывая ипортозамещение в рамках 44 и 223-ФЗ, по которым с 2017 года импортное ПО можно будет закупать только если не будет его аналогов в Росреестре или только после мотивированных объяснений, почему нужно именно оно. Правда, опять же, нужны драйверы под купюроприемник, картридер и кассеты с купюрами, но это, думаю, не такая уж большая проблема для производителей соответствующих компонентов банкомата.


        1. Jesting
          04.10.2016 12:04

          Этот вариант выглядит лучше потому, что существует JavaXFS и многие производители имеют драйвера написанные под этот стандарт.