Arribem a l'última lliçó del Mòdul 3. A 03-01 vam obrir els ports i a 03-02 els vam convertir en un inventari de serveis amb versions: Apache 2.4.29 amb PHP 7.2.24 a la botiga, MySQL 5.5.62 exposat a dev, un Werkzeug de desenvolupament al 54321, SMB amb sessió nul·la, SNMP public... Tenim programari concret amb versions concretes. Ara toca la pregunta que ho connecta tot amb l'explotació: quins d'aquests serveis són vulnerables, amb quina gravetat i per on convé començar?

Detectar vulnerabilitats és creuar cada servei/versió amb les bases de dades de vulnerabilitats conegudes (CVE, CPE, NVD, exploit-db) i amb escàners automàtics (Nessus/OpenVAS, nmap --script vuln, nuclei), per després validar-los críticament —separant el fals positiu de la troballa real—. L'entregable és una llista prioritzada de vulnerabilitats candidates que alimenta directament el Mòdul 4. Enquadrament de sempre: els escàners de vulnerabilitats són sorollosos i de vegades intrusius (poden reiniciar serveis fràgils), així que es llancen dins de l'abast, en la finestra acordada i avisant; i detectar no és explotar: aquí identifiquem i prioritzem, no llancem l'exploit.

1. Què és una vulnerabilitat i el cicle CVE
2. El llenguatge comú: CVE, CPE, NVD i CVSS
3. Cerca manual: searchsploit i exploit-db
4. Escaneig amb Nmap: --script vuln
5. Escàners de vulnerabilitats: Nessus i OpenVAS/GVM
6. nuclei: plantilles ràpides
7. Lectura crítica: falsos positius i validació
8. La llista prioritzada de vulnerabilitats de TechNova
9. Contrapartida defensiva
10. Errors comuns i consells
11. Exercicis
12. Conclusió

Una vulnerabilitat és una fallada (de programari, configuració o disseny) que un atacant pot aprofitar per violar la seguretat del sistema. En aquesta fase ens centrem sobretot en vulnerabilitats conegudes: les publicades, amb identificador i sovint amb exploit disponible. El seu cicle de vida:

El pentester treballa en el tram final: hi ha sistemes que no han aplicat el pedaç i segueixen exposats. La nostra feina és detectar aquests casos creuant el que corre (03-02) amb el que se sap que és vulnerable.

Per parlar de vulnerabilitats amb precisió hi ha un vocabulari estàndard:

El pont clau és el CPE: l'identificador de producte+versió que Nmap ja ens va donar a 03-02 (cpe:/a:apache:http_server:2.4.29). Amb aquest CPE es consulta la NVD i surten tots els CVE que afecten aquesta versió. El CVSS dóna una idea ràpida de gravetat; farem servir la puntuació només com a orientació per prioritzar —el detall de com es calcula (vectors, mètriques) és matèria de 06-02—.

Abans dels escàners, la via més directa i controlada és buscar a mà. searchsploit és la còpia local d'exploit-db a Kali:

Lectura: destaca Werkzeug - Debug Shell Command Execution. Si el servidor de desenvolupament del port 54321 té el mode debug activat (el famós PIN de Werkzeug), podria permetre execució de comandes. És una candidata forta per al Mòdul 4. Per consultar el detall o el CPE també serveix el web de la NVD filtrant per producte i versió.

La NSE inclou una categoria vuln que comprova vulnerabilitats conegudes contra els serveis detectats. És el pas natural després de l'enumeració:

Anàlisi línia a línia:

• http-slowloris-check ... LIKELY VULNERABLE (CVE-2007-6750): possible denegació de servei Slowloris. Compte: els scripts DoS poden tombar el servei; molts només ho comproven sense llançar-ho, però cal fer-los servir amb permís.
• http-csrf: possible manca de protecció CSRF a /login.php.
• http-sql-injection: Possible sqli for query: /producto.php?id=1': possible injecció SQL al paràmetre id de producto.php —just el paràmetre que el recon va marcar a la botiga—. És un candidat molt prometedor.

Fixa't en les paraules: "Possible", "LIKELY". Nmap assenyala candidates, no confirma. La validació és l'apartat 7.

Per a cobertura àmplia es fan servir escàners dedicats, que proven milers de comprovacions i generen informes amb gravetat. Els dos més habituals:

Exemple conceptual de resultat d'un escaneig autenticat sobre dev:

Cada línia porta CVE, gravetat i una puntuació CVSS orientativa. Molt potent, però amb dues advertències importants: són sorollosos (un IDS els detecta a l'instant) i generen falsos positius (per això l'apartat següent). Els escaneigs autenticats (amb credencials que doni el client) són molt més fiables que els no autenticats, perquè veuen les versions reals en lloc d'endevinar.

nuclei comprova vulnerabilitats i exposicions mitjançant plantilles (YAML) mantingudes per la comunitat. És ràpid, precís i molt usat per a superfície web:

Detecta el phpinfo.php, confirma PHP fora de suport i —troballa nova— un .git/config exposat, que podria permetre descarregar el codi font. nuclei brilla pel seu baix soroll relatiu i la seva base de plantilles actualitzada.

Aquest és l'apartat que separa un professional d'algú que enganxa la sortida d'un escàner a l'informe. Els escàners s'equivoquen, en dues direccions:

• Fals positiu: reporta una vulnerabilitat que no existeix (p. ex. marca com a vulnerable per número de versió encara que hi hagi un pedaç retroportat per la distribució —molt comú a Debian/Ubuntu—).
• Fals negatiu: no veu una vulnerabilitat real (configuració a mida, servei no reconegut).

Per això tota candidata es valida. Formes de fer-ho sense arribar a explotar:

• Contrastar la versió exacta i el pedaç. Ubuntu sol retroportar correccions sense canviar el número de versió visible; un CVE "detectat" per versió pot estar ja corregit.
• Creuar diverses fonts. Si Nessus, --script vuln i searchsploit coincideixen, la confiança puja.
• Comprovació manual lleugera. Una petició controlada (p. ex. producto.php?id=1' i veure si l'error revela SQL) confirma la sospita sense llançar encara un exploit complet.
• Descartar l'inaplicable. Un CVE d'una funció que el servei no fa servir no és explotable en aquest context.

Cada candidata s'etiqueta amb un nivell de confiança (confirmada / probable / a validar). Sense aquest filtre, un informe s'omple de soroll i perd credibilitat.

Consolidem tot en l'entregable final del mòdul: la llista prioritzada de vulnerabilitats candidates. Combina gravetat (CVSS orientatiu), exposició i confiança després de la validació:

Com es llegeix:

• El que és crític combina alta gravetat, exposició i una via d'accés plausible: la SQLi a la botiga (objectiu principal, a Internet) i la consola de debug de Werkzeug (possible execució de comandes).
• MySQL 5.5 marca CVSS altíssim però queda "a validar" pel possible retroport d'Ubuntu: es comprova abans de donar-lo per bo.
• Les troballes confirmades de configuració (sessió nul·la SMB, .bak/.git, SNMP public) són sòlides encara que el seu CVSS sigui menor, perquè no depenen d'una versió i ja estan verificades.

Aquesta taula és exactament el que el Mòdul 4 necessita: per on intentar entrar primer, amb evidència i confiança associades.

Davant de la detecció de vulnerabilitats, la defensa es juga en la gestió de vulnerabilitats:

• Apedaçar i mantenir suport. El gruix d'aquesta llista s'evapora actualitzant: PHP i MySQL suportats, dependències al dia. No fer servir programari en fi de vida.
• Escaneig propi periòdic. El defensor ha de passar Nessus/OpenVAS abans que l'atacant i prioritzar per CVSS i exposició.
• Corregir configuracions. Treure .bak, phpinfo.php i .git de producció; tancar la sessió nul·la; canviar la comunitat SNMP; desactivar el mode debug de Werkzeug.
• Detecció: els escàners de vulnerabilitats són molt sorollosos; un IDS/IPS i la monitoració de logs detecten l'allau de peticions i sondes. Que el client vegi el teu escaneig a les seves alertes és, de fet, un bon senyal per al seu SOC.

• Copiar la sortida de l'escàner tal qual. Sense validar, l'informe s'omple de falsos positius i perd credibilitat. Valida sempre abans de reportar.
• Ignorar els retroports de la distribució. Un CVE "detectat" per versió pot estar ja apedaçat a Ubuntu/Debian. Comprova l'estat real del pedaç.
• Llançar escàners sense avisar. Són intrusius; alguns scripts (DoS, força bruta) poden tombar serveis. Finestra acordada i avís al contacte tècnic, sempre.
• Confondre detectar amb explotar. Aquí produeixes candidates prioritzades; llançar l'exploit és el Mòdul 4 i requereix que l'abast ho autoritzi.
• Obsessionar-se amb el CVSS. Una SQLi al web públic pesa més que un CVSS 9.8 en un servei inaccessible. Creua gravetat amb exposició i confiança.
• Oblidar les troballes de configuració. Sessió nul·la, .git exposat o SNMP public no tenen CVE però solen ser les vies més fiables. No les infravaloris.
• Consell: combina sempre escàner + cerca manual + validació. L'automatització cobreix volum; el criteri humà decideix què és real i què importa.

Exercici 1. Un escaneig amb Nessus marca MySQL 5.5.62 com a CRÍTIC (CVSS 9.8) a dev. Descriu els passos que faries per validar si és una troballa real o un fals positiu, sense arribar a explotar-lo, i menciona almenys una causa habitual de fals positiu a Ubuntu.

Exercici 2. De l'inventari de TechNova tens dues candidates: (a) una possible SQLi a tienda.technova.lab/producto.php?id= (Internet, objectiu principal) i (b) un CVE d'OpenSSH 7.6 d'enumeració d'usuaris a dev (intern). Ambdues "detectades" per escàner. Prioritza per al Mòdul 4 i justifica creuant gravetat, exposició i confiança.

Exercici 3. Explica per què una troballa sense CVE com la sessió nul·la d'SMB amb el recurs RRHH accessible pot ser més valuosa per al Mòdul 4 que un CVE amb CVSS 9.8 detectat només per número de versió.

Solució 1. Passos de validació: (1) confirmar la versió exacta amb nmap --script mysql-info i banner, no refiar-se només de l'escàner; (2) comprovar l'estat del pedaç: a Ubuntu els paquets conserven el número de versió (5.5.62-0ubuntu…) encara que s'hagin retroportat correccions de seguretat —causa habitual de fals positiu—, així que cal mirar el changelog del paquet i els avisos de seguretat d'Ubuntu (USN); (3) creuar fonts: veure si searchsploit i la NVD confirmen que aquest CVE aplica a aquesta build concreta i que la funcionalitat afectada està en ús; (4) etiquetar la candidata com a "confirmada" o "descartada" segons el resultat. Tot sense llançar l'exploit: només verifiquem aplicabilitat.

Solució 2. Prioritat: 1r (a) la SQLi de la botiga. Encara que ambdues les marqui un escàner, la SQLi combina gravetat molt alta (accés potencial a la base de dades), màxima exposició (Internet, objectiu principal de l'abast) i una via d'accés directa; es valida amb una comprovació manual lleugera (id=1') que puja ràpid la confiança. 2n (b) l'enumeració d'usuaris d'OpenSSH: gravetat mitjana, exposició baixa (host intern) i només aporta noms d'usuari, no accés; és útil com a suport (alimenta atacs de contrasenyes), no com a via principal. El criteri: a igualtat de "detectat per escàner", manen exposició i impacte real.

Solució 3. Perquè la sessió nul·la d'SMB està confirmada i és directament accionable: ja sabem que dóna accés a usuaris reals i a documents de RRHH sense credencials, és una via real i verificada. En canvi, un CVE 9.8 "detectat només per número de versió" és una sospita sense validar: pot ser un fals positiu (pedaç retroportat), pot requerir condicions que no es compleixen, o no tenir exploit fiable. En pentesting val més una via modesta confirmada que una crítica incerta: la primera és una entrada; la segona, encara una hipòtesi.

Tanquem el Mòdul 3. Vam començar amb una llista d'hosts vius i l'hem convertida, pas a pas, en una cosa accionable: primer els ports oberts (03-01), després els serveis amb versions (03-02) i ara una llista prioritzada de vulnerabilitats candidates (03-03), cadascuna amb la seva referència, la seva gravetat orientativa i —el més important— el seu nivell de confiança després de validar-la. Hem après el llenguatge comú (CVE, CPE, NVD, CVSS), a buscar a mà (searchsploit/exploit-db) i amb escàners (--script vuln, Nessus, OpenVAS, nuclei), i a llegir els seus resultats amb esperit crític per no ofegar-nos en falsos positius.

Recapitulant el mòdul sencer: el reconeixement ens va dir on mirar; l'escaneig i l'enumeració ens han dit què hi ha exactament i què d'això és feble. TechNova ja no és una caixa negra: sabem que la seva botiga exposa una probable injecció SQL i fitxers sensibles, que dev corre una consola de debug i una base de dades antiquada exposada, i que la xarxa interna regala informació per SMB i SNMP. Tot documentat, validat i ordenat per prioritat.

I aquí acaba la feina d'"identificar". Fins ara no hem explotat res: hem dibuixat el mapa de portes febles. Al Mòdul 4: Explotació de Vulnerabilitats, agafarem la candidata número u d'aquesta llista i passarem —sempre dins de l'abast, amb permís explícit i control de l'impacte— de "això sembla vulnerable" a "això és explotable i això és el que un atacant aconseguiria". La primera lliçó, 04-01 Introducció a l'Explotació, arrenca just aquí: amb la nostra llista prioritzada de vulnerabilitats candidates a la mà.