Intrusión y Ataques a Equipos
en la Web
Floren Molina
Responsable Auditoría Zona Norte S21sec
“Confutatis maledictus, flammis acribus addictus”
Contexto
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.)
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
Ventana de Invulnerabilidad
 Tiempo en días entre que se reporta una vulnerabilidad
y se hace público el exploit.
Sistemas atacados












Linux
Win 2000
Win NT/9x
FreeBSD
Windows
Win 2003
Solaris SunOS
AIX
IRIX
BSDOS
Unix
Otros

Fuente: Zone-h.org
60.7%
19.3%
4.2%
2.9%
2.9%
2.1%
1.8%
0.4%
0.2%
0.2%
0.1%
5.2%
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.
Nivel técnico del atacante
Nivel técnico del atacante
Nivel técnico del atacante
www.k-otik.com
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.
DEFACE
DEFACE
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.
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
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
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.
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.
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.
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)
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--
CASE STUDY
Tengamos la pagina web:
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.
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/
CASE STUDY
Se accede a
http://www.beavictim.com/gestion/
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"))
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’
CASE STUDY
CASE STUDY
Acceso a la administración del sistema web,
con posibilidad de alteración de la pagina
web.
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.
¿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.
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.
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.)
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
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
Gracias por su atención
Descargar

Test intrusion Banco Zaragozano