Exposición de claves de Stripe pone en riesgo los datos de 688.363 clientes

Los investigadores indicaron que encontraron 650 claves secretas activas sk_live y nueve claves restringidas. Del conjunto de cuentas afectadas, 573 podían aceptar pagos, 531 podían realizar transferencias de fondos y 519 podían hacer ambas cosas, según el análisis citado.

Por qué una sola clave activa podía ser peligrosa

Una clave secreta de Stripe es una credencial para acceder a la API, no un simple identificador. Su alcance depende de los permisos asignados y de la configuración de la cuenta, pero una clave comprometida puede exponer recursos del comercio y permitir operaciones de pago no autorizadas.

Las pruebas descritas en los informes mostraron que una clave activa podía utilizarse para consultar listas de clientes, crear enlaces de pago fraudulentos y realizar cargos de prueba. Entre las posibles consecuencias se encuentran la enumeración de datos de clientes, el abuso de los sistemas de pago, los reembolsos no autorizados, el phishing dirigido y las campañas de ingeniería social relacionadas con pagos. Las cuentas con capacidad para realizar transferencias también debían comprobar de inmediato sus destinos y parámetros de pago.

El riesgo más inmediato es la velocidad. Una credencial del lado del servidor expuesta puede convertir un fallo de gestión de secretos en una investigación de fraude antes de que el comercio detecte actividad anómala.

Por qué los investigadores no lo clasificaron como una brecha de Stripe

La evidencia disponible sugiere que los atacantes utilizaron credenciales válidas de los comercios para extraer datos mediante el acceso legítimo a la API de Stripe. Al examinar los ficheros sin conexión, los investigadores observaron que los objetos con formato de Stripe y la estructura de directorios eran compatibles con exportaciones obtenidas a través de sus endpoints API. Como parte de esa revisión, no se autenticaron con las claves expuestas ni accedieron a los entornos activos de los comercios.

La diferencia es importante: el posible fallo de control estaría en los lugares donde los comercios almacenan o dejan expuestos sus secretos, no necesariamente en los sistemas centrales de Stripe. Entre las vías plausibles se encuentran:

• Infecciones por malware ladrón de información en dispositivos de desarrolladores o administradores.
• Repositorios públicos y el historial de Git.
• Archivos .env y configuraciones de servidores expuestos.
• Almacenamiento en la nube, copias de seguridad y capas de contenedores.
• Sistemas CI/CD y registros de GitHub Actions.
• Servidores mal configurados o escaneos automatizados en busca de variables expuestas.

Aún no se ha establecido cómo fueron robadas inicialmente las credenciales de los 659 comercios. Estas son rutas de exposición plausibles, no un origen único confirmado para todo el conjunto de datos.

La publicación relacionada y la cautela con las cifras

Hudson Rock vinculó otra publicación en un foro con el mismo actor. Ese lanzamiento habría incluido 669 carpetas de proveedores y 1.033 claves API comprometidas, con un tamaño anunciado de 33 GB, aunque el archivo disponible para descargar era supuestamente más pequeño. El actor también afirmó disponer de unas 20.000 claves API de Stripe comprometidas y sugirió que podrían publicarse más lotes.

Estas cifras no deben sumarse como si formaran un total verificado. Las diferencias entre 659 cuentas comerciales, 669 carpetas de proveedores y 1.033 claves pueden explicarse por conjuntos de datos distintos, varias claves asociadas a una misma cuenta, duplicados o métodos de recuento diferentes. La cifra de 20.000 claves sigue siendo una afirmación no verificada del actor.

Países con más comercios afectados

La distribución geográfica destacada en los informes disponibles fue la siguiente:

• Estados Unidos: 212 comercios.
• Reino Unido: 81.
• Francia: 57.
• Canadá: 38.
• Brasil: 30.
• Australia: 27.

Estos números describen la distribución comunicada de los comercios y deben interpretarse junto con la advertencia de que el alcance total del conjunto todavía estaba siendo evaluado.

Qué deben hacer ahora las empresas que usan Stripe

1. Revocar y renovar las claves secretas activas

Revoca y sustituye cualquier clave activa que pueda haber aparecido en código fuente, registros, copias de seguridad, telemetría de endpoints, imágenes de contenedores o infraestructura pública. No esperes a detectar fraude para renovar una credencial potencialmente expuesta.

2. Auditar la actividad de la API y las operaciones de pago

Revisa los registros de API y de seguridad en busca de llamadas desconocidas, nuevos enlaces de pago, cargos de prueba o no autorizados, reembolsos inesperados, cambios de permisos y direcciones IP inusuales. Conserva los registros relevantes para poder reconstruir la cronología del incidente.

3. Verificar la configuración de transferencias

Comprueba la configuración de pagos a la cuenta bancaria, los datos de las cuentas conectadas y los destinos de las transferencias. Comunica rápidamente cualquier cambio sospechoso a Stripe y a las entidades financieras, siguiendo los procedimientos de respuesta y notificación aplicables.

4. Sustituir las credenciales amplias por claves restringidas

Utiliza claves restringidas al menor conjunto de operaciones API que necesite cada servicio. Separa los sistemas de producción, los entornos de desarrollo y las funciones operativas, en lugar de repartir una única credencial con permisos amplios entre varias aplicaciones.

5. Buscar secretos en todos los lugares donde pueden persistir

Revisa los repositorios actuales e históricos, el historial de Git, las salidas de CI/CD, los registros de GitHub Actions, los archivos .env, las capas de contenedores, el almacenamiento en la nube, la documentación y las copias de seguridad en busca de valores sk_live. Toda credencial localizada debe revocarse y sustituirse, aunque ya no aparezca en la versión actual del código.

6. Considerar el análisis de GitHub como una capa, no como una solución completa

GitHub indica que el análisis de secretos se ejecuta automáticamente en los repositorios públicos, mientras que los repositorios privados e internos propiedad de organizaciones requieren GitHub Secret Protection en los planes que cumplen los requisitos. Esta función tampoco puede recuperar secretos que ya se hayan copiado en registros, copias de seguridad, telemetría de endpoints o archivos descargados. Debe complementar, no sustituir, una gestión centralizada de secretos, credenciales de corta duración, controles de acceso y monitorización continua.

La lección principal para los comercios

La conclusión más clara es que la seguridad de una plataforma de pagos también depende de la gestión que cada comercio haga de sus credenciales. Los informes disponibles no demuestran una brecha de la infraestructura de Stripe, pero sí muestran cómo una clave API activa expuesta puede abrir la puerta al acceso a datos de clientes y al abuso de los pagos. Las claves de producción deben tratarse como credenciales de alto impacto: nunca deben quedar en el código ni en los registros, deben tener permisos limitados, renovarse con rapidez y activar una investigación ante cualquier actividad inesperada de la API o de las transferencias.