Cuestiones técnicas Autor: Klaus Möller
Agenda Como trabajan los intrusos Recolección de información Irrupción a un sistema Ocultando el rastro y atrincherandose Abuso de los sistema
Objetivos Familiarizarse con: Los conceptos técnicos detrás de un incidente de seguridad en cómputo La terminología técnica utilizada. Como trabajan los intrusos Que debilidades son explotadas Que puede hacer un CSIRT
Como trabajan los intrusos El ciclo de la intrusión Tipos de intrusos Motivación
El ciclo de la intrusión El intruso obtiene información de los sistemas disponibles Obtención de información Si el sistema es vulnerable a los tipos de ataque disponibles Se intenta una penetración El intruso oculta el rastro de la intrusión y de la actividad adicional Ocultando y atrincherando El sistema es utilizado para ataques posteriores Intrusión en otros sistemas, DoS, Warez, Y más recolección de información
El ciclo de la intrusión: Por qué? Hace a la detección menos probable El administrador local no se preocupa frecuentemente por los ataques actuales El sistema comprometido probablemente no tendrá bitácoras confiables La victima culpará a la organización comprometida Es muy difícil rastrear al atacante a través de varios intermediarios Especialmente si se cruzan idiomas, zonas horarias, sistemas legales Puede Dar acceso a recursos adicionales Más ancho de banda que en la casa del intruso Contactar a sistemas ocultos (p.e. detrás de un firewall)
Tipo de intruso 1: Hackers Experto o muy experto técnicamente Realmente encuentra debilidades en software Desarrolla software para explotar debilidades Frecuentemente son pruebas de concepto (proof of concept) Algunas veces son herramientas muy avanzadas Edad: 20+, la mayoría de ellos son varones Motivación: Aprendizaje, fama en una comunidad Tiene un código de conducta para no hacer un daño real Pero: No le preocupa lo que otros hagan con su código
Tipo de intruso 2: Script Kiddies Crackers Aprendiz de Hacker Poca experiencia técnica Utiliza las herramientas del tipo 1: Hackers No hay código de conducta Podría interrumpir un servicio, destruir datos Edad: 10+, la mayoría hombres, algunas mujeres Motivación: alardear, Porque yo puedo guerras de IRC, ataques DoS distribuidos
Cosas que tienen en común Temerario No les importan las consecuencias legales o cualquier otra. Si las cosas se rompen, es culpa del administrador o del usuario No están realmente interesados en seguridad adicional Si fuese así, ellos harían a los sistemas más seguros Usualmente apolítico, o elige la causa del mes No hay un objetivo en común, solo un caos aleatorio Aman a las computadoras y a la Internet No destruirán (intencionalmente) su patio de juegos.
Guerras de IRC IRC: Red de servidores y clientes interconectados Los Script Kiddies adoran apoderarse de canales IRC DoS a miembros del canal: conexiones IRC sin respuesta El atacante es el primero en regresar al canal, y obtiene nivel de operador Puede expulsar a otros del canal, es el rey de la colina Charla de manera privada con amigos, comparten código, cuentas, tarjetas de crédito, sistemas vulnerables, etc. Riñas en el IRC, incita a peleas de DDoS Cuando dos kiddies tratan de apoderarse del mismo canal IRC
Recolección de información
Obtención de información Escaneos Barridos de ping; ICMP Timestamp, Netmask Escaneos TCP: connect, SYN, ACK, RST, XMAS, Escaneos UDP Pruebas Información de versión (captura de banners, consultas) DNS Como diferenciar escaneos/pruebas de la actividad normal
Obtención de información: Ejemplo En las bitácoras del router: 08:45:43 router.test.com 648358: 7w0d: %SEC-6-IPACCESSLOGP: list 101 denied tcp 10.0.147.89(2789) -> 192.168.140.99(25), 1 packet 08:45:50 router.test.com 648361: 7w0d: %SEC-6-IPACCESSLOGP: list 101 denied tcp 10.0.147.89(2907) -> 192.168.140.217(25), 1 packet 08:47:03 router.test.com 648372: 7w0d: %SEC-6-IPACCESSLOGP: list 101 denied tcp 10.0.147.89(3698) -> 192.168.140.221(25), 1 packet Probablemente un escaneo al puerto 25
Propósito de los escaneos Enumeración de equipos Encontrar que equipos en un rango IP están en línea Cimientos de cualquier actividad posterior Paso omitido en favor de escaneos de puertos directamente Escaneos de puertos Encontrar que servicios ofrece un equipo, que puertos están abiertos Pero, 65536 puertos para TCP & UDP Toma mucho tiempo escanear todos Podría concentrarse en pocos servicios con números de puerto conocidos.
Ping y otros escaneos ICMP Envío de paquetes ICMP echo request (tipo 8/código 0) Equipos en línea contestarán con un paquete echo reply (0/0) Posibles falsos positivos, una falta de respuesta puede significar: No hay un sistema presente o Un sistema configurado para no contestar o El paquete de solicitud o respuesta se pierde en el trayecto o se filtra Ping es utilizado por administradores para pruebas de conectividad De manera que un echo request o un echo reply no son filtrados frecuentemente Otros tipos de ICMP pueden ser filtrados o deshabilitados Timestamp (13/0,14/0), Address Mask(17/0,18/0)
Escaneos TCP TCP es un protocolo orientado a conexión Antes de intercambiar datos, se debe establecer una conexión El 3-way handshake de TCP hace esto
Escaneo connect TCP Se realiza mediante la conexión completa exitosa hacia un puerto conocido Si es exitosa, algún servicio se esta ejecutando sobre ese puerto Un escaneo muy confiable No hay falsos positivos, excepto cuando se filtra mediante firewall Lento, comparado con otros tipos de escaneo Fácil de detectar el patrón Pero cada conexión individual aparenta ser normal Puede ser realizado sin privilegios especiales En Unix, pero no en Windows, otros escaneos requieren tener acceso de root
Escaneo SYN TCP Envío del primer paquete, similar al escaneo connect (con la bandera SYN activada) Espera por el primer paquete que responde el equipo a escanear Se recibe un paquete SYN/ACK; el puerto esta abierto Se recibe un paquete RST; el puerto esta cerrado No se recibe respuesta; el puerto podría estar filtrado por un firewall Mas rápido que connect, pero puede generar resultados falsos Paquete SYN, o SYN/ACK perdido o filtrado, (se asume que el puerto está cerrado) RST generado por filtro de paquetes (se asume que el puerto está cerrado) Conexión no completada; se deja conexión TCP semi-abierta Podría ser visto como una lluvia TCP SYN Algunas veces, los escaners envían paquetes RST para cerrar la conexión
Escaneo ACK TCP Las banderas SYN y ACK establecidas en el primer paquete Pretendiendo ser una respuesta a una solicitud de conexión saliente Algunos filtros (non-stateful) podrían ver todo normal olvidando que no han visto un paquete SYN inicial Escucha por un paquete de respuesta Un paquete RST; el puerto esta abierto Si no hay respuesta; el puerto esta cerrado Posibles resultados falsos Paquete SYN/ACK o RST perdido o filtrado(asume pto. cerrado) RST generado por filtro de paquetes (se asume puerto abierto)
Escaneo XMAS TCP y otros Banderas FIN, PUSH y URG activadas en el primer paquete Uso de la técnica de mapeo inverso Si el puerto esta abierto, el sistema no contestará Si el puerto esta cerrado, el sistema contestará con un paquete RST Riesgo de los falsos positivos Si el paquete RST se pierde o se filtra, se asume el puerto abierto Riesgo de falsos negativos Algunos SO s (WinXX y algunos *nix) contestaran con un paquete RST en puertos abiertos Algunos firewalls e IDS pueden enviar un paquete RST El mismo comportamiento para NULL scan (sin banderas) y FIN scan
Escaneo RST TCP Varios paquetes de prueba vistos con la bandera RST activada No puede ser un escaneo No contestar a un paquete con la bandera RST activada Si el puerto esta abierto o no La bandera RST no puede ser utilizada para disparar respuestas Probablemente: un ataque de DoS con una dirección de origen falsa La dirección de origen es victima de un ataque La dirección destino es el equipo de quien fue falsificada tal dirección
Escaneos UDP Problema Simple, protocolo no orientado a conexión: sin banderas, opciones o retransmisión No se requiere que la aplicación conteste Solución: técnica de escaneo inverso Envío de un paquete UDP Si el puerto esta cerrado, el equipo responderá con un mensaje ICMP Port Unreachable Si el puerto esta abierto, el servicio podría responder (tal vez con otro paquete UDP) Resultado inverso: Si no hay un ICMP Port Unreachable, el puerto esta abierto Poco confiable, varios tipos de falsos positivos Paquetes UDP o ICMP perdidos o filtrados Equipo con un limite de ICMPs, la respuesta no se generará siempre
Información de versión Escaneos de puertos sólo indican si un servicio se esta ejecutando No si este es vulnerable a un ataque Pero conociendo la versión del servicio puede ser suficiente Verificar en el sitio del desarrollador si dicha versión es vulnerable Tres formas (entre varias) de hacer esto: Captura de banners Consulta directas a aplicaciones Información de DNS Diferentes métodos para diferentes servicios
Captura de banners Varios servicios muestran su versión cuando nos conectamos moeller@bluebird:~ > ftp bluebird 220 bluebird FTP server (Version 6.5/OpenBSD, linux port 0.3.2) ready. Solo esto es necesario moeller@bluebird:~ >telnet mailhub 25 220 mailhub ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2656.59) ready
Captura de banners (cont.) Ejemplo 3: Telnet No proporciona una versión del servicio Pero proporciona versión del SO, y tipo de procesador moeller@bluebird:~ > telnet bluebird Trying 127.0.0.2... Connected to bluebird. Escape character is '^]'. Welcome to SuSE Linux 7.1 (i386) - Kernel 2.2.18(2)
Consultas de versión Si la versión no está en un banner, generalmente puede ser consultada Ejemplo 1: Llamadas a procedimientos remotos (RPC) de SUN rpcinfo p <sistema> proporciona versión y números de puerto Puede ser consultada directamente con una llamada a procedimiento nulo program vers proto port service 100000 4 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100021 1 udp 4045 nlockmgr 100229 1 tcp 32771 metad 100230 1 tcp 32772 metamhd 100024 1 udp 32772 status 100024 1 tcp 32773 status
Consultas de versión Ejemplo 2: Consulta de versión del servidor de nombres nslookup type=txt class=chaos version.bind some.host.de Server: some.host.de Address: 192.168.1.7 version.bind text = 8.2.3-REL
Consultas de versión (NetBIOS) La tabla de nombres proporciona equipos, dominios, usuarios, servicios nbtstat A 192.0.0.1 Machine1 <20> UNIQUE Registered [server svc] Machine1 <00> UNIQUE Registered [workstation svc] DOMAIN <00> GROUP Registered DOMAIN <1C> GROUP Registered [domain controller] DOMAIN <1B> UNIQUE Registered [PDC] DOMAIN <1E> GROUP Registered Machine1 <03> UNIQUE Registered [messenger svc] INet~Services <1C> GROUP Registered IS~Machine1 <00> UNIQUE Registered [?web service?] DOMAIN <1D> UNIQUE Registered [domain browse master] USER1 <03> UNIQUE Registered [logged in user] -- MSBROWSE <01> GROUP Registered [subnet master browser]
Consultas a DNS El Servicio de Nombres de Dominio almacena una cantidad enorme de información Mapeo completo de nombre de equipo a dirección IP Puede ser obtenida mediante transferencias de zona (Si no esta deshabilitada) Nslookup > ls <zone_fqdn> Los registros HINFO, WKS y SRV almacenan equipo y tipo de OS, así como servicios conocidos, (mail, http, etc) Pueden ser obtenidos mediante nslookup type=wks <fqdn> <server> nslookup type=hinfo <fqdn>
Ejercicio 1: Recolección de información
Como suceden las intrusiones El atacante explota una vulnerabilidad presente en el sistema Las vulnerabilidades caen en tres categorías: Mala configuración Diseño débil en protocolos Errores de programación; dos muy comunes: Buffer overflows Bugs en Formatos de cadenas de caracteres
Mala configuración El administrador del sistema o el usuario han cometido un error en la configuración del sistema Errores típicos Compartir archivos con permisos RW para todos Proxies sin uso restringido (mail, web, socks, ) Cuentas de usuarios sin contraseñas o con contraseñas conocidas Base de datos de contraseñas leíble por todos El atacante puede adivinar las contraseñas fuera de línea mediante fuerza bruta o ataques de diccionario Contenido activo habilitado en navegador o cliente de correo Puede ser ejecutado automáticamente cuando se muestre un mensaje
Diseño débil Fallas importantes en el diseño de protocolos o software No puede ser resuelto sin afectar versiones anteriores Manteniendo el bug se conserva la compatibilidad hacia atrás Casos típicos Autentificación en texto claro en protocolos (telnet, ftp) Las credenciales pueden ser sniffeadas por un intruso Dependencia de dirección IP para la autenticación El atacante puede falsificar direcciones IP
Errores de programación Error común Hacer suposiciones sobre el ambiente del programa P.e. Las cadenas de caracteres de entrada serán cortas y en ASCII imprimible Pero usuarios maliciosos pueden introducir lo que ellos deseen La entrada puede venir desde Variables de ambiente Entrada del programa (local o en red) Otras fuentes
Buffer overflows Error: Asumir que un buffer de tamaño fijo es lo suficientemente grande como para almacenar toda la entrada El lenguaje C no tiene incorporado verificaciones de limite de buffer Pregunta Qué tal si hay mas datos que espacio en el buffer? Respuesta Los datos extra son escritos en memoria, después del buffer Ejemplo: Stack smashing
Stack smashing Qué esta después de un buffer de entrada? Capas generales de la pila
Stack smashing (cont.) Mientras el atacante escribe mas allá del buffer, sobrescribe variables locales y argumentos con su propio código La dirección de regreso es sobrescrita con la dirección proporcionada por el atacante que apunta al código en el buffer
Stack smashing (cont.) Al regresar del procedimiento, el código del atacante es ejecutado Típicamente se genera un interprete de comandos que proporciona una línea de comandos Posibles complicaciones El atacante debe de conocer la dirección de su código Rutinas de copia de cadenas, terminan con byte nulo (fin de cadena)
Condiciones para un buffer overflow Condiciones que deben cumplirse para la generación de un buffer overflow No se realiza la verificación de limites El espacio adyacente al buffer debe de poder ser escrito El atacante puede llenar el buffer con su propio contenido Una dirección del código debe de estar adyacente al buffer No todos los buffer son vulnerables La mayoría de los sistemas operativos son vulnerables
P.e. Demonio IMAP de Linux Intento sin éxito Apr 1803:05:13 imapd[3344]: Crack attempt,host=badhost.com Apr 18 03:05:16 imapd[3344]: Login failure user=^p^p^p^p^p^p^p^p^p^p^p^p^p^p^p^p^p ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P ^P^P^P^P^P^P^P^P^P^P^P host=badhost.com Apr 18 03:05:18 imapd[3344]: Connection broken while reading line user=^p^p^p^p^p^p^p^p^p^p ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P ^P^P^P^P^P^P^P^P^P host=badhost.com
P.e. Demonio IMAP Linux (cont.) Intento exitoso May 11 16:09:31 goodhost imapd[271]: connect from 1.2.3.4 May 11 16:09:42 goodhost imapd[271]: command stream end of file, while reading line user=??? host=attack.net May 11 16:40:36 goodhost imapd[271]: connect from 1.2.3.4 May 11 16:42:08 goodhost in.telnetd[603]: connect from 5.6.7.8 May 11 16:42:24 goodhost PAM_pwdb[606]: (login) session opened for user codeking by (uid=0) May 11 16:42:24 goodhost login[606]: LOGIN ON ttyp0 BY codeking May 11 17:16:36 goodhost in.telnetd[917]: connect from 5.6.7.8 FROM badhost.com May 11 17:17:11 goodhost PAM_pwdb[942]: (su) session opened for user rewt by codeking (uid=0)
P.e. Demonio IMAP Linux (resultados) Nuevos usuarios en /etc/passwd moeller:*:500:500:/home/moeller:/bin/bash janitz:*:501:501:/home/janitz:/bin/bash codeking::0:0:/tmp:/bin/bash rewt::0:0:/tmp:/bin/bash /etc/hosts.deny eliminado Nueva entrada en /etc/hosts.allow all:all
P.e. Bug en Windows RPC DCOM Gusano Blaster (Agosto del 2003) Paquete al puerto 135 provoca un buffer overflow Produce un shell como puerta trasera en el puerto 4444 Obtiene su propio ejecutable mediante TFTP Escanea e infecta a otros equipos Instala llave en el registro para recarga al reiniciar el equipo Podía atacar el sitio web de windowsupdate
Ataque de formato de cadena No hay problema si el formato de cadena se especifica en el código P.e. printf( %s = %d\n, variable, value); Problema si el formato de cadena puede ser especificado por el intruso P.e. printf(error); Qué tal si el error = <código malicioso>%x %x.. %n..%n..%n..%n? Varias funciones utilizan formatos de cadena, p.e. printf, fprintf, sprintf, snprintf, vprintf, syslog, setproctitle, Error común: syslog(mensaje) donde el mensaje viene de la entrada del usuario
Como funciona Los mismos pasos que los buffer overflow Poner código en la pila (binario hostil) Moverse a través de la pila (%x muestra variables, o la pila) Sobrescribir la dirección de retorno (%n establece una variable, o byte en la pila) Como funciona el ataque El atacante utiliza varios %x para moverse a la dirección de retorno Entonces el atacante sobrescribe la dirección de retorno con %n Escribe n1 bytes seguidos por %n para escribir el byte 1 de la nueva dirección de retorno El resto del buffer es llenado con el código del atacante En el regreso, la ejecución salta al código del atacante Puede sobrescribir otras direcciones, p.e. process user id
Ejercicio 2: Irrupción al sistema
Ocultando y atrincherando Después de una intrusión exitosa, el atacante intenta ocultar el rastro de la intrusión y de la demás actividad generada Eliminando entradas sospechosas De bitácoras De las bases de datos de accounting Esconder archivos, procesos y conexiones de red Instalando puertas traseras
Ocultando el rastro - Unix Unix almacena las bitácoras sobre /var/adm o /var/log Mensajes sospechosos son aquellos que muestran Direcciones de donde el ataque pudo originarse Inicios de sesión de usuarios creados por el ataque Las bitácoras pueden ser editadas o borradas Usualmente involucra el reinicio de los procesos de syslog La fecha de inicio de las bitácoras de syslogd podrían ser sospechosas Datos de cuentas: quien inicio sesión, desde donde, por cuanto tiempo Archivos: utmp, wtmp, utmpx, wtmpx, lastlog Los registros puedes ser sobrescritos por los atacantes
Ocultando el rastro - Windows El Windows event log es más difícil de alterar Buscar huecos de tiempo o inicio/detención del event logger El event logger debería de iniciarse/detenerse al inicio/ cierre del sistema El llenado de la bitácora sobrescribirá eventos anteriores El intruso podría intentar crear eventos 'inofensivos' para ocultar su rastro Asegurarse de que la bitácora es lo suficientemente grande como para hacer esto impráctico Asegurarse que los eventos interesantes sean
Otros rastros Los atacantes a menudo olvidan algunos lugares sulog: quien cambio su userid, cuando y para que shell history: comandos ejecutados, sin timestamp Inicios de sesión fallidos: faillog, loginlog, syslog Si te preparas antes del incidente Auditoria de Procesos y pistas de auditoría(muchos datos, difícil de usar) IDS snort, argus, etc. También ejecuta tripwire u otro verificador de FS en sistemas críticos Necesidad de conocer como luce de manera normal el sistema Herramientas forenses podrían obtener información adicional
Escondiendo archivos y procesos (tradicional) Intrusos esconden archivos en lugares no usuales Nombre de directorio iniciando con. o llamado Nombres de archivo similares a archivos en directorio, p.e. /dev/ptx1, /usr/lib/libdll, winlogin.exe (winlogon.exe es genuino), Flujos de datos alternos en Windows file:hidden o /dir:hidden Procesos tienen nombres de ejecutables estandar vi, mail, httpd, winlogon Pero sus rutas y parámetros los delatan Encontrarlos es fácil cuando se sabe donde buscar ls al para encontrar archivos, ps para encontrar procesos, last para encontrar inicios de sesión FoundStone, Sysinternals y SystemTools para el forense en Windows
Escondiendo archivos y procesos (moderno) Atacantes reemplazan utilerías del sistema Herramientas que podrían mostrar sus archivos, procesos o actividad p.e. ps, pstree, kill, killall, killpid, top, ls, find, du, echo, grep Cadenas para omitir compilación, o en archivos separados Investigadores deben usar herramientas confiables (p.e. en un CD) Los desarrolladores publican las firmas de los binarios genuinos Últimamente: Los atacantes reemplazan componentes del SO Rutinas del sistema que listan archivos, procesos, etc El SO mentirá a cualquier programa aun binarios confiables Los rootkits de kernel existen en Windows y en Unix El investigador debe de transferir el disco a un equipo confiable
Escondiendo conexiones de red La actividad en la red, podría ser la única señal visible de una intrusión Los atacantes también reemplazan estas herramientas Programas que muestran o almacenan la actividad de la red p.e. netstat, ifconfig, tcpd, inetd Los reemplazos omiten ciertas direcciones IP o nombres de equipo El investigador debe monitorear la red por si mismo (argus, netflow, etc.) Los atacantes utilizan criptografía para evitar el sniffing Frecuentemente secure shell es instalado en un puerto diferente O utilizan SSL si el servidor web es el punto de entrada
Puertas traseras (obvias) El intruso desea regresar al equipo comprometido Solución: un shell escuchando por un puerto TCP Entrada en la configuración de inetd, lanza un shell de root 2222 stream tcp nowait root /bin/sh i El gusano blaster ejecuta una línea de comandos en el puerto 4444 Desventajas Cualquiera puede utilizar la puerta trasera, (solo hay que buscarla) Algunas requieren contraseña Una puerta trasera en un puerto inusual es fácil de encontrar
Puertas traseras (Sutil) Mejor solución: reemplazar un servicio de red existente P.e. sshd, telnetd, rshd Llamar al servicio original a menos que una condición especial sea encontrada P.e. inicio de sesión de root, si la variable DISPLAY esta establecida a jabberwocky Puerta trasera esta oculta de usuarios y scanners Aparentemente un servicio normal en un puerto normal Los inicios de sesión normales trabajan normalmente, no hay sospecha O reemplazar el programa de login mismo Por tanto se puede utilizar un telnet normal, ssh, y servicios rlogin
Herramientas de acceso remoto Programas diseñados para la administración/control remota La mayoría para Windows p.e. Sub-7, Netbus, BackOrifice, Dameware,... Interfaces gráficas permiten un control remoto fácil Los caballos de troya generalmente instalan uno de estos Puertos conocidos, pero estos se pueden cambiar Muchos escaneos en busca de sistemas ejecutándolos Por qué irrumpir si alguien más lo ha hecho por mi?
Ejercicio 3: Ocultamiento
Abusos Qué hacer con sistemas comprometidos? Nuevos escaneos e intrusiones Uso de los recursos del sistema Como deposito de software propio (almacenamiento) Para cracking de cifrado (computo) Distribuir copias ilegales de software, música, videos, imágenes, etc (Warez) Utilizar el sistema para denegar a las victimas de servicios esenciales (DoS) Ataques a la infraestructura
Denegación de servicio Objetivo: Denegar el acceso a o el uso de recursos por la victima Explotar debilidades para hacer el servicio indisponible P.e. Ping of death Paquetes ICMP grandes causan la caída del sistema El ataque se vuelve inefectivo una vez que el parche esta disponible O agotar los recursos en el objetivo con peticiones En principio, no se puede definir cual es una petición genuina Usualmente se falsifica la dirección origen para dificultar el rastreo Inundación simple, si el atacante tiene más recursos que la victima. O agotar un limite (bajo) oculto, p.e. TCP SYN flood
Inundación TCP SYN El servidor TCP debe almacenar el estado de todas las conexiones El atacante envía un paquete SYN, pero no finaliza el handshake La conexión se deja semi-abierta; estado SYN RECEIVED El protocolo TCP menciona que este es un estado de poca vida Varias implantaciones sólo permiten un número limitado (p.e. 1024) a la vez. Cuando estas se han alcanzado, no se aceptan más conexiones Una conexión semi-abierta tomará varios minutos en expirar El atacante solo necesita enviar 1024 paquetes de 40 bytes La victima no puede aceptar conexiones TCP La victima puede utilizar el 100% de los recursos de CPU en procesos de red.
Inundación simple Llenar la conexión de red de la victima con muchos paquetes grandes A menudo se utilizan paquetes UDP o ICMP echo reply (ping) Fácil de generar y probablemente no están bloqueados por el firewall Ataque limitado por el enlace más lento entre la victima y el atacante El ataque consume el ancho de banda de la victima La red se vuelve lenta o no responde Caso especial Paquete UDP falsificado de victima:chargen a victima:echo Solamente un pequeño paquete es necesario para lanzar el ataque
Ataques distribuidos Ataque al objetivo desde varios sistemas a la vez Sin limitación del ancho de banda de un solo enlace SMURF Inundación de ping distribuida Envía un ICMP echo request a una dirección de broadcast Peor de los casos: todos los equipos en la red responden La dirección de origen falsificada para ser la de la victima Una configuración adecuada del router debería prevenir esto No reenviar hacia direcciones de broadcast (default de algunos routers) Aún hay redes amplificadoras de Smurf por ahí Denegación de Servicio Distribuido DDoS
Denegación de Servicio Distribuido El atacante instala agentes en varios sistemas comprometidos Por una intrusión manual, gusano, correo o virus de IRC Después,indica a todos los agentes que ataquen a la misma victima Atacan mediante inundaciones simples: TCP SYN, UDP/PING, SMURF o atacan aplicaciones, p.e. DNS, SMTP, HTTP Se han visto redes de >1k sistemas, que envían >1Gbps Un sistema de tres capas: atacante, manejadores, agentes (ver la siguiente figura) Los manejadores envían los comandos del atacante a los agentes Protocolos personalizados basados en TCP, UDP, ICMP, podrían ser cifrados Los manejadores están también en maquinas comprometidas Muy difícil de rastrear al atacante desde la víctima
DDoS (cont.)
Rastreando ataques DDoS Desde la victima a los agentes muy difícil Dirección de origen falsificada significa una pista incompleta Necesidad de que ISP rastree el flujo Administrador local podrá escanear puertos abiertos en los agentes Desde el agente localizar al manejador Binario en el agente podría contener la dirección del manejador Podría ser posible observar trafico entre el manejador y el agente Desde el manejador mejor oportunidad Manejadores frecuentemente descubiertos después de la limpieza de la intrusión El manejador tiene una lista de las direcciones de los agentes Frecuentemente cifrada, pero los script kiddies utilizan la llave predeterminada Podría ser posible ver el flujo del trafico atacante/manejador/agente
Nuevas herramientas DDoS basadas en IRC Utilizan IRC como canal de comunicación atacante/agente Servidores IRC funcionan como manejadores; no se necesita desarrollarlos El protocolo IRC reemplaza la comunicación con el protocolo predeterminado Actualmente existen grandes redes de bots de IRC Agentes comprometidos entran a canales IRC y esperan instrucciones No hay un puerto abierto que pueda ser escaneado en el agente Conexión a IRCs podría ser normal No hay sospechas, y no son filtradas El atacante envía el comando al canal
Ataques de infraestructura Existe en teoría, empieza a aparecer en practica DNS hacer que un nombre resuelva a otra cosa Servidor DNS autoritativo comprometido Envenenamiento poisoning del DNS local Pharming O simplemente falsificar la petición al administrador de nombres Protocolos de ruteo redirección de flujo del trafico Mensajes de ruteo son raramente autentificados Router comprometido puede mentir sobre las direcciones detrás de él
Ejercicio 4: Negación de servicio