Комментарии 14
Для проведения атаки сначала необходимо было заразить банкомат. А вот триггером для срабатывания зловреда являлся специально подготовленный чип на карте. То есть: вставляем карту, вредоносное ПО распознает ее как свою и открывает Святой Грааль.
Этот пример финансовой кибератаки подтверждает, что на стороне пользователя технология EMV надежна.
Вдумайтесь, пожалуйста, вначале в первую фразу, а потом осознайте, pls, вторую.
Какая вообще связь с EMV? После того как "зловред" получил доступ, ему все равно по какому признаку "свой подошел к банкомату" опустошать кассеты. С таким же успехом можно было на любое событие отлеживать "свой".
Взяли событие "вставление чиповой карты с определенными данными". По видимому, что бы внешне (действия с банкоматом) не выглядело подозрительно. Причем здесь EMV вообще?
Это не первая уязвимость подобного рода и компании периодически выплачивают солидные вознаграждения black hat'ам за неразглашение.
Интерфейс библиотек (DLL) взаимодействия с диcпенсером, EPP клавиатурой и EMV kernel не является уж очень большим секретом (ну и не может быть секретом).
И не правильно говорить о том, что использование штатного программного интерфейса этих библиотек — это уязвимость
После того как "зловред" получил возможность запускаться под админ правами — он может все. Какие, в данном случае, уязвимости библиотек EMV? Они не занимаются авторизацией и управлением диспенсером.
Встроится и перехватить callback вызов на работу с EMV приложением (например со специально выделенным AID) как триггер на опустошение кассет..
Т.е. потенциально через некоторое время и новые прибамбасы к EMV спекам будут кейсы заражения ATM прямо с вставленной карточки, снятие наличных, ребута и практически полного уничтожения следов.
но случаи уязвимости самих EMV ядер были,
Теория заговора? :)
Примеры pls… Все всегда становится широко известно в узких кругах.
Т.е. потенциально через некоторое время и новые прибамбасы к EMV спекам будут кейсы заражения ATM прямо с вставленной карточки, снятие наличных, ребута и практически полного уничтожения следов.
Потенциально…
Ну да. Теоретически можно допустить все что угодно.
На практике, я слишком хорошо знаю спецификации EMV и вообще как это все работает в терминале/банкомате, что бы предположить такие сценарии, как заражение банкоматного ПО через EMV интерфейс.
Простой инсайд (:
Не все уязвимости идут по пути криминала. Компании-производители сами готовы отстегнуть — это дешевле.
уязвимости самих EMV ядер
Вы имеете в виду сертифицированные (EMVco) библиотеки или вообще реализации POS/ATM?
Да кто бы спорил… Ошибки программные будут всегда. Просто ошибки. Могу Вас заверить, в старые времена работы с магниткой их не меньше допускали.
Но причем здесь EMV как таковое? EMV это, фактически, стандарт описывающий интерфейс "карта — устройство". И некоторые рекомендации по алгоритмам (фактически зафиксированные VSDC и MChip особенности) и, как дополнение, CPA реализация апплета и рекомендации по персонализации (CPS).
кейсы заражения ATM прямо с вставленной карточки
Написать обработку EMV данных так, что бы получить передачу на выполнение кода в "данные загруженные c приложения"… так это даже если специально делать в исходниках, то это не тривиально в реализации (не на всех процессорных и OS архитектурах вообще сработает).
В "случайную дыру" такого типа, уж извините… не верю.
А не случайна дыра, при правильном подходе (PA-DSS), возникнуть не должна.
Вы имеете в виду сертифицированные (EMVco) библиотеки
Именно они L2, над которыми работают единицы допущенных в обособленных отделах и каждый бинарный релиз которых проходит сертификацию под лупой. Внутри тот ещё С-ишный треш творится.
А не случайна дыра, при правильном подходе (PA-DSS), возникнуть не должна.
htm
Это бумажная бюрократия на честном слове в первую очередь. То, что происходит на деле иногда лучше и не знать, особенно когда бизнес перегружает разработку и выжимает сроки. Вот, например, тот же Static Analysis в виде Coverity проблему не видел. Некоторые проблемы известны внутри, но обновлять весь флот близких к End-of-Life терминалов в поле не всегда оправданно.
Ну раз мы говорим про одно и то же…
Глюков в этих библиотеках достаточно (особенно бесконтактные, которые вообще черный ящик писанный индусами… наверное..).
Но что то особо критичных глюков, оставляющих большие дыры, которые не закрыть внешней логикой — не видел (хотя не исключаю, что они есть).
Но и все одно решение (terminal risk management) принимает внешнее, по отношению к библиотекам ПО. И как то (в России) все очень не любят off-line операции…
В общем, подробности не здесь стоит обсуждать.
Это бумажная бюрократия на честном слове в первую очередь.
Эх… я же сказал "при правильном". Всегда хочется надеяться что где то там все гораздо лучше со сроками, и строгим соблюдением всего. НЕ лишайте меня иллюзий!
За те деньги, которые EMVco берет за сертификацию и деньги которые стоят инструменты для EMV тестирования/предсертификации… Всегда хочется надеяться..
Компетенция работы с EMV?
Там нет ничего сложного… Вся документация открыта. Простейшее EMV приложение на Java или просто активация одного из стандартных EMV апплетов (на выбор… VSDC, MChip, CUP, Gemalto реализация CPA, "Мир" :) ) со своим набором данных.
Ну это как… ну как админу знать стек TCP протокола.
Security Week 35: перехват клавиатуры через WiFi, атака на банкоматы с помощью EMV-чипа, новый IoT-ботнет