Arrenquem el Mòdul 4 just on vam tancar el Mòdul 3: amb la llista prioritzada de vulnerabilitats candidates de TechNova a la mà. A 03-03 vam passar de "no sabem res" a "aquestes vuit coses semblen febles, ordenades per prioritat". La candidata número u és una probable injecció SQL a tienda.technova.lab/producto.php?id=; la segueixen la consola de debug de Werkzeug al port 54321, MySQL 5.5 exposat, PHP en fi de vida, una sessió nul·la d'SMB i diversos fitxers filtrats. Fins ara no hem tocat res: només hem mirat. Explotar és creuar aquesta línia amb permís, cap i control.

Explotar és aprofitar una vulnerabilitat per aconseguir alguna cosa que el sistema no hauria de permetre: llegir una dada, executar una ordre, obtenir una sessió. En un pentest professional, l'explotació no és un acte d'agressió, sinó la validació autoritzada del risc: demostrem, amb evidència i de manera controlada, que la vulnerabilitat candidata és real i què aconseguiria un atacant, perquè TechNova pugui arreglar-la. Tota aquesta lliçó —i tot el mòdul— passa dins del laboratori legal de TechNova, amb contracte, abast (scope) i regles d'enfrontament (RoE) signats. Objectius: només els autoritzats. Impacte: minimitzat i acordat. Cada acció: documentada.

1. De vulnerabilitat candidata a accés validat
2. Vocabulari essencial: exploit, payload, shell
3. Shells: directa, reverse i bind
4. Del CVE a l'exploit: fiabilitat i risc
5. Exploits públics vs. a mida
6. Verificar un exploit abans de llançar-lo
7. El cicle controlat d'explotació
8. Marc de control d'impacte
9. Errors comuns i consells
10. Exercicis
11. Conclusió

Al Mòdul 3 etiquetàvem cada troballa amb un nivell de confiança: confirmada, probable, a validar. Explotar és el pas que converteix una candidata "probable" en un fet demostrat.

La diferència amb un atacant real és el per a què i el com: l'atacant vol causar dany i persistir; el pentester vol provar el risc amb el mínim impacte i documentar-lo. Per això una prova de concepte (PoC) ben feta no bolca la base de dades sencera ni esborra res: extreu un únic valor de prova —la versió de MySQL, un id, el nom d'un usuari fictici— que demostra l'accés sense abusar-ne.

Tres termes que es confonen constantment i convé separar bé:

Un mateix exploit (el rossinyol) pot dur payloads diferents: un que només mostra un id (prova inofensiva), un altre que obre una shell, un altre que —en mans d'un atacant— xifraria les dades. El pentester tria sempre el payload de menor impacte que demostri el punt. Aquesta elecció és el que fa ètic el procés.

Quan un exploit aconsegueix execució d'ordres, l'objectiu sol ser una shell: una consola remota a la màquina víctima. Hi ha tres models:

La reverse shell és la més comuna perquè els tallafocs solen bloquejar connexions entrants però permeten les sortints. Exemple conceptual d'escolta (el pentester) i de connexió de tornada (payload a la víctima):

Detallat: nc -lvnp 4444 deixa el pentester escoltant al port 4444. El payload de la víctima redirigeix una shell interactiva (bash -i) a través d'una connexió TCP cap a 10.10.10.5:4444. Resultat: el pentester rep una consola. Al laboratori això es fa per demostrar execució, no per instal·lar res persistent (això seria Mòdul 5).

No tots els CVE tenen exploit, i no tot exploit és fiable. Abans de llançar, s'avaluen dos eixos:

• Fiabilitat: funciona de manera consistent o falla la meitat de les vegades? Un exploit poc fiable pot deixar el servei a mitges.
• Risc/impacte: què passa si falla? Els exploits de corrupció de memòria (buffer overflow) poden tombar el servei si la versió no coincideix exactament. Un exploit d'injecció SQL, en canvi, sol ser inofensiu si es controla la càrrega.

Metasploit classifica els seus mòduls amb un camp Rank que ho resumeix:

Regla pràctica: a igualtat de resultat, tria l'exploit més fiable i de menor risc. Una SQLi que llegeix una dada és preferible a un desbordament de pila que podria reiniciar la botiga de TechNova (i provocar una denegació de servei no acordada).

Hi ha dues grans fonts d'exploits:

• Públics: exploit-db, Metasploit, GitHub, PoC d'investigadors. Ràpids, però cal auditar-los abans de fer-los servir.
• A mida: els escrius tu per a una vulnerabilitat concreta (típic en SQLi, XSS o lògica de negoci, on cada aplicació és diferent).

Per buscar exploits públics fem servir searchsploit (la còpia local d'exploit-db a Kali, ja vista a 03-03):

searchsploit -m copia l'exploit a la teva carpeta (mirror), no l'executa. Aquest és el punt: primer es llegeix, després —si escau— es fa servir. La presentació a fons de Metasploit i les altres eines arriba al Mòdul 7; aquí les fem servir de passada.

Mai executis un exploit descarregat sense llegir-lo. Un exploit públic pot:

• Estar dissenyat per a una versió diferent i fallar o tombar el servei.
• Contenir un payload destructiu o fins i tot una porta del darrere contra tu (exploits "troianitzats" que roben qui els fa servir).
• Apuntar per defecte a una IP o domini que no és el teu.

Checklist mínim de verificació:

1. Llegeix-lo sencer. Entén quina vulnerabilitat ataca i quin payload duu per defecte.
2. Confirma la versió objectiu. Ha de coincidir amb el que es va enumerar a 03-02.
3. Identifica l'impacte. Només prova, o modifica/esborra alguna cosa? Ajusta'l a una PoC de baix impacte.
4. Revisa adreces i credencials incrustades. Que apunti a 10.10.10.x del laboratori, no a un tercer.
5. Prova'l primer en una rèplica si l'actiu és delicat.

Aquesta disciplina no és burocràcia: és el que separa una validació controlada d'un incident autoinfligit al sistema del client.

Tota explotació en aquest curs segueix el mateix cicle, pensat per maximitzar evidència i minimitzar dany:

1. Verificar abast: l'actiu és dins l'scope? Si no, no es toca. Punt.
2. Verificar l'exploit: el checklist de l'apartat 6.
3. PoC de baix impacte: executar la mínima prova que demostri la fallada (llegir una versió, un id, un valor sentinella).
4. Capturar evidència: ordre exacta, sortida, marca de temps, captura de pantalla. És la matèria primera de l'informe (Mòdul 6).
5. Aturar-se i documentar: l'explotació acaba quan s'obté accés/execució. El que es fa després (escalar, persistir, pivotar) és Mòdul 5.

Aquest és el cor ètic del mòdul. Abans de cada acció, tres preguntes:

• Està autoritzat? L'actiu dins l'scope i la tècnica permesa per les RoE.
• És reversible / de baix impacte? Preferir sempre la prova que no altera dades ni disponibilitat. Res d'esborrar taules, xifrar fitxers ni llançar denegacions de servei no acordades.
• Queda documentat? Cada ordre i el seu resultat, amb hora, per poder reconstruir i perquè el client ho pugui auditar.

Si una prova només es pot demostrar causant dany real, es documenta el risc i s'acorda amb el client abans de procedir; no s'improvisa.

• Executar exploits sense llegir-los. És la via més ràpida a tombar el servei del client o a infectar-te tu. Verifica sempre (apartat 6).
• Sortir-se de l'abast per inèrcia. Trobar una porta oberta a un sistema no autoritzat no dona dret a entrar. Fora de l'scope, es reporta, no s'explota.
• Triar el payload més potent "per si de cas". L'objectiu és demostrar, no dominar. El payload de menor impacte que prova el punt és el correcte.
• No capturar evidència. Una explotació sense ordre, sortida i hora registrats és una troballa que no podràs defensar a l'informe.
• Confondre explotar amb post-explotar. Aquí acaba al foothold (accés obtingut). Escalar i persistir és Mòdul 5; avançar-ho trenca el fil i el control.
• Llançar mòduls DoS o de força bruta sense acord. Poden causar caigudes o bloquejos de comptes reals. Requereixen autorització explícita a les RoE.
• Consell: tracta cada exploit com a codi no fiable i cada actiu com si estigués en producció (sovint ho està). La prudència és una competència professional, no timidesa.

Exercici 1. Tens la candidata #1 del Mòdul 3 (probable SQLi a producto.php?id=). Dissenya una PoC de baix impacte que demostri que la injecció existeix sense extreure dades sensibles ni alterar la base de dades. Indica quin "valor de prova" demanaries i per què és inofensiu.

Exercici 2. Trobes a exploit-db un script en Python per a la consola de debug de Werkzeug (candidata #2). Abans de llançar-lo contra dev:54321, enumera els passos de verificació que aplicaries i explica quin risc concret mitiga cadascun.

Exercici 3. Durant l'auditoria descobreixes que un servidor fora de l'abast (10.20.0.5, una altra xarxa) és trivialment explotable amb un exploit públic. Què fas? Justifica la teva decisió des de les RoE i l'ètica professional.

Solució 1. PoC de baix impacte per a la SQLi: injectar una condició que retorni un valor del propi motor sense tocar dades de clients, per exemple forçar que la consulta mostri @@version o el resultat d'1+1, o comprovar una injecció booleana (id=1 AND 1=1 davant id=1 AND 1=2 i observar la diferència en la resposta). El "valor de prova" seria la versió de MySQL o un 2 com a resultat d'1+1: demostra que l'entrada s'interpreta com a SQL (la vulnerabilitat és real) sense llegir taules d'usuaris ni modificar res. És inofensiu perquè no extreu dades personals, no escriu ni esborra, i és reversible (només llegeix metadades del motor). Tota la sortida es captura com a evidència.

Solució 2. Verificació abans de llançar: (1) llegir l'script sencer per entendre què fa i quin payload duu —mitiga executar codi destructiu o troianitzat—; (2) confirmar que la versió de Werkzeug de l'script coincideix amb l'enumerada a dev:54321 —mitiga fallades o crash per versió equivocada—; (3) revisar IPs/URLs incrustades perquè apunti a 10.10.10.x i no a un tercer —mitiga atacar fora d'abast per descuit—; (4) identificar el payload per defecte i substituir-lo per un de baix impacte (executar id en lloc d'obrir una shell persistent) —mitiga excés d'impacte—; (5) confirmar que l'actiu és dins l'scope i dins la finestra acordada. Només llavors s'executa, capturant ordre i sortida.

Solució 3. No s'explota. 10.20.0.5 és fora de l'abast: tocar-lo seria accés no autoritzat, il·legal i una violació de les RoE, per trivial que sigui. El correcte és documentar la troballa (existeix un sistema explotable i com el vas detectar) i comunicar-lo al contacte del client, suggerint ampliar l'abast si volen que s'avaluï. La facilitat tècnica mai és autorització; el permís el dona el contracte, no la vulnerabilitat.

Ja tenim el marc. Explotar, en un pentest professional, és convertir una vulnerabilitat candidata en risc demostrat, de manera autoritzada, amb el mínim impacte i deixant evidència de cada pas. Hem separat els conceptes que tot el mòdul farà servir —vulnerabilitat, exploit, payload, shell (reverse/bind)—, hem vist com es va del CVE a l'exploit valorant fiabilitat i risc, i hem fixat la disciplina innegociable: llegir i verificar abans de llançar, triar el payload de menor impacte, capturar evidència i aturar-se a l'accés obtingut.

Amb el cicle controlat i el marc de control d'impacte interioritzats, ja podem agafar la llista prioritzada de TechNova i començar per dalt. La lliçó següent, 04-02 Explotació de Vulnerabilitats Web, ataca la candidata número u —la injecció SQL de la botiga— i la resta de classes OWASP que viuen a tienda.technova.lab: cadascuna amb el seu mecanisme, la seva PoC de baix impacte i, sempre, la seva remediació. Baixem del marc a la pràctica.