Nginx Alias Traversal segueix sent un problema crític per a molts projectes
Fa poc es va donar a conèixer la notícia que alguns servidors amb nginx segueixen sent vulnerables a la tècnica «Nginx Àlies Traversal», que es va proposar a la conferència Blackhat el 2018 i permet l'accés a arxius i directoris ubicats fora del directori arrel especificat a la directiva «àlies».
L'essència de el problema és que els fitxers per a blocs amb la directiva d'àlies es proporcionen adjuntant la ruta sol·licitada, després de fer-la coincidir amb la màscara de la directiva d'ubicació i tallant la part de la ruta especificada en aquesta màscara.
El problema apareix només en configuracions amb una directiva «àlies», ja que a la configuració de Nginx, hi ha una directiva anomenada 'location' que pot descriure com s'ha de manejar l'accés a una URL en particular, i s'usa sovint per assignar adreces URL a fitxers al servidor.
Al patró que utilitza aquesta ubicació en combinació amb l'àlies, és crític quan es compleixen les dues condicions de 'no posar una barra al final de la URL especificada per la ubicació' i 'posar una barra al final de la ruta especificada pel àlies ' es compleixin. Es diu que la vulnerabilitat passarà.
A la conferència BlackHat 2018, Orange Tsai va presentar la seva investigació sobre la ruptura d'analitzadors d'URL. Entre altres troballes impressionants, va demostrar una tècnica descoberta en un desafiament CTF del 2016 de HCTF, creat per @iaklis.
Perquè la tècnica sigui aplicable, s'han de complir les condicions següents:
La locationdirectiva no ha de tenir una barra inclinada al seu camí;
Una àliesdirectiva ha de ser present dins el context d'ubicació i ha d'acabar amb una barra inclinada.
Per a l'exemple d'una configuració vulnerable que es mostra a dalt, un atacant pot sol·licitar el fitxer «/img../test.txt» i aquesta sol·licitud coincidirà amb la màscara especificada a la ubicació «/img», després de la qual cosa la cua restant "../test.txt" s'adjuntarà a la ruta de la directiva d'àlies "/var/images/" i com a resultat se sol·licitarà el fitxer "/var/images/../test.txt".
Per tant, els atacants poden accedir a qualsevol fitxer al directori «/var», no només als fitxers a «/var/images/», per exemple, per descarregar el registre de nginx, podeu enviar la sol·licitud «/img ../log/nginx /acceso.log».
una anàlisi dels repositoris a GitHub va mostrar que els errors en la configuració de nginx que condueixen al problema encara es troben en projectes reals.
Per exemple, es va detectar l'existència d'un problema al backend de l'administrador de contrasenyes de Bitwarden i es podria utilitzar per accedir a tots els fitxers al directori /etc/bitwarden (les sol·licituds de /arxius adjunts es van emetre des de /etc/bitwarden/ attachments/), incloent la base de dades emmagatzemada allà amb contrasenyes «vault.db», certificat i registres, per a això va ser suficient enviar sol·licituds «vault.db», «identity.pfx», «api.log», etc.
S'esmenta que la gravetat d'aquesta vulnerabilitat pot fluctuar significativament segons el projecte, des d'un impacte insignificant fins a un de crític. El grau de repercussions està determinat principalment per si el directori exposat conté dades confidencials que poden facilitar atacs addicionals o resultar en la divulgació d'informació privada.
Com a punt de partida en la nostra cerca d'aquesta vulnerabilitat, vam triar explorar els repositoris populars de GitHub que mostraven aquest problema. Identificar aquesta vulnerabilitat específica en entorns amb accés al codi font esdevé significativament més factible, principalment a causa de dos factors principals:
Detecció: l'ús d'eines d'anàlisi de codi senzilles, com cerques d'expressions regulars, ens permet identificar de manera efectiva els fitxers de configuració de Nginx potencialment vulnerables dins d'aquests projectes.
Explotació: tenir coneixement del directori de destinació exacte a què se li ha assignat un àlies ens permet configurar una instància local, examinar els directoris amb àlies usant un shell local i determinar a quins fitxers es pot accedir a través de la vulnerabilitat.
Cal esmentar que el mètode també va funcionar amb Google HPC Toolkit, on les sol·licituds es van redirigir al directori d'interès per obtenir una base de dades amb una clau privada i credencials, un atacant podria enviar consultes secret_key i db.sqlite3.
Finalment si estàs interessat en poder conèixer més sobre això, pots consultar els detalls en el següent enllaç.