Уязвимость алгоритма хеширования в платформе MIGS
С появлением кредитных карт и Интернета совершение покупок стало намного проще и, как говорят, безопаснее. Всего пара кликов и нужный Вам товар уже на пути к Вашему дому. Однако не все системы идеальны, точнее таких нет. Всегда можно найти какую-то ошибку, брешь, позволяющую злоумышленникам делать свое черное дело. Сегодня я хотел бы обратить Ваше внимание на исследование очень талантливого программиста Yohanes Nugroho, рассказавшего об уязвимости в системе MIGS.
Данный текст является переводом слов самого исследователя уязвимости Yohanes Nugroho. Приятного ознакомления.
Уязвимость алгоритма хеширования в платформе MIGS
В прошлом году я обнаружил ошибку в алгоритме хеширования на базе MD5, который использовался MIGS (Mastercard Internet Gateway Service). Она позволяла вносить изменения в размер транзакции. Компания наградила меня за обнаружение этой проблемы. В этом же году, MIGS перешли на использование HMAC-SHA256, но и тут обошлось не без уязвимости.
Что есть MIGS?
Когда Вы платите на веб-сайте, его владельцы обычно подключают свою систему к промежуточному платежному шлюзу (происходит переход на другую страницу). Этот платежный шлюз далее подключается к нескольким платежным системам, доступным в конкретной стране. Для кредитных карт многие шлюзы подключаются к другим шлюзам (одним из которых и является MIGS), которые работают с многими банками для предоставления 3DSecure.
Как это работает?
Последовательность платежа, если Вы используете MIGS, обычно выглядит так:
- Вы выбираете товар на сайте.
- Вводите номер кредитной карты.
- Номер карты, размер платежа и другие параметры подписываются и возвращаются обратно в браузер, автоматически формирующий POST-запрос к промежуточному платежному шлюзу.
- Этот шлюз конвертирует информацию в формат, который поддерживается MIGS, подписывает с помощью MIGS-ключа и возвращает в браузер. После чего браузер формирует еще один POST-запрос к самому серверу MIGS.
- Если служба 3DSecure не задействована, то этот шах пропускается. В противном случае MIGS переводит запрос в банк, выпустивший карту. Банк запрашивает OTP и генерирует HTML, который формирует POST-запрос для сервера MIGS.
- MIGS возвращает подписанные данные в браузер и создает POST-запрос для промежуточного платежного шлюза.
- Проверка правильности данных и подписи промежуточным платежным шлюзом. Если данные неверны, то формируется страница с ошибкой.
- Основываясь на ответе MIGS, платежный шлюз передает статус платежа продавцу.
Уязвимость в алгоритме хеширования на базе MD5
Ошибка эта очень простая. В методе хеширования применяется такая формула:
MD5(Secret + Data)
Но уязвимости к удлинению хеша нет (для предотвращения этого были выполнены некоторые проверки). Данные (Data) формируются таким образом: все параметры запроса, которые начинаются на vpc_, сортируются, после чего значения связываются без разделений. Например, у нас есть такие данные:
Name: Joe
Amount: 10000
Card: 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
То значение MD5 будет тем же. То есть, по факту, когда данные передаются в MIGS, мы можем внести дополнительный параметр после размера платежа чтобы убрать последнюю цифру, или перед ним — чтобы убрать первую. И Вы сможете заплатить 2 доллара вместо 2000 за MacBook.
Промежуточные шлюзы и продавцы могут избежать этой уязвимости, всегда проверяя совпадают ли размер платежа, возвращенный MIGS, с тем что был затребован.
MasterCard вознаградила меня за выявление этой ошибки премией в размере $8500.
Уязвимость в хешировании HMAC-SHA256
Новая система HMAC-SHA256 имеет уязвимость, которую можно использовать, если мы внедрим неверные значения в промежуточный платежный шлюз. Я проверил наличие этой ошибки на одном из платежных шлюзов (Fusion Payments). Они выплатили мне 500 долларов премии за это. Эта уязвимость может воздействовать и на другие платежные шлюзы, подключенные к MIGS.
В новой версии были добавлены разделители (&) между полями, имена полей (не только значения) и, конечно же, HMAC-SHA256. Для тех же данных, что были ранее, хешированная строка выглядит так:
Vpc_Amount=10000&vpc_Card=1234567890123456&vpc_Name=Joe
Мы не можем ничего сдвинуть, все в этом плане в порядке. Но что если значение содержит символы & или = или какой-либо другой?
Прочитав документ «MiGS Virtual Payment Client Integration Reference», я обнаружил:
«Примечание: Значение во всех парах имя/значение, с целью хеширования, НЕ должны содержать URL символы»
Я акцентирую внимание на »НЕ». Это значит, если у нас такие поля:
Amount=100
Card=1234
CVV=555
Хеширование будет таким: HMAC (Amount=100&Card=1234&CVV=555)
А если поля будут такими (с применением & и =):
Amount=100&Card=1234
CVV=555
То хеширование выглядит так: HMAC (Amount=100&Card=1234&CVV=555)
Точно так же. Но пока не такая уж и проблема.
Конечно, я подумал, что может быть в официальной документации проблема, может URL символы все же должны быть использованы. Но я проверил поведение MIGS сервера, все было так, как в документе. Может они не хотят работать с другой кодировкой (типа + вместо %20).
Вроде никаких проблем быть не должно, неверные значения будут проверяться MIGS и выдавать ошибку (к примеру, неверный размер платежа будет отклонен).
Но я заметил, что в некоторые платежные шлюзы, вместо проверки введенных данных на стороне их сервера, просто все подписывают и перенаправляют в MIGS. Гораздо проще провести проверку JavaScript на стороне клиента, подписать данные на стороне сервера, а потом пусть MIGS решает правильный ли номер карты, должен ли CVV состоять из 3 или 4 цифр, правильный ли срок действия карты и т.д. Логика такова: 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
Заметьте:
Хеширование будет тем же, что и с предыдущими данными.
Клиент проигнорирует vpc_AccessCode и его значение.
Клиент обработает vpc_TxnResponseCode и т.д., предполагая что транзакция верна.
Можно сказать, что это ошибка MIGS клиента, но метод хеширования, используемый MasterCard, позволяет этой ошибке существовать. Если бы значения были закодированы, этой уязвимости не было бы.
Ответ от MIGS
MasterCard не отреагировала на этот баг в HMAC-SHA256. Я связался с несколькими людьми, с которыми общался ранее по поводу предыдущей уязвимости. Ответа нет. Даже отписки в стиле «мы проверяем это». У них есть и мой Facebook, если они захотят со мной связаться (со времен переписки по поводу MD5).
Некоторые видимо делают вид, что не видели моего отчета, но я поставил на письмо пароль. Было как минимум 3 просмотра с IP адреса MasterCard. При этом, это не случайные клики без прочтения, так как нужно осознанно ввести пароль. Я пишу им каждую неделю.
Моим ожиданием было, что они предупредят всех, кто соединяется с их системой, проверять и отфильтровывать внедренные данные.
Бреши в платежных шлюзах
В добавок хочу сказать: несмотря на то, что платежные шлюзы занимаются деньгами, они не так безопасны как кажется. В течение моих пентестов (тестов на проникновение), я обнаружил несколько уязвимостей в платежных протоколах в нескольких промежуточных шлюзах. К сожалению, я не могу рассказать детали (если я говорю «пентесты», то это что-то, подпадающее под соглашение о неразглашении).
Я также нашел ошибки в имплементации. К примеру, атаки удлинением хеширования, XML, ошибки верификации подписей, и т.д. Один из самых простых багов я нашел в Fusion Payments. Первым багом, что я нашел, был: они даже не проверяют подписи от MIGS. Это значит, что мы можем просто изменить данные возвращенные MIGS и пометить транзакцию, как успешную. Это означает всего лишь изменение одного символа: с F (неудачная) to 0 (удачная).
То есть, по сути, мы можем ввести любой номер карты, получить некорректный ответ от MIGS, изменить его, и вдруг платеж становится успешно проведенным. Это компания с бюджетом в 20 миллионов, а я получил от них 400 баксов. Это не единственный платежный шлюз с такой уязвимостью, во время своих пентестов я обнаруживал подобное и в других шлюзах. Несмотря на небольшое вознаграждение, Fusion Payments на данный момент единственный платежный шлюз, с которым я связывался, который очень четок в своей программе вознаграждений за найденные баги. Они очень быстро отвечали на мои сообщения и быстро исправляли свои баги.
Вывод
Платежные шлюзы не так безопасны, как Вы думаете. При столь низких вознаграждениях (а в некоторых случаях я получил 0 долларов), мне интересно, сколько людей уже воспользовались этими уязвимостями в платежных шлюзах.
Ремарка от переводчика
От себя хочу немного добавить пару слов к выводам автора исследования. Прежде всего это исследование является предупреждением и призывом к осторожности для продавцов, так как найденные уязвимости делают именно из них жертв злоумышленников. Но есть множество других багов, которые могут нести вред и покупателям (держателям карт, пользователям платежных систем, и т.д.). Будьте осторожны, вводя свои персональные платежные данные, на непроверенном сайте. А еще лучше имейте в своем распоряжении отдельную банковскую карту, на которой будет ровно та сумма, которая Вам нужна для проведения покупки в Интернете.
Сталкивались ли Вы с какими-то багами в платежных системах, или, быть может, Вы даже были жертвой таких багов? Делитесь своим опытом, мнением и советами как себя обезопасить в комментариях. Приятного дня и безопасных покупок.
На правах рекламы.Акция! Только сейчас получите до 4-х месяцев бесплатного пользования VPS (KVM) c выделенными накопителями в Нидерландах и США (конфигурации от VPS (KVM) — E5–2650v4 (6 Cores) / 10GB DDR4 / 240GB SSD или 4TB HDD / 1Gbps 10TB — $29 / месяц и выше, доступны варианты с RAID1 и RAID10), полноценным аналогом выделенных серверов, при заказе на срок 1–12 месяцев, условия акции здесь, cуществующие абоненты могут получить 2 месяца бонусом!
Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?
