A la lliçó anterior vas col·locar el mapa: els dominis de la disciplina, els marcs que l'organitzen i —sobretot— el cicle de vida d'un atac. Ara omplirem aquest esquelet de contingut. Aquesta lliçó recorre els atacs tècnics que s'executen contra sistemes com el de Nimbus Reservas, ordenats per la fase de la cadena en què apareixen: com l'adversari recull informació, com ataca la xarxa, com aconsegueix credencials, com explota una aplicació web, com desplega ransomware o compromet una cadena de subministrament i com abusa d'una API. De cadascun en veuràs què és, un exemple mínim i conceptual sobre l'arquitectura de Nimbus, com es detecta i cap on apunta la seva defensa. L'enfocament és defensiu en tot moment: els exemples són il·lustratius, mínims i sempre acompanyats de la seva correcció. Conèixer l'atac no és un fi, és el requisit per dissenyar la defensa.

1. Com s'organitza aquest catàleg i un advertiment previ
2. Fase 1 — Reconeixement: OSINT i escaneig
3. Atacs a la xarxa: escolta, suplantació i interposició
4. Denegació de servei: volumètrica i aplicativa
5. Atacs a credencials i sessions
6. Atacs a aplicacions web: el Top 10 d'OWASP com a marc
7. Programari maliciós en acció: ransomware modern i doble extorsió
8. Atacs a la cadena de subministrament
9. Atacs específics a API
10. Un atac encadenat sobre Nimbus, pas a pas
11. Taula resum: atac, propietat afectada, detecció i defensa

Un catàleg d'atacs sense estructura és una llista impossible de recordar. Per això fem servir l'eix que ja coneixes —les fases de la Kill Chain— i hi afegim una segona clau de lectura: quina propietat de la tríada CIA trenca cada atac, la que vas establir a 01-01.

Advertiment necessari. Tot el que segueix està escrit per defensar. Aquí no hi trobaràs eines llestes per atacar, codi funcional de programari maliciós ni instruccions aplicables a sistemes de tercers. Els exemples són fragments mínims sobre l'entorn fictici de Nimbus, sempre amb la seva correcció al costat. Executar qualsevol d'aquestes tècniques contra sistemes que no són teus i sense autorització expressa i per escrit és un delicte; el marc legal i ètic de les proves autoritzades es tracta a 06-06, i la metodologia de les proves de penetració a 05-03.

El reconeixement és la fase que les organitzacions ignoren perquè no deixa rastre als seus sistemes: bona part passa sense tocar-los.

Què és. Recopilar informació públicament disponible sobre l'objectiu. No s'explota res; es llegeix el que l'organització ha publicat sense adonar-se'n.

Què troba un atacant sobre Nimbus sense tocar ni un sol servidor:

Com es defensa. No es pot impedir que algú llegeixi el que és públic, però sí reduir el que es publica sense voler:

• Revisar periòdicament els subdominis que apareixen en transparència de certificats i retirar els que ja no existeixen (és la troballa de l'exercici 3 de la lliçó anterior).
• Escanejar l'històric dels repositoris buscant secrets —no n'hi ha prou d'esborrar el fitxer: a Git continua estant a l'historial— i rotar qualsevol credencial exposada.
• Netejar metadades dels documents publicats.
• Assumir que la llista de correus de l'equip és pública. La defensa no és amagar-la, és MFA i formació (02-03, 02-05).

Què és. Contactar activament amb els sistemes de l'objectiu per descobrir què hi ha: quines IP responen, quins ports estan oberts, quins serveis i versions corren, quines rutes existeixen a l'aplicació web.

A diferència de l'OSINT, l'escaneig sí que deixa rastre. I aquí hi ha l'asimetria important per a una pime: Nimbus ja està sent escanejada contínuament per bots que no saben què és. Distingir l'escaneig dirigit del soroll de fons és difícil; el que sí que és factible és fixar-se en escanejos lents, ordenats i des d'una mateixa font, que suggereixen interès real.

Com es llegeix aquest extracte:

• Sis peticions en sis segons des de la mateixa IP, totes a rutes que no existeixen a Nimbus. És un escàner automatitzat provant el catàleg habitual.
• /wp-login.php i /phpmyadmin/ delaten que el bot no sap quina tecnologia fa servir Nimbus: ho prova tot. Això és l'atac oportunista de 01-04 en estat pur.
• El senyal defensiu més valuós no és als 404, sinó el dia que un d'ells retorni 200. Per això l'alerta útil no és «tenim escanejos» (els tens sempre), sinó «una ruta sensible ha retornat alguna cosa diferent de 404».

Les eines de descobriment i escaneig es veuen a 05-01 i 05-03. Aquí interessa el concepte i la seva contrapartida defensiva: cada servei que no exposes és un servei que no apareix en cap escaneig.

Aquests atacs ataquen el canal, no els extrems. Comparteixen una premissa: si l'atacant aconsegueix estar al mig o escoltar, la seguretat dels extrems deixa de bastar.

És la pregunta correcta. TLS ben implementat fa que l'escolta passiva sigui inútil: l'atacant veu trànsit xifrat. Però queden tres forats reals a Nimbus:

1. El trànsit intern que no va xifrat. Al DFD de 01-04, el flux F3 (balancejador → API) era HTTP intern. Algú que arribi a aquesta xarxa el llegeix en clar. És el motiu del principi Zero Trust: la xarxa interna no és de confiança.
2. Les metadades continuen visibles. Encara que el contingut estigui xifrat, un observador veu a quins dominis et connectes, quan i quin volum. La consulta DNS prèvia sol anar en clar.
3. La degradació i l'error d'usuari. Si un portàtil de Nimbus accepta un certificat no vàlid amb un clic, TLS deixa de protegir. Per això existeix HSTS (que veurem a 02-04) i per això els clients han de rebutjar, no preguntar.

Exemple mínim de l'error clàssic al codi de Nimbus:

Per què verify=False és tan greu i tan freqüent: desactiva la comprovació que el certificat presentat correspon realment al domini i està signat per una autoritat reconeguda. El trànsit continua xifrat, cosa que dona una falsa sensació de seguretat, però xifrat contra l'atacant si aquest s'hi ha interposat. Apareix gairebé sempre com a pedaç temporal en un entorn de proves i acaba a producció. Regla pràctica: verify=False no ha d'existir en cap repositori; si un certificat intern dona problemes, la solució és afegir l'autoritat interna al magatzem de confiança, no desactivar la verificació. Una anàlisi estàtica al CI (02-04) ho detecta automàticament.

L'objectiu és la disponibilitat: impedir que els clients de Nimbus facin servir el servei. Per a un SaaS del qual depenen agendes de clíniques en marxa, una hora de caiguda té un cost immediat i visible.

El més perillós per a Nimbus és el tercer, i és el més subestimat. Recorda l'endpoint d'informes sense paginació que trencava la disponibilitat a 01-01: 20 peticions ben triades poden tombar l'API, mentre que un DDoS volumètric requereix una botnet. La defensa contra el volumètric es compra (servei anti-DDoS del proveïdor); la defensa contra l'aplicatiu es programa.

Les quatre defenses que apareixen aquí, explicades:

1. Validació de tipus (des_de: date en lloc de str): rebutja entrades malformades abans d'arribar a la base de dades.
2. Límit de negoci (92 dies): un informe d'ocupació de deu anys no és un cas d'ús legítim. Els límits de negoci són més efectius que els tècnics perquè són defensables davant del client.
3. Paginació amb LIMIT: acota la memòria i el temps de cada petició, passi el que passi.
4. Límit de taxa (5/minute): acota quantes vegades es pot pagar aquest cost. Sense ell, els altres tres límits només obliguen l'atacant a repetir més.

Detecció: latència mitjana de l'API disparada amb poc trànsit entrant, consultes lentes a PostgreSQL concentrades en un endpoint, i un mateix user_id o token concentrant la major part del consum. Aquests senyals, en un DDoS volumètric, serien diferents: molt trànsit i saturació de xarxa.

La identitat és avui la via d'entrada dominant, perquè una credencial vàlida no dispara cap alarma: no hi ha exploit, no hi ha programari maliciós, no hi ha anomalia de protocol. Només algú entrant.

Mereix atenció especial perquè està dissenyat per eludir el bloqueig de compte. Si Nimbus bloqueja després de 5 intents fallits per compte, l'atacant prova una sola contrasenya molt comuna contra els 38 comptes de l'equip, espera una hora i prova la següent. Cap compte no arriba mai a 5 errors.

Com es llegeix: quatre errors i un èxit, un intent per compte, mateixa IP, quatre segons entre cadascun, a les 2 de la matinada. Cap compte no ha arribat al llindar de bloqueig, i tanmateix l'atac ha tingut èxit. La detecció correcta no compta errors per compte, sinó errors diferents per origen i la relació entre comptes atacats i comptes existents. Aquesta és exactament la mena de regla que es construeix a 05-02.

La defensa que el neutralitza gairebé del tot és l'MFA resistent al phishing, juntament amb la comprovació de contrasenyes contra llistes de filtrades. Totes dues es desenvolupen a 02-05.

A l'inventari vas descobrir un token del compte nimbus-deploy-bot sense caducitat i amb permisos d'escriptura a tots els repositoris. Un token així té tres propietats que el converteixen en l'objectiu perfecte:

• No caduca: robar-lo un cop n'hi ha prou per sempre.
• No té segon factor: un token és la credencial completa.
• És a molts llocs: a la configuració del CI, al portàtil de qui el va crear, potser en un fitxer .env, potser a l'historial d'un xat.

La seva correcció —caducitat curta, àmbit mínim, credencials efímeres del propi CI i rotació— es detalla a 02-05.

L'OWASP Top 10 és la llista de les deu categories de risc més esteses en aplicacions web. No és un catàleg exhaustiu de vulnerabilitats: és una llista de categories per freqüència i impacte, i per això funciona bé com a guia de revisió. Recorrem les més rellevants per a l'API de Nimbus.

És la primera categoria del Top 10 per prevalença, i ja te la vas trobar a 01-01.

Què és. El sistema autentica correctament («sé qui ets») però no autoritza correctament («no comprovo que això sigui teu»).

Variants de la mateixa família que convé reconèixer:

• Escalada horitzontal: accedir a dades d'un altre usuari del mateix nivell (l'IDOR clàssic).
• Escalada vertical: un usuari de recepció aconsegueix funcions d'administrador perquè el control només és a la interfície i no al servidor.
• Manipulació de paràmetres: enviar {"rol": "admin"} al cos d'una actualització de perfil i que el servidor ho accepti perquè fa una assignació massiva de camps.

Detecció. És difícil des de fora i fàcil des de l'auditoria: si el registre anota usuari, tenant i recurs, una consulta que busqui accessos on el tenant del recurs no coincideix amb el de l'usuari troba els intents. Sense aquest registre, és invisible. Vet aquí per què l'auditoria de 01-01 i 01-03 no era burocràcia.

Què és. La dada de l'usuari es concatena en una consulta i el motor la interpreta com a instrucció en lloc de com a dada.

Si text conté una cometa, l'estructura de la consulta canvia. N'hi ha prou amb aquest exemple conceptual: un valor com ' OR '1'='1 transforma la condició de cerca en una condició sempre certa, i la consulta retorna totes les files a les quals el rol de base de dades tingui accés. Variants més avançades permeten llegir altres taules o inferir dades caràcter a caràcter pel temps de resposta (injecció cega).

Per què la parametrització funciona de debò i l'«escapament manual» no: amb paràmetres, el motor rep primer l'estructura de la consulta i després els valors, ja com a dades. No hi ha cap contingut de text que pugui canviar l'estructura, perquè l'estructura ja està fixada. L'escapament manual, en canvi, depèn d'encertar totes les combinacions de cometes, codificacions i modes del motor: tard o d'hora falla.

Segona capa (la que salva quan la primera falla): el rol nimbus_api de 01-03 no té DELETE, no té DDL i no pot llegir nomines ni claus_passarela. Una injecció amb aquest rol és greu, però acotada. I la RLS de PostgreSQL impedeix a més que retorni files d'un altre tenant. Defensa en profunditat en estat pur.

Detecció: errors d'SQL als registres d'aplicació (un syntax error at or near és un senyal inequívoc que algú està provant), pics de consultes anòmalament lentes, i peticions amb cometes o paraules clau SQL en paràmetres que no haurien de contenir-les mai. Un WAF detecta molts intents, però no substitueix la parametrització.

Què és. L'atacant aconsegueix que el navegador d'una altra víctima executi codi en el context del lloc de Nimbus. La víctima no és el servidor: és l'usuari.

Exemple conceptual i mínim. El camp «notes» d'una reserva admet text lliure. Si la SPA l'insereix a la pàgina sense escapar, un text que contingui una etiqueta <script> s'executarà al navegador de la recepcionista de la clínica que obri aquella cita. L'impacte no és «una finestra emergent»: és que aquest codi actua amb la sessió de la recepcionista, i pot llegir l'agenda completa o fer accions en nom seu.

Les tres capes de defensa contra XSS, per ordre d'importància:

1. Codificació a la sortida segons el context. La mateixa dada s'escapa diferent en HTML, en un atribut, en JavaScript o en un URL. Els motors de plantilles moderns i els frameworks de SPA ho fan per defecte; el problema apareix quan algú ho desactiva a propòsit (innerHTML, dangerouslySetInnerHTML, |safe).
2. Content-Security-Policy: capçalera que indica al navegador de quins orígens pot carregar i executar codi. Converteix molts XSS explotables en intents fallits. Es detalla a 02-04.
3. Galetes HttpOnly: impedeixen que el JavaScript llegeixi la galeta de sessió, limitant el robatori directe. No impedeixen que el codi actuï en nom de l'usuari. Es detalla a 02-05.

Què és. Un lloc maliciós fa que el navegador de la víctima, ja autenticat a Nimbus, enviï una petició no desitjada. El navegador adjunta la galeta de sessió automàticament, així que la petició sembla legítima.

Exemple a Nimbus: l'administradora d'una clínica està autenticada al tauler i visita una altra pàgina que, sense que ella se n'adoni, envia un formulari a POST /api/v1/usuarios/invitar per donar d'alta un usuari nou amb permisos.

Defenses, i per què cal combinar-les:

Què és. L'atacant aconsegueix que el servidor de Nimbus faci una petició a un URL que ell tria. És especialment perillós al núvol, perquè el servidor és dins de la xarxa privada i pot arribar a llocs on ningú no arriba des de fora.

Exemple a Nimbus: una funcionalitat permet a la clínica indicar l'URL del seu logotip per a les factures, i el servidor la descarrega. Si no es valida, l'atacant pot indicar una adreça interna —el servei de metadades del proveïdor cloud, un tauler administratiu intern, localhost— i fer que el servidor la consulti per ell. El cas més greu és l'accés al servei de metadades de la instància, que en configuracions antigues pot retornar credencials temporals del compte cloud (A-05).

Les quatre decisions del codi corregit: només HTTPS (evita file://, gopher:// i altres esquemes); resolució prèvia del nom i comprovació que la IP no cau en un rang intern; sense seguir redireccions, perquè una redirecció és la forma clàssica de saltar-se la comprovació; i límit de mida perquè la descàrrega no es converteixi en una denegació de servei. Tot i així, la defensa definitiva és d'arquitectura: que aquestes peticions surtin per un proxy de sortida amb llista blanca, i que el servei de metadades exigeixi la versió que requereix token (es veu a 05-07).

Què és. L'aplicació reconstrueix objectes a partir de dades que vénen de fora. Alguns formats permeten que el procés de reconstrucció executi codi.

La regla: pickle, yaml.load sense SafeLoader i equivalents en altres llenguatges mai no s'han d'aplicar a dades que vinguin de fora. Fes servir JSON i valida l'esquema. La validació amb un model explícit aporta a més defensa contra l'assignació massiva de camps: només s'accepten les tres claus declarades.

Menys vistosa i molt freqüent. Formes habituals en una API com la de Nimbus:

• Retornar més del necessari: SELECT * que inclou dni, notes_internes o hash_password, i confiar que la interfície no els mostri. La dada viatja al client i és al navegador.
• Missatges d'error verbosos: una traça completa amb la versió de la biblioteca, la ruta del fitxer i fins i tot la consulta SQL.
• Registrar el que no s'ha de registrar: tokens, contrasenyes o dades de salut als registres. Es tracta a 02-04.
• Objectes accessibles sense autorització: el bucket d'adjunts (A-02) sense política restrictiva. Ja ho vas resoldre amb URL signades de 120 s a 01-03.

L'API de Nimbus arrossega al voltant de 180 dependències transitives de Python. L'Iván ha escrit una fracció mínima del codi que s'executa a producció.

Com es llegeix i què es fa: cada línia és una vulnerabilitat coneguda amb la seva versió corregida. L'important no és la llista, és el procés: que aquesta ordre s'executi a cada construcció, que trenqui la integració quan aparegui alguna cosa de severitat alta i que existeixi un compromís explícit de termini de correcció. Una anàlisi que ningú no llegeix és pitjor que cap, perquè genera la sensació d'estar cobert. El yaml complet del CI és a 02-04.

A 01-02 vas veure la taxonomia de nou famílies de programari maliciós. Aquí interessa com opera avui la que més dany causa a empreses de la mida de Nimbus.

El que va canviar respecte al ransomware clàssic: ja no és un fitxer que xifra un ordinador. És una operació humana, amb diversos grups especialitzats, que dura setmanes i en la qual el xifratge és l'últim pas.

Les tres conclusions defensives que es deriven d'aquesta cronologia:

1. Hi ha tres setmanes de finestra. El ransomware no és instantani: és la conclusió visible d'un compromís llarg. Cada dia d'aquesta finestra és una oportunitat de detecció que Nimbus avui no aprofita perquè ningú no mira els registres.
2. Les còpies són l'objectiu, no un dany col·lateral. L'atacant busca activament les còpies i les esborra. Per això una còpia accessible amb les mateixes credencials que producció no és una còpia: és un fitxer més que es xifrarà. La resposta és la immutabilitat i la separació de comptes (02-04, 04-06).
3. Pagar no resol la fuita. Encara que es pagui i es desxifri, les dades ja van sortir. Per a Nimbus, amb dades de cites de clíniques, això significa notificació de bretxa amb independència de si es recupera el servei. Les implicacions concretes es veuen a 06-03, i la decisió de pagament s'analitza en el cas de Colonial Pipeline a 02-06.

Nota legal: el pagament de rescats té implicacions legals, fiscals i de sancions que varien segons la jurisdicció i la identitat del grup atacant. Qualsevol decisió en un cas real s'ha de consultar amb assessoria jurídica i amb les autoritats competents.

Què és. En lloc d'atacar Nimbus directament, l'adversari compromet alguna cosa en què Nimbus confia i espera que Nimbus la instal·li o l'executi. És un atac d'eficiència extrema: es compromet un i s'arriba a milers.

Per què és tan difícil de detectar: tot l'anterior sembla legítim. Una dependència instal·lada per pip des de l'índex oficial, una acció de CI amb nom conegut, una connexió de la consultora en horari laboral. No hi ha cap anomalia de protocol per detectar; només comportament posterior.

Defenses aplicables avui a Nimbus:

• Fixar versions exactes i un fitxer de bloqueig amb sumes de verificació, perquè la construcció sigui reproduïble.
• Fixar les accions de CI per hash del commit, no per etiqueta:

• Mínim privilegi al CI: que el flux de construcció no tingui accés als secrets de producció, i que els secrets siguin efímers.
• Generar un inventari de components (SBOM) per poder respondre en minuts a «fem servir la biblioteca que acaba de sortir a les notícies?». És l'inventari de 01-04 aplicat al programari.

El tractament del proveïdor com a risc gestionable —avaluació, contracte, revisió— correspon a 04-04.

L'API de Nimbus (A-04) és la seva superfície principal: ~120 endpoints usats per la SPA i l'app mòbil. Els atacs a API no sempre són «vulnerabilitats» en el sentit clàssic; moltes vegades són usos legítims portats a l'extrem.

El punt que més se subestima: l'abús de lògica de negoci. No hi ha cap vulnerabilitat tècnica a reservar i cancel·lar 200 cites; el sistema fa exactament el que se li va demanar. Cap WAF, cap anàlisi estàtica i cap escàner no ho detecten, perquè no hi ha res malformat. Només ho detecten límits de negoci pensats per algú que coneix el domini, i alertes sobre mètriques de negoci (taxa de cancel·lació anòmala en un tenant). És la raó per la qual la seguretat no es pot delegar del tot a les eines.

Els atacs reals no són una tècnica: són una cadena en què cada baula aprofita l'anterior. Reconstruïm-ne un de complet, connectant el que hem vist a la lliçó.

On es trenca aquesta cadena, baula per baula:

L'observació decisiva: de les vuit baules, cinc es trenquen amb mesures que costen poc o res —caducitat de tokens, àmbit mínim, filtre de tenant, límit de taxa i una alerta de volum—. Cap no requereix comprar un producte. I la baula 6 ja estava trencada d'antuvi gràcies a una decisió de disseny presa a 01-03: les URL signades de vida curta. Això és exactament el que significa «defensa en profunditat» quan funciona.

Errors comuns:

• Estudiar els atacs com una llista de noms. El que cal retenir de cadascun són tres coses: quina propietat trenca, quin senyal deixa i quin control el neutralitza. El nom és el de menys.
• Creure que HTTPS resol els atacs de xarxa. Resol l'escolta del contingut extern. No cobreix el trànsit intern en clar, ni les metadades, ni l'usuari que accepta un certificat no vàlid.
• Confiar el filtratge d'entrades a una llista negra. Intentar prohibir ', <script> o UNION sempre es pot eludir amb codificacions. La defensa correcta és estructural: parametritzar consultes i codificar a la sortida.
• Pensar que un WAF substitueix el codi correcte. Un WAF és una capa útil que dona temps; no arregla una injecció ni un control d'accés trencat.
• Ignorar el DDoS aplicatiu. S'inverteix en protecció volumètrica mentre un sol endpoint sense paginació permet tombar el servei des d'un portàtil.
• Tractar el ransomware com un problema d'antivirus. És una operació de setmanes el desenllaç de la qual el decideixen les còpies immutables, l'MFA i la segmentació, no la signatura del fitxer final.
• Suposar que les dependències són problema d'altres. El 95 % del codi que corre a producció no l'ha escrit l'Iván, i les vulnerabilitats d'aquest 95 % són igual d'explotables.
• Oblidar la lògica de negoci. Cap eina no detecta l'abús d'una funcionalitat que funciona exactament com es va dissenyar.

Consells:

• Quan revisis un endpoint, fes-te quatre preguntes en aquest ordre: qui ets? (autenticació), és teu? (autorització), és vàlid el que envies? (validació) i quant costa això? (límits).
• Busca al repositori de Nimbus aquests cinc patrons: verify=False, SELECT *, concatenació de cadenes en SQL, innerHTML i pickle.loads. Hi trobaràs la major part del risc d'aplicació en menys d'una hora.
• Per a cada atac nou que aprenguis, escriu la consulta de registre que el detectaria. Si no la pots escriure, no el detectaràs.
• Practica l'exercici de la cadena: agafa qualsevol incident i pregunta't en quina baula hauria estat més barat trencar-lo. Gairebé sempre és una de les primeres.
• Recorda que la majoria dels atacs amb èxit no fan servir exploits: fan servir credencials vàlides i configuracions oblidades.

Per a cadascun d'aquests extractes o fets observats a Nimbus, indica: quin atac suggereix, quina propietat CIA hi ha en joc, què comprovaries a continuació i quina defensa correspon.

Els fragments següents són al codi de Nimbus. Per a cadascun: identifica la vulnerabilitat, explica com s'explotaria conceptualment, reescriu el codi corregit i afegeix una segona capa de defensa independent del codi.

Nimbus pateix l'incident següent:

1. El Rubén rep un correu amb un fitxer adjunt que diu ser una incidència d'una clínica client. L'obre.
2. El seu portàtil executa un component que estableix un canal sortint amb l'atacant.
3. L'atacant extreu del navegador del Rubén la galeta de sessió del tauler intern de suport, que no caduca fins passats 30 dies.
4. Amb aquesta galeta entra al tauler de suport sense passar per l'inici de sessió ni per l'MFA.
5. Des del tauler de suport, que permet «veure com a client», accedeix a les dades de 40 clíniques.
6. Exporta un CSV amb 120.000 registres de cites fent servir la funcionalitat d'exportació del tauler.
7. Tres dies després, l'exportació apareix publicada en un fòrum.

Es demana: (a) assigna cada pas a la seva fase de la Kill Chain i a la tècnica del catàleg d'aquesta lliçó; (b) indica dos controls per pas que l'haurien trencat; (c) explica per què l'MFA no va protegir al pas 4 i quina mesura concreta sí que ho hauria fet; (d) digues en quin pas la detecció hauria estat més fàcil i quin senyal exacte hauries buscat.

Solució 1

Solució 2

(a) Cercador de clients. Vulnerabilitats: injecció SQL per concatenació i exposició excessiva per SELECT *. Explotació conceptual: un valor de q amb una cometa tanca la cadena i permet afegir condicions, convertint el filtre en una condició sempre certa i retornant el contingut complet de la taula accessible al rol.

Segona capa independent del codi: el rol nimbus_api sense DELETE ni DDL (01-03) i la RLS per tenant_id, que impedeix retornar files alienes encara que la consulta es manipuli. El LIMIT 50 afegeix a més protecció contra l'extracció massiva i el mínim de 3 caràcters evita el cercador buit que retorna tota la base.

(b) Descàrrega d'adjunts. Vulnerabilitat: control d'accés trencat — es descarrega qualsevol clau del bucket sense comprovar que la reserva pertany al tenant de l'usuari. A més pot permetre recorregut de rutes si la clau conté ../. Explotació conceptual: coneguda o endevinada una clau, qualsevol usuari autenticat descarrega l'adjunt d'una altra clínica: un informe mèdic escanejat.

Canvis clau: el client ja no tria la clau de l'objecte, sinó l'identificador de la seva reserva; la clau real s'obté de la base de dades després de verificar-ne la propietat; es lliura un URL signat de 120 s en lloc de servir l'objecte; i es registra l'accés. Segona capa: el bucket és privat, la política impedeix l'accés anònim i l'API no té permís d'esborrament sobre ell (01-03).

(c) Webhook de pagament. Vulnerabilitats: suplantació (no es verifica que el missatge vingui de la passarel·la) i manipulació de la integritat (qualsevol pot marcar factures com a pagades). Explotació conceptual: una petició HTTP a aquest endpoint amb un JSON adequat converteix una factura impagada en pagada. És l'amenaça S del flux F8 del DFD de 01-04.

Segona capa: confirmar l'estat contra l'API de la passarel·la abans de donar per bona una operació econòmica, i restringir l'origen a les IP publicades pel proveïdor. L'HMAC s'explica en detall a 03-04.

Solució 3

(a) i (b) Cadena, tècniques i controls:

(c) Per què l'MFA no va protegir. L'MFA es verifica en el moment de l'inici de sessió i produeix una sessió. Si l'atacant roba la sessió ja emesa, no torna a passar per l'autenticació: entra directament amb un artefacte vàlid. Aquesta és l'essència del pass-the-cookie i la raó per la qual «tenim MFA» no és una resposta completa.

El que sí que hauria funcionat, per ordre d'eficàcia:

1. Vincular la sessió a un context (dispositiu, IP o certificat de client), de manera que una galeta usada des d'un altre equip s'invalidi.
2. Sessions curtes amb renovació silenciosa: una galeta de 30 dies és una credencial permanent disfressada. Hores, no setmanes.
3. Reautenticació per a operacions sensibles: suplantar un client o exportar dades exigeix tornar a presentar el segon factor, encara que la sessió sigui vàlida.
4. Enllaç criptogràfic del token al client (token binding / claus lligades al dispositiu), que és la línia cap a la qual apunten les passkeys (02-05).

(d) On detectar i quin senyal buscar. El punt més fàcil és el pas 6: una exportació de 120.000 registres que abasta 40 tenants diferents és un esdeveniment quantitativament únic en l'operació normal de Nimbus. La consulta de detecció és directa sobre la taula d'auditoria append-only de 01-01:

L'important d'aquesta consulta no és el seu SQL, sinó la seva premissa: només funciona si l'auditoria registra sessio_id, tenant_id i num_registres. La detecció no s'improvisa quan passa l'incident; es dissenya quan s'escriu el registre. Un segon senyal útil, més primerenc, és el pas 4: una sessió activa sense esdeveniment d'autenticació previ al registre és una anomalia que no té explicació legítima.

Ja coneixes l'adversari en acció. Has recorregut els atacs ordenats per les fases de la cadena: el reconeixement que passa sense tocar els teus sistemes —OSINT en certificats, repositoris i ofertes de feina— i l'escaneig que sí que deixa rastre, amb la lliçó pràctica que l'alerta útil no és «ens escanegen» sinó «una ruta sensible ha deixat de retornar 404». Has vist els atacs a la xarxa —escolta, ARP i DNS spoofing, interposició— i per què continuen important en un món amb HTTPS: pel trànsit intern en clar, per les metadades i pel verify=False que algú va deixar a producció. Has distingit la denegació de servei volumètrica, en què es compra defensa, de l'aplicativa, que es programa, i has comprovat que vint peticions ben triades fan més mal que una botnet quan falta la paginació.

En credencials has après a distingir força bruta, diccionari, password spraying —dissenyat precisament per eludir el bloqueig per compte—, credential stuffing i robatori de sessió, amb la idea incòmoda que una credencial vàlida no dispara cap alarma. En aplicacions web has recorregut el Top 10 d'OWASP sobre l'API de Nimbus: control d'accés trencat i IDOR, injecció SQL i per què la parametrització funciona on l'escapament manual falla, XSS amb les seves tres capes de defensa, CSRF, SSRF i la seva ruta cap a les credencials del compte cloud, deserialització insegura, exposició de dades i dependències vulnerables. Has entès el ransomware modern com una operació de tres setmanes el desenllaç de la qual el decideixen les còpies immutables, no l'antivirus; els atacs a la cadena de subministrament, on tot sembla legítim; i els atacs a API, amb l'abús de lògica de negoci que cap eina no detecta. I has reconstruït una cadena completa sobre Nimbus, comprovant que cinc de les seves vuit baules es trenquen amb mesures que no costen diners.

Falta el vector que encapçala gairebé totes les estadístiques i que no apareix en cap de les tècniques anteriors: la persona. A la lliçó següent, Enginyeria Social i Phishing (02-03), veurem per què el factor humà és la via dominant, quins principis d'influència exploten els atacants, el catàleg complet de tècniques —del phishing massiu al frau del CEO dirigit a la Sara, el vishing, el quishing i el consent phishing—, com desmuntar un correu maliciós indicador per indicador llegint-ne les capçaleres, i les defenses tècniques i de procés que el contraresten, començant per SPF, DKIM i DMARC.