“El Peor Incidente: El Pago Parece Normal, Pero el Dinero No Coincide”
Manipulación de API de Pagos, Tarifas y Puntos
“El sistema de pagos funciona correctamente… entonces, ¿por qué el dinero no coincide?”
El equipo de liquidación fue el primero en detectar una señal extraña.
El gráfico de ingresos claramente aumentaba, pero el importe realmente recibido era cada vez menor.
Al principio pensaron:
• ¿Un problema con las comisiones de tarjeta?
• ¿Un retraso en la liquidación del proveedor de pagos?
• ¿Un error contable interno?
Todo fue revisado, pero los registros del servidor y las aprobaciones de pago aparecían como “normales”.
Sin embargo, después de un mes, esa pequeña diferencia se había convertido en decenas de millones de wones.
Así comenzó el incidente de manipulación de API de pagos, tarifas y puntos.
¿Por Qué Este Incidente Es Tan Peligroso?
Existen muchos tipos de incidentes relacionados con pagos, pero este tipo es especialmente peligroso por una razón:
El servidor sigue creyendo que las solicitudes son normales hasta el final.
• La aprobación del pago parece correcta
• La respuesta de la API parece correcta
• No aparecen registros anómalos
Por eso la detección se retrasa.
Además, los atacantes:
• No roban grandes cantidades de una sola vez
• Extraen pequeñas cantidades durante mucho tiempo y en silencio
➡ Daño económico + máxima dificultad de detección
Por eso este tipo de ataque ocupa el TOP 2.
Escenario Real de Manipulación de API
La aplicación de estilo de vida utilizaba pagos con puntos y pagos dentro de la aplicación.
El flujo del ataque fue:
1. Intercepción de Red (Network Hooking)
o Interceptar tráfico API desde un entorno de aplicación modificada
2. Manipulación Detallada de Parámetros API
o Ajustar importes de pago y cantidades descontadas de puntos
3. Alteración de Descuento Después de la Aprobación
o El pago mediante la pasarela continúa siendo normal
o Solo cambia el importe real descontado al usuario
El usuario ve “Pago completado” y el servidor registra “Aprobado”.
Pero los números han sido modificados ligeramente durante el proceso.
¿Cuál Fue el Problema Principal de Seguridad?
La esencia del problema no estaba en la seguridad del servidor.
Estaba en la falta de confianza hacia el cliente.
Problemas Específicos
• Se permitían llamadas API desde aplicaciones modificadas y entornos con hooking
• Se confiaba directamente en los importes enviados por el cliente
• No era posible distinguir usuarios normales de usuarios manipulados
• No existían criterios para detectar ataques repetitivos de pequeño importe
En otras palabras:
La mayor vulnerabilidad fue asumir que “una solicitud API normal significa un usuario normal”.
¿Cómo Defendió LIAPP Este Ataque?
Después del incidente, el servicio revisó primero el entorno de ejecución de la aplicación antes de modificar la estructura de pagos.
LIAPP – Bloqueo de Entornos Modificados y Hooking
• Detección de hooking de red y uso de proxies
• Verificación de integridad de la aplicación (bloqueo de apps modificadas y reempaquetadas)
• Bloqueo ante manipulación de memoria o API hooking
• Detección de solicitudes automatizadas mediante scripts
• Bloqueo automático de usuarios sospechosos
Impide que los entornos manipulados llamen directamente a las APIs de pago.
Detecta ataques de “pequeñas cantidades repetidas” mediante datos de comportamiento.
Aunque exista una cuenta válida, un entorno sospechoso no puede mover dinero.
Cambios Después de Aplicar Seguridad
Después de implementar seguridad:
• Se eliminaron las discrepancias en importes de pago
• Disminuyeron los abusos de puntos
• Se redujeron riesgos de liquidación y auditoría
• Se redujo el tiempo de respuesta ante auditorías externas
El cambio más importante fue:
La idea de que “solo hay que proteger el servidor para proteger los pagos” desapareció completamente.
Lección Aprendida
Los incidentes de pago siempre comienzan con números pequeños.
• 100 wones
• 200 wones
• 500 wones
Pero si se ignoran, esos números pueden amenazar la confianza y la continuidad del negocio.
La esencia de la seguridad de pagos no es el importe.
Es la confiabilidad de la solicitud.
Esa confianza solo puede protegerse verificando:
• Si la aplicación es legítima
• Si el entorno es seguro
• Si existe una persona real utilizando el servicio
Las APIs de pago deben protegerse desde la aplicación, no únicamente desde el servidor.
#AppLifestyle #SeguridadPagos #ManipulacionAPI #AbusoPuntos #PagoInApp #IncidenteFinanciero #SeguridadMovil #SeguridadApps #RiesgoLiquidacion #RespuestaAuditoria #CasoSeguridad #AtaqueHooking #LIAPP #LISS #LIKEY
