A01:2021 - Control d'accés trencat

14 octubre de 2024 Celia Catalán

El control d'accés a una web defineix si un usuari té permès accedir a un recurs determinat o realitzar una determinada acció. Aquest control pot passar de manera horitzontal i vertical:

Control d'accés vertical: Un usuari sense privilegis no pot accedir als recursos d'un usuari administrador.

Control d'accés horitzontal: Un usuari, per exemple, en una web bancària, pot accedir a les vostres targetes i comptes, però no a la dels altres usuaris.

Com es perd aquest control d'accés?

Perquè aquest control funcioni correctament, les mesures de seguretat han d'estar ben implementades, i aquest no sempre és el cas. Males configuracions, versions vulnerables de programari o un mal disseny de la seguretat pot resultar en un control d'accés deficient, vulnerant així la confidencialitat, la integritat i la disponibilitat de la informació.

Igual que classifiquem el control d'accés vertical o horitzontal, aquestes vulnerabilitats poden resultar en un escalat de privilegis vertical o un moviment horitzontal.

Escalat de privilegis vertical

L'escalat vertical de privilegis passa quan un atacant explota una vulnerabilitat per elevar el nivell d'accés, passant d'un usuari amb privilegis baixos (com un usuari estàndard) a un rol amb més privilegis, com a administrador. En altres paraules, s'obté control sobre funcionalitats o dades que haurien d'estar reservades només per a usuaris amb nivells d'accés superiors i compromet la seguretat de l'aplicació. Aquests són alguns exemples d'escalat de privilegis:

Accés no autoritzat al tauler d'administració.

Modificació del rol dun usuari de la plataforma.

Accés a funcionalitats d'administrador (esborrar un usuari, modificar la contrasenya d'un usuari…).

Moviment horitzontal

El moviment horitzontal passa quan un atacant amb accés a un compte d'usuari del sistema obté accés a altres comptes d'usuari de privilegis similars. Aquest moviment horitzontal es dóna tant si aconsegueix accedir directament a un compte dusuari com si és capaç daccedir a funcionalitats o dades del dit usuari no privilegiat.

A diferència del moviment vertical, on l'atacant obté més permisos dins del sistema, el moviment horitzontal s'enfoca a comprometre altres comptes no privilegiats per descobrir nous vectors d'atac a l'aplicació. Alguns exemples d'aquest moviment horitzontal són:

Descobriment de les credencials dun altre usuari del sistema.

Un control d'accés al perfil d'usuari basat en un ID predictible.

Accés a fitxers propietat d'altres usuaris del sistema.

D'escalat horitzontal a escalat vertical

Si bé és cert que distingim aquests dos tipus de moviment, són comuns els casos de moviment horitzontal que deriven en un escalat vertical de privilegis. Això es dóna quan un atacant mitjançant tècniques de moviment horitzontal aconsegueix accedir a un usuari del sistema amb privilegis d'administració. Per exemple, si un atacant canvia l'ID d'usuari a la URL per accedir al perfil d'un altre usuari, faria un moviment horitzontal. Tot i això, mitjançant aquesta tècnica acaba accedint a un usuari administrador de la pàgina web.

D'aquesta manera observem que no és tan senzill destriar entre què és un escalat de privilegis i què un moviment horitzontal, atès que no depèn tant de la tècnica o atac realitzat, sinó en el resultat obtingut una vegada realitzat aquest atac.

Vulnerabilitats de control d'accés

Com hem explicat a l'apartat anterior, a causa de la dificultat de classificar els atacs entre atacs d'escalat de privilegis i atacs de moviment horitzontal, en aquest apartat ens cenyirem a explicar diferents atacs, com fer-los i el resultat que es pot obtenir.

IDOR (Referència d'objectes directes insegurs)

IDOR és una subcategoria de control d'accés on s'utilitzen paràmetres modificables per l'usuari per accedir a recursos. Un exemple seria un botó al perfil dusuari per descarregar lhistòric de xats.

Aquest botó fa una petició a un fitxer exemple.txt, però aquest paràmetre és modificable mitjançant un proxy, per la qual cosa es pot arribar a accedir als històrics de xats d'altres usuaris.

En aquest exemple, en intentar descarregar l'històric de xats del nostre usuari, en interceptar la petició amb un servidor intermediari, veiem que realitza una consulta a un fitxer 2.txt. Després d'aquesta petició GET obtenim la resposta següent:

Tot i això, aquest paràmetre és modificable, per la qual cosa si reemplacem aquest 2.txt per 1.txt obtenim l'històric de xats d'un altre usuari, en el qual podem trobar la contrasenya:

Funcionalitat no protegida

Aquest és un atac és molt senzill i requereix una falta gairebé absoluta de control daccés per part del servidor. Podeu trobar pàgines web on els recursos d'un administrador estiguin ocults, però no protegits. En aquest cas, podem trobar aquests recursos de maneres diferents:

Un mètode és accedir al fitxer robots.txt. Aquest fitxer sol estar disponible a l'arrel de la pàgina web i conté informació sobre quins recursos i directoris tenen permès recórrer els bots de Google, Microsoft… Moltes vegades podem trobar-nos amb directoris ocults o d'administració sota l'etiqueta Disallow, revelant així la localització de panells d'administració o fitxers sensibles:
Una altra font per trobar aquest tipus de directoris ocults és el propi codi JavaScript. És comú trobar referències a fitxers i directoris sensibles en funció d'aquest llenguatge de programació, com observem a la imatge següent:

De nou, malgrat la rellevància de la informació que podem trobar en aquestes fonts, si volem accedir a aquests directoris i recursos com a usuari sense privilegis, l'absència de control d'accés és indispensable.

Control d'accés basat en paràmetres

Hi ha altres casos en què els permisos d'un usuari es basen en valors emmagatzemats que l'usuari pot modificar, com un camp ocult, una galeta o un valor predefinit fer les consultes.

En aquest exemple, els permisos de l'usuari estan en mans del mateix usuari, ja que s'utilitza una galeta emmagatzemada al navegador amb valor false. Només modificant el valor d'aquesta galeta podem accedir a recursos sensibles sense necessitat d'un usuari administrador:

Podem veure un altre cas al següent exemple. En realitzar un canvi de correu electrònic amb el nostre usuari, si interceptem amb un proxy la petició realitzada i la resposta obtinguda, observem que a la petició POST, estem enviant el nostre correu electrònic nou en format JSON i rebem la següent informació, també, en format JSON:

Com es presenta a la imatge superior, en fer el canvi de correu electrònic rebem al JSON de resposta un paràmetre roleid amb valor 1. Si en fer la petició, en lloc d'enviar únicament el correu electrònic enviem també un paràmetre roleid amb valor 2, veiem que el servidor ens torna aquest valor, indicant que els privilegis del nostre usuari han canviat:

D'aquesta manera, enviant al servidor un paràmetre que no s'esperava, aconseguim alterar els privilegis del nostre usuari, convertint-lo en un usuari privilegiat.

Mala configuració

En casos de mala configuració, és possible trobar-se amb webs que restringeixen les peticions sobre la base de la URL, per exemple, perquè un usuari no tingui permès fer un POST a la URL /admin/delete. Tot i això, si aquesta mateixa web permet utilitzar capçaleres de reescriptura d'URL com X-Original-URL o X-Rewrite-URL podem saltar aquests controls de seguretat.

Com veiem en aquest cas, tenim restringit accedir a la URL /admin/delete?username=carlos, que ens permetria esborrar l'usuari carlos. Però en introduir l'URL arrel de la pàgina, utilitzant la capçalera X-Original-URL per reescriure aquesta URL, veiem que som capaços de saltar-nos aquest control d'accés a aquesta URL:

En altres casos, si la pàgina és flexible quant als mètodes que processa, si està restringit per mètode i URL, podem canviar el mètode per i saltar així el control daccés. En aquest exemple, en intentar canviar els permisos de l'usuari carlos amb un usuari sense privilegis, veiem que no tenim autorització per fer aquesta modificació:

Tot i això, a causa de la flexibilitat de la pàgina web, podem fer aquesta mateixa petició en format GET, el servidor la processa correctament però no aplica el control d'accés, per la qual cosa aconseguim saltar el control de seguretat:

Discrepàncies a la concordança d'URL

Hi ha també pàgines que restringeixen l'accés a determinades URL mitjançant cadenes de caràcters, però després internament mapegen resultats “semblants” a aquesta mateixa URL.

Per exemple, en escriure una URL en majúscules com /ADMIN/DELETEUSER redirigeix internament a /admin/deleteuser, però, com que no és exactament la mateixa cadena de caràcters, no aplica el control d'accés. A Spring, per exemple, en introduir una URL per accedir a un fitxer (que tingui extensió), en cas de no trobar aquest fitxer, resol aquest mateix recurs, però sense l'extensió, el que pot portar a un bypass del control de accés:

/admin/deleteUser.anything → /admin/deleteUser

Cal destacar que aquesta redirecció està habilitada per defecte en versions de Spring anteriors a la versió 5.3.

Procés de múltiples passes sense control d'accés

Quan hi ha més d'una petició o més d'un pas per fer una determinada acció, com ara esborrar un usuari, és possible que una de les peticions sí que estigui correctament assegurada mentre que el segon o tercer passos són vulnerables.

En aquest exemple, veiem clarament aquest procés múltiple per elevar els privilegis d'un usuari. En realitzar la petició inicial de canvi de privilegis amb un usuari no privilegiat, obtenim la resposta següent del servidor indicant que no tenim permís per realitzar aquesta acció:

Tot i això, si continuéssim amb el procés d'elevació de privilegis amb un usuari privilegiat, veuríem una pàgina de confirmació preguntant si estem segurs que volem realitzar aquesta acció.

Si interceptem aquesta petició i tractem de fer aquesta mateixa petició amb la galeta de l'usuari sense privilegis, veiem que ens permet fer aquesta acció, saltant el control de seguretat:

És important tenir en compte que moltes vegades necessitem un coneixement previ de quines són les funcionalitats d'un usuari administrador per poder fer aquest tipus d'atacs. En aquest cas, com a usuari normal no hauríem de poder accedir mai a aquesta pàgina de confirmació, ja que ens bloquejaria el procés des del començament.

Aquestes vulnerabilitats són molt més fàcils de detectar si es posseeix un usuari administrador per endavant per analitzar-ne les funcions. Per aquest motiu, en auditories web moltes vegades és essencial tenir tant un usuari sense privilegis com un amb privilegis.

Control d'accés basat a la capçalera Referer

De vegades, per limitar l'accés a subpàgines com /admin/deleteUser, es comprova que la capçalera Referer contingui l'URL principal /admin. D'aquesta manera, el servidor intenta comprovar que l'usuari prové d'un directori exclusiu d'un usuari amb privilegis elevats. No obstant això, en ser aquesta modificable per lusuari, pot portar a un salt daquest control daccés.

En el cas següent, veiem exactament això. En indicar al Referer que la petició es fa venint prèviament de la URL /admin (encara que no sigui cert), el sistema permet realitzar una modificació de permisos d'usuari utilitzant una galeta d'usuari no privilegiat, ja que el servidor web només està comprovant la capçalera Referer:

Exemples simples de moviment horitzontal

Per acabar, presentem algunes tècniques senzilles de moviment horitzontal. Un cas molt recurrent sol ser l'accés al perfil d'usuari mitjançant un identificador a la pròpia URL. Només canviant aquest identificador podem accedir a perfils d'altres usuaris:

Per evitar-ho, és usual l'aleatorietat d'aquests identificadors perquè no siguin endevinables. Però de tant en tant és possible trobar referències a aquest identificador en algun lloc a la pàgina web.

En aquest exemple, navegant a un bloc publicat per carlos, podem observar que el vostre identificador d'usuari es troba a la pròpia URL del bloc:

Un altre cas força comú és trobar informació a les redireccions. Quan no podem accedir a un recurs, com el tauler d'administrador, el servidor ens torna un codi 302 per redirigir-nos, per exemple, de tornada a l'arrel de la pàgina. No obstant això, hi ha vegades que, si interceptem la resposta del servidor, podem trobar al cos de la pròpia resposta de redirecció tot el codi HTML del recurs al qual volíem accedir:

Remediació

Tots aquests atacs són possibles a causa d'un control d'accés deficient per part de la pàgina web. Per aquest motiu, es recomana seguir els principis següents a l'hora d'implementar un control d'accés correcte: