Tema 18
Después de obtener acceso autorizado a un sistema Linux de laboratorio o dentro del alcance, el objetivo es entender el contexto local: quién somos, qué permisos existen, qué servicios corren y qué configuraciones podrían permitir escalar privilegios.
La explotación en Linux dentro de un pentest suele empezar después de obtener una sesión, una cuenta válida o acceso a un servicio. En ese punto, el trabajo cambia: ya no se trata solo de entrar, sino de entender qué puede hacerse con ese acceso y qué impacto tendría.
La escalada local busca pasar de un usuario limitado a un contexto con más privilegios. Puede ocurrir por permisos incorrectos, sudo mal configurado, binarios SUID, capabilities peligrosas, servicios editables, tareas programadas, secretos expuestos o vulnerabilidades del kernel.
Este tema presenta una metodología de análisis local orientada a entornos autorizados. El foco es validar riesgo con cuidado, documentar evidencia y recomendar correcciones.
Una sesión en Linux puede ser frágil y estar registrada. Antes de ejecutar acciones, hay que entender el alcance y evitar cambios innecesarios.
La enumeración local responde preguntas básicas: quién soy, dónde estoy, qué sistema es, qué permisos tengo y qué servicios existen.
| Pregunta | Qué buscar | Riesgo asociado |
|---|---|---|
| ¿Qué usuario soy? | UID, GID, grupos | Grupos con permisos especiales |
| ¿Qué sistema es? | Distribución, kernel, arquitectura | Vulnerabilidades locales o soporte vencido |
| ¿Qué procesos corren? | Servicios, usuarios propietarios | Procesos privilegiados mal configurados |
| ¿Qué puedo leer? | Archivos, configuraciones, logs | Secretos o información sensible expuesta |
| ¿Qué puedo escribir? | Directorios, scripts, rutas de servicio | Alteración de ejecución privilegiada |
Los grupos en Linux pueden otorgar capacidades importantes. No todos los riesgos requieren ser root directamente; pertenecer a ciertos grupos puede permitir acceso a archivos, contenedores, dispositivos o ejecución indirecta.
La evidencia debe mostrar el grupo y su impacto, no solo listar membresías.
Los permisos incorrectos son una causa frecuente de escalada. Un archivo editable por un usuario limitado, pero ejecutado por root, puede ser una ruta crítica. Un archivo legible con secretos puede abrir otra vía de acceso.
Sudo permite ejecutar comandos con privilegios de otro usuario. Una configuración demasiado permisiva puede permitir escalada directa o indirecta.
| Configuración | Riesgo | Validación segura |
|---|---|---|
| Comandos sin contraseña | Ejecución privilegiada inmediata | Listar permisos y probar comando inocuo |
| Permiso sobre editores | Escape a shell privilegiada | Documentar riesgo sin modificar archivos |
| Permiso sobre scripts | Abuso si el script llama rutas manipulables | Revisar contenido y permisos |
| Variables de entorno permitidas | Hijacking de librerías o rutas | Validar configuración, no ejecutar payloads peligrosos |
| Wildcards en rutas | Coincidencias inesperadas | Demostrar con archivo de prueba si está autorizado |
Un binario con SUID se ejecuta con los privilegios de su propietario, normalmente root. Esto es necesario para algunas funciones del sistema, pero puede ser peligroso si el binario permite ejecutar comandos, leer archivos o cargar librerías de forma insegura.
Aspectos a revisar:
La validación de SUID debe evitar alterar binarios o ejecutar acciones peligrosas. Muchas veces basta con demostrar que existe un binario SUID no estándar y explicar su ruta de abuso.
Las capabilities dividen privilegios de root en permisos más específicos. Son útiles para reducir privilegio total, pero mal asignadas pueden permitir acciones peligrosas.
| Capability | Riesgo potencial | Ejemplo de impacto |
|---|---|---|
| cap_setuid | Cambio de identidad de proceso | Puede facilitar escalada a root |
| cap_dac_read_search | Lectura ignorando permisos normales | Acceso a archivos sensibles |
| cap_dac_override | Escritura ignorando controles DAC | Modificar archivos protegidos |
| cap_net_raw | Uso de sockets raw | Riesgos de sniffing o manipulación de red |
| cap_sys_admin | Privilegios muy amplios | Frecuentemente equivalente a alto riesgo |
Los servicios pueden ejecutarse como root u otros usuarios privilegiados. Una configuración insegura puede permitir modificar unidades, scripts, binarios o variables usadas por el servicio.
La validación debe centrarse en permisos y configuración, evitando reiniciar servicios productivos sin autorización.
Cron ejecuta tareas en horarios definidos. Si una tarea privilegiada llama a un script editable por un usuario limitado, puede existir una ruta de escalada.
PATH hijacking ocurre cuando un script o servicio ejecuta comandos sin ruta absoluta y el atacante puede influir en el PATH o en el directorio donde se busca el binario.
Señales:
La evidencia puede ser el script, el PATH y los permisos. No siempre es necesario ejecutar un reemplazo.
Linux suele contener secretos en archivos de configuración, variables de entorno, historiales, backups y directorios de aplicaciones. Encontrarlos puede permitir moverse a otro usuario, servicio o sistema.
No se deben copiar secretos completos si un fragmento o ruta basta para evidenciar exposición.
Las claves SSH y archivos de configuración pueden permitir acceso a otras cuentas o sistemas. En un pentest, cualquier uso de credenciales encontradas debe estar autorizado.
| Elemento | Riesgo | Validación segura |
|---|---|---|
| Clave privada legible | Acceso a usuario o servidor | Documentar permisos y propietario |
| known_hosts | Revela destinos relacionados | Usar como contexto, no escanear sin alcance |
| config SSH | Hosts, usuarios y rutas de claves | Registrar metadatos no sensibles |
| authorized_keys | Llaves con acceso persistente | Revisar permisos y entradas sospechosas |
Si un usuario pertenece al grupo docker o puede controlar contenedores, el impacto puede ser alto. Docker mal configurado puede permitir acceder al host, montar archivos o ejecutar procesos privilegiados.
Las vulnerabilidades locales de kernel pueden permitir escalada, pero suelen tener riesgo de inestabilidad. En producción, normalmente se validan por versión, configuración y parches, no ejecutando exploits directamente.
En servidores Linux, las aplicaciones web suelen ejecutarse como usuarios como www-data, nginx, apache o usuarios de aplicación. Desde ese contexto, la enumeración debe centrarse en configuración, secretos y permisos.
Existen scripts que automatizan la enumeración local. Son útiles, pero deben revisarse antes de ejecutarlos porque pueden acceder a muchos archivos o generar ruido.
La evidencia debe demostrar la ruta de privilegio sin dejar cambios innecesarios.
| Hallazgo | Evidencia útil | Evitar |
|---|---|---|
| Sudo inseguro | Regla permitida y comando inocuo | Modificar archivos críticos |
| SUID peligroso | Permisos, propietario y ruta de abuso | Reemplazar binarios |
| Script root editable | Permisos del script y tarea que lo ejecuta | Insertar payload persistente |
| Secreto expuesto | Ruta y fragmento enmascarado | Copiar secreto completo |
| Capability riesgosa | Binario y capability asignada | Ejecutar abuso si no es necesario |
Las recomendaciones deben apuntar a causa raíz: permisos, configuración, privilegios o secretos.
Un flujo responsable puede ser:
La explotación local en Linux exige entender permisos, procesos, configuración y secretos. No se trata de ejecutar scripts al azar, sino de construir una ruta de impacto clara y validarla de forma proporcional.
En el próximo tema veremos explotación en Windows: privilegios, servicios, credenciales y escalada local, con sus propios modelos de permisos, autenticación y administración.