ElevenPaths Boletín semanal de ciberseguridad 16-22 enero Actualización del compromiso de SolarWinds Se han dado a conocer nuevos detalles acerca del compromiso a la cadena de suministro de software desvelado en diciembre: Los investigadores de FireEye han publicado...
Amador Aparicio CVE 2020-35710 o cómo tu RAS Gateway Secure revela el espacio de direccionamiento interno de tu organización Parallels RAS (Remote Application Server), es una solución de entrega de aplicaciones e infraestructura de escritorio virtual (VDI) que permite a empleados y clientes de una organización acceder y...
ElevenPaths Noticias de Ciberseguridad: Boletín semanal 24-30 de octubre Vulnerabilidad crítica en Hewlett Packard Enterprise SSMC La compañía Hewlett Packard Enterprise ha corregido una vulnerabilidad crítica de evasión de autenticación (CVE-2020-7197, CVSS 10.0) que afecta a su software de...
ElevenPaths ElevenPaths Talks: La Red Bajo Ataque ¡Regístrate aquí! El próximo jueves 9 de marzo únete a un nuevo webcast de ElevenPaths Talks, nuestra serie de webinars sobre ciberseguridad. En esta ocasión aprende con los expertos Arsene...
ElevenPaths Boletín semanal de ciberseguridad 16-22 enero Actualización del compromiso de SolarWinds Se han dado a conocer nuevos detalles acerca del compromiso a la cadena de suministro de software desvelado en diciembre: Los investigadores de FireEye han publicado...
Diego Samuel Espitia Detectando los indicadores de un ataque En seguridad siempre optamos por implementar mecanismos de prevención y disuasión, más que de contención. Sin embargo, la implementación de estos mecanismos no siempre son eficaces o sencillos de...
ElevenPaths Internet se ha roto, otra vez (I) Poco se puede aportar ya al fallo de implementación criptográfica Heartbleed (ya tenemos disponibles plugins para FOCA y Faast). Se trata de un grave problema que tendrá (y es...
ElevenPaths Susan Kare: pionera en diseño gráfico y creadora de iconos emblemáticos de Apple y Windows Ilustración realizada por Catalina Guzmán “Es más fácil entender imágenes que palabras”. Susan Kare Susan Kare es creadora de algunos de los iconos más reconocidos de Apple, y a pesar de haberlos creado...
ElevenPaths Boletín semanal de ciberseguridad 16-22 enero Actualización del compromiso de SolarWinds Se han dado a conocer nuevos detalles acerca del compromiso a la cadena de suministro de software desvelado en diciembre: Los investigadores de FireEye han publicado...
Diego Samuel Espitia Detectando los indicadores de un ataque En seguridad siempre optamos por implementar mecanismos de prevención y disuasión, más que de contención. Sin embargo, la implementación de estos mecanismos no siempre son eficaces o sencillos de...
ElevenPaths Todo lo que vimos en Security Innovation Day 2015 (II): tu móvil, tu identificador único Tu número de móvil, tu llave de acceso En ElevenPaths estamos cambiando la forma en la que los usuarios interactúan y se relacionan en el mundo digital. El móvil se...
ElevenPaths ElevenPaths Radio 2×13 – Entrevista a Josep Albors y Andrés Naranjo El mercado de los videojuegos mueve mucho dinero en todo el mundo. Tanto es así que el valor estimado del mercado global de videojuegos superó los 123.000 millones de...
DNS poisoning gracias a los sistemas de protección anti-DDoSElevenPaths 17 octubre, 2013 Un método habitual para mitigar los ataques de denegación de servicio distribuido basados en la amplificación DNS, se sustenta en ignorar ciertos mensajes cuando se sospecha que son consultas destinadas a generar un ataque. Pero esta técnica destinada a mitigar los ataques DDoS, pone en riesgo a los servidores que los utilizan, porque facilita a un atacante envenenar la caché de los servidores DNS que la usan. Vamos a explicarlo en detalle. El protocolo DNS en general siempre ha sido el punto débil en la red. Ataques de spoofing con diferentes técnicas, cachés envenenadas, la vulnerabilidad de Kaminsky (que es un problema de diseño intrínseco al protocolo), los fallos propios y vulnerabilidades de implementación de BIND… Su importancia, sencillas características y falta de seguridad se prestan a todo tipo de abusos. Últimamente el protocolo DNS está siendo usado para realizar ataques DDoS aprovechando la amplificación de tráfico. Pero en ciertos casos, parece que el remedio aplicado es peor que la enfermedad, porque facilita el envenenamiento de caché. Así lo han demostrado Florian Maury y Mathieu Feuillet en su investigación “Blocking DNS Messages is Dangerous”. Amplificación DNS Hasta hace relativamente poco, para “tumbar” páginas web importantes bastaba con tener una botnet lo suficientemente grande como para generar el tráfico necesario. Pero la “globalización” de servicios y mejora de los sistemas DDoS en general, hacen que cada vez sea más complejo para un atacante disponer de los bots mínimos para causar daño. Así que necesitan “amplificar” ese tráfico que generan para poder atacar. Esto lo conseguían en los 90 con ataques tipo “smurf”, pero actualmente (el ICMP era fácil de capar) se usa sobre todo el DNS. Tanto ICMP como UDP permiten falsificar al emisor y sobre todo, generar respuestas “muy grandes” a consultas muy pequeñas. Así, lo que los atacantes hacen es: Envían una petición pequeña (pocos bytes) desde muchas máquinas, falsificando la dirección de origen y haciendo pensar que las realiza la víctima. Hago así como dig ANY microsoft.com @195.5.64.2 Las envían a servidores DNS abiertos, que resuelven cualquier petición. Estos servidores DNS reciben las miles de pequeñas preguntas y devuelven las miles de respuestas gigantescas (hasta 50 veces más bytes que la pregunta) a la víctima, que recibe un tráfico muy grande que no ha solicitado. Algo así como esta respuesta por cada pregunta: ; <<>> DiG 9.7.0-P1 <<>> @195.5.64.2 microsoft.com ANY +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2663 ;; flags: qr ra; QUERY: 1, ANSWER: 11, AUTHORITY: 5, ADDITIONAL: 7 ;; QUESTION SECTION: ;microsoft.com. IN ANY ;; ANSWER SECTION: microsoft.com. 3591 IN TXT “FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ==” microsoft.com. 3591 IN TXT “v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all” microsoft.com. 3591 IN SOA ns1.msft.net. msnhst.microsoft.com. 2013101607 300 600 2419200 3600 microsoft.com. 2244 IN A 64.4.11.37 microsoft.com. 2244 IN A 65.55.58.201 microsoft.com. 3591 IN MX 10 microsoft-com.mail.protection.outlook.com. microsoft.com. 172791 IN NS ns3.msft.net. microsoft.com. 172791 IN NS ns4.msft.net. microsoft.com. 172791 IN NS ns1.msft.net. microsoft.com. 172791 IN NS ns5.msft.net. microsoft.com. 172791 IN NS ns2.msft.net. ;; AUTHORITY SECTION: microsoft.com. 172791 IN NS ns5.msft.net. microsoft.com. 172791 IN NS ns1.msft.net. microsoft.com. 172791 IN NS ns4.msft.net. microsoft.com. 172791 IN NS ns2.msft.net. microsoft.com. 172791 IN NS ns3.msft.net. ;; ADDITIONAL SECTION: ns1.msft.net. 993 IN A 65.55.37.62 ns2.msft.net. 2540 IN A 64.4.59.173 ns3.msft.net. 993 IN A 213.199.180.53 ns4.msft.net. 993 IN A 207.46.75.254 ns4.msft.net. 2629 IN AAAA 2404:f800:2003::1:1 ns5.msft.net. 3124 IN A 65.55.226.140 ns5.msft.net. 943 IN AAAA 2a01:111:200f:1::1:1 ;; Query time: 905 msec ;; SERVER: 195.5.64.2#53(195.5.64.2) ;; WHEN: Thu Oct 17 10:34:30 2013 ;; MSG SIZE rcvd: 832 Se han encontrado incluso scripts PHP colgados en páginas comprometidas que facilitan esta labor. http://www.webroot.com/blog/2013/09/10/web-based-dns-amplification-ddos-attack-mode-supporting-php-script-spotted-wild/ Recursivo e iterativo Además de la botnet y las peticiones falsificadas, los atacantes necesitan “resolvedores” que se presten a este juego amplificando el tráfico. Los servidores configurados como recursivos públicamente (se estima que existen sobre el millón accesibles en la red) son los nuevos servidores de correo que permitían el “open relay” de los 90, y contra ellos se está luchando. Servidor DNS actuando en modo modo iterativo Un servidor DNS opera en general en dos modos: Modo iterativo: El usuario pregunta al servidor DNS por un dominio. Si no lo tiene, lo deriva a otro DNS (un root, por ejemplo) que lo sepa y deja que pregunte él mismo. En resumen, le envía un “referral” y que sea el cliente el que trabaje, preguntando varias veces. Ambos comparten el “esfuerzo” de generar y recibir tráfico. Modo recursivo: El servidor DNS, si no sabe cómo resolver un dominio, se ocupa de todo. Pregunta al servidor root, hasta llegar al autoritativo del dominio, recopilar toda la información, y devolvérsela al cliente. Así el tráfico está mal repartido. Al cliente le hacen todo el trabajo y, con pocos bytes, consigue que se devuelva una respuesta enorme. Si además se falsifica la fuente… el DDoS está servido. Desde hace pocos años BIND cambió su configuración por defecto para intentar mitigarlos. Esquema de ataque con el servidor DNS actuando en modo recursivo El modo recursivo tiene su utilidad en redes internas en los que los usuarios solo acceden a un DNS corporativo y no pueden consultar a otros… pero si se administra mal y no se limita para este servidor recursivo solo responda a las IPs de su LAN… nos encontramos con que los atacantes disponen de servidores de los que abusar. El ataque Se basa en buena parte en el problema descubierto por Kaminsky en 2008, que permitía engañar a la caché de un servidor DNS. Muy simplificado, se enviaban muchas respuestas falsas a preguntas que nunca hizo el servidor. Si alguna coincidía en el puerto de origen con una pregunta, el servidor devolvía la respuesta falsa como verdadera a la víctima. El problema encontrado por Kaminsky se resolvió introduciendo más entropía al cálculo del puerto fuente en la respuesta. Desde entonces las probabilidades de que coincidan son tan bajas que el ataque no resulta práctico. Lo que pensaron estos investigadores es que, si el problema es que existe mucha entropía, quizás con más tiempo para probar más posibilidades, podrían volver a conseguir que el ataque de Kaminsky fuera viable. Y así fue. Si se ayudan de los mecanismos anti-DDoS, es posible que el ataque de envenenamiento de caché sea práctico de nuevo. Fundamentalmente, los métodos anti-DDoS abren una ventana de tiempo que puede ser aprovechada por el atacante. Lo que ocurre es que: El atacante, desde cualquier punto, envía una petición de resolución al servidor DNS del que se va ayudar, y que dispone de un sistema anti-DDoS. Este servidor DNS realiza la recursión, preguntando al servidor autoritativo del dominio que corresponda, porque él no sabe la respuesta. La botnet del atacante avisa deliberamente al servidor autoritativo, diciéndole que ese servidor DNS está siendo usado para amplificar, y que active sus mecanismos de protección que fundamentalmente consisten en que ignore a ese servidor DNS que le pregunta: que no le responda o que lo haga más tarde. Mientras el servidor espera, el atacante le envía ataques Kaminsky al servidor (respuestas falsas que cacheará), porque tiene tiempo de sobra para hacerlo. El servidor cree que vienen del servidor autoritativo y las cacheará. El ataque de envenenamiento puede ser otro, pero ellos han usado Kaminsky, por resultar un problema de diseño intrínseco al protocolo DNS. En resumen, aprovechar ese tiempo de “baneo” para enviar masivamente respuestas y aumentar las probabilidades de éxito en el envenenamiento de caché. En realidad, es vulnerable cualquier dispositivo que, queriendo usar DNS “Response Rate Limiting” para precisamente evitar ataques, llegue a desestimar peticiones DNS por considerarlas peligrosas. Incluso ciertos cortafuegos. La solución a todo problema de DNS es DNSSEC, pero como no es probable que se instaure a corto plazo… la contramedida ofrecida es responder a todos los paquetes, incluso si es con un “REFUSED”, pero nunca dejar esperando al servidor simplemente ignorando sus consultas. Sergio de los Santos ssantos@11paths.com @ssantosv Cómo aprovechar el autofill de Chrome para obtener información sensibleCómo usar Metashield protector for Client y por qué utilizarlo
ElevenPaths Boletín semanal de ciberseguridad 16-22 enero Actualización del compromiso de SolarWinds Se han dado a conocer nuevos detalles acerca del compromiso a la cadena de suministro de software desvelado en diciembre: Los investigadores de FireEye han publicado...
Diego Samuel Espitia Detectando los indicadores de un ataque En seguridad siempre optamos por implementar mecanismos de prevención y disuasión, más que de contención. Sin embargo, la implementación de estos mecanismos no siempre son eficaces o sencillos de...
Amador Aparicio CVE 2020-35710 o cómo tu RAS Gateway Secure revela el espacio de direccionamiento interno de tu organización Parallels RAS (Remote Application Server), es una solución de entrega de aplicaciones e infraestructura de escritorio virtual (VDI) que permite a empleados y clientes de una organización acceder y...
Área de Innovación y Laboratorio de ElevenPaths #CyberSecurityReport20H2: Microsoft corrige muchas más vulnerabilidades, pero descubre bastantes menos Existen muchos informes sobre tendencias y resúmenes de seguridad, pero en ElevenPaths queremos marcar una diferencia. Desde el equipo de Innovación y Laboratorio acabamos de lanzar nuestro propio informe...
ElevenPaths ElevenPaths Radio 3×07 – Entrevista a Mercè Molist ¿Conoces la historia del hacking en España? Primero debemos conocer su ética, su forma de vida y de pensamiento, su cultura… Para hablar sobre hackers y hacking en España, tenemos...
ElevenPaths Noticias de Ciberseguridad: Boletín semanal 9-15 de enero Sunburst muestra coincidencias en su código con malware asociado a Rusia Investigadores de Kaspersky han encontrado que el malware Sunburst utilizado durante el ataque a la cadena de suministro SolarWinds,...