Con la llegada de las tarjetas de crédito e Internet, comprar se ha vuelto mucho más fácil y, como dicen, más seguro. Solo un par de clics y el producto que necesita ya está en camino a su hogar. Sin embargo, no todos los sistemas son ideales, o más bien no hay ninguno. Siempre puedes encontrar algún tipo de error, una brecha que permite a los atacantes hacer su acto sucio. Hoy me gustaría llamar su atención sobre el estudio de un programador muy talentoso, Yohanes Nugroho, quien habló sobre las vulnerabilidades en el sistema MIGS.
Este texto es una traducción de las palabras del propio investigador de vulnerabilidades Yohanes Nugroho. Que la pases bien.
Vulnerabilidad del algoritmo hash MIGSEl año pasado, descubrí un error en el algoritmo hash basado en MD5 utilizado por MIGS (Mastercard Internet Gateway Service). Le permitió realizar cambios en el tamaño de la transacción. La compañía me recompensó por descubrir este problema. En el mismo año, MIGS cambió a usar el HMAC-SHA256, pero hubo algunas vulnerabilidades.
¿Qué es MIGS?Cuando paga en un sitio web, sus propietarios generalmente conectan su sistema a una pasarela de pago intermedia (hay una transición a otra página). Esta pasarela de pago se conecta a varios sistemas de pago disponibles en un país en particular. Para las tarjetas de crédito, muchas puertas de enlace se conectan a otras puertas de enlace (una de las cuales es MIGS), que trabajan con muchos bancos para proporcionar 3DSecure.
Como funcionaLa secuencia de pago, si usa MIGS, generalmente se ve así:
- Selecciona un producto en el sitio.
- Ingrese su número de tarjeta de crédito.
- El número de tarjeta, el tamaño de pago y otros parámetros se firman y se devuelven al navegador, lo que genera automáticamente una solicitud POST a la pasarela de pago intermedia.
- Esta puerta de enlace convierte la información en un formato compatible con MIGS, firma con una clave MIGS y la devuelve al navegador. Después de lo cual el navegador genera otra solicitud POST al servidor MIGS.
- Si 3DSecure no está habilitado, este paso se omite. De lo contrario, MIGS transfiere la solicitud al banco que emitió la tarjeta. El banco solicita OTP y genera HTML, que genera una solicitud POST para el servidor MIGS.
- MIGS devuelve los datos firmados al navegador y crea una solicitud POST para la pasarela de pago intermedia.
- Validación de datos y firma por una pasarela de pago intermedia. Si los datos son incorrectos, se genera una página de error.
- Según la respuesta de MIGS, la pasarela de pago transmite el estado del pago al vendedor.
Vulnerabilidad en el algoritmo de hash MD5Este error es muy simple. El método hash usa la siguiente fórmula:
MD5 (Secreto + Datos)Pero no hay vulnerabilidad a la extensión hash (se realizaron algunas comprobaciones para evitar esto). Los datos se forman de esta manera: todos los parámetros de solicitud que comienzan con vpc_ se ordenan, después de lo cual los valores se conectan sin separación. Por ejemplo, tenemos los siguientes datos:
Nombre: Joe
Monto: 10000
Tarjeta: 1234567890123456
vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456
Aplicar clasificación:
vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe
Conectamos los valores:
100001234567890123456Joe
Observe si cambio los parámetros:
vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000
Aplicar clasificación:
vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe
Conectamos los valores:
100001234567890123456Joe
Ese valor MD5 será el mismo. Es decir, de hecho, cuando los datos se transfieren a MIGS, podemos agregar un parámetro adicional después del tamaño del pago para eliminar el último dígito o antes de eliminar el primero. Y puede pagar $ 2 en lugar de 2000 por una MacBook.
Las puertas de enlace intermedias y los comerciantes pueden evitar esta vulnerabilidad al verificar siempre si el monto del pago devuelto por MIGS coincide con lo solicitado.
MasterCard me recompensó por identificar este error con una prima de $ 8500.
Vulnerabilidad de Hash HMAC-SHA256El nuevo HMAC-SHA256 tiene una vulnerabilidad que podría explotarse si inyectamos valores incorrectos en la pasarela de pago intermedia. Verifiqué este error en una de las pasarelas de pago (Fusion Payments). Me pagaron un bono de $ 500 por esto. Esta vulnerabilidad también podría afectar otras pasarelas de pago conectadas a MIGS.
En la nueva versión, se agregaron delimitadores (&) entre campos, nombres de campo (no solo valores) y, por supuesto, HMAC-SHA256. Para los mismos datos que antes, la línea hash se ve así:
Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe
No podemos mover nada; todo en este plan está en orden. Pero, ¿qué pasa si el valor contiene los caracteres & o = o algún otro?
Después de leer el documento MiGS Virtual Payment Client Integration Reference Reference, encontré:
"Nota: El valor en todos los pares de nombre / valor, para el hash, NO debe contener caracteres URL"Me concentro en
NO . Esto significa que si tenemos los siguientes campos:
Cantidad = 100
Carta = 1234
CVV = 555
El hashing será así: HMAC (Cantidad = 100 y Tarjeta = 1234 y CVV = 555)
Y si los campos son así (usando & y =):
Cantidad = 100 y tarjeta = 1234
CVV = 555
Ese hash se ve así: HMAC (Cantidad = 100 y Tarjeta = 1234 y CVV = 555)
De la misma manera. Pero hasta ahora, no es un problema.
Por supuesto, pensé que podría haber un problema en la documentación oficial, tal vez aún deberían usarse los caracteres de URL. Pero verifiqué el comportamiento del servidor MIGS, todo estaba como en el documento. Tal vez no quieran trabajar con una codificación diferente (como + en lugar de% 20).
Parece que no debería haber ningún problema, MIGS verificará los valores incorrectos y dará un error (por ejemplo, se rechazará el tamaño de pago incorrecto).
Pero noté que en algunas pasarelas de pago, en lugar de verificar los datos ingresados en el lado del servidor, simplemente firman y redirigen todo a MIGS. Es mucho más fácil probar JavaScript en el lado del cliente, firmar los datos en el lado del servidor y luego dejar que MIGS decida si el número de tarjeta es correcto, si CVV debe constar de 3 o 4 dígitos, si la tarjeta caduca correctamente, etc. La lógica es esta: MIGS verificará dos veces los datos y los mejorará.
En Fusion Payments, descubrí que esto es lo que sucede: le permiten ingresar cualquier longitud de código CVV (la verificación se realiza solo en JavaScript), luego firmar la solicitud y enviarla a MIGS.
ExplotarPara aprovechar esta vulnerabilidad, necesitamos crear una cadena que será la solicitud correcta y obtener la respuesta correcta del servidor MIGS. No necesitamos comunicarnos con el servidor MIGS, solo hacemos que el cliente firme los datos correctos.
Solicitud básica:
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999 & vpc_OrderInfo = vdchecurefurecure
Y la respuesta básica del servidor será así:
vpc_Message = Aprobado & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_Secure25Shecpe25
En el caso de Fusion Payment, el exploit se implementa implementando vpc_CardSecurityCode (CVV)
vpc_AccessCode = 9E33F6D7 y vpc_Amount = 25 y vpc_Card = Visa y vpc_CardExp = 1,717 y vpc_CardNum = 4599777788889999 y vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3Da y vpc_OrderInfo = Información de Pedido y vpc_SecureHash = THEHASH y vpc_SecureHashType = SHA256
El cliente / pasarela de pago genera el hash correcto para esta línea.
Ahora podemos ingresar estos datos en el propio cliente (sin interactuar con el servidor MIGS de ninguna manera), pero los cambiaremos un poco para que el cliente reconozca las variables necesarias (la mayoría de los clientes solo verifican vpc_TxnResponseCode y vpc_TransactionNo):
vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 y vpc_Message = Aprobado y vpc_OrderInfo = de Pedido y vpc_ReceiptNo = 722819658213 y vpc_TransactionNo = 2000834062 y vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO y vpc_SecureHash = THEHASH y vpc_SecureHashType = SHA256
Nota:
El hash será el mismo que con los datos anteriores.
El cliente ignorará vpc_AccessCode y su valor.
El cliente manejará vpc_TxnResponseCode, etc., suponiendo que la transacción sea correcta.
Se puede decir que este es un error del cliente MIGS, pero el método hash utilizado por MasterCard permite que exista este error. Si los valores se codificaran, esta vulnerabilidad no existiría.
Respuesta de MIGSMasterCard no respondió a este error en el HMAC-SHA256. Me puse en contacto con varias personas con las que había contactado anteriormente sobre una vulnerabilidad anterior. No hay respuesta Incluso darse de baja en el estilo de "lo probamos". Tienen mi Facebook si quieren contactarme (desde la correspondencia sobre MD5).
Aparentemente, algunos fingen que no vieron mi informe, pero puse una contraseña en la carta. Hubo al menos 3 vistas desde la dirección IP de MasterCard. Al mismo tiempo, estos no son clics aleatorios sin leer, ya que debe ingresar conscientemente la contraseña. Les escribo todas las semanas.
Mi expectativa era que advertirían a todos los que se conectan a su sistema para verificar y filtrar los datos incrustados.
Brechas en las pasarelas de pagoAdemás, quiero decir: a pesar del hecho de que las pasarelas de pago manejan dinero, no son tan seguras como parece. Durante mis pentests (pruebas de penetración), descubrí varias vulnerabilidades en los protocolos de pago en varias pasarelas intermedias. Desafortunadamente, no puedo decir los detalles (si digo "pentest", entonces esto es algo que cae dentro del acuerdo de confidencialidad).
También encontré errores de implementación. Por ejemplo, ataques de extensión hash, XML, errores de verificación de firma, etc. Uno de los errores más fáciles que encontré en Fusion Payments. El primer error que encontré fue: ni siquiera verifican las firmas de MIGS. Esto significa que simplemente podemos modificar los datos devueltos por MIGS y marcar la transacción como exitosa. Esto solo significa cambiar un carácter: de F (sin éxito) a 0 (exitoso).
Es decir, de hecho, podemos ingresar cualquier número de tarjeta, recibir una respuesta incorrecta de MIGS, cambiarla y, de repente, el pago se vuelve exitoso. Esta es una empresa con un presupuesto de 20 millones, y recibí 400 dólares de ellos. Esta no es la única pasarela de pago con tal vulnerabilidad, durante mi pentest encontré esto en otras pasarelas. A pesar de la pequeña recompensa, Fusion Payments es actualmente la única pasarela de pago con la que contacté, lo cual es muy claro en su programa de recompensa por errores encontrados. Respondieron muy rápidamente a mis mensajes y rápidamente corrigieron sus errores.
ConclusiónLas pasarelas de pago no son tan seguras como crees. Con recompensas tan bajas (y en algunos casos recibí $ 0), me pregunto cuántas personas ya han explotado estas vulnerabilidades en las pasarelas de pago.
Comentario del traductorPor mi parte, quiero agregar algunas palabras a las conclusiones del autor del estudio. En primer lugar, este estudio es una advertencia y una llamada de precaución para los vendedores, ya que las vulnerabilidades encontradas los convierten en víctimas de intrusos. Pero hay muchos otros errores que pueden ser perjudiciales para los clientes (titulares de tarjetas, usuarios de sistemas de pago, etc.). Tenga cuidado al ingresar su información de facturación personal en un sitio no verificado. Mejor aún, tenga a su disposición una tarjeta bancaria separada, en la que habrá exactamente la cantidad que necesita para realizar una compra en Internet.
¿Ha encontrado algún error en los sistemas de pago, o tal vez fue víctima de esos errores? Comparta sus experiencias, opiniones y consejos sobre cómo protegerse en los comentarios. Que tengas un buen día y compras seguras.
Como un anuncio publicitario. Promoción! Solo ahora obtenga
hasta 4 meses de uso gratuito de VPS (KVM) con unidades dedicadas en los Países Bajos y los EE . UU. (Configuraciones de VPS (KVM) - E5-2650v4 (6 núcleos) / 10GB DDR4 / 240GB SSD o 4TB HDD / 1Gbps 10TB - $ 29 / mes y superior, las opciones con RAID1 y RAID10 están disponibles) , un análogo completo de servidores dedicados, cuando se ordena por un período de 1-12 meses, los
términos de la acción están aquí, ¡ los suscriptores existentes pueden obtener 2 meses como bonificación!
Cómo construir la infraestructura del edificio. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?