1 Intrusión y Ataques a Equipos en la Web Intrusión y Ataques a Equipos en la Web Floren Molina Responsable Auditoría Zona Norte S21sec “Confutatis maledictus, flammis acribus addictus”

2 Contexto

3 Posibles Ataques  Deface: Modificación de paginas para desprestigiar imagen pública  DoS: Denegación de servicio  Acceso, Robo y/o alteración de información confidencial o no pública  Alteración de datos de negocio (estadísticas, precios, etc.)  PHISING  Intrusión a sistemas internos  Punto de ataque a otros sistemas  Uso fraudulento del sistema atacado (Pubstro, SPAM, etc.)

4 Métodos de ataque  29.9%Fallo en Configuración o Administración  25.3%Vulnerabilidad Conocida (Sistema sin Parchear)  23.1%Vulnerabilidad no Publicada  14.6%Ataque por Fuerza Bruta  6.5%Ingeniería Social  0.6%Sin Determinar Fuente: zone-h.org

5 Ventana de Invulnerabilidad  Tiempo en días entre que se reporta una vulnerabilidad y se hace público el exploit.

6 Sistemas atacados  Linux60.7%  Win 200019.3%  Win NT/9x4.2%  FreeBSD2.9%  Windows2.9%  Win 20032.1%  Solaris SunOS1.8%  AIX0.4%  IRIX0.2%  BSDOS0.2%  Unix0.1%  Otros5.2%  Fuente: Zone-h.org

7 Atacantes  Hacker, Cracker, Black Hat, Script Kiddie, Pirata de Warez, empleado descontento, ex-empleados, empleados temporales, el servicio de limpieza, el de mantenimiento, un gusano de internet, programador de virus, el propio virus, etc.

8 Nivel técnico del atacante

9

10  www.k-otik.com

11 DEFACE  Este ataque atenta directamente contra la imagen pública.  Se modifica la pagina web de inicio de un web corporativo.  Aprovechando una vulnerabilidad se modifican los archivos necesarios.  Motivaciones politicas, culturales, etc.

12 DEFACE

13

14 PHISING  Literalmente, 'pescar', 'ir de pesca'.  Se suplanta la identidad de un sitio web.  El usuario recibe por correo electrónico un enlace a una pagina muy similar a la original. El cliente accede y teclea su número de cuenta bancaria, número de tarjeta de crédito, usuario, contraseña, etc.), confiando en el entorno.  Barclays, Lloyds TSB, NatWest, Citibank, Visa, Paypal, eBay, BestBuy.  En España, Grupo Banco Popular, Banco de Bilbao y Vizcaya Argentaria (BBVA).  Mina la confianza en el comercio y la banca electrónica.

15 PHISING  La palabra "phising" fue acuñada alrededor de 1996 por gente que robaba cuentas y passwords de America Online.  Por analogía con el deporte de la pesca, estas personas utilizaban e-mails atractivos, poniendo anzuelos para "pescar" passwords y datos financieros del "mar" de usuarios de Internet.  Sabían que aunque la mayoría de los usuarios no mordería el anzuelo, unos pocos probablemente lo harían.  El término fue mencionado en el newsgroup alt.2600 en enero de 1996, pero probablemente fue utilizado con anterioridad en el diario impreso 2600, The Hacker Quarterly. Fuente: www.elimparcial.com

16 PHISING  Durante el 2003, fueron reportados alrededor de 171 importantes incidentes de phising, número que ya ha sido rebasado tan sólo en el primer trimestre del 2004, con 184 incidentes.  Los resultados, según el artículo "Q1 2004 Tops in Cyber Attacks", publicado en Financialexpress.com, son pérdidas estimadas entre 24 y 30 mil millones de dólares. Fuente: www.elimparcial.com

17 Antecedente historico Code Red  A pesar de los firewalls, el gusano aprovechaba una vulnerabilidad del servidor web de Microsoft IIS para infectar el equipo y propagarse.  Entre las variantes del gusano algunas montaban servidores FTP pubstro (para distribución publica de warez), puertas traseras para ejecución remota de comandos, infección, troyanización del sistema, infectaba las redes internas, etc.

18 Antecedente historico Code Red  Sentó un precedente, en los dos sentidos.  Se actualizaron millones de servidores IIS, se concienció a los administradores de red sobre el parcheo periódico de sus sistemas.  En cuanto a programación de gusanos en Internet para los desarrolladores de virus. Los siguientes han aprovechado vulnerabilidades en otros servicios para expandirse.  Viendo que actualmente la propagación de virus esta mucho mas controlada parece obvio que algún fruto ha dado.

19 SQL Injection  Ataque a nivel de código del aplicativo, se trata de atacar formularios que hagan consultas a bases de datos a través de peticiones SQL, inyectando en esas peticiones las consultas del atacante.  Gracias a estas consultas, el atacante puede obtener información del sistema, alterar, borrar e insertar información en las bases de datos, ejecutar código en el servidor, etc.

20 SQL Injection  ' UNION SELECT @@VERSION -- Microsoft SQL Server 2000 - 8.00.194 (Intel X86) Aug 6 2000 00:57:48 Copyright (c) 1988-2000 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 3)

21 SQL Injection  Ver las TABLAS de la BD aa' UNION SELECT [...],TABLE_NAME,[...] FROM INFORMATION_SCHEMA.TABLES--  Ver los CAMPOS de una tabla aa' UNION SELECT [...],COLUMN_NAME,[...] FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='tabla_que_queremos'--  Ver los PROCEDIMIENTOS ALMACENADOS de la BD aa' UNION SELECT [...],ROUTINE_NAME,[...] FROM INFORMATION_SCHEMA.ROUTINES--  Ver el CODIGO FUENTE de los PROCEDIMIENTOS ALMACENADOS aa' UNION SELECT [...],ROUTINE_DEFINITION,[...] FROM INFORMATION_SCHEMA.ROUTINES--

22 CASE STUDY  Tengamos la pagina web: www.beavictim.com www.beavictim.com  Se trata de un IIS 6.0, por tanto montado sobre un servidor windows 2003.  Todo con tecnología ASP y NET.  Detrás de un firewall ultimísimo modelo, debidamente parcheado.  El servidor ha sido parcheado debidamente.

23 CASE STUDY  Se accede al fichero robots.txt, con el se indican a los buscadores en que parte de la pagina web no está permitido entrar ni indexar su contenido. User-agent: * Disallow: /cgi-bin/ Disallow: /datos/ Disallow: /gestion/Interesante!! Disallow: /intranet/ Disallow: /upload/ Disallow: /web/ Disallow: /estadistica/

24 CASE STUDY  Se accede a http://www.beavictim.com/gestion/ http://www.beavictim.com/gestion/

25 CASE STUDY  Como usuario se introduce administrador  Como contraseña se intenta realizar un ataque de SQL Injection a‘ OR ‘a’=‘a  Los campos del formulario serán: usuario=parseador(Request.Form(“usuario")) contraseña=parseador(Request.Form(“contraseña"))

26 CASE STUDY  SELECT * FROM usuarios WHERE usuario =‘administrador’ AND contraseña=‘ a’ OR ‘a’=‘a ’  SELECT * FROM usuarios WHERE usuario =‘administrador’ AND contraseña=‘ a’ OR TRUE  SELECT * FROM usuarios WHERE usuario =‘administrador’ AND TRUE  SELECT * FROM usuarios WHERE usuario =‘administrador’

27 CASE STUDY

28  Acceso a la administración del sistema web, con posibilidad de alteración de la pagina web.

29 Mas ataques  XSS. Cross Site Scripting, a traves de un deficiente filtrado de los campos en un formulario se puede obtener de un usuario de un site información sobre su sesion, o bien utilizarlo para engañar al usuario y hacerle que caiga en un ataque de phising.  XST. Aprovechando una deficiente configuración del servidor que permite el método TRACE se puede utilizar para realizar ataques de XSS.  SSI. Server Side Includes, ataque al servidor en el que se inyecta código en un determinado lugar de la petición web y que provoca que el servidor ejecute el código.  Inyección de código, en ocasiones el lenguaje de programación permite incluir código de un servidor web atacante.

30 ¿Soy un objetivo?  Con toda probabilidad  Todo sistema conectado a Internet con una pagina web de manera publica es un objetivo claro de algún tipo de ataque.  Los ataques automáticos, mass defacers, gusanos de internet, etc. No distinguen victimas, toda dirección IP es un objetivo.  Todo el mundo tiene al menos un enemigo y a veces trabaja con él.

31 Tengo un firewall y un antivirus  “¿Y a mi que?”  En muchos casos los problemas son derivados de una ineficiente programación web.  A pesar del firewall, se pueden explotar vulnerabilidades de código.  La falta de un firewall a nivel de aplicación puede exponer un sistema totalmente.  La falta de conciencia en cuanto a programación segura de cualquier tipo de aplicativo, implica posibilidades de ataque.

32 Tengo un firewall y un antivirus  Configurar deficientemente el servidor web, con permisos equivocados, módulos no necesarios, aplicaciones no necesarias.  Filtrado poco apropiado en los campos de los formularios  Administración en el propio servicio web y poco asegurado.  Información proporcionada al atacante (versión del servidor y componentes, comentarios en el código fuente, etc.)

33 Soluciones  Programación segura  Parcheo de sistemas consistente  Administración y configuración segura de los servidores  Eliminar funciones extras de los servidores web  Firewalls tanto de red, como de aplicación  Antivirus al día

34 Y si todo falla  (Rezar / Orar / Sacrificar un cordero) para que el daño sea mínimo  Seguir el plan de contingencia especifico y planeado  Analizar la incidencia  La mayor parte de las ocasiones se sabe el alcance (daños y grado de penetración del atacante), pero no el método empleado.  En estos casos, lo mejor es un análisis forensico del servidor y establecer acciones no detectadas y como ha conseguido ejecutarlas.  Aprender del ataque, fortificar y seguir

35 Gracias por su atención