Identification and authentication failures

Falles d'identificació i autenticació

20 gener de 2025 Celia Catalán

¿Identificació, autenticació o autorització?

Primer, hem d'entendre la diferència entre identificació i autenticació:

Identificació: És el procés on s'ofereix una identitat; un usuari o sistema indica qui és.
Autenticació: És el procés de verificar una identitat. Quan un usuari o sistema s'identifica, indica qui és; quan s'autentica, es comprova que sigui qui diu ser.

Encara que la majoria dels errors més coneguts són d'autenticació, ja que allà es realitzen els controls de seguretat per verificar la identitat dels usuaris, també existeixen errors en el procés d'identificació que poden afectar la seguretat de la informació. Alguns exemples són:

Identificació incorrecta o no reconeguda: Si un usuari introdueix un nom d'usuari o ID no registrat al sistema, el procés d'identificació falla perquè no es troba cap identitat associada a aquesta entrada.

Identitat duplicada: En alguns sistemes, poden existir dues comptes amb noms d'usuari similars o ID molt semblants, la qual cosa genera confusió en intentar associar a quin usuari es refereix la identificació.

D'altra banda, és crucial entendre la diferència entre autenticació i autorització, que, tot i que sonen similar, són processos diferents. Mentre que l'autenticació, com hem explicat, verifica la identitat d'un usuari o sistema, l'autorització determina si aquest usuari o sistema té permís per realitzar o accedir a determinada acció o recurs.

Factors d'autenticació

Hi ha tres tipus principals de factors d'autenticació, basats en principis simples: alguna cosa que l'usuari sabe, alguna cosa que l'usuari té i alguna cosa que l'usuari és.

Alguna cosa que l'usuari sabe: per exemple, una contrasenya o la resposta a una pregunta de seguretat.

Alguna cosa que l'usuari té: com un objecte físic o un token de seguretat.

Alguna cosa que l'usuari és: com un dada biomètrica (empremta dactilar) o patrons de comportament.

Encara que les contrasenyes segueixen sent el mecanisme d'autenticació més comú, cada sistema pot requerir diferents tipus de factors per verificar la identitat de l'usuari. Avui dia, existeixen múltiples mecanismes: des d'aquells basats únicament en dades biomètriques (com el desbloqueig de smartphones) fins als que utilitzen maquinari específic (com dispositius extraïbles). A més, és cada cop més freqüent l'ús d'autenticació multifactorial, combinant, per exemple, contrasenyes amb tokens de seguretat.

Aquest panorama divers de mecanismes d'autenticació ofereix una major flexibilitat i millora la seguretat general dels sistemes. No obstant això, també introdueix noves complexitats i potencials punts febles que els atacants podrien explotar.

A continuació, analitzarem els diferents tipus de vulnerabilitats relacionades amb el procés d'autenticació, agrupant-les segons el mecanisme afectat. Ens centrarem en aquestes vulnerabilitats ja que representen la majoria dels fallos de seguretat en aquest àmbit.

Autenticació basada en contrasenya

Els sistemes que utilitzen únicament usuari i contrasenya com a mètode d'autenticació confien plenament en la contrasenya com a prova d'identitat de l'usuari. Això implica que un atacant que obtingui les credencials d'un usuari podria comprometre completament el procés d'autenticació. Hi ha diversos tipus d'atacs per vulnerar aquest mecanisme:

Força bruta

Els atacs de força bruta són un procés de prova i error on l'atacant introdueix constantment diferents credencials —de manera aleatòria, seguint regles o utilitzant diccionaris de paraules— amb l'objectiu de descobrir les credencials d'un usuari legítim.

Abans d'intentar descobrir la contrasenya, si no es coneix cap nom d'usuari, és necessari realitzar una enumeració d'usuaris. Hi ha diversos mètodes per identificar noms d'usuari vàlids en una aplicació web.

El primer es basa en la resposta del servidor. En introduir un usuari registrat a l'aplicació, rebem una resposta diferent a la que obtenim en introduir un usuari inexistent. Per automatitzar aquest procés, podem utilitzar eines com l'Intruder de BurpSuite, que permet realitzar atacs de força bruta a paràmetres en una petició web utilitzant diccionaris de paraules o regles per generar seqüències de caràcters i números. En l'exemple següent, observem que una de les paraules introduïdes retorna una resposta de mida diferent de la resta:

Verifiquem en la resposta d'aquesta sol·licitud que la plataforma indica que la contrasenya no és vàlida, a diferència de la resta de respostes que assenyalen que l'usuari introduït no és vàlid:

No sempre és una cosa tan òbvia; de vegades hem de fixar-nos en fallades subtils del propi programa. En el següent cas, observem una situació similar. Encara que totes les respostes tenen diferent mida i indiquen que l'usuari o la contrasenya no són vàlids, hi ha un petit error ortogràfic en la programació de la resposta. Aquest error provoca que, en introduir un usuari existent, es produeixi una lleugera variació en la resposta:

Resposta correcta:

Resposta incorrecta:

Un altre mètode, quan la resposta és sempre la mateixa, és utilitzar el temps de resposta com a indicador. Si introduïm una contrasenya molt llarga, i el servidor només la processa en encertar l'usuari, és possible que trigui més temps a intentar processar una cadena de caràcters tan extensa. En aquest exemple, provem amb diferents usuaris utilitzant sempre una contrasenya molt llarga:

Hi ha moltes més tècniques d'enumeració d'usuaris. Si estàs interessat a conèixer-les, pots visitar la nostra publicació sobre la vulnerabilitat de "Insecure Design" d'OWASP.

Evasió de bloquejos per IP

És possible trobar-nos amb restriccions d'inici de sessió. El bloqueig més comú és el d'IP, on el servidor bloqueja temporalment els intents d'inici de sessió des d'una adreça IP específica. No obstant això, hi ha mètodes per evadir aquest bloqueig. Per exemple, l'ús de capçaleres com X-Forwarded-For, que, si és processada pel servidor, pot portar a una evasió del bloqueig d'IP.

En altres casos, el bloqueig pot ocórrer cada cert nombre d'intents, però es reinicia un cop s'inicia sessió correctament. Per exemple, si detectem que la IP es bloqueja cada 3 intents, podem utilitzar un diccionari de credencials i intercalar les credencials d'un usuari legítim (necessitem posseir credencials d'algun usuari) cada 2 entrades del diccionari. Amb aquest mètode, podem evitar el bloqueig i provar totes les entrades del nostre diccionari.

També hi ha casos on l'enumeració o l'evasió de l'esquema d'autenticació es pot realitzar amb una única petició HTTP, evadint així qualsevol bloqueig per repetició d'intents d'inici de sessió. Per exemple, en enviar un JSON per iniciar sessió, si enviem un array de contrasenyes en lloc d'un valor únic, el servidor podria processar correctament aquest JSON i permetre'ns iniciar sessió sense conèixer les credencials d'usuari correctes.

Evasió del bloqueig del compte d'usuari

El bloqueig de compte és un altre mecanisme de seguretat. A diferència del bloqueig per IP, aquest mètode bloqueja el compte després de múltiples intents fallits d'inici de sessió. No obstant això, si el sistema només bloqueja comptes existents, això pot portar inadvertidament a una enumeració d'usuaris. Per exemple, en intentar iniciar sessió repetidament amb diferents noms d'usuari, notem que un compte en particular es bloqueja després del cinquè intent fallit:

D'aquesta manera, aconseguim una enumeració d'usuari al panell d'inici de sessió de l'aplicació web.

Autenticació d'accés bàsica

Encara que aquest mètode és molt antic, encara és possible trobar servidors que utilitzin aquest sistema vulnerable. Aquest mecanisme d'autenticació consisteix a concatenar el nom d'usuari i la contrasenya, codificar-los en Base64, i introduir-los a la capçalera Authorization en cada petició:

Aquest mètode és particularment perillós. A menys que la pàgina web implementi HSTS, un atacant que realitzi un atac de home al mig podria interceptar aquest capçalera. Amb només desxifrar-la, obtindria les credencials de l'usuari.

Autenticació de factor múltiple

Els mètodes d'autenticació basats únicament en contrasenya dipositen tota la seguretat en un sol paràmetre: alguna cosa que l'usuari sap.

En contrast, l'autenticació multifactorial introdueix almenys un factor addicional. Un exemple comú és l'autenticació de dos factors (2FA), que requereix alguna cosa que l'usuari sap (una contrasenya) i alguna cosa que té (com un codi d'un sol ús enviat per correu electrònic). No obstant això, hi ha altres combinacions, com l'ús de empremtes dactilars —alguna cosa que l'usuari és— o aplicacions d'autenticació com Microsoft Authenticator, una app mòbil que substitueix el codi enviat per correu electrònic.

Evasió del doble factor d'autenticació

El cas més simple ocorre quan el sistema considera l'usuari autenticat després d'introduir només el primer factor, malgrat sol·licitar un segon. Per exemple, si coneixem la contrasenya d'un usuari i tenim informació sobre directoris o recursos reservats per a usuaris autenticats, podríem accedir a aquests directament sense proporcionar el token de seguretat sol·licitat. Això evidencia una implementació deficient del segon factor d'autenticació, ja que el sistema hauria de considerar autenticats únicament els usuaris que hagin completat tot el procés.

Moviment lateral per fallida d'implementació

Similar al cas anterior, aquí observem un problema en la verificació que tots els passos del procés han estat realitzats per l'usuari que intenta accedir. Encara que pot semblar confús, el següent exemple ho il·lustra clarament.

Considerem una web amb autenticació de dos factors (2FA). Després d'introduir usuari i contrasenya, l'aplicació sol·licita un token de seguretat per confirmar la identitat. Es realitza una petició GET a /login2 perquè el servidor enviï el token al correu electrònic de l'usuari. El servidor envia aquest token a l'usuari especificat a la capçalera Cookie de la petició:

D'aquesta manera, si reemplaçem el nostre nom d'usuari pel de la víctima, el servidor enviarà el token d'accés al correu electrònic de l'usuari víctima:

Una vegada aquest token arriba al correu electrònic de la víctima, l'atacant pot començar la sessió amb les seves pròpies credencials d'usuari i passar al procés d'introduir el token. A l'hora d'introduir el token, si canvia de nou aquesta capçalera Cookie per introduir el nom d'usuari víctima i realitza força bruta sobre el token de seguretat, podrà descobrir el token de seguretat enviat al correu electrònic i accedir amb aquest a l'usuari víctima:

En aquest cas, el servidor només verifica el segon pas del procés d'autenticació, és a dir, el token de seguretat. Si el token és vàlid i coincideix amb el que s'ha enviat a l'usuari especificat a la capçalera Cookie, el servidor concedeix l'accés. No obstant això, no valida que les credencials proporcionades en el primer pas de l'autenticació (com el nom d'usuari i la contrasenya) corresponen a l'usuari al qual s'està intentant accedir.

Vulnerabilitats en altres mecanismes d'autenticació

Les vulnerabilitats associades al procés d'autenticació no es limiten únicament a l'inici de sessió. També es poden trobar en altres procediments crítics, com el canvi de contrasenya, l'actualització de l'adreça de correu electrònic o la gestió de la persistència de la sessió, com veurem a continuació.

Opció de “Manten-me autenticat”

En moltes pàgines web, en iniciar sessió, s'ofereix l'opció de mantenir la sessió activa fins i tot si tanquem i tornem a obrir el navegador. Aquesta funcionalitat s'implementa mitjançant una cookie persistent, similar a una cookie de sessió, però amb una durada més prolongada (almenys durant un temps determinat). Encara que aquesta pràctica és molt comuna, la seguretat de l'aplicació pot veure's compromesa depenent de com estigui dissenyat i gestionat aquest token.

En l'exemple següent, en seleccionar l'opció de mantenir la sessió iniciada i iniciar sessió, observem la presència de les següents cookies:

La primera cookie correspon a la sessió activa, mentre que la segona és la cookie persistent esmentada anteriorment. Aquest token hauria de ser accessible únicament per a l'usuari que ha iniciat sessió. No obstant això, en analitzar-ho, hem observat que és relativament previsible, ja que està codificat en Base64 i conté el nom d'usuari seguit del hash MD5 de la seva contrasenya:

Coneixent l'estructura del token, és possible intentar un atac de força bruta per generar un token vàlid i accedir al compte de l'usuari. Per això, utilitzarem Intruder de BurpSuite per fer un fuzzing del paràmetre corresponent a la galeta persistent. El primer pas serà convertir totes les contrasenyes en els seus respectius hashes MD5:

Un cop creada la llista de hashes MD5, la utilitzarem com a diccionari per al nostre atac. Tanmateix, abans d'això, és necessari realitzar un post-processament del diccionari: afegirem com a prefix el nom d'usuari de la víctima seguit de :, i després convertirem tota la cadena a Base64. Posteriorment, executem l'atac amb Intruder, cosa que ens permetrà obtenir una resposta exitosa en accedir al perfil de la víctima utilitzant una de les galetes persistents generades.

Robo de galeta a través de XSS

És possible que el servidor ens bloquegi si realitzem massa sol·licituds al provar diferents tokens, però hi ha altres mètodes per eludir aquesta restricció. En lloc de provar múltiples cookies, podríem intentar robar la cookie de sessió d'un usuari. Si el token segueix un esquema com usuari:hash[contrasenya], tal com en el cas anterior, podem intentar desxifrar el hash mitjançant força bruta utilitzant eines com hashcat. Però com podem obtenir la cookie d'un usuari? Això es pot aconseguir a través d'un atac XSS, com es detalla en l'exemple següent.

La secció de comentaris d'un dels blogs resulta ser vulnerable a una injecció de codi JavaScript. Aquesta pàgina és accessible per a altres usuaris, per la qual cosa en injectar codi maliciós, la nostra víctima podria accedir a la secció de comentaris i executar el codi JavaScript sense adonar-se'n. Per robar la cookie de sessió, primer configurem un servidor que esperi rebre peticions, i després injetem el següent codi als comentaris:

D'aquesta manera, la víctima, en intentar carregar aquest objecte i, farà una petició al nostre servidor inserint les seves cookies de sessió en aquesta petició. Acte seguit, rebrem aquesta informació al nostre servidor, com observem a la següent imatge:

Observem de nou que es tracta d'una cadena de text codificada en Base64 amb el següent format:

Com el servidor ens bloqueja al fer moltes peticions, podem intentar crackejar aquest hash utilitzant hashcat amb un diccionari com rockyou.txt:

Com observem a la imatge, vam aconseguir crackejar el hash i obtenir la contrasenya de la víctima.

Error en el canvi de contrasenya

És possible identificar falles en la lògica del procés de canvi de contrasenya, especialment quan un usuari oblida la seva contrasenya i sol·licita un canvi a través del correu electrònic. En aquest cas, s'envia un enllaç al correu associat a l'usuari que ha oblidat la seva contrasenya, permetent-li canviar-la per una nova. No obstant això, la sol·licitud que es realitza en fer clic a l'enllaç inclou al cos els següents paràmetres:

Com veiem, hi ha un paràmetre que indica l'usuari, i aquest és modificable per l'usuari. Si en comptes del nostre usuari, escrivim el nom d'usuari de la víctima, aconseguim canviar la contrasenya de la víctima sense conèixer la seva contrasenya actual:

Enverinament de canvi de contrasenya

Per comprendre aquesta vulnerabilitat, és fonamental explicar primer el funcionament del procés de canvi de contrasenya. Generalment, quan un usuari oblida la seva contrasenya, el servidor envia un enllaç al correu electrònic associat que redirigeix a una pàgina per restablir-la. Atès que l'usuari no pot accedir al seu compte, no pot utilitzar un token de sessió per verificar la seva identitat. Per aquesta raó, el servidor sovint genera un token d'un sol ús i incrusta aquest token en l'enllaç de redirecció a la pàgina de canvi de contrasenya. La seguretat d'aquest token es basa en que només l'usuari que té accés al seu correu electrònic pot accedir a l'enllaç i, per tant, al token, i que, un cop utilitzat, el token perd la seva validesa.

Tanmateix, existeix una vulnerabilitat que pot comprometre aquest sistema. En crear l'enllaç de canvi de contrasenya, el servidor ha d'incloure a la URL tant el host com el paràmetre del token:

El host hauria de ser sempre el mateix, corresponent a la pàgina web legítima. No obstant això, en certs casos, el servidor determina el host de la URL en funció del valor de la capçalera Host de la sol·licitud realitzada quan el client fa clic a "enviar correu electrònic", i aquesta capçalera pot ser manipulada per un atacant. D'aquesta manera, un actor maliciós pot enganyar el servidor perquè enviï un correu electrònic amb un enllaç maliciós a la víctima.

Per dur a terme aquest atac, l'atacant ha de fer clic al botó de "contrasenya oblidada" i introduir el nom d'usuari de la víctima en lloc del propi. A continuació, utilitzant una eina de proxy com BurpSuite, intercepta la sol·licitud i modifica l'encapçalament Host, substituint el host del servidor per la URL d'un servidor que estigui sota el seu control:

D'aquesta manera, el servidor enviarà al correu electrònic de la víctima un enllaç per canviar la contrasenya, incloent un token temporal. No obstant això, el host d'aquest enllaç pertanyrà a l'atacant. Si la víctima fa clic en aquest enllaç, enviarà una sol·licitud al servidor de l'atacant, que interceptarà la petició i capturarà el token temporal. D'aquesta manera, l'atacant podrà canviar la contrasenya de la víctima i apoderar-se del seu compte d'usuari.

És possible trobar servidors que admeten capçaleres no estàndard i, en aquest context, en lloc d'utilitzar la capçalera Host per generar l'enllaç, el servidor podria emprar capçaleres com X-Forwarded-Host:

Com prevenir atacs d'autenticació

Proteger els mecanismes d'autenticació és fonamental per evitar vulnerabilitats que puguin comprometre un lloc web i les dades dels usuaris. A continuació, es destaquen les mesures més significatives:

Atenció amb les credencials: Mai enviar dades d'inici de sessió a través de connexions no xifrades. Implementar HTTPS i redirigir automàticament les sol·licituds HTTP. Auditar el lloc per evitar l'exposició de noms d'usuari o correus electrònics.
No dependre dels usuaris: Els usuaris solen evitar polítiques estrictes de seguretat. En lloc d'aplicar polítiques tradicionals de contrasenyes, és més eficaç utilitzar verificadors de contrasenyes, com la biblioteca zxcvbn, que proporcionen retroalimentació en temps real sobre la fortalesa de les contrasenyes.
Prevenir l'enumeració de noms d'usuari: Evitar donar pistes sobre si un usuari existeix al sistema mitjançant missatges d'error genèrics, amb temps de resposta i codis HTTP idèntics.
Protecció contra atacs de força bruta: Implementar límits en el nombre d'intents d'inici de sessió per adreça IP i utilitzar CAPTCHA després de diversos intents fallits. Això dificulta que els atacants realitzin atacs de força bruta de manera eficient.
Verificació de lògica: Auditar exhaustivament la lògica d'autenticació per assegurar-se que no hi hagi fallades o possibles bypassos que puguin ser explotats.
Atenció a funcionalitats addicionals: Funcions com el restabliment de contrasenyes també són vulnerables, per la qual cosa han de ser tan segures com l'inici de sessió principal.
Autenticació multifactor (2FA): Implementar 2FA utilitzant aplicacions o dispositius dedicats és més segur que mètodes com l'enviament de codis per SMS o correu. Auditar la lògica del 2FA per evitar que sigui eludida.