Estamos en el proceso de migrar todo el tráfico IPv4 a IPv6 desde hace ya unos años, y la verdad es que poco a poco esto está creciendo, pero aún estamos lejos de llegar al objetivo de tener más tráfico IPv6 que tráfico IPv4 en las redes de todo el mundo. Sin embargo, existen algunas otras propuestas de cambios para IPv4 distintas a la de IPv6, y recientemente se ha publicado la propuesta hecha por James Thain de, en lugar de migrar a IPv6, hacerlo a IPv8, que es cuanto menos interesante.
La propuesta fue publicada hace menos de un mes, con una serie completa de documentos para definir los protocolos necesarios para pasar a IPv8, como serían los protocolos DHCP8, WHOIS8, y el conjunto mínimo de protocolos de gestión del enrutamiento de tráfico IPv8 en las redes de Internet de hoy en día.
El objetivo principal de esta propuesta, como bien se explica a lo largo de todo el documento, que la verdad, es bastante sencillo de leer, consiste en mantener la compatibilidad hacia atrás con todo lo construido hasta el momento, haciendo un cambio muy pequeño, que es cambiar la dirección IPv4 por la dirección IPv8.
La gran diferencia, como se puede ver en el paquete IPv8 es que se añaden las cabeceras ASN de 32 bits tanto a la dirección IP de origen, como a la dirección IP de destino, lo que permite a los protocolos de enrutamiento reenviar correctamente al ASN correspondiente el paquete correctamente.
Al añadir el Autonomous System Number (ASN), marcado como r.r.r.r, en los cuatro primeros bytes, una dirección IPv8 sería la suma de la parte de ASNr.r.r.r más la parte de IPv4 clásica, a la que se llama en el documento como n.n.n.n.
Esto sería como tener 2 a la 32 veces el tamaño de direcciones IPv4 que tenemos hoy en día, y dejando la dirección 0.0.0.0.n.n.n.n como la red de IPv4 que tenemos en Internet funcionando ahora mismo.
Es decir, con un cambio sencillo en el envío de paquetes de red IPv4 se podría resolver el problema de que se acaben las direcciones IPv4 manteniendo todo el software construido sobre él funcionando. Y la propuesta es porque está costando ir más rápido a IPv6 de lo que se estaba esperando al inicio. Si miramos radar, podemos ver en Radar de Cloudflare que en los últimos doce meses el tráfico sobre IPv6 está estable en un 30% más o menos.
Claro, mantener la compatibilidad hacia atrás implica que sigan funcionando todos los ataque en redes de datos IPv4 que ya conocemos, además de todas sus medidas de seguridad. Es decir, se supone que el conocimiento que tenemos de estos protocolos debemos usarlos en hacerlos más seguros y no en migrarlos.
Los cambios que sí que habría que hacer son los relativos a la interconexión de redes, por lo que todos los protocolos de enrutamiento de tráfico y gestión de redes deberían cambiar a IPv8, como serían BGP8, OSPF8, WHOIS8, SNMP8, etcétera, que están definidos en sus correspondientes documentos.
Y por supuesto, crear los tipos de redes especiales con direccionamientos reservados, al igual que tenemos en IPv4 e IPv6, que están descritos con detalle en el documento de Internet Protocol Version 8 (IPv8) del que estamos hablando.
El documento recoge también las direcciones especiales que deben existir en estas redes IPv8, donde los nodos de enrutamiento dentro de tráfico a través de los ASNs deben ser tenidos en cuenta de manera especial, así que en la definición de estándar están especificados.
En definitiva, me parece una propuesta súper bonita como trabajo técnico de arquitectura de redes. Me falta criterio tan pronto para decir si es una opción mejor que ir hacia IPv6 o no, pero desde luego mis felicitaciones a James Thain por este trabajo tan bonito que ha publicado. Así es la investigación y la innovación, proponer ideas concretas que puedan ser evaluadas y aprender de ellas.
IPv6 es un acrónimo alfanumérico de cuatro caracteres de longitud que, a su “descompresión” viene a decir/representar: Internet Protocol version 6
¿Se puede “comprimir”/acortar más? Esa es la idea… El objetivo es lograr una reducción a su mitad, tal que: IP. Dejando a un lado (u obviando) su versionado.
Podría describirse la palabra versión como sustantivo femenino que se refiere a la forma o variante particular de algo, especialmente cuando existen varias alternativas o modificaciones de un mismo objeto, texto, idea o producto. En un contexto tecnológico, puede haber un par de motivos para destacar/resaltar una versión frente a un protocolo;
Mismo protocolo pero con grandes diferencias en funcionalidades y capacidades (nuevas y/o mejoradas).
Convertirse en deprecado debido a un agujero, fallo de seguridad lo suficientemente grave como para hacerse hincapié sobre ello y movilizar a los recursos necesarios para erradicarse o ser cambiado mediante una actualización, etc.
En este caso, el motivo en IPv6 es el primero descrito. Todavía a día de hoy, no hemos podido hacernos con la misión, no hemos sido capaces de resolver el problema y quedarnos con la versión actual. Según calendario, llevamos con “el pez que se muerde la cola” desde 2010 aproximadamente a un modo de alerta recurrente. Tal vez sea lo más parecido a la escasez del petróleo en este actual siglo ¿Y... cómo ponemos solución al remedio?
IPv6 Council al Rescate
La IPv6 Council es una asociación, grupo de interés sin ánimo de lucro con espíritu muy colaborativo, portadora de ideas, ganas de promocionar, dar soporte... con el afán de “apadrinar” a la “sexta elementa” para poner a España a la vanguardia tecnológica haciendo uso de la versión “moderna” del protocolo IP.
Liderado por Carlos Ralli, Fran Gómez y Rafa Sánchez, se mira de hacer todo lo posible para hacer llegar preocupaciones, tácticas de encaje con dinamismo y posturas flexibles al extenso ámbito tecnológico, ya que, la IP es un pilar básico de cualquier dispositivo digital (como toda la “cacharrería” de los IoT).
Sin ir más lejos, en este mismo mes de Mayo han estado presencialmente en el congreso MetaWorld Congress [MTW]/OpenExpo celebrado en la La Nave de Madrid.
Al tratarse de ataques tanto en IP “clásica” como en IPv6, tienen que explicar sus bases de raíz para tener un mínimo contexto. Si le echáis un vistazo al índice podréis ver los conceptos en su capítulo V, apartado 5.1, “Conceptos básicos sobre IPv6”.
Sí, efectivamente, comenté que en este par de libros, como una de la tareas principales era analizar el tráfico que fluía por los dispositivos que tienes en tu hogar, primero debes de conocerlos bien, hacer un “PreCheckeo: I&I, Identificación e Inventariado” (apartado 2 del capítulo III del primer libro de Hacking Home Devices), tal y como puedes ver en el índice que te dejo a continuación.
Y te vas dando cuenta que IPv6 es también una protagonista notoria que se aposenta en tu red como telarañas discretas en un hogar. Sobretodo la presencia automática e obligatoria de Link-Local (sí, aquella que empieza con el prefijo fe80::…) Si ejecutas un ipconfig en el “ventanal negro” y la ves, es señal de que tienes en activo IPv6 (by default es así).
Primero aprende la primera versión de la IP (IPv4)
Cualquier docente mínimamente cualificado te dirá que antes de aventurarte con IPv6, primero debes entender bien su funcionamiento estudiando su hermana menor, la IPv4. Podríamos explicarlo en este artículo, pero se haría muy largo… por eso, me siento en la obligación de recomendar un libro realmente bueno para aprender de IP y de otros conceptos informáticos elementales (y no tan elementales). El libro de David Casas de Competencia Digital.
Te bastará solo con su lectura para entender bien su composición, tipos de IP, rango, subredes… ¿Y no habla luego de IPv6? Sí, por supuesto, pero no se potencia en detalle como IPv4 porque su interés es primero en entender bien las bases de una IP. A pesar de sus diferencias respecto a la clásica IP, la construcción de la versión 6 se hace de manera similar, pero éstas son mas bien un “choricillo” (como bien menciona David Casas) de longitud, precisamente para abarcar con muchísimas más IP’s disponibles que con IPv4 (pasando de 32 a 128 bit en la sexta versión).
Aún así, estoy bastante convencido, que si llega el día de la extinción al completo de IPv4, todavía perdurará en los libros y documentación en Internet para facilitar su enseñanza, aunque existen grandes diferencias de funcionamiento después con IPv6 que debes aprender.
Las IPv6 de tu casa
Como se ha descrito antes, puedes saber si tu sistema operativo como Windows usa IPv6 y qué dirección toma. Si sabes como van las IPv4, las direcciones IPv6 de Link-Local (con prefijo fe80::/10) se asignan automáticamente a toda interfaz de red con IPv6 habilitado, son obligatorias y sólo funcionan dentro del segmento de red local.
Se utilizan para funciones esenciales como la auto-configuración, el descubrimiento de vecinos (NDP) y la comunicación local entre dispositivos. Aunque tradicionalmente la parte identificadora podía derivarse de la MAC (EUI-64), hoy en día muchos sistemas operativos emplean métodos aleatorios para mayor privacidad.
La unicidad de la dirección se verifica mediante NDP, y no son enrutables fuera del enlace local, igual que las direcciones APIPA en IPv4, aunque en IPv6 su presencia es universal y no sólo ante fallos de DHCP. Supongamos que tu equipo toma esta dirección IPv6:
fe80::9a94:43a9:9ff4:6981
Como se expresa en hexadecimal, las letras-números válidos son de 0-9 y A-F. Cada casillon de la IPv6 se compone de 4 dígitos hexadecimales y cada carácter hexadecimal representa 4 bit. Por lo tanto, cada casillón obtiene 16 bit en grupos de 8 casillones. Pero espera… ¿por qué yo aquí sólo veo 5 grupos? Cuando los grupos están a “0” se suele expresar/interpretar con doble -dos puntos- “::”. Esta IPv6 se expresaría así;
fe80:0000:0000:0000:9a94:43a9:9ff4:6981
Vale entiendo… pero y esto de la /10? Al igual que IPv4 con sus máscaras, el estándar dice que las Link-Local, pueden ir de la fe80:: a la febf:: . Esto es simple cuando descomponemos a binario (de hexadecimal a binario).
fe80:: seria 1111 1110 1000 0000
febf:: seria 1111 1110 1011 1111
La parte subrayada es la que contempla/hace referencia a la red y es intocable. El resto pertenece a la parte de host (recuerda entender bien IPv4 para saber como va el “rollete” ;) ). En la practica (por el momento) se utiliza la notación de máscara /64 por lo que el prefijo fe80:: siempre será impuesto en toda Link-Local. Es decir, en el ejemplo de la IPv6 Link-Local:
fe80:0000:0000:0000:9a94:43a9:9ff4:6981
Será inmóvil sus 4 primeros grupos. Una de mis reglas mnemotécnicas preferidas es hacer uso de la calculadora de Windows, sobretodo para esclarecer la parte de net y la de host.
Figura 12: Rango de IPv6 Link-Local haciendo
uso de la Calculadora de Windows
Se estipula en modo programador, en notación hexadecimal y teclado numérico de alternancia de bits. La parte roja hace referencia a la parte de red, que son sus primeros 10 bit inmóviles (/10) y la parte verde la de host, donde se conmutan todos los bits a “1” para saber su rango máximo en su primer casillón de 16 bits. Lo bueno de la calculadora, es que te permite conmutar cada bit a clic de ratón (parece una tontería, pero refuerza el entendimiento para su comprensión). Nota: Cómo se muestra en la figura, puedes también ejecutar más de una instancia de calculadora al mismo tiempo.
¿Y que más tipos IPv6 prefijadas puedo ver en casa?
Aquí te dejo este “chuletón” de llamadas/peticiones multicast interesantes:
ff02::1: Es la dirección multicast de todos los nodos en el segmento local. Todo dispositivo IPv6 la escucha.
ff02::1:2: Es la dirección multicast para todos los servidores DHCPv6 en el segmento local.
ff02::1:3: Es la dirección multicast usada por LLMNR (Link-Local Multicast Name Resolution) en IPv6, en el puerto 5355.
ff02::1:ffxx:xxxx (Solicited-Node Multicast): Es la dirección multicast generada automáticamente por cada host IPv6 para facilitar la resolución de direcciones (Neighbor Discovery Protocol, NDP), similar al ARP en IPv4, pero usando ICMPv6. El rango es ff02::1:ff00:0/104, y los últimos 24 bits corresponden a los últimos 24 bits de la dirección IPv6 del host.
ff02::2: Es la dirección multicast de todos los routers IPv6 en el segmento local.
ff02::c: Se utiliza para el descubrimiento de servicios SSDP (Simple Service Discovery Protocol), típicamente en el puerto 1900.
ff02::16: Es la dirección multicast para MLDv2 (Multicast Listener Discovery versión 2), usada por routers para saber qué dispositivos escuchan tráfico multicast.
ff02::fb: Es la dirección multicast utilizada por mDNS (Multicast DNS) en IPv6, puerto 5353.
Un Vídeo MitM como excusa para dar bombo a IPv6
La verdad es que esto del vídeo ha sido una “alineación de astros y planetas” en toda regla y salió en un momento bastante oportuno. Os explico a modo resumen como se gestó esto.Yo participo en el chat público de El lado del mal en MyPublicInbox. Marta Tobarias me comentó que tenía un blog de ciberseguridad y me dijo que si pudiese darle un poco de “feedback” estaría genial. Me llamó la atención uno sobre Neighbor Spoofing en IPv6. Y buscando en YouTube a mí no me acababan de llenar los vídeos sobre este tema concreto (que igual no busqué en profundidad…).
Yo sabía bien de su funcionamiento, por. las charlas y artículos de Chema Alonso y la Evil Foca. Y le dije a Marta que le haría un vídeo intentándolo explicar bien y hacerlo un poco divertido. A este proyecto se sumó Maria Gomez Prieto que quería meterle mano, un lavado digital para romper la aburrida barrera informática de comandos y paquetes, locos protocolos… que seria OK para los más entendidos pero no tan bien para quien está aprendiendo seguridad informática (ya sabéis que este tipo de videos suelen ser en su mayoría “feos”, poco estéticos y aburridos ¡Para que engañarnos!).
Figura 14: Los culpables de que se haya hecho este artículo y vídeo.
Yo a María la conocí en su pedazo de artículo sobre "Cómo recuperar juegos creados en Flash usando Ruffle", me sorprendió mucho su manejo en la edición de vídeos y la destreza en barajar los bits como pelar patatas para freírlas, o para acabar haciendo tortilla a la española… es decir, fue como recuperar una receta perdida y modificarla para reemplazar con ingredientes que no se tienen (o que son más fáciles de encontrar).
Me contentó mucho cuando la vi por el chat, y me convertí en una especie de fan (admiro mucho su trabajo). Tal es así que nos conocimos en persona en la MTW/OpenExpo junto a otro miembro del chat, a Mikeldi.
Figura 15: Posando frente a un Delorean de Bit2Me. Gerard Fuguet (izquierda)
María me bautizó en el chat como Mr. Fuguet, yo a ella como Lady Maria y María a Marta como Miss Marta. Con Lady Maria tengo muy buena afinidad, similar humor, etcétera. De igual modo con Mikeldi, persona espectacular y bondadosa. Me sentí muy bien y querido, estoy muy contento por hacer amistad con gente con la que tienes mucho de lo que compartir, todo gracias a ELDM y el chat que ha sido el punto de unión.
¡Y volviendo al vídeo! No es nada nuevo pero creo que ha quedado una obra maestra la cual todo el mérito, para nada es mío… Como os he dicho, la colaboración ha generado un producto que creo que es de muy buena calidad. Os presento, en esta foto, a los actores que participan y hablamos de sus roles ;)
Figura 16: Los actores del vídeo IPv6 con MitM con NDP
Izquierda-arriba: Tenemos a Manson quien actúa de mero servidor FTP (sí, sin “s” ¡OJO!) bajo Windows 10. Se va a quedar todo el tiempo calladito :D
Abajo-izquierda-derecha: La dulce y atractiva Marilyn, es la víctima en este escenario de juego. Quien se comunica con el FTP de Manson.
En el centro (¡y pa dentro!):Tenemos a Kalimera. Que le encanta el Kalimocho y cuando bebe se pone a “ciberdelinquir” un rato :P Le encanta disfrazarse para pasar desapercibida (arriba-derecha en la foto).
Las características del laboratorio son simples. Todo se corre en VirtualBox. La red usada (donde se unen todas las máquinas) es de tipo interna. Se estipula la IPv4 a modo estático en cada una de las máquinas. Tanto Marilyn como Manson usan Windows 10 de 32 bit (el motivo es para no consumir muchos recursos) que están actualizadas al máximo con su Win Update a FULL y firewall activo “By Default”, únicamente se le ha permitido la regla de FTP de entrada en la máquina de Manson.
Y como no, una Kali versión 2022.3 (no muy actual pero suficiente). Las herramientas de ataque usadas vienen incluidas en Kali, son atk6-parasite6 (para verlo pasivamente) y atk6-fake_advertise6 (modo activo). No tiene sentido que os describa todo el vídeo aquí en este post, ya que “habla” por sí solo (incluida la descripción del mismo, que he agotado al máximo los 5000 caracteres que permite YouTube). Pero sí me parece interesante contarte algo que no se diga en él.
La intención de esta figura es mostrar las relaciones de IPv6 y partes de ella con la zona prefijada de MAC’s que surgen en el momento de acogerse a una IPv6 Link-Local por la “inocente” Marilyn y el rellenado de su tabla caché (relación IPv6 y MAC) cuando necesita, además, obtener la MAC de un host destino (y lo pide muy amablemente la señorita).
Figura 18: Solicited-node Multicast Address. Vista de Wireshark
y tabla de cache de los vecinos en cmd de la víctima
Antes se ha mencionado que cada host crea obligatoriamente una dirección Solicited-node Multicast. En la figura, primero se ha generado la Solicited-node Multicast - última línea en cmd - del propio host. Como se observa, los últimos 6 caracteres hexadecimales concuerdan con los últimos 6 de la MAC (lo cuál no indica su MAC real de host, se estipula para consultar sí coincide con la solicitud del contrario que intenta comunicarse con Marilyn en dicho mecanismo).
El primer paquete que aparece en la figura, el número 14, se hace uso de este mismo sistema, en su capa de datos se puede ver cómo se pide la IPv6 - Target Address - de Manson. Luego, en la ventana cmd, se genera una segunda línea por encima de su propia generada al crearse su Link-Local,Solicited-node Multicast para “dejarlo por escrito” (como un log/registro) ¿Se esclarece el enigma mejor viendo los paquetes de red?
Y llegó el momento de ver el vídeo de todo este embrollo… Puedes hacerte unas palomitas si lo deseas porque te prometo, que en estos casi treinta minutos, se te pasarán rápidos, como ver una película en tu mejor cine - en tu propia casa, a tus anchas, a tus comodidades y tus reglas -. ¡¿Preparad@?! LET’S GO!!!
Cuando en una auditoría de seguridad te toca lidiar con una vulnerabilidad SQL Injection en la que la base de datos está almacenada en un motor JET de Microsoft Access las herramientas con las que hay que trabajar son muy distintas a las del resto de los motores de bases de datos. No es que cuando te enfrentes a un Microsoft SQL Server, un Oracle Database o un MySQL sean las cosas exactamente iguales en ellos, pero la ausencia de un diccionario de datos que consultar como los esquemas de Oracle o la no existencia de procedimientos almacenados como los que hay en Transact-SQL hacen las cosas siempre un poco más difíciles.
Figura 1: Codemotion 2013 - Feliz 15 aniversario SQL Injection
En la charla que di en el pasado Codemotion que os dejo por aquí hago un repaso a las principales técnicas de SQL Injection durante los últimos 15 años, y si quieres aprender bien las técnicas de SQL Injection puedes leer el libro de Hacking de Aplicaciones Web: SQL Injection.
SQL Injection en Microsoft Access
En uno de esos sitios me topé con SQL Injectionin-band en el que era posible construir una consulta de inyección con un UNION. Hacer esto había sido fácil porque el truco para hacerlo es sencillo y lo había utilizado ya para hacer las consultas pesadas en el trabajo de Time-Based Blind SQL Injection using Heavy Queries sobre Access. Solo debía tirar sobre una de las tablas que existen en las bases de datos y que pueden utilizarse en una consulta SQL.
En este caso la tabla que utilicé fue MSysAccessObjects que está disponible en las versiones de Microsoft Access 97 o Microsoft Access 2000, ya que en 2003 y 2007 esa tabla fue cambiada por otras. La lista de tablas que hay en cada versión de MS Access 97 a MS Acces 2007 - a partir de MS Access 2010 el formato dejó de ser mdb - está disponible en muchos sitios. Yo tiré de este tutorial de Net_Spy. Como se puede ver, aunque cada versión tiene una lista de tablas comunes, solo son utilizables en una consulta SQL aquellas que tienen el carácter asterisco a su lado.
Figura 2: Tablas disponibles en las versiones de Microsoft Access 97 a 2007
Una vez que está construida la consulta de inyección SQLi con el UNION usando constantes y apoyándonos en una tabla conocida como MSysAccessObjects, el siguiente paso es descubrir las tablas que forman parte de esa base de datos, para lo que se debe tirar a los sospechosos habituales - como users, users, customers, clients, usuarios, etcétera -.
En mi caso, no hubo suerte con los sospechosos habituales, así que había que pasar a tirar un diccionario con una buena cantidad de palabras porque no había encontrado ninguna. Esto puede pasar muchas veces. Si el dueño de la base de datos ha decidido utilizar una nomenclatura del tipo tablaAppCompras_usuarios, te puedes hacer anciano esperando a descubrir una de esas tablas. Ese es el problema de no tener un diccionario de datos que se pueda consultar en el motor.
Si se hubiera descubierto el nombre de las tablas, luego se puede abusar de los mensajes de error que se obtienen al usar la claúsula Group BY, o bien volver hacer un ataque de diccionario otra vez contra los campos de las tablas. En este caso en concreto solo fui capaz de sacar el nombre de unos campos de la tabla con ataques out-band generando mensajes de error del motor JET.
No obstante, en Microsoft Access se pueden hacer cosas muy chulas fuera del motor de la base de datos, que paso a detallaros, ya que os pueden venir bien en una auditoría en el futuro. Todos ellos son ataques out-band que se apoyan en el mensaje de error del motor JET de Microsoft Access.
Descubrir si un fichero existe y/o si está en uso
En el lenguaje SQL de Microsoft Access se puede hacer uso del operador IN para especificar que una tabla se encuentra dentro de otro fichero mdb de Microsoft Access. Es decir, es posible hacer una consulta que haga JOIN entre dos tablas y que cada una de ellas se encuentre en un fichero .mdb distinto. La consulta es tan sencilla como:
and exists (Select 1,2,3 from MSysAccessObjects IN 'autoexec.bat')
Poniendo el nombre de cualquier fichero - no importa si el fichero no es de bases de datos Microsoft Access - recibiremos un error distinto en tres situaciones posibles:
a) El fichero no existe
Figura 3: error al usar "and exists (Select 1 from MSysAccessObjects in 'foca.foca')
b) El fichero existe pero está en uso y no se puede abrir
Figura 4: El fichero boot.ini existe pero no se puede abrir
c) El fichero existe, se puede abrir, pero no es una base de datos Access
Figura 5: error al usar "and exists (Select 1 from MSysAccessObjects in 'autoexec.bat')
Por desgracia, yo me he encontrado con algunas limitaciones con estas inyecciones, que paso a detallaros:
1.- No es posible cambiar de unidad, así que si la base de datos del motor JET está en la unidad C:, este truco te permitirá listar solo ficheros de esa unidad.
2.- No se pueden listar ficheros sin extensión. El error que he obtenido ha sido siempre el mismo con ficheros que sé que existen y con ficheros que se que no existen.
3.- No funciona para listar directorios. Si se intenta usar para saber si un directorio existe o no, solo se puede hacer con algún fichero que se conozca que está dentro. Si no, el mensaje de error que se obtiene es siempre el mismo.
4.- No se pueden utilizar comodines * o ? para escribir el nombre de los ficheros.
5.- No se pueden utilizar las variables de entorno tipo %USERDIR%, %WINDIR%, etcétera.
Sacar los datos de un fichero mdb en el mismo servidor
En los ejemplos anteriores se ha supuesto que el objetivo era conocer la existencia o no de un fichero, pero si se descubriera otro fichero mdb de otra aplicación en el sistema. Se podría extraer toda la información de la misma usando como base la conectada a la aplicación con SQL Injection que se está utilizando para lanzar el ataque.
Figura 6: Extraer datos de otra base de datos mdb no expuesta a Internet
Sacar la lista de usuarios de un sistema Windows
Aprovechándome de esta función de listar ficheros, decidí que un buen truco sería listar ficheros de los perfiles de los usuarios que existieran. En este caso, se puede ver que tirando del directorio de Default User es cómodo construir alguna consulta con algún fichero de los perfiles de usuario.
Figura 7: Ruta al perfil de Default User
En este ejemplo usé NTUSer.dat para tener un fichero sobre el que apoyarme y luego ir cambiando el nombre de los usuarios. Como puede verse, el usuario Administrator existe.
Figura 8: Ruta al perfil del Administrador. Existe y está en uso, lo que significa que la sesión está abierta.
El resto es lanzar un diccionario con los nombres de usuario para tener la lista completa y, por supuesto, aprovecharse de los nombres de usuarios que FOCA hubiera descubierto de los metadatos de los documentos del sitio web.
Descubrir si un fichero existe y/o si está en uso usando formato de nombres 8:3
Acordándome del bug de IIS Shortname se me ocurrió que podría ser buena idea intentar localizar nombres de ficheros de más de 8 caracteres usando la codificación 8:3. Esto haría que fuera bastante más reducido el tiempo con un intento de descubrir ficheros de una carpeta, sobre todo si se va a hacer un ataque de fuerza bruta.
Figura 9: Ruta al perfil de Default User con nombres 8:3
Para comprobarlo, utilicé de nuevo el fichero de perfil de Default User y como se puede ver es posible, por lo que para hacer un ataque de fuerza bruta a la lista de usuarios se simplificaría un poco. Se podría haber hecho de igual forma con el usuario Admini~1, y volveríamos a ver que el fichero está en uso.
Figura 10: Ruta al perfil del Administrador en nombres 8:3
No solo ayuda a reducir el número de ataques, sino a reducir el tamaño de la URL inyectada, lo que siempre viene bien para evitar cualquier límite de tamaño que pudiera existir.
Listar el software instalado en el servidor
Con la misma idea de reconocer usuarios del sistema por los ficheros de su perfil, se podría hacer un listado del software instalado en el equipo - y el que está en arrancado por los errores de acceso en uso - buscando los ficheros de los programas. Para ello habría que tener una lista de rutas de instalación por defecto de los programas más comunes y buscarlos.
Figura 11: Ruta de instalación por defecto de WinZip. No está en el sistema
Si los programas están instalados en otra unidad o están en rutas distintas esto no valdría, pero si se conoce el software se podría intentar preparar, por ejemplo un ataque de evil grade o un exploiting concreto conociendo la existencia de un software vulnerable sin actualizar.
Descubrir la ruta de instalación del servidor web
Otro de las fugas de información que se pueden aprovechar con los errores JET es el del path de instalación del motor en el servicio web. No es la ruta en la que se encuentra el fichero mdb de la base de datos Microsoft Access, pero sí que da información más que suficiente para conocer con qué servidor Windows se está lidiando.
Figura 12: Local path disclosure al buscar en foca.foca
Para conseguirlo solo hay que hacer una consulta SQL inyectada similar a esta:
and exists (Select 1,2,3 from fake_database.fake_table)
Al no existir el fichero fake_database con una base de datos Microsoft Access en la carpeta donde se encuentra la base de datos actual, se produce un error que muestra la ruta local al servicio IIS.
Listar los roles del servidor. ¿Es un Controlador de Dominio?
Los archivos que tiene un servidor Windows sirven también para identificar los roles que tiene un servidor Windows asignado. Si tiene un servicio DHCP, un servicio DNS o si es un controlador de domino.
Figura 13: Petición de la base de datos de Active Directory. No está disponible.
Por ejemplo, para saber si es un Active Directory se podría buscar la base de datos NTDIS.Dat en la ruta en la que se configura. En este caso no tiene asignado este rol.
Descubrir el nombre del fichero de la base de datos
Uno de los ataques más fáciles de realizar a sistemas que usan como repositorio de datos un fichero mdb de Microsoft Access, es descargar el fichero completo. Para ello hay que averiguar dos cosas que son, el directorio donde se almacena - que deberá ser público para poder descargarlo- y el nombre del fichero.
Si esto se hace en dos fases en lugar de en una, el proceso es un poco más sencillo. Averiguar el nombre del fichero, sin importar el directorio en el que esté, se puede hacer haciendo uso de una consulta inyectada similar a la anterior, pero en lugar de usar una fake_database, usar uno de los nombres posibles:
and exists (Select 1,2,3 from fichero.tabla_existente)
esto permite que se obtenga un error cuando el fichero no exista se obtenga un error que indica que ese fichero mdb no está allí. Si existe, se conseguirá otra respuesta de la base de datos, en este caso un mensaje de syntax error porque la inyección se ha hecho para forzar el error out-band.
Figura 14: El fichero se llama database.mdb (nada imaginativo)
Una vez conocido el nombre de la base de datos, conocer su ubicación puede realizarse probando en todos los directorios de la web descubiertos con todas las técnicas que ya os dejé en el artículo: Técnicas para descubrir los ficheros de un servidor web.
Una frase para terminar
Un bug de SQL Injection es un fallo muy serio, y si tenemos una base de datos MS Access por medio se pueden hacer muchas cosas en el sistema operativo aunque no seamos capaces de descubrir las tablas de la base de datos. En este caso se ha hecho aprovechando un ataque out-band para ver los mensajes de error de que el fichero existe, la tabla existe, etcétera y errores de sintaxis, pero también se podría haber usado la técnica de Blind SQL Injection o Time-Based Blind SQL Injection using Heavy Queries para generar retardos de tiempo cuando la respuesta fuera correcta.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
