Проблемы безопасности бесконтактных платежей

Контекст платформы

Создание информационных продуктов в банковской сфере всегда закладывает определенные ресурсы на разработку в контексте ИБ как всей системы в целом, так и отдельных ее компонентов. Работа мобильного платежного приложения подразумевает полноценную работу с персональными данными пользователя – счетами, балансами, паспортными данными, контактами.

Для успешной реализации проекта необходимо было следовать ряду поставленных требований, разработанных платежной системой Visa. Такими требованиями стали стандарты и спецификации проведения бесконтактных платежей, безопасности облачных платежных систем и банковских мобильных приложений, а также разработанный внутренний набор требований в контексте ИБ.

Специфика пользователя

Помимо особенностей финансовой сферы стоит учитывать тенденции пользователей. Количество пользователей мобильных банкингов и электронных кошельков ежегодно растет. Параллельно с ростом использования подобных приложений также растет количество атак и вирусов на мобильные платформы, нацеленных непосредственно на данные самих платежных приложений. Лидером по количеству их распространения на конец 2014 г. является Россия.

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

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

Специфика платформы

Технология HCE на данный момент поддерживается только операционной системой Android, в контексте этой системы далее и пойдет речь.

Типы уязвимостей под мобильные ОС уже выделяют в отдельный классификатор, один из них – OWASP Mobile Security Project TOP-10. Причинами появления описываемых в нем рисков могут быть:

• Стремительные изменения самой платформы (за последние три года – смена ядра, архитектуры, добавление большого количества функциональности в API), при этом очень многие устройства так и остаются на старых версиях ОС, а их популярность не так стремительно падает – почти половина устройств в мире еще работает на версии Android 4.3 (выпущена в середине 2013 г.) и ниже.
• Плохая поддержка со стороны производителей устройств, многие из них не выпускают даже критичные обновления безопасности для устройств, которым больше 1–2 лет.
• Специфика архитектуры безопасности платформы. В архитектуру iOS и Windows Phone изначально закладывали подход с изолированной средой для каждого приложения, когда приложение имеет доступ только до выделенных для него директорий, файлов, хранилищ. В Android такой принцип появился лишь с версии 5.0.
• Малое количество информации, исследований о защите приложений. Всего известно порядка 2000 уязвимостей под Android, большую часть запротоколировали лишь в 2014 г., но и до сегодняшнего дня находятся 0-day-уязвимости (Stage-fright). При этом в классификаторе CVE сейчас описано лишь 54 бюллетеня для ОС Android против 605 под iOS.
• Недостаточная осведомленность разработчиков приложений о безопасности мобильных систем ввиду частых изменений, многие аспекты устаревают, добавляются новые. Порядка 40% коммерческих организаций не уделяют внимание безопасности своих мобильных приложений, в том числе и банки.

Требования к мобильному приложению

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

Требование к приложению: приложение принудительно выбирает наиболее надежный протокол передачи данных, предоставляемый сервером. Это исключает потенциальные атаки с понижением версии протокола (прим. SSL3 POODLE).

Второе требование: приложение проверяет валидность серверного SSL-сертификата. Здесь был применен подход SSL-pinning – ассоциация сервера с его ожидаемым сертификатом. Приложение, зная адрес сервера, к которому обращается, также знает SSL-сертификат, с которым должен ответить сервер. Приложение игнорирует хранилище сертификатов устройства и доверяет только прописанному в нем самом источнику. Этот прием во многом помогает предотвратить возможность перехвата трафика (MitM-атаки), исключением будут вредоносные программы, отслеживающие и подменяющие сертификат локально на устройстве.

Хранение, шифрование и целостность данных
В классификаторе OWASP Mobile TOP-10 одна из самых распространенных уязвимостей – это небезопасное хранение т.н. чувствительных данных. Т.е. хранение их в ненадежных источниках, недостаточное или полное отсутствие шифрования, наличие приватной информации в ресурсах, файлах конфигурации, излишнее хранение данных. Для Android-устройств это может быть база данных SQLite, логи приложения, дамп памяти.

Задача состояла в разделении, типизировании и перемещении части информации из локального хранилища. Одним из решений является использование сессионного шифрования и хранение данных, когда аутентификационный токен является одноразовым и может работать лишь до конца пользовательской сессии. При этом шифрование и подпись данных происходит на основе выданных на эту сессию ключей. Это предотвращает возможность подмены хранимых данных платежных ключей в случае HCE.

Root, Debug, Emulation
Требование, препятствующее изменению и распространению ложного приложения, которое должно блокировать часть функциональности, ответственной за работу наиболее критичного к защите компонента – самой функции HCE. Основная особенность простоты выполнения бесконтактного платежа накладывает серьезные обязательства по предотвращению внесения изменений в исходные данные и коды.

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

Debug, Emulation. В целях разработчика закрытой информационной системы всегда была задача скрытия алгоритма программы. Затруднение реверс-инжиниринга может предотвратить возможность дальнейшего изменения системы. Для мобильных приложений это может выглядеть как препятствие запуска в недоверенной среде, эмулирующей работу устройства. Возможность просмотра и живой трассировки байт-кода может увеличить шансы взлома, поэтому приложение само должно максимально отслеживать режим своего запуска.

Контрольная сумма
В ОС Android для совершения успешной атаки на клиентское приложение иногда достаточно изменить манифест приложения, не влезая в детальную реализацию кода. Ложно запущенная Web-страница (WebView) может вести на фишинговые ресурсы.

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

Режим ожидания
Особенность бесконтактных платежей состоит в отсутствии лишних действий при совершении транзакции. Это как преимущество для user-experience, так и недостаток для безопасности пользователя. Известны случаи, когда злоумышленники ходили в общественном транспорте со считывающим модулем в руках, эмулирующим работу POS-терминала. Прислоняя его к карманам пассажиров, они считывали данные с PayWave-карт жертв и тем самым проводили платеж.

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