Уязвимость алгоритма хеширования в платформе MIGS 95 bingo dumps legit, best cc for miles
Эта уязвимость позволяет изменять размер транзакции. Компания Mastercard наградила меня премией за отчет о данной проблеме.
Автор: Yohanes Nugroho
В прошлом году я нашел ошибку в архитектуре метода хеширования, использующего алгоритм MD5 , в платформе MIGS (Mastercard Internet Gateway Service). Эта уязвимость позволяет изменять размер транзакции. Компания Mastercard наградила меня премией за отчет о данной проблеме. В этом году стала использоваться технология HMAC-SHA256, однако и здесь не обошлось без проблем, хотя от MasterCard до сих пор никакой реакции не последовало.
Если вы хотите знать, в чем суть проблемы, переходите к разделу с описанием уязвимости.
Что такое MIGS?
Кода вы совершаете платеж на веб-сайте, происходит подключение к промежуточному платежному шлюзу (вы будете перенаправлены на другой сайт). Затем этот платежный шлюз подключается к нескольким платежным системам, доступным в конкретной стране. При оплате кредитной картой, шлюзы будут подключаться к другому шлюзу (один из которых – MIGS), работающего со многими банками с целью предоставления службы 3DSecure .
Схема работы
Если вы используете платформу MIGS процедура платежа выглядит следующим образом:
Обратите внимание, что коммуникация происходит не напрямую между серверами, а через пользовательский браузер, хотя вся информация подписана. В теории, если процессы подписи и верификации корректны, все сложится успешно.
сожалению, так происходит не всегда.
Ошибка в алгоритме хеширования на базе MD5
Ошибка чрезвычайно проста. В методе хеширования используется следующая формула:
MD5(Secret + Data)
Этот алгоритм устойчив к атаке, связанной с удлинением хеша (hash length extension attack), поскольку вначале выполняются некоторые защитные проверки. Секция Data формируется следующим образом: все параметры запроса, начинающиеся с vpc_, вначале сортируются, а потом соединяются значения без использования разделителя. Например, у нас есть следующие данные:
Имя: Joe
Размер: 10000
Карта: 1234567890123456
vpc_Name=Joe&Vpc_Amount=10000&vpc_Card=1234567890123456
Сначала параметры сортируются:
vpc_Amount=10000
vpc_Card=1234567890123456
vpc_Name=Joe
Потом извлекаются и объединяются значения параметров:
100001234567890123456Joe
Если я изменю значения параметров:
vpc_Name=Joe&Vpc_Amount=1&vpc_Card=1234567890123456&vpc_B=0000
Произойдет сортировка:
vpc_Amount=1
vpc_B=0000
vpc_Card=1234567890123456
vpc_Name=Joe
А затем извлечение и объединение значений:
100001234567890123456Joe
В итоге имеем то же самое значение, используемое в формуле хеширования. Таким образом, когда данные отсылаются в MIGS, мы может добавить еще один параметр после размера транзакции, чтобы урезать последние цифры параметра vpc_Amount, или вначале, чтобы урезать первые цифры. В итоге, размер будет уменьшен, и вы можете заплатить 2 доллара за MacBook стоимостью 2000 долларов.
Промежуточные шлюзы и мерчант магазина могут без проблем работать и всегда проверять, что размер возвращаемый MIGS всегда совпадает с размером, который запрашивается.
За обнаружение этой уязвимости компания MasterCard наградила меня премией в размере 8500 долларов.
Ошибка в алгоритме хеширования на базе HMAC-SHA256
В HMAC-SHA256 также имеется уязвимость, которую можно использовать, если мы сможем инжектировать некорректные значения в промежуточный платежный шлюз. Во время тестирования выяснилось, что как минимум один платежный шлюз (Fusion Payments) имеет эту брешь. От Fusion Payments я получил вознаграждение в размере 500 долларов. Возможно, другие платежные шлюзы, подсоединенные к MIGS, также подвержены этой уязвимости.
В новой версии, вдобавок к HMAC-SHA256, при объединении значений добавлены разделители (&) между полями и имена полей. Для тех же самых параметров, которые использовались выше, объединенная строка выглядит так:
Vpc_Amount=10000&vpc_Card=1234567890123456&vpc_Name=Joe
Теперь мы не можем выполнить сдвиг как раньше, и, на первый взгляд, проблем нет. Но что если значение параметра содержит & или = или другой специальный символ?
В документации говорится следующее:
Примечание: Значения во всех парах имя/значения при хешировании не должны содержать символы, используемые при кодировании URL’а.
Вышеприведенная фраза означает, что если у нас есть следующие поля:
Amount=100
Card=1234
CVV=555
Алгоритмом хеширования будет обработана следующая строка: HMAC(Amount=100&Card=1234&CVV=555)
С другой стороны, если у нас есть такие поля (поле amount содержит символы & и =):
Amount=100&Card=1234
CVV=555
Алгоритмом хеширования будет обработана следующая строка: HMAC(Amount=100&Card=1234&CVV=555)
В итоге оба варианта идентичны, и на первый проблемы на наблюдается.
Естественно, я подумал, что возможно в документации ошибка, и при хешировании следует использовать кодировку. Однако после проверки выяснилось, что MIGS-сервер работает так, как описано в документации. Возможно, разработчики не захотели иметь дело с различными кодировками (например, + вместо %20).
На первый взгляд кажется, что проблемы отсутствуют. Любые некорректные символы проверяются на стороне MIGS-сервера и выдается ошибка (например, некорректный размер, указанный выше, не прокатит).
Однако я заметил, что в некоторых платежных шлюзах, вместо проверки входных параметров на стороне сервера, происходит просто подпись и отправка на MIGS-сервер. Намного проще выполнить проверку на стороне клиента при помощи JavaScript, подписать данные на стороне сервера и далее отправить информацию в MIGS, чтобы тот сервер уже проверял, корректен ли номер карты и дата истечения срока, сколько цифр должно быть в поле CVV и так далее. Логика строится на том, что MIGS-сервер повторно выполнит проверку и намного качественнее.
В шлюзе Fusion Payments обнаружилась именно такая ситуация: в поле CVV разрешались любые символы и любой длины (происходила только проверка на стороне клиента в JavaScript). Затем запрос подписывался и отправлялся в MIGS.
Эксплоит
Чтобы использовать эту уязвимость, мы должны сконструировать строку, которая будет представлять собой правильный запрос, а также правильный ответ MIGS-сервера. Нам не нужно контактировать с MIGS-сервером, поскольку на стороне клиента будет осуществляться подпись корректной информации.
Базовый запрос выглядит так:
vpc_AccessCode=9E33F6D7&vpc_Amount=25&vpc_Card=Visa&vpc_CardExp=1717&vpc_CardNum=4599777788889999&vpc_CardSecurityCode=999&vpc_OrderInfo=ORDERINFO&vpc_SecureHash=THEHASH&vpc_SecureHashType=SHA256
Базовый ответ сервера будет выглядеть так:
vpc_Message=Approved&vpc_OrderInfo=ORDERINFO&vpc_ReceiptNo=722819658213&vpc_TransactionNo=2000834062&vpc_TxnResponseCode=0&vpc_SecureHash=THEHASH&vpc_SecureHashType=SHA256
В случае с Fusion Payment эксплуатация осуществлялась посредством инжектирования в поле vpc_CardSecurityCode (CVV):
vpc_AccessCode=9E33F6D7&vpc_Amount=25&vpc_Card=Visa&vpc_CardExp=1717&vpc_CardNum=4599777788889999&vpc_CardSecurityCode=999%26vpc_Message%3DApproved%26vpc_OrderInfo%3DORDERINFO%26vpc_ReceiptNo%3D722819658213%26vpc_TransactionNo%3D2000834062%26vpc_TxnResponseCode%3D0%26vpc_Z%3Da&vpc_OrderInfo=ORDERINFO&vpc_SecureHash=THEHASH&vpc_SecureHashType=SHA256
Клиент/платежный шлюз будут генерировать корректный хеш для этой строки.
Теперь мы можем отправить эти данные обратно клиенту (без подключения к MIGS-серверу), но перед этим внесем небольшие изменения так, чтобы клиент считал корректные переменные (большинство клиентов будут проверять только параметры vpc_TxnResponseCode и vpc_TransactionNo):
vpc_AccessCode=9E33F6D7%26vpc_Amount%3D25%26vpc_Card%3DVisa%26vpc_CardExp%3D1717%26vpc_CardNum%3D4599777788889999%26vpc_CardSecurityCode%3D999&vpc_Message=Approved&vpc_OrderInfo=ORDERINFO&vpc_ReceiptNo=722819658213&vpc_TransactionNo=2000834062&vpc_TxnResponseCode=0&vpc_Z=a%26vpc_OrderInfo%3DORDERINFO&vpc_SecureHash=THEHASH&vpc_SecureHashType=SHA256
Теперь:
Можно сказать, что это ошибка MIGS-клиента, но алгоритм хеширования был выбран MasterCard. Если бы значения при хешировании были закодированы, этой уязвимости не было бы.
Ответ от MasterCard
От MasterCard я не получил ответа относительно бреши в алгоритме HMAC-SHA256. Я отправил письма нескольким людям, с которыми общался при обнаружении предыдущей уязвимости. Я даже не получил отписку в духе «мы проверяем информацию». У них также есть мой Facebook на случай, если представители компании захотят связаться со мной.
Некоторые сотрудники пытаются сделать вид, что не видели моего отчета. Вначале я защитил статью паролем, и с того момента было как минимум 3 просмотра с IP-адресов компании MasterCard (то есть как минимум 3 человека вводили пароль). Для прочтения отчета необходимо было ввести пароль в обязательном порядке, что исключает случайные клики без прочтения. Я отправлял письма еженедельно.
Предполагаю, что сотрудники MasterCard предупредили всех, кто подключен к системе MIGS для проверки и фильтрации инъекции.
Уязвимости в платежных шлюзах
В качестве дополнения хотелось бы отметить, что даже платежные шлюзы не настолько безопасны, как вы думаете. Во время моих пентестов, я обнаружил несколько уязвимостей в архитектуре протокола обработки платежей в нескольких промежуточных шлюзах. К сожалению, я не могу рассказывать о деталях (когда я упоминаю слово «пентест», имею ввиду нечто, что подпадает под соглашение о неразглашении информации).
Кроме того, я нашел несколько уязвимостей в реализации шлюзов. Например, связанные с удлинением хеша, или ошибки при проверке XML-сигнатуры. Одна из простейших уязвимостей была найдена в Fusion Payments . Самая первая роблема заключалась в отсутствии проверки сигнатуры от MIGS. В этом случае мы можем изменять данные, возвращаемые MIGS-сервером, и помечать транзакцию как успешную. В последнем случае нужно поменять символ F, связанный с неудачной транзакций, на 0, связанный с успешной транзакцией.
То есть мы можем ввести любой номер кредитной карты, получить ответ об ошибке от MIGS, изменить этот ответ, и платеж окажется успешным. За найденную уязвимость я получил 400 долларов от компании стоимостью в 20 миллионов долларов . Это не первый платежный шлюз с такой брешью. Во время пентестов я нашел в точности такую же проблему в другом платежном шлюзе. Несмотря на относительно небольшое вознаграждение, на данный момент Fusion Payments – единственный платежный шлюз, с которым я контактировал и у которого самые прозрачные и честные условия относительно программы вознаграждения. Представители компании быстро отвечали на мои письма и оперативно исправляли уязвимости.
Заключение
Платежные шлюзы не настолько безопасны, как может показаться на первый взгляд. При относительно небольшом вознаграждении за найденные уязвимости (в некоторых случаях я не получал вообще ничего) у меня возникает закономерный вопрос: сколько людей уже воспользовались найденными уязвимостями.
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
bingo dumps legit best cc for miles