La lliçó anterior va acabar amb una pregunta que ni l'escàner de 05-01 ni la detecció de 05-02 no responen: aguantaria de debò? Un escàner comprova versions i una detecció observa el que passa, però cap dels dos no intenta encadenar tres debilitats petites —una capçalera absent, un límit de taxa que no existeix i un identificador predictible— fins a convertir-les en un compromís real. Això és el que fa un atacant, i això és el que simula una prova de penetració. Aquesta lliçó t'ensenya a encarregar-la, acotar-la, entendre-la i aprofitar-la, amb un enfocament defensiu: veuràs què es va trobar a l'entorn de Nimbus i, sobretot, com es va corregir cada cosa.

⚠️ Advertiment legal — aquesta és la lliçó més delicada del curs

Executar tècniques d'intrusió sobre un sistema aliè sense autorització escrita és un delicte, no una entremaliadura. A Espanya:

• Art. 197 bis del Codi Penal: accedir o facilitar l'accés al conjunt o a una part d'un sistema d'informació vulnerant les mesures de seguretat, o interceptar transmissions no públiques, es castiga amb pena de presó. No cal causar dany ni copiar res: n'hi ha prou amb accedir.
• Art. 264 i següents: danyar, esborrar, alterar o fer inaccessibles dades o sistemes aliens, amb penes agreujades si afecten infraestructures crítiques o un nombre elevat de sistemes.
• Art. 197 ter: produir, facilitar o posseir eines concebudes per cometre aquests delictes també és punible quan s'hi destinen.

Conseqüències pràctiques: «només volia provar» no és eximent, l'absència de dany no elimina el tipus penal, un nmap intrusiu contra un tercer ja pot constituir un intent, i l'autorització ha de ser escrita, prèvia, signada per qui té capacitat per atorgar-la i vigent en la data de la prova. Al núvol necessites a més l'autorització del proveïdor a més de la del client.

Per això aquesta lliçó no conté exploits, ni payloads, ni ordres d'explotació. Descriu les fases de forma conceptual, mostra la verificació defensiva equivalent i desenvolupa amb detall com es corregeix el que s'ha trobat. El marc ètic i legal complet —inclosa la divulgació responsable i el perquè d'aquestes normes— es desenvolupa a 06-06. (Nota: la qualificació penal concreta depèn del cas; davant de qualsevol dubte, validació jurídica prèvia.)

1. Què és un pentest i què no ho és
2. Modalitats: caixa negra, grisa i blanca
3. Abast i regles d'enfrontament
4. Les fases metodològiques
5. Què passa a cada fase, i el seu equivalent defensiu
6. Recorregut d'una prova autoritzada sobre l'entorn de Nimbus
7. L'informe de pentest
8. Què passa després: esmena i nova prova de verificació
9. Divulgació responsable i bug bounty com a alternativa contínua
10. Com contractar un pentest sent petit
11. On practicar legalment

Un pentest és una prova autoritzada en què un professional intenta comprometre un sistema fent servir les mateixes tècniques que un atacant real, amb un objectiu declarat i un informe com a producte. El seu valor no és trobar vulnerabilitats soltes —per a això hi ha 05-01— sinó demostrar l'impacte encadenant-les.

Per a Nimbus avui, un red team seria llençar els diners. Mesura la capacitat de detecció i resposta, i a 05-02 acabem de construir les primeres dotze deteccions: es contracta quan fa un any que funcionen. El que sí que escau és un pentest anual de l'aplicació i la infraestructura, que és on viuen el producte i el risc.

I una diferència que convé tenir clara: un pentest no demostra que un sistema sigui segur. Demostra que, en un termini acotat i amb un abast acotat, una persona concreta va trobar aquestes coses. Un informe sense troballes sol significar que l'abast era estret o que el temps va ser curt, no que el sistema sigui inexpugnable.

La caixa grisa dona més valor per euro, i en un SaaS multi-tenant la diferència és abismal. El motiu és directe: a Nimbus, el risc principal no és que un desconegut hi entri, sinó que un client legítim vegi les dades d'un altre —l'IDOR d'01-04 és exactament això—. Un pentest de caixa negra no ho hauria trobat mai, perquè per provar-ho cal ser a dins amb dos comptes de dos tenants diferents. Pagar perquè algú dediqui tres dies a descobrir el que un nmap dona en deu minuts és un mal ús del pressupost.

Recomanació per a Nimbus: caixa grisa amb dos comptes de prova de dues clíniques fictícies diferents i un compte de rol suport, més accés de lectura a la documentació de l'API.

Les regles d'enfrontament (rules of engagement) són el document que converteix una intrusió en un servei professional. Sense elles, la prova és legalment fràgil per a totes dues parts i operativament perillosa.

Cinc clàusules mereixen èmfasi. El punt 3 protegeix l'auditor tant com el client: Nimbus no pot autoritzar proves sobre la passarel·la de pagament perquè no és seva, i fer-ho seria exactament el delicte de l'advertiment inicial. L'autorització del proveïdor cloud (punt 1) és obligatòria i molts l'obliden: el proveïdor té una política de proves i saltar-se-la pot suspendre el compte. El punt 5 és el que evita convertir una auditoria en una bretxa: si preproducció té dades reals —recorda A-22, «classificació a revisar»—, descarregar-les crea l'incident que es volia prevenir. El punt 6c existeix perquè passa: de vegades l'auditor troba que ja hi ha algú a dins, i aquí la prova s'atura i s'activa el pla de 04-05. I el punt 8 és el que separa un servei útil d'un informe pòstum: si el dia 2 algú troba la manera de llegir les dades de totes les clíniques, no s'esperen dues setmanes.

Les metodologies reconegudes —PTES, OSSTMM i, per a aplicacions web, l'OWASP Web Security Testing Guide (WSTG)— coincideixen en l'estructura. La WSTG és a més una llista de comprovació pública i gratuïta: si contractes un pentest d'aplicació, demanar cobertura WSTG és la forma més simple de comparar ofertes.

Dos avisos sobre el diagrama. El primer: la fase 4 no és l'objectiu, és la prova. Explotar serveix per demostrar que la vulnerabilitat és real i mesurar-ne l'impacte; un auditor professional explota just el necessari per documentar-ho i s'atura. El segon: la fase 7 és la que gairebé tothom omet, i sense ella no saps si vas pagar per una llista de deures que ningú no va fer.

Sobre les eines esmentades, amb la precisió que exigeix l'enfocament d'aquesta lliçó: nmap i testssl.sh són de reconeixement i verificació i els fas servir tu cada dia; ZAP i Burp són proxies d'intercepció que permeten veure i modificar les peticions que el teu propi navegador envia —el seu ús legítim és contra la teva aplicació—; ffuf i gobuster proven llistes de rutes i fitxers contra un servidor propi per descobrir el que va quedar publicat sense voler; hydra prova credencials, i només té un ús admissible aquí: comprovar sobre els teus propis comptes de prova que el bloqueig per intents fallits i el límit de taxa funcionen, que és una verificació defensiva; i Metasploit és un marc que empaqueta mòduls d'explotació de vulnerabilitats conegudes i l'ús del qual queda dins de l'abast autoritzat i mai en aquest material.

Una observació que estalvia diners: gairebé tot el que un pentest troba de veritat valuós en un SaaS és manual i de lògica de negoci. L'IDOR, el flux de recuperació de contrasenya que permet enumerar usuaris, l'endpoint d'informes que ignora el rol. Cap eina no ho automatitza, i per això es paga per hores d'una persona amb criteri.

La Marta contracta cinc dies de caixa grisa sobre preproducció, amb les regles del §3. Aquestes són les cinc troballes i la seva correcció.

El WHERE tenant_id es va aplicar als endpoints de reserves i clients, però el mòdul d'informes es va escriure després i consulta amb una vista agregada que ningú no va revisar. Amb el compte de la clínica Alfa, canviant un identificador de la petició, s'obtenien totals de facturació de la clínica Beta.

La correcció de fons no és la línia canviada: és que l'identificador de client deixa de ser un paràmetre d'entrada a tota l'API. A més es va activar RLS a la vista agregada, que ja protegia les taules base però no la vista (03-07). La generalització d'aquest patró a tota l'aplicació es desenvolupa a 05-05.

L'auditor va comprovar que es podien enviar 4.000 intents d'autenticació en cinc minuts sense bloqueig ni alentiment: la porta oberta al credential stuffing de 02-02.

I a l'aplicació, bloqueig per compte a més de per IP, perquè el password spraying fa servir una IP diferent per intent: després de 10 fallades sobre el mateix compte en 15 minuts, s'exigeix segon factor o es retarda exponencialment. Tots dos alimenten la detecció D-01 de 05-02.

Faltava Content-Security-Policy a la SPA, cosa que convertia qualsevol XSS en un robatori de sessió complet. Es va desplegar primer en mode informe per no trencar l'aplicació:

Després de revisar els informes i ajustar dos orígens legítims, es va canviar a Content-Security-Policy en mode bloquejant. El conjunt complet de capçaleres i el perquè de cadascuna és a 05-05.

El reconeixement va trobar pruebas-2019.nimbusreservas.example, servit per un host que acceptava TLS 1.0 i suites amb RC4, i apuntant a una IP que ja no estava sota control de Nimbus: candidat a apropiació de subdominis (05-04).

Correcció: eliminar el registre DNS —no aplicar pedaços a un host que ha de desaparèixer, com ja vam concloure a 05-01— i afegir a l'inventari una revisió trimestral de la zona DNS.

Un tauler d'administració de cues, desplegat «temporalment» fa vuit mesos, responia a /flower amb admin/admin i sense autenticació al proxy. Des d'allà es veien els identificadors i els correus de les tasques en curs.

L'accés passa a fer-se per túnel SSH a través del bastió. Aquesta troballa és la més instructiva de les cinc: no és una vulnerabilitat de programari, no té CVE, cap escàner de 05-01 no l'hauria marcada com a crítica i feia vuit mesos que estava exposada. És el mateix patró que el python -m http.server: el que és temporal i s'hi queda.

L'informe és el producte. Un auditor que lliura un bolcat d'eina amb 80 pàgines de sortida sense prioritzar no ha fet la feina, i aquest és el senyal més fiable per no repetir amb aquell proveïdor.

Els elements que el fan accionable són els mateixos de 05-01, amb dos afegits propis del pentest: la reproducció pas a pas —sense ella, el desenvolupador no pot confirmar la correcció— i el criteri de verificació de la nova prova, que fixa per endavant què es considerarà arreglat.

L'error clàssic és arxivar l'informe. El cicle correcte és curt i té propietaris:

1. Reunió de lliurament amb l'auditor, la Marta, la Lucía i l'Iván. Es discuteix cada troballa fins que l'equip l'entén; un informe que es lliura per correu i no s'explica perd la meitat del seu valor.
2. Pla d'esmena amb propietari i data, fent servir la política de terminis de 05-01: crítiques en 7 dies, altes en 30. Cada troballa es converteix en un issue amb criteri d'acceptació.
3. Actualització del registre de riscos de 04-01. L'IDOR residual no és una troballa solta: modifica el risc R-04 (fuita de dades entre clients), el residual del qual estava calculat assumint que el control C-05 estava implantat. Estava implantat a mitges, que és la lliçó de 04-03 sobre implantat davant d'eficaç.
4. Nova prova de verificació (retest), inclosa al contracte original i no com a servei a part. És un exercici curt —normalment un o dos dies— que només comprova les troballes corregides i produeix un annex amb l'estat final. Sense nova prova, el pentest mesura el passat.
5. Lliçons estructurals. Si van aparèixer dos IDOR, el problema no són dues línies: és que l'autorització es decideix a cada ruta. La correcció estructural —la dependència comuna— evita el tercer.

Un pentest anual és una foto; els investigadors externs miren tot l'any. Per a una pime hi ha tres graons, i el primer és gratuït i obligatori:

Advertiment de gestió: un bug bounty sense capacitat de resposta és pitjor que no tenir-lo. Si arriben 40 informes i ningú no els tria en 48 hores, la comunitat ho publica i la reputació (A-20) pateix més que amb la fallada original. L'ètica de la divulgació, els terminis raonables i el conflicte entre investigador i empresa es desenvolupen a 06-06.

Què demanar a la petició d'oferta, i són cinc coses concretes: metodologia declarada (PTES o WSTG), perfil i certificacions nominals de qui l'executarà (no de l'empresa), dies-persona reals dedicats —la variable que determina la qualitat—, nova prova de verificació inclosa, i un informe d'exemple anonimitzat, que és el millor predictor del que rebràs.

Preu orientatiu a Espanya per a una pime: 4.000-8.000 € per una aplicació web amb API, en caixa grisa, 5 dies-persona amb informe i nova prova; 8.000-15.000 € si s'hi afegeixen infraestructura cloud i aplicació mòbil. Cadència raonable: anual, més una prova addicional davant de canvis arquitectònics importants (mòdul nou amb dades sensibles, canvi de proveïdor d'identitat, migració d'infraestructura). Amb 18.000 €/any, Nimbus es pot permetre un pentest anual d'aplicació si accepta que aquest és el desemborsament únic més gran del pressupost, i la decisió és defensable: A-04 és el producte.

Tres senyals d'alarma en comparar ofertes: preu tancat sense conèixer l'abast, «pentest automatitzat» (això és un escaneig amb un altre nom i un altre preu), i negar-se a lliurar un informe d'exemple.

Practicar explotació és necessari per entendre la defensa, i només hi ha un lloc on fer-ho: entorns dissenyats per a això.

La regla, sense matisos: si el sistema no és teu i no tens autorització escrita, no és un laboratori. No ho són el web de la teva antiga empresa, ni el d'un proveïdor que «segur que ho agrairà», ni el d'un familiar. Els laboratoris de la taula existeixen precisament perquè mai no hi hagi excusa. I en un entorn professional, aquesta pràctica es fa a més en una xarxa aïllada, amb instantànies i sense connexió a la xarxa corporativa.

• Encarregar un pentest sense autorització escrita ni regles d'enfrontament. Exposa legalment les dues parts i deixa sense marc el que passa si alguna cosa cau.
• Triar caixa negra per «realisme». En un SaaS multi-tenant pagues reconeixement en lloc de profunditat, i el risc principal —fuita entre clients— es queda sense provar.
• Provar contra producció sense necessitat. Si preproducció és equivalent, es prova allà; i si no ho és, arreglar aquesta diferència és més urgent que el pentest.
• No excloure els tercers. No pots autoritzar proves sobre la passarel·la de pagament ni sobre la consultora: no són teus.
• Contractar sense nova prova de verificació. Sense verificació, l'informe descriu un sistema que ja no existeix i ningú no sap si es va corregir.
• Tractar les troballes com a incidències soltes. Dos IDOR no són dos errors: són un patró de disseny de l'autorització.
• Consell: passa-li a l'auditor el resultat de 05-01. Si ja has corregit el que un escàner troba, els seus cinc dies se'n van al que cap eina no veu. És la forma més directa de multiplicar el valor del que pagues.
• Consell: publica avui el teu security.txt. Costa mitja hora, és gratis i determina si la propera fallada que algú trobi arriba a la teva bústia o a un altre lloc.
• Consell: avisa la teva pròpia guàrdia. Amb les deteccions de 05-02 actives, un pentest generarà alertes. Que saltin i s'atenguin és, de fet, una prova gratuïta que la detecció funciona: anota-ho com a verificació.

Un proveïdor envia aquest resum d'abast. Identifica almenys sis problemes i reescriu les clàusules afectades.

Nimbus llança al setembre un mòdul de teleconsulta amb vídeo i notes clíniques. La Marta disposa de 9.000 € per a seguretat ofensiva aquest any i pregunta què contractar.

1. Pentest, red team, auditoria o bug bounty? Justifica-ho.
2. Modalitat i abast concrets, incloent-hi quins comptes i què s'exclou.
3. Com repartir els 9.000 € i què es fa amb el que sobri.

Durant la prova, l'auditor descobreix que el flux de recuperació de contrasenya respon "Correu no registrat" quan l'adreça no existeix i "T'hem enviat un enllaç" quan sí, cosa que permet enumerar quins correus són clients de cada clínica. En un SaaS usat per clíniques de fisioteràpia, saber que una adreça és client ja és informació sensible.

1. Redacta la fitxa de la troballa amb el format del §7, assignant severitat amb criteri.
2. Escriu la correcció en python explicant per què funciona.
3. Indica com es verificaria a la nova prova i quina detecció de 05-02 ho cobriria.

Exercici 1

Exercici 2

(1) Pentest, sens dubte. Red team queda descartat perquè mesura detecció i resposta, i les deteccions de 05-02 fa mesos, no anys, que existeixen: mesuraria un fracàs previsible per un preu molt alt. L'auditoria de compliment respon a una altra pregunta i es tractarà a 06-04. El bug bounty exigeix capacitat de resposta que Nimbus encara no té. I el moment és el correcte: un mòdul amb vídeo i notes clíniques són dades de salut, és una superfície nova i és exactament quan convé provar, abans del llançament i no després.

(2) Modalitat i abast. Caixa grisa, amb dos comptes de clíniques diferents, un compte de pacient i un de suport, més la documentació de l'API i del flux de vídeo. Abast: el mòdul de teleconsulta complet (creació de sala, control d'accés a la sala, notes clíniques, adjunts i el seu xifratge camp a camp de 03-07) més els endpoints de l'API que toca, en preproducció. Exclosos: producció, el proveïdor de vídeo, la passarel·la, el correu transaccional i tota enginyeria social. Es demana cobertura OWASP WSTG i API Top 10 (05-05), amb dues preguntes explícites per a l'auditor: pot un pacient entrar a la sala d'un altre? i pot una clínica veure les notes d'una altra?

(3) Repartiment. ~6.500 € en 5 dies-persona de caixa grisa amb informe i nova prova de verificació inclosa; ~1.000 € reservats per a una segona volta curta si apareixen crítiques que exigeixin redisseny; i ~1.500 € sense gastar fins després de l'informe. El que sobri no es gasta en més ofensiva: es gasta a corregir. L'error més car del sector és consumir el pressupost a trobar i quedar-se sense res per arreglar. A més, gratis: publicar el security.txt i executar 05-01 sobre el mòdul abans que arribi l'auditor, perquè els seus dies es dediquin a la lògica de negoci.

Exercici 3

(1) Fitxa:

La severitat Mitjana i no Baixa és el judici important: el CVSS base la tracta com a fuita menor d'informació, però el grup ambiental de 05-01 la puja pel context de negoci. És justament el que un escàner no pot calcular.

(2) Correcció:

Funciona perquè elimina les tres vies per les quals es filtra la diferència: el missatge, el codi d'estat i el temps. La tercera és la que s'oblida: sense l'anivellament temporal, enviar un correu real triga 300 ms més i l'atacant mesura aquesta diferència amb precisió. El mateix raonament s'aplica al registre de comptes i al canvi de correu, que són els altres dos punts on aquesta fallada reapareix.

(3) Verificació i detecció. A la nova prova s'envien 200 peticions alternant adreces vàlides i invàlides i es comparen cos, codi i distribució de temps: si la latència mitjana dels vàlids difereix de forma consistent, la troballa segueix oberta. La detecció que ho cobreix és una variant de D-01: més de 20 peticions a /auth/recuperar des d'una IP en 5 minuts, o més de 100 correus diferents provats en una hora, amb severitat S3 i bloqueig automàtic per fail2ban —una de les accions que 05-02 va classificar com a segures d'automatitzar per ser reversibles—.

Ara saps què és i què no és un pentest: una prova autoritzada que demostra impacte encadenant debilitats, diferent de l'escaneig (superfície coneguda), de l'auditoria (conformitat) i del red team (capacitat de detecció), amb la seva durada, el seu cost orientatiu i el criteri per triar cadascun —i amb la conclusió que per a Nimbus avui un red team seria llençar els diners—. Saps que un pentest no demostra que un sistema sigui segur, i que un informe sense troballes gairebé sempre significa abast estret o temps curt. Coneixes les tres modalitats i per què la caixa grisa dona més valor per euro en un SaaS multi-tenant: el risc principal no és que hi entri un desconegut, sinó que un client legítim vegi les dades d'un altre, i això només es prova des de dins amb dos comptes.

T'endus la plantilla d'acord d'abast i regles d'enfrontament amb les seves clàusules crítiques: actius exclosos —no pots autoritzar proves sobre tercers—, autorització del proveïdor cloud, finestra i intensitat, prohibició de descarregar dades reals, condició d'aturada per compromís preexistent, contacte d'emergència 24/7 i avís en calent de troballes crítiques. Coneixes les fases metodològiques de PTES/OSSTMM/WSTG i què passa a cadascuna, sempre amb el seu equivalent defensiu: enumera els teus propis subdominis, executa testssl.sh, corregeix el que un escàner veu abans que arribi l'auditor i mesura la teva segmentació tu mateix. I saps el que estalvia diners: el veritablement valuós en un SaaS és manual i de lògica de negoci.

Has recorregut una prova autoritzada real sobre preproducció amb les seves cinc troballes i les seves correccions: l'IDOR residual a informes, resolt fent que el tenant_id deixi de ser un paràmetre d'entrada a tota l'API; el límit de taxa absent, amb limit_req a Nginx i bloqueig per compte per al password spraying; la CSP que hi faltava, desplegada primer en Report-Only; el subdomini oblidat amb TLS obsolet, que s'elimina en lloc d'aplicar-hi pedaços; i la credencial per omissió del tauler de cues, la troballa més instructiva perquè no té CVE, cap escàner no l'hauria prioritzada i és el mateix patró que el http.server: el que és temporal i s'hi queda. Saps què ha de contenir l'informe, com es redacta una troballa amb reproducció pas a pas i criteri de nova prova, i per què lliurar un bolcat d'eina és el senyal per canviar de proveïdor. Saps què passa després: reunió de lliurament, pla amb propietaris i terminis, actualització del risc R-04 al registre de 04-01, nova prova de verificació inclosa al contracte i correcció estructural en lloc de pedaç puntual. I saps enquadrar la divulgació responsable —publica avui el teu security.txt, costa mitja hora— i el bug bounty com a graó posterior que no s'ha d'obrir sense capacitat de resposta, amb el tractament ètic i legal complet esperant-te a 06-06. Finalment, saps contractar: què demanar, què acrediten OSCP i CREST, quant costa, cada quant fer-ho i en quins laboratoris —Juice Shop, DVWA, TryHackMe, HackTheBox— es practica l'explotació, que són l'únic lloc on practicar-la.

Fixa't en quantes de les cinc troballes eren, en el fons, problemes de xarxa i d'exposició: un tauler publicat a la interfície externa del host, un subdomini que apuntava a una IP aliena, un servei accessible des d'on no havia de ser-ho. I recorda el que segueix pendent des de 05-01: PostgreSQL escoltant a 0.0.0.0:5432, SSH obert a tot Internet i la consultora amb accés permanent. A Seguretat en Xarxes (05-04) dibuixem la xarxa de Nimbus tal com està, la redissenyem per zones, tanquem aquests tres forats amb grups de seguretat i bastió, muntem l'accés remot amb WireGuard, arreglem la wifi de convidats i el DNS, i —el més important— comprovem amb proves de connectivitat que la segmentació funciona de debò, perquè un disseny no provat és només un dibuix bonic.