Los scripts Bash que comienzan siendo herramientas personales acaban creciendo: se comparten, se automatizan con cron, reciben entrada externa y a veces se ejecutan como root. Esa evolución convierte a un script sencillo en una potencial vía de ataque si no se aplican medidas básicas de seguridad.
Validar y sanear toda entrada
Toda entrada externa —argumentos, stdin, variables de entorno, archivos o respuestas de APIs— debe considerarse maliciosa. La estrategia más segura es rechazar lo que no encaje en un patrón esperado (por ejemplo, aceptar solo cadenas alfanuméricas o un formato de ruta concreto) en lugar de intentar filtrar caracteres peligrosos.
Bash ofrece herramientas útiles: printf %q para escapar cadenas de modo que el shell las trate como un único token, y expansiones de parámetros que permiten manipular y sanitizar sin ejecutar código. Evita construir líneas de código a partir de entrada sin control.
Evitar eval y ejecutar código dinámico
eval ejecuta su argumento como código Bash y es extremadamente peligroso con entrada externa. Regla de oro: si puedes evitar eval, evítalo. Para casos muy raros donde parezca necesario, replantea el diseño: suele haber alternativas como arrays, funciones y construcciones de control que no requieren evaluación dinámica. Si no queda otra, sanitiza exhaustivamente la entrada y limita el alcance de lo evaluado.
Permisos, umask y principio de menor privilegio
Establece un umask seguro al inicio de scripts que manejan datos sensibles (por ejemplo, uno que evite permisos para grupo y otros). Nunca uses chmod 777: abre el acceso a modificaciones por cualquier cuenta, incluidos procesos maliciosos. Además, aplica el principio de mínimo privilegio: ejecuta solo lo necesario con los menores permisos posibles y evita ejecutar scripts como root cuando no sea imprescindible.
Archivos temporales y condiciones de carrera
No uses nombres predecibles en /tmp (como /tmp/mi_script.tmp). Un atacante puede crear un enlace simbólico con ese nombre y redirigir la salida hacia archivos críticos. Usa mktemp o mecanismos atómicos que generen nombres únicos y seguros.
Ten en cuenta las condiciones TOCTOU (Time Of Check, Time Of Use): comprobar y usar un archivo en dos pasos puede permitir que un atacante cambie el recurso entre ambas operaciones. Cuando sea posible, realiza operaciones atómicas o usa llamadas que abran el archivo con banderas que eviten modificaciones intermedias.
Robustez en el manejo de errores
Sin medidas adecuadas, Bash continúa después de un fallo, lo que puede dejar el sistema en un estado inconsistente. Incluye al inicio de scripts profesionales líneas como set -e y set -o pipefail (o sus equivalentes) para que el script falle ante errores y para que el código de salida de una tubería refleje fallos intermedios. Para comandos que puedan fallar sin ser críticos, maneja las excepciones explícitamente usando construcciones como || true o comprobaciones condicionadas.
Comillas, variables y exposición de secretos
Siempre cita las variables para evitar expansiones inesperadas que provoquen word splitting o globbing. Nunca pases contraseñas por argumentos de línea de comandos, ya que otros procesos pueden verlos mediante herramientas del sistema; usa stdin, archivos con permisos restringidos o mecanismos de almacenamiento de secretos.
SUID en scripts y registro de acciones
El bit SUID en scripts es inseguro: los scripts interpretados no gestionan correctamente los cambios de identidad y pueden crear vectores de escalada. Reserva SUID para binarios compilados y, en scripts, busca alternativas como wrappers en C o mecanismos de privilegios temporales controlados.
Por último, registra siempre acciones sensibles: quién ejecutó el script, qué hizo y cuándo. El registro (logs) facilita auditoría y respuesta ante incidentes.
Qué deben hacer administradores y propietarios de sitios
Revisar los scripts que se ejecutan de forma automática o como root: aplicar umask, añadir comprobaciones estrictas de entrada, eliminar el uso de eval, generar temporales con mktemp, habilitar set -e y pipefail, y evitar pasar credenciales por argumentos. Donde haya dudas sobre seguridad o privilegios, replantear el diseño arquitectónico antes que parchear el script.
Lee también:
- P7 DarkSword: nueva variante del exploit kit iOS que roba claves y datos de monederos
- ESET documenta la evolución de MATCHBOIL, downloader usado por el grupo UAC-0099
Fuente: atareao con Linux
