Command injection

Una aplicación necesita algo que el lenguaje no le da, así que construye una cadena y se la entrega a un shell: convertir una imagen, hacer ping a una máquina, resolver un nombre, generar un PDF, leer el estado de un dispositivo. Si alguna parte de esa cadena viene de una petición y no se neutraliza, los metacaracteres del shell que contenga cambian el significado de la línea. Un punto y coma, una tubería, un ampersand, un salto de línea o unas comillas invertidas empiezan un segundo comando. El comando inyectado se ejecuta con la cuenta con la que corre el servicio.

El arreglo fiable no es filtrar los caracteres. Es no usar un shell en absoluto: invocar el binario directamente con sus argumentos como lista, para que el sistema operativo no llegue nunca a interpretar una línea de comandos. Donde el shell es inevitable, el argumento tiene que ser un valor de un conjunto permitido fijo, no una copia saneada de lo que mandó el usuario.

Dos cosas. La primera es la lista de prohibidos. Un filtro que quita los puntos y coma lo derrota un salto de línea, un filtro que quita los dos lo derrota la sustitución de comandos, y un filtro que caza los tres lo derrota un argumento que cambia el comportamiento del binario previsto sin llegar a arrancar un segundo proceso. Basta con pasar una cadena controlada por el atacante como opción de una herramienta que puede escribir ficheros o cargar configuración.

La segunda es dónde lo encontramos. En aplicaciones web este fallo ha ido desapareciendo de los frameworks principales y hoy vive en las costuras: endpoints administrativos, páginas de diagnóstico, generadores de informes e integraciones con herramientas de línea de comandos. En dispositivos embebidos sigue estando en todas partes, porque la interfaz web de un router o de una cámara es muchas veces una capa fina sobre scripts de shell, y por eso el análisis de firmware lo encuentra con tanta constancia y por eso es un riesgo permanente en entornos OT e ICS.

Lo buscamos allí donde un parámetro parece un nombre de máquina, una ruta, un nombre de fichero o una opción de formato, y lo confirmamos con un retardo temporal o con una llamada fuera de banda antes que con la lectura de la salida, porque la mayoría de los casos son ciegos. El informe da el parámetro, la carga, la evidencia de ejecución y la cuenta con la que se ejecutó el comando, que suele ser la diferencia entre un hallazgo alto y uno crítico que lleva a ejecución remota de código. Esto forma parte de cómo probamos los sitios donde una aplicación sale al shell.