Hasta ahora hemos explotado la aplicación (04-02) y la red (04-03). En esta lección bajamos al nivel del host: cómo un fallo en el sistema operativo o en un servicio local se convierte en ejecución de código sobre la máquina, hasta obtener una shell inicial —un foothold con privilegios limitados—. En TechNova esto aplica al servidor interno Linux, a dev y a las estaciones de la red 10.10.10.0/24, donde el Módulo 3 encontró software anticuado y servicios en fin de vida.

El encuadre sigue firme y, en sistemas, tiene un matiz técnico importante: los exploits de sistema son los más propensos a tumbar el servicio (un desbordamiento con un offset mal calculado reinicia el proceso o el host). Por eso todo ocurre en el laboratorio autorizado de TechNova, con check previo cuando exista, exploits de alta fiabilidad, payload de menor impacto y control del daño (nada de denegación de servicio no acordada). Y el límite del módulo, de nuevo: aquí llegamos al foothold. Lo que se hace desde ese punto de apoyo —escalar a root/administrador, persistir, pivotar— es Módulo 5. Enseñamos el mecanismo de cada clase y su contrapartida (parcheo, hardening); no un exploit de 0-day operativo llave en mano.

1. Del servicio de red a la ejecución en el host
2. RCE por servicio vulnerable
3. Desbordamiento de buffer: el concepto
4. Protecciones de memoria: ASLR, DEP, canarios
5. Servicios y configuraciones locales mal ajustadas
6. Obtener la shell inicial (foothold)
7. Contrapartida: parcheo y hardening
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Un RCE (Remote Code Execution) es el santo grial de la explotación de sistemas: lograr que la máquina objetivo ejecute código nuestro. Las vías más comunes:

• Servicio con vulnerabilidad de ejecución: un fallo en el código del servicio permite ejecutar comandos (como la consola de Werkzeug de 04-03).
• Corrupción de memoria: un desbordamiento de buffer u otro fallo de memoria que permite desviar el flujo de ejecución.
• Configuración local abusable: binarios, permisos o servicios mal ajustados que dan ejecución.

El objetivo de esta lección es llegar a C: la shell inicial. La flecha punteada hacia D es el Módulo 5.

La vía más limpia es un servicio con RCE conocido y un módulo fiable. El patrón (visto ya en 04-03) es siempre el mismo: verificar, check, payload mínimo, evidencia.

La salida uid=33(www-data) demuestra ejecución de comandos como un usuario sin privilegios: ya tenemos un foothold. No abrimos una shell persistente ni tocamos datos: id; hostname es prueba suficiente para el informe.

Contrapartida: parchear el servicio, retirarlo si está en fin de vida, ejecutarlo con mínimo privilegio (que www-data no pueda mucho es, precisamente, lo que limita el impacto) y aislarlo por red.

El desbordamiento de buffer (buffer overflow) es la clase de corrupción de memoria más clásica. Lo explicamos a nivel conceptual/educativo: qué es y por qué ocurre. No vamos a escribir un exploit operativo.

Mecanismo. Un programa reserva un espacio fijo (buffer) para unos datos. Si copia en él más datos de los que caben sin comprobar el tamaño, los bytes sobrantes sobrescriben memoria adyacente, incluida —en la pila— la dirección de retorno de la función. Controlando esa dirección, un atacante puede desviar la ejecución hacia su propio código.

Si entrada tiene 100 bytes, strcpy escribe más allá de nombre[64] y machaca lo que hay detrás en la pila. Diagrama de la pila:

Al sobrescribir la dirección de retorno, cuando la función termina, en lugar de volver a donde debía, salta a donde el atacante quiera. Ese es el corazón del exploit. La disciplina del pentester aquí: reconocer la clase, entender por qué el código es vulnerable y —crucial— saber que probar esto puede tumbar el proceso, así que se hace solo en laboratorio y con acuerdo.

Código seguro (mitigación en el propio código):

Usar funciones que respetan el tamaño (strncpy, snprintf) en lugar de las inseguras (strcpy, gets, sprintf) elimina la clase de raíz. En lenguajes con gestión de memoria (Python, Java, Rust) esta familia de fallos prácticamente desaparece.

Los sistemas operativos modernos añaden defensas en profundidad que hacen que un desbordamiento sea mucho más difícil de explotar (por eso un exploit "de laboratorio" a menudo no funciona contra un sistema actualizado):

Estas protecciones no eliminan el fallo, pero elevan enormemente el coste de explotarlo. Para el informe, esto importa: un desbordamiento en un binario sin estas protecciones es mucho más grave que el mismo fallo en uno que las tiene todas. Se comprueban con herramientas como checksec.

No todo RCE viene de corrupción de memoria; muchas veces la vía es una mala configuración local del propio sistema:

En TechNova, el PHP 7.2.24 en fin de soporte y el MySQL 5.5.62 del inventario son ejemplos claros: software sin mantenimiento con CVE acumulados. La vía de entrada más fiable suele ser esta —configuración y obsolescencia— antes que un desbordamiento a medida.

El resultado de esta lección es la shell inicial: una consola en el host con los privilegios del servicio explotado (normalmente limitados: www-data, devapp, un usuario de servicio). Recapitulando el flujo controlado:

Una vez con la shell, se estabiliza lo justo para trabajar y se captura la evidencia (usuario, host, prueba de ejecución). Y aquí paramos: qué hacer con ese foothold —enumerar el sistema desde dentro, escalar privilegios, mantener acceso, pivotar— es todo Módulo 5. Adelantarlo rompería el control y el hilo del curso.

Frente a la explotación de sistemas, la defensa se apoya en:

• Gestión de parches: el 90% de esta lección se evapora con sistemas actualizados y sin software EOL. Es la contramedida número uno.
• Hardening del SO: mantener activas ASLR, DEP, PIE y canarios; deshabilitar servicios innecesarios; revisar permisos y SUID; aplicar CIS Benchmarks.
• Mínimo privilegio: que los servicios corran con el menor privilegio posible limita el valor de un foothold.
• Detección: EDR/antivirus, monitorización de procesos y logs, alertas ante shells inesperadas o binarios anómalos. Una reverse shell saliente inusual es una señal clara para el defensor.

• Lanzar exploits de memoria sin check ni fiabilidad alta. Son los que más tumban el servicio; un crash en producción es una denegación de servicio no acordada. Verifica y prioriza Rank alto.
• Intentar escribir tu propio buffer overflow contra el cliente. No es el objetivo (ni el alcance) de un pentest estándar; reconoce la clase, repórtala y valida con un PoC seguro o con check.
• Ignorar las protecciones de memoria en el informe. Un fallo en un binario sin ASLR/DEP/canary es mucho más grave; documenta con checksec el estado real.
• Seguir adelante tras la shell. El foothold es el final del Módulo 4. Enumerar y escalar desde dentro es Módulo 5; hacerlo aquí rompe el control.
• Fijarse solo en CVE llamativos y olvidar la configuración. El software EOL, las credenciales por defecto y los permisos excesivos suelen ser la vía real y más fiable.
• No estabilizar ni documentar la shell. Una shell perdida por no estabilizarla, o sin evidencia capturada, es trabajo tirado.
• Consejo: antes de un exploit de memoria arriesgado, busca la vía aburrida y fiable (servicio EOL, credencial por defecto, mala config). Suele existir y es de mucho menor impacto.

Ejercicio 1. Explica con tus palabras, a nivel conceptual, por qué la función saludar con strcpy es vulnerable a desbordamiento de buffer, qué se sobrescribe y por qué eso puede dar control de la ejecución. Escribe la versión segura y di qué protecciones del SO dificultarían el ataque aunque el código siguiera siendo vulnerable.

Ejercicio 2. Vas a validar un RCE en un servicio interno de TechNova (10.10.10.60) con un módulo de Metasploit. Describe la secuencia de bajo impacto que seguirías para demostrar ejecución sin tumbar el servicio ni pasarte de alcance, y qué evidencia capturarías. Indica dónde termina esta lección y qué sería ya Módulo 5.

Ejercicio 3. El inventario del Módulo 3 lista PHP 7.2.24 y MySQL 5.5.62 (ambos EOL) en TechNova. Argumenta por qué esta "vía aburrida" de software obsoleto puede ser preferible, para el pentester, a intentar un desbordamiento de buffer a medida, y da la contrapartida de remediación.

Solución 1. strcpy(nombre, entrada) copia entrada en nombre[64] sin comprobar el tamaño; si entrada supera 64 bytes, los bytes sobrantes escriben más allá del buffer y sobrescriben la memoria adyacente en la pila, incluida la dirección de retorno de la función. Al terminar saludar, la CPU salta a esa dirección: si el atacante la ha controlado, desvía la ejecución hacia su código. Versión segura: usar strncpy(nombre, entrada, sizeof(nombre)-1) y terminar con '\0', de modo que nunca se escriba fuera del buffer. Protecciones del SO que dificultarían el ataque aunque el código fuera vulnerable: stack canary (detecta la sobrescritura antes de saltar), DEP/NX (la pila no es ejecutable, el shellcode inyectado no corre) y ASLR/PIE (aleatorizan las direcciones, el atacante no sabe a dónde saltar).

Solución 2. Secuencia de bajo impacto: (1) confirmar que 10.10.10.60 está en alcance y en la ventana; (2) use del módulo y leer qué hace; (3) check para confirmar la vulnerabilidad sin explotar; (4) elegir el payload mínimo (cmd/unix/generic) con set CMD "id; hostname" en lugar de una shell persistente; (5) run y capturar la salida (uid=..., hostname) como evidencia de ejecución. Esta lección termina en la shell/ejecución inicial (el foothold con privilegios limitados). Enumerar el sistema desde dentro, escalar a root, mantener el acceso o pivotar a otras subredes es Módulo 5.

Solución 3. El software EOL es preferible porque es una vía fiable y de bajo impacto: tiene CVE conocidos con exploits probados y módulos con check, no depende de calcular offsets ni de sortear ASLR/DEP, y por tanto es mucho menos propenso a tumbar el servicio que un desbordamiento a medida (que puede reiniciar el proceso si algo no encaja). En pentesting se prefiere la entrada segura y demostrable frente a la arriesgada. Contrapartida de remediación: actualizar a versiones soportadas de PHP y MySQL (o migrar), retirar todo software en fin de vida, y mientras tanto aislar y monitorizar esos servicios. La gestión de parches es la contramedida principal.

Cerramos el bloque técnico de explotación por capas: aplicación (04-02), red (04-03) y ahora sistema (04-04). Hemos visto cómo se llega a ejecución de código en un host —por un servicio con RCE, por corrupción de memoria (con el desbordamiento de buffer explicado a nivel conceptual y sus protecciones ASLR/DEP/canarios) o por configuración local insegura— hasta obtener la shell inicial: un foothold con privilegios limitados, validado con un id, documentado y sin pasar de ahí. La contrapartida ha sido constante: parchear, endurecer y aplicar mínimo privilegio.

Nos queda una vía de acceso transversal que atraviesa la web, la red y los sistemas: las credenciales. Muchos de los footholds más fiables no vienen de un exploit, sino de una contraseña débil, por defecto o reutilizada. La última lección del módulo, 04-05 Ataques a Contraseñas y Autenticación, aborda cómo se evalúan la autenticación, el hashing, los ataques offline/online y los mecanismos de sesión y MFA, siempre con su contrapartida defensiva. Y con ella cerraremos el Módulo 4 para dar paso a la post-explotación.