Mòdul Professional 5: Hacking ètic

Índex

L'objectiu d'un procés de hacking ètic no és altre que executar unes pobres (pentest) prèviament acordades amb el client per a verificar el nivell de seguretat de l'organització, redactant un informe posterior on destaqui els punts febles detectats i indicacions de com reforçar-los.

Per tant estem parlant d'una activitat de ciberseguretat ofensiva on l'equip pren el rol d'atacants i utilitza els coneixements sobre vulnerabilitats, formes d'atac, etc en benefici de l'organització que ha contractat els serveis.

Així doncs, aquesta és una disciplina on hem d'entendre i entrenar la forma de pensar i procedir del criminal cibernètic per poder-lo emular. Durant tot el curs, i en varis mòduls, anirem veient moltes formes d'anàlisis del comportament, eines i estratègies dels atacants (per exemple el projecte MITRE ATK). Les hem d'agafar com a referència i guia per anar complementant els nostres coneixements i habilitats però alhora hem de tenir molt clar que el hacking ètic té un component de vanguarda (cerca de nous vectors d'atac, exploits 0 day, etc) i gran part d'art (intuïció, control del procés, petites modificacions a eines Open Source, etc) que fa que calgui un estudi constant de tècniques noves alhora que calgui també un reciclatge constant en estratègies ja conegudes.

És per això que alhora de practica ciberseguretat ofensiva ens caldran també molts coneixements base si volem fer la nostra feina realment bé. En el mòdul veurem les metodologies i eines més utilitzades, així com un grapat d'atacs associats a cada tecnologia però cal prendre consciencia de que:

També remarcar que, com podreu veure en els punts anteriors, a part d'alts coneixements en xarxes i sistemes també calen alts coneixements en programació per aconseguir detectar bugs, crear exploits i eines personalitzades.

1 El servei del hacking ètic

El hacking ètic com a servei és una demanda creixent de les empreses i organitzacions, ja que es pot considerar part de l'autidoría de un SGSI (especialment arrel de la Llei Hacking de 23 de Desembre del 2010) i per tant realitzar-se de forma anual (com a mínim).

Aquest servei es pot oferir de forma interna, dins la pròpia organització, implementat per els coneguts red teams o de forma externa per realitzat per una tercera empresa.

També, i com veurem més endavant, existeix la possibilitat d'oferir un programa de Bug Bounty o recompensa de bugs on s'especifiqui per part de l'organització els paràmetres i condicions on està permés de fora oberta (o semi oberta) el hacking ètic amb la intenció de permetre la comunitat de ciberseguretat a explorar aquests productes o part de l'organització i recompensar-los si troben e informen d'algun bug. En tot cas això ja ho veurem en tractar el hacking web, on s'està establint com a model.

En tot cas, i abans d'iniciar el procés de pentesting és molt important establir una sèrie de paràmetres o regles de joc que permetin que el client tingui clar què pot obtenir alhora que limiti qualsevol conseqüència negativa derivada del pentest.

Aquí potser cal fer esment que, com en qualsevol atac, un pentest pot provocar de forma no intencionada una baixada de rendiment del sistemes o fins i tot la degradació d'aquests deguda a la càrrega de codi aliè (exploit). Per tant el client ha de ser conscient que "poden passar coses" i el pentester ha de ser molt curós en què utilitza i com ho utilitza i no emprar cap programa, tècnica o exploit que no tingui clar quines seran les seves conseqüències (si cal, és recomanable utilitzar-los abans en un entorn de proves abans de llançar-los contra la infraestructura del client).

2 Paràmetres d'un procés de hacking ètic

Com ja hem comentat, establir els paràmetres del contracto o servei abans de realitzar cap activitat és capdal en un pentesint o hacking ètic. Cal recordar que l'activitat que es desenvoluparà és bàsicament serà atacar la infraestuctura informàtica de l'organització client, això constitueix un delicte tipificat en el codi penal, per tant caldrà establir de forma molt clara i delimitada en el contracte què està permès fer i on. Si l'equip de pentesting surt d'aquests paràmetres acordats amb el client es pot veure denunciat molt fàcilment.

Normalment els paràmetres que s'estableixen en un procés de hacking ètic són:

2.1 Caixa blanca/negre/gris

Determinen l'enfoc o rol del pentester i per tant la quantitat d'informació sobre el client i la seva infraestructura de la que disposa de forma inicial. Podem trobar dos enfocs classics (blanca i negre) amb un nou terme intermig.

Caixa blanca
El pentester té accés a tota la informació de l'organizació. Aquest tipus d'adutories s'acostumen a realitzar simulant un usuari intern (insider) i revisant configuracions, permissos, polítiques, etc. En aquest tipus d'auditoría les fases de fingerprint i footprint no tenen cap mena de sentit ja que es disposa de tota la informació.
Caixa negre
En aquest cas, el red team no té cap mena d'informació sobre l'empresa ni la seva infraestructura. Es simula un atacant extern en tots els aspectes, i és la millor simulació per defensar-nos d'aquest tipus d'atacants.
Caixa gris
Aquí es simula que l'atac prové d'un "associat", s'adopta el rol d'un client o proveïdor o fins i tot un treballador sense permisos o permissos mínims. Aquí la informació sobre l'infraestructura i l'empresa és parcial i dependrà molt del rol adoptat.

2.2 Scope (permisos i autoritzacions)

El scope fa referència a l'abast i condicions on està permés el hacking ètic.

Aquest pot restringir els elements objectius (xarxes, servidors, software, etc) així com les tècniques utilitzades (DoS, enginyeria social, contacte a clients, accés a dades protegides per la LOPD dels clients o proveïdors, etc) o fins i tot horaris de proves, etc.

Com es pot intuir aquest és l'apartat més crític alhora de pactar el servei i redactar el contracte.

També es poden definir objectius del pentesting, com per exemple accés a les dades confidencials del client (projectes de I+D), fuga d'informació, resistència contra APT (Advanced Persistent Threats), Proves d'estress (DoS / DDoS), etc.

3 Fases del hacking i eines relacionades

3.1 Estandars i guies

OWASP
Organització pro la seguretat de les aplicacions web.
OSSTMM
L'OSSTMM és un protocol d'auditoria de seguretat a tots els nivells. Comprèn seguretat lògica i física. Analitza Xarxes, Telefonia, Presència, bases de dades, Servidors…
MITRE
La Mitre Corporation és una organització nord-americana sense ànim de lucre que fomenta la innovació en el cap tecnològic incloent la ciberseguretat.
OWISAM
Metodologia per el pentesting de xarxes WiFi.

3.2 Fases d'un pentest

Aquestes fases les veurem en tots els pentesting que realitzarem durant el curs, alhora que també en altres mòduls o "els bons" intentaràn detenir l'avanç de l'atacant o detectar-lo durant aquestes fases. Gran part dels passos i tècniques a aplicar seràn força repetitius de contracte a contracte i permetrà automatitzar-los i/o crear checklists, però cada sistema és diferent i per tant sempre caldrà adaptar aquestes rutines i amotllar-les a la realitat de cada client.

Tanmateix ara per ara farem una primera aproximació teòrica per entendre què són i més endavant veurem eines associades a cada fase i específiques de les diferents tipologies de pentesting a realitzar (de xarxes, wifi, aplicacions web, etc).

3.2.1 Footprintig

Aquesta és la primera fase de tot hacking i consisteix en recollir tota la informació possible sobre l'objectiu. Com a resum direm que tenim dues tècniques bàsiques (o categories) que són el reconeixement passiu (on no s'accedeix als elements del objectiu, sinó a informació existent a Internet amb tècniques de OSINT principalment) i el reconeixement actiu (on aquí si accedim als recursos del objectiu com poden ser la seva web).

La intenció aquí és doble:

  • Recopilar tota la informació possible per coneixer els màxim detalls de l'objectiu.
  • Mapejar els elements exposats de la mateixa, i per tant els que poden permetre accedir-hi.

Cal remarcar que aquesta és potser la fase més important de tot hacking ja que depenent de la quantitat i qualitat de la informació aconseguida podrem afinar més o menys l'atac i aconseguir que aquest sigui efectiu i exitòs. Per exemple podem descobrir el format dels noms d'usuaris interns de l'empresa, conèixer personal (noms, càrrecs, aficions, hàbits, vicis, etc), detectar servidors de proves o equips abandonats, fins i tot contrasenyes o informació sensible.

3.2.2 Fingerprinting

Aquesta segona fase tracta sobre identificar les tecnologies i característiques tècniques dels elemets detectats en la fase anterior. Això normalment ja implica una interacció directe amb els sistemes objectius i caldrà recopilar informació com per exemple:

  • Software i versió (que podrà determinar si existeixen bugs coneguts).
  • Explorar configuracions.

3.2.3 Determinar vector d'atac

Un cop tenim tota la informació sobre el nostre objectiu caldrà analitzar i determinar quin vector d'atac és el que té més possibilitats d'èxit i realitzar les tasques prèvies a llançar-lo. Això pot implicar per exemple:

  • Realitzar campanyes de Phishing.
  • Preparar exploits específics.
  • Fer proves prèvies en entorns controlats.
  • Personalitzar o crear eines noves.

3.2.4 Exploit / Atac

Aquesta fase, tot i ser la que més tensió provoca, simplement és executar el pla que hem traçat. Si tornem a mirar-ho en perspectiva, els resultat que obtindrem aquí seràn simplement el reflex de la feina feta en els punts anteriors, especialment els dos primers.

3.2.5 Consolidació i escalada de privilegis

Un cop s'ha accedit als sistemes objectius normalment caldrà consolidar la posició. Això implica generar un nou accés al sistema que no impliqui tornar a carregar codi aliè en un procés (exploit).

També en aquesta fase s'intentarà aconseguir control total sobre el element compromés de manera que puguem realitzar totes les tasques que ens siguin necessàries més endavant.

3.2.6 Pivoting

Normalment l'element compromés no contindrà tota la informació de l'objectiu i caldrà aprofundir en la seva xarxa per arribar a elements més crítics (informació sobre clients, projectes I+D, etc). Per fer-ho caldrà utilitzar el equip hackejat com a pasarel·la o cap de platja des d'on llançar nous atacs a la resta de la xarxa objectiu.

Per tant aquí caldrà tornar a iniciar el procés de pentesting, en aquest cas l'exploració serà focalitzada en el nou entorn (segment de xarxa) descobrint nous elements i possibles mecanismes de seguretat interns.

3.2.7 Eliminació del rastre

Finalment l'atacant intentarà eliminar el rastre generat, eliminant logs del sistema i utilitzant tècniques anti-forense per dificultar qualsevol intent d'investigació posterior. No cal dir que aquesta fase dependrà molt del objectiu del pentesting i és possible que no s'efectiu donat que es poden eliminar dades d'atacs reals o de gestió i administració de l'organització client.

4 Informes de pentesting

El producte final de tot procés de hacking ètic és l'informe. Aquest, cop en altres ocasions que veureu durant el curs, ha de contenir dures seccions o enfocs clarament diferenciats: l'informe tècnic i l'informe executiu.

Informe executiu
Com hem explicat, aquest informe va dirigit al CEO o elements de desicions de l'empresa client, que no tenen gaires coneixements tècnics. Aquí les explicacions tècniques s'han de fer a molt alt nivell i per contra cal expandir l'apartat de conclusions per aconseguir transmetre una idea clara de l'estat actual i de les mesures a prendre. Caldrà doncs vigilar que les explicacions siguin conscises i clares, no utilitzar un llenguatge altament tècnic i emprar més elements de resum (gràfics per exemple) així com lleguantge que entenguin millor els caps (econòmic, imatge d'empresa, etc).
Informe tècnic
Per contra el informe tècnic acostuma a ser molt és extens donat que s'expliquen de forma molt més detallada el procés, proves i resultats obtinguts. L'objectiu és donar tota la informació necessària per a que els responsables de ciberseguretat i tècnics informàtics del client entenguin que s'ha fet, el detall del com, que s'ha trobat i les indicacions de com solucionar-ho. Aquí caldrà ser molt específic a nivell tècnic per a que l'informe sigui de valor alhora de solucionar les feblesses detectades.

Sigui del tipus que sigui, aquests informes han de tenir una estructura clara i organitzar i explicar la informació de forma que sigui fàcilment assimilable. Podem trobar varis models d'informe, tots ells correctes, però per fer-ho una mica més genèric l'estructura a seguir seria la següent:

4.1 Portada

La portada acostuma a ser genèrica de l'empresa o unitat auditora, però és important incloure la versió del document, el nom dels auditors, revisors i responsables. També és molt important incloure la data per donar una idea clara de l'actualitat de l'informe.

4.2 Control de versions

El control de canvis, o control de versions és un element important dins de l'informe de pentesting ja que dota de validesa al informe. Tot i que és totalment personalitzable i no hi ha un format homogeni pot ser interessant incloure un quadre amb la següent informació:

Versió Data Redacció (Dept. Seguretat) Revisió (Cap Dept. Seguretat) Aprovació (CISO)
1.0 13/08/21 Pep Llenes Joan Casàliga Raul Gimenez
1.1 17/08/21 Joan Climens Joan Casàliga Raul Gimenez

D'aquesta manera es té controlat la versió actual, les dates i evolució de l'informe i les persones involucrades i la seva responsabilitat. A més cladrà afegir la signatura de cada persona junt amb el seu nom.

4.3 Index

Com tot bon document, l'índex té com objectiu facilitar la navegació dins del document per a localitzar ràpidament l'informació cercada. Per tant s'ha de buscar que sigui funcional (títols clars i com a molt tres nivells de profunditat).

4.4 Introducció

L'introducció cal que expliqui de forma clara de què tracta l'informe. És interessant que expliqui com està estructurat i quina informació hi ha en cada apartat.

També és interessant que s'expliquin quins són els objectius generals, els específics i el scope del informe, de manera que quedi clar què ha quedat cobert i que no en el pentesting.

4.5 Desenvolupament

Aquest apartat és el que variarà més depenent del tipus d'informe a el·laborar. Caldrà explicar les proves fetes i els resultat obtinguts. No cal que sigui una explicació a fons a nivell tècnic, però si que cal que quedi clar què s'ha fet, com i quan alhora que els resultats obtinguts i el que se'n deriva.

La recomanació més important en aquest apartat és estructurar-ho forma cronològica, de forma que es construeixi un relat, i categoritzar de forma molt evident els resultats obtinguts (per exemple es pot destacar els atacs amb resultat crític en vermell, els que han estat efectius però amb impacte moderat en taronja i els que tan sols han donat informació poc rellevant en groc).

4.6 Conclusions

Aquest és l'apartat potser més important ja que ha de donar una visió general del que objectivament és important i recomanacions sobre els controls de seguretat o modificacions a realitzar per solucionar-ho. Al cap i a la fi, aquest és l'apartat que interessa al client.

Per tant és recomanable fer aquí un quadre o llistat resum de les deficiències trobades, ordenades per perillositat, i contols per solucionar-les o mitigar-les.

4.7 Annexes

Finalment, en els annexes, si s'escau es pot incloure informació més tècnica o addicional que permeti al personal de IT entendre els resultats obtinguts i/o reproduir algunes les de les probes crítiques realitzades. Qualsevol cosa que creguem que pot aportar informació rellevant i que no s'hagi inclòs anteriorment l'afegiríem aquí.

5 Informes automatitzats

Existeixen eines que automatitzen un procés d'escanieg de xarxa, fingerprinting i consulta a bases de dades de vulnerabilitats. Finalment presenten un informa automatitzat que ens pot servir com a "quick shoot" o exemple simple del procés a seguir.

Tanmateix, i com resulta lògic, aquestes eines i informes aporten poc valor com a procés de hacking ètic i per tant el seu us és anecdòtic.

6 Descobriment de noves vulnerabilitats

Quan durant un pentesting és possible que descobrim una nova vulnerabilitat (0-day) en el programari o aplicació web objectius (o fins i tot peça de hardware) i es pot procedir de tres formes, de més correcta/lega a menys trobarem:

6.1 Informar al propietari

Primer de tot s'informa al propietari o proveïdor del HW o SW vulnerable, explicant en detall la vulnerabilitat detectada i aportant proves suficient per a que es pugui reproduir la vulnerabilitat. Com que aquest pas pot provocar mal estar, i propiciar-nos una denuncia, tot sovint s'utilitzen terceres entitats neutres i sensibilitzades amb la ciberseguretat com intermediàries del procés. Aquestes típicament poden ser INCIBE o un advocat.

Un cop solucionat el problema detectat s'allibera la informació tot registrant la vulnerabilitat al MITRE amb un CVE.

6.1.1 CVE

Durant tot el curs parlarem o veurem molts cops CVEs i per tant cal conèixer de què estem parlant.

Són les Vulnerabilitats i Exposicions Comuns o, dit d'una forma més planera, és un registre de les vulnerabilitats trobades mantingut per MITRE, publicades i per tant conegudes que que s'han detectat tant en webs, software, protocols, etc.

Aquest registre conté una entrada específica per cada vulnerabilitat, identificada per el CVE-ID (on el ID és un codi numèric amb el format CVE-YYYY-NNNN on Y és l'any de publicació i N un identificador numèric) i a més hi figuren dades interessants, tant per atacants com per defensors, com són:

  • Descripció de la vulnerabilitat.
  • Element vulnerable i versions afectades.
  • solucions a la vulnerabilitat (pegats, configuracions, etc).
  • Mesures de mitigació.
  • Referències i publicacions amb més informació i PoC (Prof of Concept).

Quan un investigador de seguretat, proveïdor, o simplement la pròpia comunitat d'Internet detecta i documenta una nova vulnerabilitat, l'envia per a que sigui recollida. Se l'hi assigna un CVE-ID i queda publicada.

Normalment aquest procés es realitz amb el permís del propietari del recurs afectat per la vulnerabilitat, i després de que aquest hagi tret ja un pegat de seguretat que pugui solucionar la vulnerabilitat i entregar als seus clients.

Els CNA són suborganitzacions que col·laboren amb MITRE per al manteniment del registre. Per exemple a Espanya podem trobar INCIBE. És aquí ons ens podem dirigir quan detectem una nova vulnerabilitat.

6.1.2 Registre d'un CVE

Els passos per registrar un CVE són:

  1. Reservar el CVE : Bàsicament solicitar la reserva d'un CVE explicant de forma resumida la vulnerabilitat trobada.
  2. Ens contestaran donant un CVE temporal (no definitiu) i requerint informació més específica on caldrà explicar si ha estat solucionada o no, tipus de vulnerabilitat, descripció general, autors, versions afectades i les conseqüències. Com veurem si busquem CVE no cal fer explicacions tècniques.

6.2 Full Disclosure

En aquest cas no s'informa al propietari o proveïdor que conté la vulnerabilitat, ja sigui per que aquest no ha contestat en un temps raonable o qualsevol altre motiu. Es registra directament el CVE o s'allibera la informació de la vulnerabilitat a la comunitat d'internet.

6.3 0-Day

Aquest últim cas és l'emprat per elements delictius de forma típica i consisteix simplement en reservar-nos la informació d'aquest 0-day per a ús privat (i per tant per realitzar tasques delictives) o fins i tot per vendre-ho a la DarkWeb. Aquests 0-days suposen vectors d'atac altament efectius (ja que encara ni s'han detectat, molt menys investigat, creat un pegat i estès el pegat) i depenent de la plataforma afectada poden constituir un perill molt important alhora que poden valer molts diners.

Data: 2021-10-08 dv. 00:00

Autor: Raul Gimenez Herrada

Created: 2021-09-30 dj. 12:54