Análisis de un ataque (Parte 3)

Analizando un ataque (Parte 1)
Analizando un ataque (Parte 2)

Don Parker

En la parte 2 de esta serie, dejamos toda la información necesaria para un ataque a la red de la víctima. Con esto en mente, pasemos a un ataque real. Este ataque implica la transmisión de varios programas de solicitud para poder ir más allá en la explotación de un ataque.

No tendría sentido simplemente atacar una computadora y luego retirarnos, así que haremos un ataque fuerte. Generalmente, el objetivo de un atacante malintencionado no es sólo aumentar su presencia en una red informática, sino también mantenerla. Esto significa que el atacante todavía quiere seguir ocultando su presencia y realizar otras acciones.

Cuestiones interesantes

Ahora utilizaremos Metasploit Framework para facilitar un ataque real. Este mecanismo de trabajo es realmente interesante porque te brinda muchos tipos diferentes de minería, así como muchas opciones diferentes a la hora de elegir cargas útiles. Quizás no quieras una utilidad inversa o una inyección VNC. La carga útil a menudo depende del objetivo futuro, la arquitectura de la red y el objetivo final. En este caso lo haremos con una utilidad inversa. Este suele ser el enfoque más ventajoso, especialmente en los casos en que nuestro objetivo está detrás del enrutador y no es directamente accesible. Por ejemplo, “accede” a un servidor web pero la carga aún está equilibrada. No hay garantía de que sea posible conectarse a él con una utilidad de avance, por lo que querrá que su computadora genere una utilidad inversa. No cubriremos cómo utilizar Metasploit Framework ya que es posible que ya se haya tratado en otro artículo. Ahora centrémonos en cosas como los niveles de paquete.

Esta vez, en lugar de utilizar el método de presentar cada paso del ataque con breves imágenes y fragmentos de código, presentaremos un ataque diferente. Lo que se hará es recrear el ataque con la ayuda de Snort. Aprovecharemos el registro binario del ataque que realizamos y luego lo analizaremos a través de Snort. Lo ideal sería que se pareciera a todo lo que hicimos. De hecho, lo que se implementará es un paquete de pruebas. El objetivo aquí es ver con qué precisión podemos reconstruir lo que sucedió. Con esto en mente, utilizaremos el registro de paquetes binarios que registró todo lo que se ejecutó y lo analizaremos a través de Snort usando algunas de sus reglas predeterminadas.

Salida de Snort

La sintaxis utilizada para invocar Snort es la siguiente:

C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full

Esta sintaxis hace que Snort analice un paquete binario llamado article_binary, el resultado se muestra a continuación. Hemos truncado la salida de Snort para que podamos ver cada sección en detalle.

==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

Esta sección es interesante porque hubo 63 alertas activadas por una acción de ataque. Veremos el archivo alert.ids, que puede proporcionar muchos detalles sobre lo que sucedió. Ahora, si recuerdas, lo primero que hizo el atacante fue usar Nmap para realizar un escaneo de red, eso también creó la primera alerta que activó Snort.

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]

De esta forma, el atacante utilizó netcat para enumerar el servidor web y descubrir qué tipo de servidor web es. Esta acción no activó ninguna alerta de Snort. También queremos saber qué sucedió, así que echemos un vistazo más de cerca al registro del paquete. Después de observar el procedimiento habitual de protocolo de enlace TCP/IP, veremos el paquete a continuación.

15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%[email protected].
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

No hay nada destacable en este paquete salvo el hecho de que tiene una solicitud GET con algunos problemas internos posteriores, como slslsl, por ejemplo. Así que, en realidad, Snort no tiene nada que hacer. Por lo tanto, es muy difícil construir una firma IDS (o firmas) efectiva para activar este tipo de intento de enumeración. Por eso no existen tales firmas. El siguiente paquete después de ese es donde se incluye el servidor web de la red víctima.

Una vez realizada la enumeración, el atacante envía inmediatamente un código para ejecutar el exploit al servidor web. Luego, este código dará algunos resultados con las firmas Snort habilitadas. Específicamente para el exploit que se muestra a continuación podemos ver esta firma de Snort.

[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

Una vez que el atacante obtiene acceso al servidor web, comenzará a utilizar el cliente TFTP para transferir 4 archivos: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Una vez transferidos estos archivos, el atacante utiliza netcat para enviar una utilidad a su computadora. Desde allí, puede desconectar la otra utilidad que resultó del ataque inicial y hacer todo el trabajo restante en la utilidad netcat. Curiosamente, Snort no registró ninguna de las acciones realizadas por el atacante a través de la utilidad inversa. Sin embargo, a pesar de ello, el atacante utilizó un rootkit que transmitió vía TFTP para ocultar información del proceso para netcat.

Conclusión

En la tercera parte de esta serie, vimos un ataque demostrado usando Snort. Podemos recrear completamente una de las cosas que se hicieron excepto por el uso del rootkit. Si bien IDS es una pieza de tecnología bastante útil y parte de su sistema de defensa de red, no siempre es perfecto. Los IDS sólo pueden alertarlo sobre el tráfico que pueden detectar. Con esto en mente, aprenderemos cómo construir firmas de Snort en la parte final de esta serie. Además de eso, también aprenderemos cómo probar una firma digital (firma) para evaluar su efectividad.