Seguridad seria: cómo los errores tipográficos deliberados podrían mejorar la seguridad del DNS

A lo largo de los años, hemos escrito y habla en Naked Security muchas veces sobre el espinoso problema del DNS secuestro.

DNS, como probablemente sepa, es la abreviatura de sistema de nombres de dominio, y con frecuencia escuchará que se describe como el "directorio telefónico" o "nomenclátor" de Internet.

Si no estás familiarizado con la palabra nomenclátor, se refiere al índice en la parte posterior de un atlas donde busca, digamos, Monrovia, Liberia en una conveniente lista alfabética, y dice algo como 184 - C4. Esto le indica que pase directamente a la página 184 y siga las líneas de la cuadrícula hacia abajo desde la letra C en la parte superior del mapa y hacia el número 4 a la izquierda. Donde se unen las líneas, encontrarás Monrovia.

Para la mayoría de los usuarios, la mayoría de las búsquedas de DNS contienen un nombre de servidor y solicitan una respuesta que incluya lo que se conoce como su registro A o su registro AAAA.

(Los registros A se utilizan para números de Internet IPv32 de 4 bits, como 203.0.113.42; Los registros AAAA son las respuestas equivalentes para direcciones IPv128 de 6 bits, como 2001:db8:15a:d0c::42 – en este artículo, solo usaremos registros A y números IPv4, pero los mismos problemas de seguridad se aplican al proceso de búsqueda en ambos casos).

Aquí hay un ejemplo, donde estamos buscando el nombre de dominio imaginario naksec.test a través de un servidor DNS que fue especialmente creado para rastrear y enseñarle sobre el tráfico DNS.

Hemos utilizado la herramienta Linux de la vieja escuela dig, corto para dominio internet groper, para generar una solicitud de DNS simple (dig por defecto busca registros A) para el servidor que queremos:

$ cavar +noedns @127.42.42.254 naksec.test ;; SECCIÓN DE PREGUNTAS: ;naksec.test. EN UN ;; SECCIÓN DE RESPUESTAS: NAKSEC.TEST. 5 EN A 203.0.113.42 ;; Tiempo de consulta: 1 ms ;; SERVIDOR: 127.42.42.254#53(127.42.42.254) (UDP) ;; CUÁNDO: lun 23 de enero 14:38:42 GMT 2023 ;; TAMAÑO DEL MENSAJE recibido: 56

Así es como nuestro servidor DNS manejó la solicitud, mostrando un volcado hexadecimal de la solicitud entrante y la respuesta exitosa que se devolvió:

---> Solicitud de 127.0.0.1:57708 a 127.42.42.254:53 ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6e 61 6b |bN. ......... nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 |seg.test..... | Búsqueda de DNS: registro A para naksec.test ==> A=203.0.113.42 <--- Respuesta de 127.42.42.254:53 a 127.0.0.1:57708 <--- 00000000 62 4e 84 b0 00 01 00 01 00 00 00 00 06 6e 61 6b |bN...........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |seg.test......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |PRUEBA.KSEC.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Tenga en cuenta que, por motivos de rendimiento, la mayoría de las solicitudes de DNS utilizan UDP, el protocolo de datagrama de usuario, que funciona sobre la base de enviar y esperar: dispara un paquete UDP en el servidor con el que desea hablar y luego espera para ver si recibe una respuesta.

Esto hace que UDP sea mucho más simple y rápido que su primo mayor TCP, el Protocolo de Control de Transmisión, que, como sugiere su nombre, se encarga automáticamente de muchos detalles que UDP no hace.

En particular, TCP se ocupa de detectar la pérdida de datos y volver a solicitarlos; asegurarse de que los fragmentos de datos lleguen en el orden correcto; y proporcionar una única conexión de red que, una vez configurada, se puede utilizar para enviar y recibir al mismo tiempo.

UDP no tiene el concepto de una "conexión", por lo que las solicitudes y respuestas esencialmente viajan de forma independiente:

• Una solicitud DNS llega al servidor DNS en un paquete UDP propio.
• El servidor DNS mantiene un registro de qué computadora envió ese paquete en particular.
• El servidor se pone a buscar una respuesta para devolverla, o decidir que no hay uno.
• El servidor envía una respuesta. al remitente original, utilizando un segundo paquete UDP.

Desde el nivel del sistema operativo o la red, esos dos paquetes UDP anteriores son transmisiones independientes e independientes, no están vinculados como parte de la misma conexión digital.

Depende del servidor recordar a qué cliente enviar cada respuesta; y depende del cliente averiguar qué respuestas se relacionan con qué solicitudes envió originalmente.

¿Como puedes estar seguro?

En este punto, especialmente al observar el tamaño diminuto de la solicitud DNS y la respuesta anterior, probablemente se esté preguntando: "¿Cómo puede el cliente estar seguro de que coincide con la respuesta correcta y no una que ha sido distorsionada en tránsito o dirigida incorrectamente?" por error, ya sea por accidente o por diseño?

Desafortunadamente, muchas, si no la mayoría, de las solicitudes de DNS (especialmente aquellas de servidor a servidor, cuando el primer servidor al que le preguntas no sabe la respuesta y necesita encontrar uno que la sepa para formular su respuesta) no están encriptadas, o etiquetado de otra manera con cualquier tipo de código de autenticación criptográfico.

De hecho, de forma predeterminada, las solicitudes de DNS incluyen una sola "etiqueta de identificación", a la que se hace referencia en la documentación del formato de datos de DNS simplemente como ID.

Sorprendentemente, a pesar de haber recibido numerosas actualizaciones y mejoras sugeridas a lo largo de los años, el RFC oficial de Internet (Solicitud de comentarios) el documento que actúa como la especificación DNS sigue siendo RFC 1035 (actualmente estamos en RFC a mediados de los 9000), que datan de noviembre de 1987, ¡hace poco más de 35 años!

En aquel entonces, tanto el ancho de banda como la potencia de procesamiento eran escasos: las velocidades típicas de la CPU eran de unos 10 MHz; las computadoras de escritorio tenían alrededor de 1 MB de RAM; las velocidades de acceso a Internet, para las organizaciones que podían conectarse, a menudo eran de 56 kbits/seg o 64 kbits/seg, compartidas entre todos; y 1200bits/seg fue la opción asequible para la conectividad personal a través de los módems de acceso telefónico de la época.

Es por eso que los encabezados de solicitud y respuesta de DNS fueron, y aún lo son, comprimidos en unos míseros 12 bytes, de los cuales la etiqueta de identificación ocupa los dos primeros, como el lindo RFC 1035. Arte ASCII deja claro:

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | identificación | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| Código de operación |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CUENTAQD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CUENTA | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCUENTO | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Puede ver el ID en acción en los volcados hexadecimales que se muestran arriba, donde los paquetes de solicitud y respuesta comienzan con los mismos dos caracteres. bN, que corresponden al identificador de 16 bits 62 4e en hexadecimal.

Hablando en términos generales, esos 16 bits son tanto como lo que proporciona el protocolo DNS oficial a modo de "autenticación" o "detección de errores".

Entrometiéndose por conjeturas

Como puede imaginar, dada la simplicidad de un extremo a otro del tráfico DNS regular, cualquier persona con un llamado caja intermedia or proxy de escaneo quien puede interceptar, examinar y modificar el tráfico de su red puede entrometerse trivialmente con su tráfico de DNS.

Esto incluye el envío de respuestas que deliberadamente le brindan información inexacta, como que su equipo de TI lo redirija fuera de los servidores que sabe que están llenos de malware.

También puede incluir que su ISP cumpla con la legislación de su país que requiere que algunos servidores se informen como inexistentes, incluso si están vivos y funcionando bien, porque están en una lista de bloqueo de contenido ilegal, como material de abuso infantil.

Pero, a primera vista, este tipo ultradébil de etiquetado de ID de DNS también parece trivial incluso para los atacantes que no tienen visibilidad del tráfico de su red en absoluto para disparar respuestas de DNS falsas a sus usuarios o sus servidores...

…con una probabilidad de éxito peligrosamente alta.

Después de todo, si los atacantes saben que a alguien en su red le gusta visitar regularmente naksec.test, ese servidor puede parecer un buen lugar para implantar noticias falsas, actualizaciones dudosas o código JavaScript no autorizado.

Y si los atacantes no pueden piratear el naksec.test mismo servidor, ¿qué pasaría si dispararan paquetes UDP de forma regular y frecuente en su servidor DNS, utilizando una etiqueta de identificación inventada, que afirmaba responder a la pregunta: "¿Cuál es el registro A para naksec.test"?

De esa manera, podrían secuestrar la solicitud de DNS, proporcionar una respuesta falsa y, por lo tanto, desviar su próxima visita al sitio web, esencialmente secuestrando el sitio en sí sin necesidad de atacar el naksec.test servidor en absoluto.

Un poco de suerte requerida

Tendrían que tener un poco de suerte, por supuesto, aunque podrían intentarlo una y otra vez para aumentar sus posibilidades generales, dado que solo necesitan tener éxito una vez, mientras que usted necesita obtener una respuesta DNS veraz cada vez.

Para tener éxito, necesitarían enviar su respuesta DNS no autorizada:

• Durante un período en el que su propio servidor aún no sabía la respuesta a la pregunta. Las respuestas de DNS incluyen un número de 32 bits llamado TTL, abreviatura de tiempo para vivir, que dice cuánto tiempo el otro extremo puede seguir reutilizando la respuesta. Si usted o cualquier otra persona en su red solicitó naksec.test recientemente, su servidor DNS podría tener la respuesta en su caché. No se necesitaría más búsqueda y no habría una solicitud saliente para que los atacantes la secuestraran.
• Entre el momento en que envió su solicitud y la respuesta oficial llegó desde el exterior. Incluso en los viejos tiempos, los tiempos de búsqueda de DNS rara vez duraban más de unos pocos segundos. Hoy en día, se miden mejor en milisegundos.
• Con el número correcto en sus primeros 16 bits. Puede caber 65536 (2¹⁶) diferentes valores en 16 bits, por lo que los atacantes tendrían que tener algo de suerte. Pero con los anchos de banda de la red actual, enviar 65536 respuestas falsas diferentes a la vez, cubriendo así todos los números de identificación posibles, toma una pequeña fracción de segundo.

Afortunadamente, los servidores DNS decentes toman un paso adicional para dificultar el secuestro de forma predeterminada.

Al menos, eso es lo que han estado haciendo desde 2008, cuando el difunto Dan Kaminsky señaló que muchos servidores DNS en ese entonces no solo estaban configurados para escuchar las solicitudes entrantes en un puerto UDP fijo (casi siempre el puerto 53, oficialmente asignado a DNS)...

…pero también para recibir respuestas entrantes en un puerto fijo, a menudo también en el puerto 53, aunque solo sea para crear una agradable simetría en el tráfico.

La razón para usar un puerto fijo en ambas direcciones probablemente fue originalmente para simplificar la programación. Al escuchar siempre las respuestas en el mismo número de puerto UDP, no necesita realizar un seguimiento de qué puertos deben abrirse para qué respuestas. Esto significa que el controlador de solicitudes y los componentes del generador de respuestas de su software DNS pueden operar de forma independiente. El oyente de la solicitud no necesita decirle al remitente de la respuesta: "Esta respuesta en particular debe regresar a un puerto especial, no al habitual".

Usar números de puerto como identificación adicional

En estos días, casi todos los servidores DNS basados ​​en UDP escuchan en el puerto 53, como siempre, pero realizan un seguimiento del llamado "puerto de origen" utilizado por el solicitante de DNS, que espera que se elija al azar.

Los puertos de origen UDP, que son un poco como un "número de extensión" en una central telefónica de oficina de la vieja escuela, están destinados a ayudarlo a usted y a la red a diferenciar las solicitudes entre sí.

Los puertos de protocolo de Internet (TCP también los usa) pueden ejecutarse del 1 al 65535, aunque la mayoría de las conexiones salientes solo usan los puertos de origen 1024-65535, porque los números de puerto 1023 e inferiores generalmente se reservan para procesos con privilegios del sistema.

La idea es que el remitente de cualquier búsqueda de DNS no solo debe insertar una identificación de 16 bits verdaderamente aleatoria al comienzo de cada solicitud, sino también elegir un número de puerto de origen UDP verdaderamente aleatorio en el que escuchará la respuesta asociada.

Esto agrega un nivel adicional de conjeturas que los delincuentes tienen que agregar a su lista anterior de "suerte de secuestro", es decir, que tienen que enviar una respuesta falsa que marca todas estas casillas:

• Debe ser una consulta que se hizo recientemente, normalmente en los últimos segundos.
• Debe ser una búsqueda que no estaba en el caché del servidor local, típicamente significa que nadie más preguntó al respecto en los últimos minutos.
• Debe tener el número de identificación de 16 bits correcto al comienzo del paquete de datos.
• Debe enviarse al puerto de destino correcto en el número de IP del servidor correspondiente.

Y otra cosa

De hecho, hay otro truco más que pueden hacer los solicitantes de DNS, sin cambiar el protocolo DNS subyacente y, por lo tanto (en su mayor parte), sin romper nada.

Este truco, sorprendentemente, fue primero propuesto allá por 2008, en un artículo gloriosamente titulado Mayor resistencia a la falsificación de DNS a través de la codificación de 0x20 bits: SEGURIDAD MEDIANTE CONSULTAS LEET.

La idea es extrañamente simple y se basa en dos detalles en el protocolo DNS:

• Todas las respuestas de DNS deben incluir la sección de consulta original al principio. Las consultas, obviamente, tienen una sección de respuesta vacía, pero se requiere que las respuestas reflejen la pregunta original, lo que ayuda a garantizar que las solicitudes y las respuestas no se mezclen accidentalmente.
• Todas las preguntas de DNS no distinguen entre mayúsculas y minúsculas. Ya sea que pidas naksec.testo NAKSEC.TESTo nAksEc.tESt, debe obtener la misma respuesta.

Ahora, no hay nada en el protocolo que diga que DEBE usar la misma ortografía en la parte de la respuesta donde repite la consulta original, porque al DNS no le importan las mayúsculas y minúsculas.

Pero aunque RFC 1035 requiere que haga comparaciones sin distinción entre mayúsculas y minúsculas, sugiere encarecidamente que en realidad no cambies el caso de cualquier nombre de texto que reciba en las solicitudes o recupere de sus propias bases de datos para usar en las respuestas.

En otras palabras, si recibe una solicitud de nAKsEC.tEST, y su base de datos lo tiene almacenado como NAKSEC.TEST, entonces esos dos nombres se consideran idénticos y coincidirán.

Pero cuando formulas tu respuesta, RFC 1035 sugiere que no cambie el carácter de mayúsculas y minúsculas de los datos que puso en su respuesta, a pesar de que podría pensar que se vería mejor, y aunque aún coincidiría en el otro extremo, gracias a la comparación sin distinción entre mayúsculas y minúsculas exigida por DNS.

Por lo tanto, si mezcla aleatoriamente el caso de las letras en una solicitud de DNS antes de enviarla, la mayoría de los servidores DNS reflejarán fielmente esa extraña mezcla de letras, incluso si su propia base de datos almacena el nombre del servidor de manera diferente, como puede ver aquí. :

$ cavar +noedns @127.42.42.254 nAkSEc.tEsT ;; SECCIÓN DE PREGUNTAS: ;nAkSEc.tEsT. EN UN ;; SECCIÓN DE RESPUESTAS: NAKSEC.TEST. 5 EN A 203.0.113.42 ;; Tiempo de consulta: 1 ms ;; SERVIDOR: 127.42.42.254#53(127.42.42.254) (UDP) ;; CUÁNDO: lun 23 de enero 14:40:34 GMT 2023 ;; TAMAÑO DEL MENSAJE recibido: 56

Nuestro servidor DNS almacena el nombre naksec.test todo en mayúsculas, por lo que la sección de respuesta de la respuesta incluye el nombre en la forma NAKSEC.TEST, junto con su número IPv4 (el registro A) de 203.0.113.42.

Pero en la parte de la respuesta "aquí están los datos de la consulta devueltos para la verificación cruzada" que nuestro servidor DNS devuelve, se conserva el mashup de mayúsculas y minúsculas utilizado originalmente en la búsqueda de DNS:

---> Solicitud de 127.0.0.1:55772 a 127.42.42.254:53 ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41 6b |.U. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |SEG.PRUEBA..... | Búsqueda de DNS: registro A para nAkSEc.tEsT ==> A=203.0.113.42 <--- Respuesta de 127.42.42.254:53 a 127.0.0.1:55772 <--- 00000000 c0 55 84 b0 00 01 00 01 00 00 00 00 06 6e 41 6b |.U...........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 06 4e 41 |SEG.PRUEBA......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |PRUEBA.KSEC.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Etiquetado de seguridad adicional, sin cargo

¡Bingo!

¡Hay algo más de "etiquetado de identificación" que puede agregar una búsqueda de DNS!

Junto con aproximadamente 15 bits de puerto de origen elegido al azar y 16 bits de datos de números de identificación elegidos al azar, el solicitante puede elegir entre mayúsculas y minúsculas para cada carácter alfabético en el nombre de dominio.

Y naksec.test contiene 10 letras, cada una de las cuales puede escribirse en mayúsculas o minúsculas, para un "etiquetado" aleatorio adicional de 10 bits.

Con este detalle adicional para adivinar, los atacantes tendrían que tener suerte con su tiempo, el número de puerto UDP, el valor de la etiqueta de identificación y las mayúsculas del nombre de dominio, para inyectar una "respuesta de secuestro" falsa que el servidor solicitante aceptaría.

Por cierto, el nombre codificación 0x20 arriba hay un poco de broma: 0x20 en encabezamiento es 00100000 en binario, y el bit solitario en ese byte es lo que diferencia las letras mayúsculas de las minúsculas en el sistema de codificación ASCII.

Las cartas A a I, por ejemplo, sale como 0x41 a 0x49, mientras que a a i sale como 0x61 a 0x69.

 Gráfico de codificación ASCII como texto ASCII +------+------+------+------+------+------+- -----+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60 ` |70 p | |01 ^A |11 ^Q |21 ! |31 1 |41 A |51 Q |61 a |71 q | |02 ^B |12 ^R |22 " |32 2 |42 B |52 R |62 b |72 r | |03 ^C |13 ^S |23 # |33 3 |43 C |53 S |63 c |73 s | |04 ^D |14 ^T |24 $ |34 4 |44 D |54 T |64 d |74 t | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u | |06 ^F |16 ^V |26 & |36 6 |46 F |56 V |66 f |76 v | |07 ^G |17 ^W |27 ' |37 7 | 47 G |57 W |67 g |77 w | |08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 h |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 I |59 Y |69 i |79 y | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A j |7A z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C l |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E .|3E > |4E N |5E ^ |6E n |7E ~ | | 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F o |7F | +------+------+------+--- ---+------+------+------+------+

En otras palabras, si sumas 0x41+0x20 para obtener 0x61, conviertes A dentro a; si restas 0x69-0x20 para obtener 0x49, conviertes i dentro I.

¿Por qué ahora?

Es posible que, a estas alturas, se esté preguntando, “¿Por qué ahora, si la idea apareció hace 15 años, y de todos modos serviría de algo?”.

Nuestro interés repentino, como sucede, proviene de una correo electrónico público reciente de los técnicos de Google, admitiendo que sus experimentos de 2022 con este truco de SEGURIDAD de la vieja escuela se han implementado en la vida real:

Como anunciamos anteriormente, el DNS público de Google está en proceso de habilitar la aleatorización de casos de nombres de consultas de DNS enviados a servidores de nombres autorizados. Lo hemos implementado con éxito en algunas regiones de América del Norte, Europa y Asia protegiendo la mayoría (90 %) de las consultas de DNS en aquellas regiones que no están cubiertas por DNS sobre TLS.

Curiosamente, Google sugiere que los principales problemas que ha tenido con este ajuste simple y aparentemente no controvertido es que, si bien la mayoría de los servidores DNS no distinguen entre mayúsculas y minúsculas (por lo que este truco se puede usar con ellos) o no (por lo que están en la lista de bloqueo), como se podría esperar…

…algunos servidores principales caen ocasionalmente en el modo “sensible a mayúsculas y minúsculas” por períodos breves, lo que suena como el tipo de inconsistencia que usted esperaría que los principales proveedores de servicios evitaran.

¿Realmente ayuda?

La respuesta a la pregunta, "¿Vale la pena?" aún no está claro.

Si tienes un buen nombre de servicio largo, como nakedsecurity.sophos.com (22 caracteres alfabéticos), entonces hay mucho poder de señalización adicional, porque 2²² diferentes mayúsculas significan 4 millones de combinaciones para que los ladrones prueben, multiplicado por los 65536 números de identificación diferentes, multiplicado por los aproximadamente 32000 a 64000 puertos de origen diferentes para adivinar...

…pero si ha pagado una pequeña fortuna por un nombre de dominio supercorto, como el de Twitter t.co, sus atacantes solo tienen un trabajo 2x2x2=8 veces más difícil que antes.

Sin embargo, creo que podemos decir, "Chapeau" a Google por probar esto.

Como les gusta decir a los observadores de seguridad cibernética, los ataques se vuelven cada vez más rápidos, por lo que cualquier cosa que pueda tomar un protocolo existente y agregarle tiempo adicional de craqueo, casi "gratis", es una forma útil de contraatacar.

---

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/