Bomba lógica

Una bomba lógica tiene siempre dos piezas, y conviene separarlas porque se defienden de forma distinta. Por un lado está el disparador: la condición que el código comprueba una y otra vez sin hacer nada más. Por otro está la carga: lo que ocurre cuando esa condición se cumple.

El disparador suele ser algo trivial de programar y difícil de distinguir de una comprobación legítima. Una fecha y una hora. Que exista o deje de existir una cuenta en el directorio. Que un fichero concreto siga en su sitio. Que un contador llegue a un número. Que un proceso se lance. Vista de una en una, ninguna de esas comprobaciones parece maliciosa: son exactamente las que hace cualquier tarea programada.

La carga, en cambio, no tiene nada de particular: puede ser el borrado de ficheros, el cifrado de un volumen, la corrupción silenciosa de una base de datos o la apertura de un acceso para más tarde. Por eso una bomba lógica no es una familia de malware con un comportamiento propio, sino una forma de entregarlo: lo que la define es el retardo, no el daño.

El problema de detección es que, mientras está latente, no hay nada que detectar. Un antimalware que busca comportamiento no ve comportamiento, porque no lo hay: el código se limita a comprobar una condición que todavía no se cumple. Y una detección basada en firmas solo sirve si alguien ha visto antes ese código concreto, cosa que no pasa cuando lo ha escrito quien tiene acceso legítimo al repositorio.

El segundo problema es el tiempo. Si entre la implantación y la activación pasan meses, la ventana de retención de las copias de seguridad puede ser más corta que ese intervalo, y entonces todas las copias disponibles ya contienen la bomba. Restaurar reinstala el problema. Es la razón por la que una copia inmutable y con retención larga vale mucho más aquí que una copia reciente.

Y el tercero es de quién viene. La bomba lógica es el caso clásico de amenaza interna, porque su disparador natural es «cuando mi cuenta deje de existir». Quien la coloca no necesita entrar: ya está dentro, y a menudo con permiso para desplegar código.

No se busca una bomba lógica pasando un escáner, porque no hay nada que escanear. Se buscan las condiciones que permiten colocar una y que nadie se entere. En un test interno miramos quién puede desplegar código o modificar tareas programadas sin que otra persona lo revise, si los repositorios y la cadena de despliegue guardan un registro que no pueda borrar quien despliega, y si la baja de un empleado retira de verdad el acceso al código y a la automatización, y no solo el correo.

En revisión de código, la señal que se persigue es un condicional que dependa de una fecha, de la existencia de una cuenta o de un identificador concreto, en un punto donde la lógica de negocio no tiene motivo para mirar eso. Y el hallazgo se redacta contra el proceso, no contra el fichero: si una sola persona puede poner código en producción sin revisión y sin rastro, el problema no es que hoy haya o no haya una bomba.