Pull to refresh

Comments 14

Для проведения атаки сначала необходимо было заразить банкомат. А вот триггером для срабатывания зловреда являлся специально подготовленный чип на карте. То есть: вставляем карту, вредоносное ПО распознает ее как свою и открывает Святой Грааль.

Этот пример финансовой кибератаки подтверждает, что на стороне пользователя технология EMV надежна.

Вдумайтесь, пожалуйста, вначале в первую фразу, а потом осознайте, pls, вторую.
Какая вообще связь с EMV? После того как "зловред" получил доступ, ему все равно по какому признаку "свой подошел к банкомату" опустошать кассеты. С таким же успехом можно было на любое событие отлеживать "свой".


Взяли событие "вставление чиповой карты с определенными данными". По видимому, что бы внешне (действия с банкоматом) не выглядело подозрительно. Причем здесь EMV вообще?

Потому что уязвимость скорее всего на уровне закрытого EMV kernel от одного из производителей с мировым именем — только им экономически под силу заниматься разработкой и сертификацией. Во-вторых, это ядро скорее всего крутится на отдельных защищённых устройствах, унифицированных с PoS терминалами. Соответственно, банкоматы — это лишь один из кейсов.

Это не первая уязвимость подобного рода и компании периодически выплачивают солидные вознаграждения black hat'ам за неразглашение.
Для того, чтобы задетектировать вставку карты и прочитать ее Track2, нет нужды в таких ухищрениях с EMV Kernel. Скорее всего, мошенники пошли по наипростейшему пути и просто проверяли магнитную полосу. Даже, если использовался и вправду чип, то, опять же, зловред мог просто посылать команды ридеру в обход EMV ядра, ибо проще. Для идентификации карты как своей этого достаточно.
Достаточно сомнительно, что в размеры треков на магнитной ленте можно записать полноценный зловред + ещё более сомнительно, что в примитивном парсере есть возможность сильно накосячить. А вот с уязвимостями в переполнении буфера не такого уж тривиального EMV уже были прецеденты. В оригинале статьи, ссылаются на заражение именно через EMV.

Прошу прощения, но RIPPER известная штука…
И речь идет именно о триггерном событие на выдачу наличных.
Какое еще заражение через EMV карту. О чем Вы..

Интерфейс библиотек (DLL) взаимодействия с диcпенсером, EPP клавиатурой и EMV kernel не является уж очень большим секретом (ну и не может быть секретом).
И не правильно говорить о том, что использование штатного программного интерфейса этих библиотек — это уязвимость


После того как "зловред" получил возможность запускаться под админ правами — он может все. Какие, в данном случае, уязвимости библиотек EMV? Они не занимаются авторизацией и управлением диспенсером.
Встроится и перехватить callback вызов на работу с EMV приложением (например со специально выделенным AID) как триггер на опустошение кассет..

Если речь идёт о RIPPER, который заражает цель заранее, то действительно особых вопросов к EMV нет, но случаи уязвимости самих EMV ядер были, хотя это и не афишировалось.

Т.е. потенциально через некоторое время и новые прибамбасы к 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?
Там нет ничего сложного… Вся документация открыта. Простейшее EMV приложение на Java или просто активация одного из стандартных EMV апплетов (на выбор… VSDC, MChip, CUP, Gemalto реализация CPA, "Мир" :) ) со своим набором данных.
Ну это как… ну как админу знать стек TCP протокола.

Only those users with full accounts are able to leave comments. Log in, please.