Pull to refresh

Comments 28

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

Во всяком случае так работали те читалки карточек что использовал я.
>Авторы данной атаки были не очень осторожны. Т.к. сервер не был сконфигурирован правильно, PandaLabs смога получить доступ к нему без регистрационных данных.

Ребята в целях безопасности шифруют с помощью AES трафик, перед отправкой его на сервер, но сам сервер сконфигурирован так криво, что
PandaLabs смог получить к нему доступ без регистрационных данных. Что-то тут не сходится.

А Вы, что же, ждали, что PandaLabs публично объявит "мы нарушили закон и хакнули чужой сервак"? Конечно же, они ничего не ломали, сервер стоял совершенно открытый для всех желающих, а они просто случайно мимо проходили.

Можно было просто сообщить, что PandaLabs удалось получить доступ к серверу. Без нелепого уточнения о том что сервак кривой или одного из хулиганов замучила совесть, он связался с PandaLabs и предоставил доступ. Кому нужно, тот отправит официальный запрос о правомерности доступа, и то, только после заявления от пострадавшей стороны.
Это не нелепость, это юридический хак.
Вероятно, это связано с тем, что в США и Европе (в отличие от России) очень редко используются «чипованные» карты, основная масса банковских карточек там — простые, с магнитной полосой. С ходу ссылку не нашел, но на сколько помню, буквально несколько месяцев назад, видимо на фоне вот таких новостей, власти США решили все таки надавить на банки и начать массовый переход на «чипованные» карты.

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

Некоторые российские банки (а возможно и в других странах) уже блокируют операции, которые совершаются не «по чипу», а по магнитной полосе. В частности лично сталкивался с такой ситуацией у МКБ (Московский Кредитный Банк). Накрылся чип и я пытался купить через терминал билеты по магнитной полосе. Получил отказ. В поддержке мне сказали, что по магнитной полосе они блокируют операции.
Про Европу вы, кхм, не совсем правы
https://www.emvco.com/about_emvco.aspx?id=202
Насколько я знаю, операции по магнитной полосе блокируются, если терминал поддерживает чиповые карты. То есть, если бы это был терминал без поддержи чиповых карт, то платёж по магнитной полосе прошёл бы.
Неа. Возможность использования магнитной полосы зависит сразу от всех составляющих системы — терминала, карты, банка. И угадать сработает она или нет заранее не так просто. У меня тут недавно на заправке оплату сделали по магнитной полосе. Я слегка офигел, так как был уверен что она давно уже не работает (еще лет 5-6 назад кассиры всегда сперва пытались использовать полосу, обламывались и потом втыкали чипом).
Тут необходимо уточнять модель терминала.

Не могу говорить за все банки но на примере ПриватБанк-а могу подтвердить слова ColdSUN — если терминал без поддержки чипа то платежи по полосе проходят (но такие терминалы уже большая редкость), в командировке на такой нарвался, всё прошло но с обязательной подписью клиента (на чеке так и выбилось ~«необходима подпись клиента „)
После своего печального опыта создал инициативу на РОИ:
www.roi.ru/22799
Я написал статью по практике использования чипа/магнитной полосы в банкоматах, но её отказались публиковать на geektimes, т.к. там много слов про взаимоотношения с банком. Если интересно, могу дать ссылку на ЖЖ.
http://201603.livejournal.com/
Инициатива на РОИ ещё доступна, не факт, что получится набрать 100'000 голосов, но попробовать стоит. Я очень сильно переосмыслил взаимоотношения с банками после произошедшего и после общения со следователем.
Вообще-то новость желтухой попахивает.

На картинке терминал для приема карточек. Это Ingenico IPP320. В него никакой сторонний софт просто не может быть загружен.

По тексту статьи становиться понятно, что речь идет о ПО, которое реализует кассовый функционал — компьютерная касса. Так это обычный компьютер, с обычными проблемами. И если ПО старое, а судя по всему именно так и есть, то вопросам безопасности внимания никто не уделял.

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


Ойданупрям. У него точно так же есть прошивка, там внутри обычный MIPS или ARM (а зачастую еще и Windows CE), она отлично реверсится и точно так же отлично обновляется. Насколько я помню Ingenico — там еще и USB-порт есть (правда, mini A, так что будет нужен кабель) и обновление вообще делается с подключенной USB-флешки, занимает эдак минуты полторы. То есть приходишь в магазин с сообщником, один банально отвлекает не очень продвинутого продавца вопросами, а другой в это время быстренько втыкаешь флешку и перепрошивает.

Прошивки подписывать стали сравнительно недавно, года 3-4 назад. До этого вообще — приходи кто хочешь и шей что хочешь.
Ну там задача посложнее чем «воткнул флешку с трояном в комп с виндой и сделал пару кликов мышью». Чтобы перепрошить, нужно сначала спереть оригинальную версию прошивки и модифицировать её. Если же залить фиг знает что, то платежи отвалятся, и всё раскроется при визите сервисменов из банка. Ну или не раскроется, если сервисники решат, что это клиенты кривыми руками там что-то пытались сделать, но всё равно профит минимальный получится.

Для дропов — нет, не сильно сложнее. Я бы даже сказал с десктопом куда палевнее.


Я конкретно Ingenico не программировал вообще никогда, только со стороны видел, но, например, Verifone доводилось видеть изнутри. Там вполне можно не обновлять прошивку целиком, а добавлять и удалять "приложения". Банки, собственно, там никогда и не делают собственную полную прошивку — а загружают такие кусочки — даже не с кодом, а с настройками типа APN для SIM-карты, координат гейтов, приветственных картинок или шаблонов для чеков. Можно делать хитрее и загружать именно выполняемый код, тогда в норме он выполняется в некоей защищенной среде, но я вполне допускаю, что у этой защищенной среды рано или поздно найдутся возможности jail escape. Аудит там никакой, никаких bug bounty и т.д. в помине нет. Древнющие версии libpng, libjpeg и т.п. со всеми мыслимыми уязвимостями в наличии.


Цена вопроса — либо представиться организацией внедрения POS и купить этот SDK у производителя, либо, что еще проще — спереть его в одной из таких организаций, устроившись на работу.

Про Verifone ничего не скажу, потому что не знаком.

А вот в Ingenico как минимум с 2008 года (точно раньше, но не скажу насколько) использует цифровую подпись каждой исполняемой компоненты, которая загружается в терминал.
Процедура подписывания сложна до безобразия — украсть компоненты на работе и подписывать дома не получиться.

Вариант с покупкой SDK — ну это идея. Вот только загрузить ПО можно будет только в свои терминалы, которые будут соответствовать своей же цифровой подписи. И со сторонними терминалами, опять же, ничего сделать не получиться.

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

Это залог безопасности!

Правильно ли я понял, чтобы инфицировать терминал, хозяин этого терминала должен сознательно прошить его сам?

Если коротко: да.

Вопрос кто является хозяином терминала? Как правило это банк, но банк не пишет софт сам (за редким исключением).

Банк гарантирует что софт написан доверенными людьми.

Я не понял — вопрос это или утверждение… но попробую ответить.

Банк заинтересован в том, чтобы таких случаев утечки данных не происходило. Тут уже упоминали про PA-DSS, есть еще и PCI-DSS, который банки проходят с определенной периодичностью. В ходе этой сертификации, специальными людьми проверяется ВСЁ, что связано с приёмом и обработкой карточек (да и не только).

Так вот, если происходит утечка данных, то PCI присылает «зондер-команду» для разбора ситуации. И такая команда будет стоить банку ОЧЕНЬ дорого во всех смыслах.

В результате:
— Поставщик ПО кровно заинтересован обеспечить безопасность данных карточки, иначе ему отвечать перед банком. О том что поставщик об этом заботиться свидетельствует наличие сертификата PA-DSS.
— Банк кровно заинтересован обеспечить безопасность данных карточки, потому что для него такие утечки представляют огромные риски (финансовые и репутационные).

И получается, что контроль тут очень серьезный.
Почему то мне кажется, что программировали данный ботнет вполне себе успешные инженеры если бы не… экономический коллапс, который часть изначально приличных людей заставляет заниматься…
не клеится статья уже с того момента, что заявляют о получении данных магнитной полосы карты. С 2004го года на разных типах терминалов с разными банками, версиями и тд — ни разу не встречал ситуации, что бы терминал выдавал в порт номер кредитки или еще какую либо полную информацию. Все что он выплевывает в лучшем случае 4 цифры с номера карты, код завершения операции и все! Остальная обработка выполняется только внутри терминала или в процессинговом центре. Мы заказывали специализированную прошивку для выдачи полного номера с карты, но эту доработку выполняли сами банки. И выдача шла только в том случае, если карта была «серая». Т.е. не являлась платежной (определяется по префиксу первые 4 знака). Делалось это для того, что бы через терминал можно было считывать дисконтные карты выполненные по стандарту платежных.
Есть такая штука — PA DSS, которая запрещает разработчикам ПО даже просто хранить на терминале полный PAN в открытом виде, а уж выдавать наружу и подавно.
Only those users with full accounts are able to leave comments. Log in, please.