Análisis hexadecimal de una consulta DNS

Fecha: 12 de marzo del 2024

 

Escenario

 

Este laboratorio nació como consecuencia de un ataque DDoS a un DNS que sufrimos experimentamos

en primera persona hace unas semanas en el trabajo y que en las reuniones posteriores generó la duda,

si era realmente DDoS o sólo podría ser DoS desde un solo equipo y falseando la IP de origen.

De casos así sale prueba de concepto y nace un laboratorio.

Esto no tiene como objetivo el ataque en sí, ni las herramientas para hacerlo, ni como evitarlo, sino como

suceden las cosas tras bambalinas, para poder -intentar- dominar el arte del bajo nivel.      Allá vamos…

 

 

¿ Por qué hacer la consulta en hexadecimal ? porque la herramienta es para otra cosa y usamos el payload

como consulta DNS, para eso tenemos que replicar los campos de la cabecera DNS y agregarle el dominio.

 

1.- Consulta inicial para obtener una muestra:

 

El dominio test.com sólo se utilizó como simbolo de la prueba en sí y el DNS server sólo por costumbre, se genera una consulta

con una herramienta afín, si la respuesta es correcta o no devuelve errores, la consulta se utilizará como muestra hexadecimal .

 

1.1.- Se genera la consulta:

 

C:\>nslookup

Servidor predeterminado:  dns.google

Address:  8.8.8.8

> test.com

Servidor:  dns.google

Address:  8.8.8.8

 

Respuesta no autoritativa:

Nombre:  test.com

Addresses:  3.18.255.247

                    34.224.149.186

> 

 

1.2.- Análisis de la consulta:

 

 

Frame 1: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface id 0

Ethernet II, Src: 00:45:e2:87:31:0f, Dst: 30:df:8d:2c:ea:50        (layer 2)

Internet Protocol Version 4, Src: 192.168.1.119, Dst: 8.8.8.8 (layer 3)

User Datagram Protocol, Src Port: 54037, Dst Port: 53           (layer 4)

Domain Name System (query)                                                  (layer 7)

    Transaction ID: 0x0005

    Flags: 0x0100 Standard query

        0… …. …. …. = Response: Message is a query

        .000 0… …. …. = Opcode: Standard query (0)

        …. ..0. …. …. = Truncated: Message is not truncated

        …. …1 …. …. = Recursion desired: Do query recursively

        …. …. .0.. …. = Z: reserved (0)

        …. …. …0 …. = Non-authenticated data: Unacceptable

    Questions: 1

    Answer RRs: 0

    Authority RRs: 0

    Additional RRs: 0

    Queries                                                                                 

        test.com: type A, class IN

            Name: test.com

            [Name Length: 8]

            [Label Count: 2]

            Type: A (Host Address) (1)

            Class: IN (0x0001)

    [Response In: 7]

 

0000  30 df  8d 2c ea 50 00 45  e2 87 31 0f 08 00 45 00

0010  00 36 3e 3b 00 00 80 11 2a 4d c0 a8 01 77 08 08

0020  08 08 d3 15 00 35 00 22 aa cd 00 05 01 00 00 01

0030  00 00 00 00 00 00 04 74 65 73 74 03 63 6f 6d 00

0040  00 01 00 01                                      

 

1.3.- Campos hexadecimales de la consulta DNS (layer 7):

 

 

 

Domain Name System (query) (más detalles en la RFC 1035)

Transaction ID:  00 05

Flags:                01 00  (message is a query,standard query,not truncated,desired query recursively)

Questions:         00 01  (cuantas consultas se harán en el payload)

Answer RRs:     00 00  (cuantas respuestas hay en el payload)

Authority RRs:   00 00  (recursos autoritativos utilizados)

Additional RRs: 00 00   (recursos adicionales utilizados)

test.com             04 74 65 73 74 03 63 6f 6d 00

                                  t   e    s    t   .    c  o  m      (ver la tabla ASCII más abajo)

Type: A              00 01 (solicita una dirección IP)

Class: IN            00 01 (que proviene de internet)

 

1.4.- Volcado inicial:

                                                               inicio del FQDN               fin del FQDN

                                                               |                                        |

00 05 01 00 00 01 00 00 00 00 00 00 04 74 65 73 74 03 63 6f 6d 00 00 01 00 01

 

1.5.- Stream definitivo a utilizar:

 

000501000001000000000000047465737403636f6d0000010001

 

1.6.- Tabla ASCII – hexadecimal:

 

 

Fuente: https://www.rapidtables.com/code/text/ascii-table.html

 

The End of Transmission character (EOT) is a control character in the ASCII and Unicode character sets with the value of 4.

 

In modern computing and telecommunications, the use of the EOT character is less common as more complex protocols

have been developed, but it may still be used in some contexts, such as marking the end of input in certain command-line

interfaces.

 

It should be noted that the use of such control characters can vary widely between different systems and applications, and

their interpretation can often be context-dependent.

 

Fuente: https://www.ascii-code.com/character/%E2%90%84

 

The null character (NUL) is a control character with the value zero. It is present in many character sets, including ASCII

and its extensions, Unicode, EBCDIC, and others. In some cases, it is referred to as the NUL character.

 

Here are some key details:

 

In ASCII and Unicode, the null character is defined to be U+0000, meaning it is represented in Unicode as the number 0.

The null character is used in C and C++ as a string terminator, marking the end of a string of characters.

This allows the program to know when it has reached the end of the string.

The null character does not have a visual representation, meaning it’s invisible when it’s in a string of text.

In some contexts, it is used for padding where a fixed size data buffer is required.

Null characters can sometimes cause issues, especially when dealing with text, because many programs will stop reading

a string of text when they encounter a null character, assuming that it’s the end of the string.

In network communications, the null character is often used to signal the end of a message.

 

Fuente: https://www.ascii-code.com/character/%E2%90%80

 

 

2.- Puebas con una herramienta de generación de tráfico:

 

2.1.- Se aplican los números hexadecimales al campo Data (payload layers 5-7):

 

 

 

2.2.- Verificación de la consulta/respuesta:

 

Se genera una consulta y se obtiene la respuesta exitosa, lo cual verifica que el payload hexadecimal es válido.

 

 

 

3.- Pruebas de consultas random al server:

 

Esta es una simulación mas o menos parecida al ataque DDoS al DNS sufrido en febrero, con la misma herramienta pero por CLI.

 

3.1.- Envío de la trama/paquete/segmento/query:

 

C:\>frameip -interface 3 -mac_destination 30-df-8d-2c-ea-50 -ip_source 192.168.1.119 -ip_destination 8.8.8.8 -ip_type 17 //

// -udp_port_destination 53 -data_hexa 000501000001000000000000047465737403636f6d0000010001

|

FrameIP – Create some IP frame – Version 5.10.3.13

Create on December 21, 2002, Last compilation on June 02, 2009

Created by Sebastien FONTAINE – http://www.frameip.com

 

The frame was sent from 192.168.1.119 to 8.8.8.8 with 68 Bytes

 

C:\>

 

 

3.2.- Verificación de la consulta/respuesta:

 

Se genera una consulta y se obtiene la respuesta exitosa, lo cual verifica que el payload hexadecimal es válido, como detalle y diferencia

con la herramienta gráfica (no son las mismas versiones) es que ahora se genera un mensaje ICMP al server DNS de que la respuesta es

hacia un port inalcanzable, ya que llega al port de origen utilizado pero con la ventana de espera de respuesta cerrada (o quizás ni hubo

ventana de espera, eso quedaría como análisis de la herramienta).

       

 

 

Frame 3: 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits) on interface \Device\NPF_{51237185-E795-4E8E-B10D-F4A056B761F5}, id 0

Ethernet II, Src: 00:45:e2:87:31:0f, Dst: 30:df:8d:2c:ea:50

Internet Protocol Version 4, Src: 192.168.1.119, Dst: 8.8.8.8

Internet Control Message Protocol

    Type: 3 (Destination unreachable)

    Code: 3 (Port unreachable)

    Checksum: 0xcf7f [correct]

    [Checksum Status: Good]

    Unused: 00000000

    Internet Protocol Version 4, Src: 8.8.8.8, Dst: 192.168.1.119 (ICMP usa parte del paquete original al reportar el problema)

    User Datagram Protocol, Src Port: 53, Dst Port: 20814

        Source Port: 53

        Destination Port: 20814

        Length: 66

        Checksum: 0x6f70 [correct]

        [Checksum Status: Good]

        [Stream index: 0]

        UDP payload (58 bytes)

Domain Name System (response)

    Transaction ID: 0x0005

    Flags: 0x8180 Standard query response, No error

    Questions: 1

    Answer RRs: 2

    Authority RRs: 0

    Additional RRs: 0

    Queries

        test.com: type A, class IN

            Name: test.com

            [Name Length: 8]

            [Label Count: 2]

            Type: A (Host Address) (1)

            Class: IN (0x0001)

    Answers

    [Unsolicited: True]

 

 

3.3.- Envío desde origenes random:

 

Esto simularía un ataque DDoS ya que es desde un único roigen pero falseado como si fuese desde muchos, mas abajo

veremos la idea de este tipo de concepto de ataque.

 

 

 

C:\>frameip -interface 3 -mac_destination 30-df-8d-2c-ea-50 -ip_source r -ip_destination 8.8.8.8 -ip_type 17 //

// -udp_port_destination 53 -data_hexa 000501000001000000000000047465737403636f6d0000010001

 

FrameIP - Create some IP frame - Version 5.10.3.13

Create on December 21, 2002, Last compilation on June 02, 2009

Created by Sebastien FONTAINE - http://www.frameip.com

 

The frame was sent from 139.161.64.175 to 8.8.8.8 with 68 Bytes

The frame was sent from 4.17.61.42 to 8.8.8.8 with 68 Bytes

The frame was sent from 67.5.48.78 to 8.8.8.8 with 68 Bytes

The frame was sent from 19.53.13.122 to 8.8.8.8 with 68 Bytes

The frame was sent from 140.166.10.245 to 8.8.8.8 with 68 Bytes

 

 

Obviamente las respuestan nunca van a llegar, realmente van a llegar a los orígenes que forman el query DNS, seguramente

alguien recibirá respuestas DNS que nunca solicitó, y probablemente 8.8.8.8 recibirá mensajes ICMP como en el ejemplo anterior,

 o tal vez los firewalls de los origenes bloqueen una respuesta a una consulta que nunca pasó por ellos, ya los firewall statefull

dejan una ventana de X segundos abierta esperando la respuesta, y si la ventana nunca fué abierta desde ese origen, la respuesta

rebotará contra la pared (para los que no entiendan la analogía en este caso la pared es el firewall).

 

La única diferencia “visible” contra un DDoS real es que en todos los casos el TTL es el mismo, independientemente del origen,

Esto da una idea que el origen siempre es el mismo. La herramienta no soporta la función de TTL random tal como vemos:

 

IP HEADER OPTIONS

-ip_version       Between 0 & 15     Default: 4

-ip_ihl               Between 0 & 15     Default: 5

-ip_tos              Between 0 & 255    Default: 0

-ip_length         Between 0 & 65535  Default: a (a=>automatic)

-ip_id                Between 0 & 65535  Default: r (r=>random)

-ip_flag_zero    Between 0 or 1     Default: 0

-ip_flag_mf       Between 0 or 1     Default: 0

-ip_flag_df        Between 0 or 1     Default: 0

-ip_offset          Between 0 & 8191   Default: 0

-ip_ttl               Between 0 & 255    Default: 128

-ip_type            Between 0 & 255    Default: 1 (r=>random)

-ip_checksum   Between 0 & 65535  Default: a (a=>automatic)

-ip_source       @ Ip or host name  Default: 192.168.1.119 (r=>random)

-ip_destination  @ Ip or host name  Default: 192.168.101.254 (r=>random)

 

 

 

 

4.- Prueba de esta herramienta en el mundo real:

 

No es aconsejable utilizar esta herramienta como script-kiddie ya que puede causar daños a equipos de producción,

de hecho, en estas pruebas se ejecutaron sólo 5 consultas tal como se ve en la figura anterior, sólo para probar el

concepto y documentarlo.

 

Con las pruebas de este lab queda demostrado que un ataque puede provenir desde la vuelta de la esquina y parecer

que sea desde Europa del este o de cualquier lado del mundo, más si pudiesemos tocar los TTL, al menos con esta

herramienta que es la única que se utilizó, y como fin educativo.

 

Hay otros temas que quedan fuera del alcance y que motivan a estudiar, como por ejemplo generar source IP random

y que salgan de nuestro firewall, que salgan sin natearse (o nos descubrirían), y otras magias del networking…

 

(2024) 4372617368696E67206D79206D696E64 

Rosario, Argentina