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