El incidente de Binance de 6.300 millones de dólares: qué pasó y cómo reducir el riesgo

Las conclusiones preliminares de Binance describen compromisos de equipos de empleados en junio y septiembre, seguidos de una intrusión más amplia a través de herramientas internas de IA el 20 de octubre. Los atacantes accedieron a los ordenadores de dos compañeros y encontraron un token para desplegar contenedores. El 29 de octubre lo utilizaron para desplegar código malicioso que alcanzó los sistemas de firma de monederos e inició transferencias no autorizadas.

Los atacantes también utilizaron el servicio de firma para crear una delegación EIP-7702: un permiso que permite a código controlado por los atacantes actuar en nombre de un monedero de Ethereum. Ese permiso existía en la cadena de bloques, con independencia de los sistemas de retirada de Binance. Detener las retiradas no podía eliminarlo. Binance necesitaba revocarlo por separado en la cadena.

La distinción importante es entre detener una actividad y eliminar la autoridad que la permite. Sustituir un dispositivo, revocar una credencial de despliegue y cancelar un permiso dentro de otro sistema abordan partes distintas de una intrusión.

Un portátil, un sistema de despliegue y un servicio sensible cumplen funciones distintas. El riesgo crece cuando el acceso a uno abre automáticamente el siguiente. Un token robado puede permitir a un atacante sustituir software. Ese software puede actuar después con permisos que el empleado nunca tuvo directamente.

Cuatro preguntas ayudan a identificar dónde interrumpir esa progresión:

1. Exposición de credenciales. ¿Qué acceso a producción puede obtener un atacante desde el dispositivo de un empleado?
2. Privilegios de despliegue. ¿Quién puede modificar el código que se ejecuta con ese acceso?
3. Autorización del servicio. ¿Qué acciones aceptará un servicio sensible de ese código?
4. Acceso persistente. ¿Qué permisos nuevos podrían permanecer después de deshabilitar la cuenta original?

El objetivo es limitar cómo se transmite la autoridad entre sistemas e identificar y revocar cualquier acceso adicional creado durante una intrusión. Las siguientes secciones examinan cuatro controles que contribuyen a ese objetivo.

Control 1. Reducir las credenciales que un portátil puede exponer

Una credencial es útil para un atacante porque otro sistema la acepta como prueba de autoridad. Mantener menos credenciales de producción en los dispositivos de los empleados reduce lo que se puede robar cuando se compromete una herramienta, un repositorio o una sesión del navegador.

Para el trabajo rutinario, un empleado suele necesitar permiso para solicitar una operación, como reiniciar un servicio. La credencial que la ejecuta puede permanecer asociada a una identidad de ejecución separada. Reducir la exposición implica tanto eliminar copias innecesarias como gestionar las credenciales que quedan:

• Sustituya el acceso directo rutinario por operaciones definidas de forma precisa cuando sea viable.
• Utilice identidades distintas para funciones distintas y limite su alcance y su vigencia.
• Mantenga un inventario de credenciales, sus responsables y el procedimiento para revocarlas.

Esto aplica el principio de la guía de gestión de secretos de OWASP: reducir la manipulación humana de secretos y conceder solo el acceso que necesita cada identidad. Una estación de trabajo comprometida expone entonces menos credenciales reutilizables, y los responsables de la respuesta saben quién gestiona las que aún deben revocarse.

Control 2. Tratar los permisos de despliegue como privilegios de producción

Un secreto puede estar oculto para una persona y, aun así, estar disponible para el código que despliega. Quien puede modificar ese código podría leer el secreto, llamar a una API interna o actuar como la cuenta de servicio de la aplicación. Por ello, el acceso de despliegue debe evaluarse según los permisos de la carga de trabajo resultante.

La guía de seguridad de CI/CD de OWASP considera los cambios en el repositorio, la configuración del pipeline y los hosts de ejecución como partes del mismo problema de seguridad. La protección debe abarcar el código antes del despliegue y sus permisos después:

• Exija revisión del código de producción y proteja la rama del repositorio que ejecuta la automatización.
• Controle los cambios en las definiciones de tareas, las dependencias y los parámetros de inicio, además del script principal.
• Conceda a las cargas de trabajo únicamente las credenciales y el acceso a la red que necesitan para su función.

Dos conjuntos de controles deben funcionar conjuntamente. Los permisos del repositorio y de despliegue determinan quién puede modificar el código. Las políticas de identidad, host y red, aplicadas por separado, limitan lo que ese código puede hacer al ejecutarse. El almacenamiento centralizado de secretos reduce la exposición, mientras que esas políticas restringen el programa que utiliza el secreto.

Control 3. Autorizar la operación, no solo al solicitante

Un servicio de firma puede mantener oculta su clave privada y aun así aceptar una solicitud de firma dañina. La misma distinción se aplica a una base de datos o a una API de nube: autenticar una carga de trabajo identifica al solicitante, mientras que la autorización decide qué puede hacer.

OWASP recomienda comprobar la autorización en cada solicitud y denegar el acceso salvo que esté permitido explícitamente. En el servicio receptor, esto significa comprobar tanto la acción como su destino: destinos e importes de pago permitidos, operaciones de base de datos o cambios en la infraestructura.

El resultado debe ser un servicio que evalúe la acción solicitada incluso cuando ya confía en el solicitante. La automatización regula cómo se solicita el trabajo. El servicio receptor regula qué operaciones acepta.

Control 4. Revocar el acceso creado durante la intrusión

Un atacante puede utilizar una identidad legítima para añadir otra credencial o conceder más permisos. MITRE ATT&CK documenta la manipulación de cuentas como una forma de mantener o ampliar el acceso, incluida la incorporación de credenciales de nube y claves SSH. Deshabilitar la sesión original no elimina necesariamente esos cambios.

La delegación en cadena de Binance ilustra por qué los equipos de respuesta deben inspeccionar los permisos en el propio sistema afectado. La contención debe abarcar tanto el acceso inicial como la autoridad creada a través de él:

• Limite qué identidades de automatización pueden crear otras credenciales o conceder permisos.
• Incluya las cuentas, sesiones y delegaciones recién creadas en el plan de respuesta.
• Verifique la revocación en el sistema que aplica el permiso, en lugar de considerar una tarea detenida como prueba de contención.

Estos pasos proporcionan a los equipos de respuesta un conjunto definido de identidades y permisos que investigar y revocar. También permiten comprobar la contención: el equipo puede verificar si todas las vías conocidas hacia el servicio afectado se han cerrado realmente.

Estos controles actúan en capas distintas: el dispositivo del empleado, el sistema de despliegue, el servicio receptor y el proceso de respuesta. Cada una necesita un responsable y una forma de verificar que sus restricciones se mantienen cuando otra capa resulta comprometida.

Las plataformas de gestión de automatización abordan la parte de este problema situada entre la solicitud de un empleado y la ejecución en producción. En Semaphore UI, un equipo puede preparar una tarea definida, controlar quién puede ejecutarla o modificarla y ejecutarla con una identidad separada. La autorización dentro del servicio de destino y la revocación de permisos creados en otros sistemas siguen siendo responsabilidad de esos sistemas y del equipo de respuesta.

Pensemos en un ingeniero de guardia que necesita reiniciar un servicio de API. Un responsable de mantenimiento prepara un playbook y una Task Template que fijan los hosts de destino y cómo se ejecuta el reinicio. El ingeniero inicia la tarea y consulta el resultado sin abrir una sesión SSH en producción. Las dos vías siguientes realizan el mismo reinicio, pero sitúan la credencial de ejecución en manos distintas.

Crear el flujo de reinicio requiere cuatro pasos conectados: crear una identidad de ejecución restringida, definir qué pueden ejecutar o modificar los usuarios, elegir el entorno de ejecución y hacer visible el resultado. Una vez establecidos, el mismo enfoque puede ampliarse a los despliegues.

Una sesión de operador robada puede seguir solicitando las operaciones que esa cuenta tiene permitido ejecutar. Incluso un reinicio autorizado puede interrumpir un servicio si se repite. Pruebe el flujo configurado con una cuenta de operador realista en staging, tanto para comprobar lo que puede hacer como la respuesta del equipo ante un uso indebido:

• Permisos de tareas y parámetros. Pruebe los roles reales y las opciones de inicio, incluidas ramas, inventarios y argumentos alternativos.
• Acceso más allá de la operación prevista. Compruebe el acceso a otras plantillas, credenciales y sistemas de producción, incluido lo que puede alcanzar el proceso del runner.
• Detección e impacto operativo. Confirme quién recibe los resultados, quién investiga la actividad inesperada y si las ejecuciones repetidas pueden causar interrupciones inaceptables.
• Revocación. Pruebe la revocación de sesiones y tokens e identifique los permisos que la identidad de ejecución podría crear en otros sistemas.

Documente el acceso que conserva la cuenta de prueba y cierre cualquier vía que exceda el propósito de la operación. Al terminar el ejercicio, el equipo debe conocer tanto lo que podría hacer una sesión robada como la forma de detectar y contener ese uso indebido.

Los controles de acceso funcionan junto con la protección de los equipos y un equipo que sabe responder. Haga que el flujo preparado sea lo bastante cómodo para utilizarlo sin recurrir a claves compartidas ni a atajos sin documentar. Respáldelo con algunas prácticas cotidianas:

• Ejecute instaladores desconocidos y ejercicios de entrevistas en entornos desechables y aislados, sin credenciales corporativas, montajes del host ni acceso a redes internas.
• Facilite la comunicación temprana de actividad sospechosa y sin culpabilizar a nadie. Proporcione un contacto claro y un procedimiento de respuesta a incidentes.
• Revise el acceso cuando cambien las funciones, mantenga un procedimiento controlado de acceso de emergencia y ensaye la revocación antes de un incidente.

Estas prácticas conectan la prevención, la detección y la recuperación con el trabajo diario. Ayudan a mantener el modelo de acceso alineado con los cambios de responsabilidades y ofrecen al equipo una respuesta conocida ante un evento sospechoso.

La lección principal es limitar cuánta autoridad puede acumular una identidad comprometida. Menos credenciales en los portátiles, automatización revisada, hosts de ejecución restringidos y autorización dentro de los servicios de producción reducen las vías que puede seguir un atacante.

Semaphore integra varios de esos controles en un flujo repetible: tareas preparadas, permisos separados de ejecución y edición, credenciales suministradas de forma centralizada y registros de ejecución visibles. Los operadores reciben las acciones que requiere su trabajo, mientras que los responsables de mantenimiento conservan el control sobre el código y las credenciales que las permiten.

Empiece por una operación de producción utilizada con frecuencia: prepare su plantilla de tarea, asigne los permisos de operador necesarios y pruebe el acceso resultante antes de retirar la conexión directa que sustituye. La medida útil del progreso es lo poco que un atacante puede hacer con la siguiente cuenta que comprometa.