Fins ara hem explotat l'aplicació (04-02) i la xarxa (04-03). En aquesta lliçó baixem al nivell del host: com una fallada al sistema operatiu o en un servei local es converteix en execució de codi sobre la màquina, fins a obtenir una shell inicial —un foothold amb privilegis limitats—. A TechNova això aplica al servidor intern Linux, a dev i a les estacions de la xarxa 10.10.10.0/24, on el Mòdul 3 va trobar programari antiquat i serveis en fi de vida.

L'enquadrament continua ferm i, en sistemes, té un matís tècnic important: els exploits de sistema són els més propensos a fer caure el servei (un desbordament amb un offset mal calculat reinicia el procés o el host). Per això tot passa al laboratori autoritzat de TechNova, amb check previ quan existeixi, exploits d'alta fiabilitat, payload de menor impacte i control del dany (res de denegació de servei no acordada). I el límit del mòdul, un cop més: aquí arribem al foothold. El que es fa des d'aquest punt de suport —escalar a root/administrador, persistir, pivotar— és Mòdul 5. Ensenyem el mecanisme de cada classe i la seva contrapartida (apedaçament, hardening); no un exploit de 0-day operatiu clau en mà.

1. Del servei de xarxa a l'execució al host
2. RCE per servei vulnerable
3. Desbordament de buffer: el concepte
4. Proteccions de memòria: ASLR, DEP, canaris
5. Serveis i configuracions locals mal ajustades
6. Obtenir la shell inicial (foothold)
7. Contrapartida: apedaçament i hardening
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Un RCE (Remote Code Execution) és el sant grial de l'explotació de sistemes: aconseguir que la màquina objectiu executi codi nostre. Les vies més comunes:

• Servei amb vulnerabilitat d'execució: una fallada al codi del servei permet executar comandes (com la consola de Werkzeug de 04-03).
• Corrupció de memòria: un desbordament de buffer o una altra fallada de memòria que permet desviar el flux d'execució.
• Configuració local abusable: binaris, permisos o serveis mal ajustats que donen execució.

L'objectiu d'aquesta lliçó és arribar a C: la shell inicial. La fletxa puntejada cap a D és el Mòdul 5.

La via més neta és un servei amb RCE conegut i un mòdul fiable. El patró (vist ja a 04-03) és sempre el mateix: verificar, check, payload mínim, evidència.

La sortida uid=33(www-data) demostra execució de comandes com un usuari sense privilegis: ja tenim un foothold. No obrim una shell persistent ni toquem dades: id; hostname és prova suficient per a l'informe.

Contrapartida: apedaçar el servei, retirar-lo si està en fi de vida, executar-lo amb mínim privilegi (que www-data no pugui fer gaire és, precisament, el que limita l'impacte) i aïllar-lo per xarxa.

El desbordament de buffer (buffer overflow) és la classe de corrupció de memòria més clàssica. L'expliquem a nivell conceptual/educatiu: què és i per què passa. No escriurem un exploit operatiu.

Mecanisme. Un programa reserva un espai fix (buffer) per a unes dades. Si hi copia més dades de les que hi caben sense comprovar la mida, els bytes sobrants sobreescriuen memòria adjacent, inclosa —a la pila— l'adreça de retorn de la funció. Controlant aquesta adreça, un atacant pot desviar l'execució cap al seu propi codi.

Si entrada té 100 bytes, strcpy escriu més enllà de nombre[64] i esclafa el que hi ha darrere a la pila. Diagrama de la pila:

En sobreescriure l'adreça de retorn, quan la funció acaba, en lloc de tornar on havia de fer-ho, salta cap on l'atacant vulgui. Aquest és el cor de l'exploit. La disciplina del pentester aquí: reconèixer la classe, entendre per què el codi és vulnerable i —crucial— saber que provar això pot fer caure el procés, així que es fa només al laboratori i amb acord.

Codi segur (mitigació al mateix codi):

Fer servir funcions que respecten la mida (strncpy, snprintf) en lloc de les insegures (strcpy, gets, sprintf) elimina la classe d'arrel. En llenguatges amb gestió de memòria (Python, Java, Rust) aquesta família de fallades pràcticament desapareix.

Els sistemes operatius moderns afegeixen defenses en profunditat que fan que un desbordament sigui molt més difícil d'explotar (per això un exploit "de laboratori" sovint no funciona contra un sistema actualitzat):

Aquestes proteccions no eliminen la fallada, però eleven enormement el cost d'explotar-la. Per a l'informe, això importa: un desbordament en un binari sense aquestes proteccions és molt més greu que la mateixa fallada en un que les té totes. Es comproven amb eines com checksec.

No tot RCE ve de corrupció de memòria; moltes vegades la via és una mala configuració local del mateix sistema:

A TechNova, el PHP 7.2.24 en fi de suport i el MySQL 5.5.62 de l'inventari són exemples clars: programari sense manteniment amb CVE acumulats. La via d'entrada més fiable sol ser aquesta —configuració i obsolescència— abans que un desbordament a mida.

El resultat d'aquesta lliçó és la shell inicial: una consola al host amb els privilegis del servei explotat (normalment limitats: www-data, devapp, un usuari de servei). Recapitulant el flux controlat:

Un cop amb la shell, s'estabilitza el just per treballar i es captura l'evidència (usuari, host, prova d'execució). I aquí ens aturem: què fer amb aquest foothold —enumerar el sistema des de dins, escalar privilegis, mantenir accés, pivotar— és tot Mòdul 5. Avançar-ho trencaria el control i el fil del curs.

Enfront de l'explotació de sistemes, la defensa es recolza en:

• Gestió de pedaços: el 90% d'aquesta lliçó s'evapora amb sistemes actualitzats i sense programari EOL. És la contramesura número u.
• Hardening del SO: mantenir actives ASLR, DEP, PIE i canaris; deshabilitar serveis innecessaris; revisar permisos i SUID; aplicar CIS Benchmarks.
• Mínim privilegi: que els serveis corrin amb el menor privilegi possible limita el valor d'un foothold.
• Detecció: EDR/antivirus, monitoratge de processos i logs, alertes davant shells inesperades o binaris anòmals. Una reverse shell sortint inusual és un senyal clar per al defensor.

• Llançar exploits de memòria sense check ni fiabilitat alta. Són els que més fan caure el servei; un crash en producció és una denegació de servei no acordada. Verifica i prioritza Rank alt.
• Intentar escriure el teu propi buffer overflow contra el client. No és l'objectiu (ni l'abast) d'un pentest estàndard; reconeix la classe, reporta-la i valida amb un PoC segur o amb check.
• Ignorar les proteccions de memòria a l'informe. Una fallada en un binari sense ASLR/DEP/canary és molt més greu; documenta amb checksec l'estat real.
• Continuar endavant després de la shell. El foothold és el final del Mòdul 4. Enumerar i escalar des de dins és Mòdul 5; fer-ho aquí trenca el control.
• Fixar-se només en CVE cridaners i oblidar la configuració. El programari EOL, les credencials per defecte i els permisos excessius solen ser la via real i més fiable.
• No estabilitzar ni documentar la shell. Una shell perduda per no estabilitzar-la, o sense evidència capturada, és feina llençada.
• Consell: abans d'un exploit de memòria arriscat, busca la via avorrida i fiable (servei EOL, credencial per defecte, mala config). Sol existir i és de molt menor impacte.

Exercici 1. Explica amb les teves paraules, a nivell conceptual, per què la funció saludar amb strcpy és vulnerable a desbordament de buffer, què se sobreescriu i per què això pot donar control de l'execució. Escriu la versió segura i digues quines proteccions del SO dificultarien l'atac encara que el codi continués sent vulnerable.

Exercici 2. Vas a validar un RCE en un servei intern de TechNova (10.10.10.60) amb un mòdul de Metasploit. Descriu la seqüència de baix impacte que seguiries per demostrar execució sense fer caure el servei ni passar-te d'abast, i quina evidència capturaries. Indica on acaba aquesta lliçó i què seria ja Mòdul 5.

Exercici 3. L'inventari del Mòdul 3 llista PHP 7.2.24 i MySQL 5.5.62 (tots dos EOL) a TechNova. Argumenta per què aquesta "via avorrida" de programari obsolet pot ser preferible, per al pentester, a intentar un desbordament de buffer a mida, i dona la contrapartida de remediació.

Solució 1. strcpy(nombre, entrada) copia entrada a nombre[64] sense comprovar la mida; si entrada supera 64 bytes, els bytes sobrants escriuen més enllà del buffer i sobreescriuen la memòria adjacent a la pila, inclosa l'adreça de retorn de la funció. En acabar saludar, la CPU salta a aquesta adreça: si l'atacant l'ha controlada, desvia l'execució cap al seu codi. Versió segura: fer servir strncpy(nombre, entrada, sizeof(nombre)-1) i acabar amb '\0', de manera que mai s'escrigui fora del buffer. Proteccions del SO que dificultarien l'atac encara que el codi fos vulnerable: stack canary (detecta la sobreescriptura abans de saltar), DEP/NX (la pila no és executable, el shellcode injectat no corre) i ASLR/PIE (aleatoritzen les adreces, l'atacant no sap on saltar).

Solució 2. Seqüència de baix impacte: (1) confirmar que 10.10.10.60 està en abast i a la finestra; (2) use del mòdul i llegir què fa; (3) check per confirmar la vulnerabilitat sense explotar; (4) triar el payload mínim (cmd/unix/generic) amb set CMD "id; hostname" en lloc d'una shell persistent; (5) run i capturar la sortida (uid=..., hostname) com a evidència d'execució. Aquesta lliçó acaba a la shell/execució inicial (el foothold amb privilegis limitats). Enumerar el sistema des de dins, escalar a root, mantenir l'accés o pivotar a altres subxarxes és Mòdul 5.

Solució 3. El programari EOL és preferible perquè és una via fiable i de baix impacte: té CVE coneguts amb exploits provats i mòduls amb check, no depèn de calcular offsets ni de sortejar ASLR/DEP, i per tant és molt menys propens a fer caure el servei que un desbordament a mida (que pot reiniciar el procés si alguna cosa no encaixa). En pentesting es prefereix l'entrada segura i demostrable enfront de l'arriscada. Contrapartida de remediació: actualitzar a versions suportades de PHP i MySQL (o migrar), retirar tot el programari en fi de vida, i mentrestant aïllar i monitorar aquests serveis. La gestió de pedaços és la contramesura principal.

Tanquem el bloc tècnic d'explotació per capes: aplicació (04-02), xarxa (04-03) i ara sistema (04-04). Hem vist com s'arriba a execució de codi en un host —per un servei amb RCE, per corrupció de memòria (amb el desbordament de buffer explicat a nivell conceptual i les seves proteccions ASLR/DEP/canaris) o per configuració local insegura— fins a obtenir la shell inicial: un foothold amb privilegis limitats, validat amb un id, documentat i sense passar d'aquí. La contrapartida ha estat constant: apedaçar, endurir i aplicar mínim privilegi.

Ens queda una via d'accés transversal que travessa el web, la xarxa i els sistemes: les credencials. Molts dels footholds més fiables no venen d'un exploit, sinó d'una contrasenya feble, per defecte o reutilitzada. L'última lliçó del mòdul, 04-05 Atacs a Contrasenyes i Autenticació, aborda com s'avaluen l'autenticació, el hashing, els atacs offline/online i els mecanismes de sessió i MFA, sempre amb la seva contrapartida defensiva. I amb ella tancarem el Mòdul 4 per donar pas a la post-explotació.