ATAQUES REALES: ANÁLISIS, LECCIONES Y PROTECCIÓN

ATAQUES REALES: ANÁLISIS, LECCIONES Y PROTECCIÓN
REAL ATTACKS: ANALYSIS, LESSONS AND PROTECTION
Eli Faskha,
Presidente de Soluciones Seguras, Check Point Software Centroamérica [email protected]
RESUMEN: La era de la información ha convertido a los datos de cada empresa en su activo más valioso. El
área de seguridad informática ha ido creciendo en visibilidad, importancia, y también complejidad. No existe una
solución o protección universal para proteger a una empresa. La combinación de múltiples capas de seguridad,
mejores prácticas para protección, y métodos para reaccionar a ataques, forman una caja de herramientas que
todo administrador de seguridad debe tener a su disposición. En este artículo, examinaremos tres muy diferentes ataques de negación de servicio que se han dado en la región en los últimos años, veremos la aparente motivación de los mismos, el método de ataque, la reacción durante el ataque, y los métodos que se podrían poner
para prevenir su impacto otra vez.
Palabras Clave: Ataques de Negación de Servicio, Ataques a vulnerabilidades conocidas y desconocidas, Hacktivismo, Anonimous, Nubes Públicas, Nubes Privadas, Web Application Firewalls, Proxies, Geoprotección,
Sistema de Prevención de Intrusos.
ABSTRACT: The information age has made the data for each company in its most valuable asset. The area of
information security has grown in visibility, importance and complexity. There is no universal solution to protect a
company. The combination of multiple layers of security protection best practices and methods to react to attacks, form a toolbox that all security administrator should have at their disposal. In this article, we will examine
three very different denial of service attacks that have occurred in the region in recent years, we see the apparent
motivation thereof, the method of attack, the reaction for the attack, and methods that could put to prevent their
impact again.
KeyWords: Denial of Service, Attacks known and unknown vulnerabilities, Hacktivism, Anonymous, public
clouds, private clouds, Web Application Firewalls, Proxies, Geoprotection, intrusion prevention system.
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
1. INTRODUCCIÓN
La era de la información ha convertido a los datos
de cada empresa en su activo más valioso. El área
de seguridad informática ha ido creciendo en visibilidad, importancia, y también complejidad. No existe
una solución o protección universal para proteger a
una empresa.
La combinación de múltiples capas de seguridad,
mejores prácticas para protección, y métodos para
reaccionar a ataques, forman una caja de herramientas que todo administrador de seguridad debe
tener a su disposición.
En esta presentación, examinaremos dos muy diferentes ataques de negación de servicio que se han
dado en la región en los últimos años, veremos la
aparente motivación de los mismos, el método de
ataque, la reacción durante el ataque, y los métodos
que se podrían poner para prevenir su impacto otra
vez.
2. ANTECEDENTES
Comencemos por una revisión rápida de los elementos con los que trataremos durante este rato.
La presencia pública de toda empresa o entidad, y
por pública me refiero a Internet, se compone principalmente de las páginas web, las aplicaciones
web, los servidores de correo electrónico, y otros
servidores que podrían incorporar servicios de DNS,
FTP, u otros.
Estos servidores pueden estar en varios lugares. El
lugar más sencillo, pero probablemente menos seguro, es dentro de la propia empresa y en la red
local de la misma, publicada mediante un NAT, o
traducción de dirección IP, en el dispositivo de seguridad perimetral que tenga la empresa. En más
casos, los servidores estarían en un Centro de Datos, un Data Center, ya sea dentro de alguna instalación de la entidad, o en un Centro de Datos externo de un proveedor de servicios de Data Center.
Y más y más, los servidores pueden estar virtualizados en nubes públicas como Amazon, Google o
Azure. Una gran parte de los servicios de correo
electrónico (email) ya están migrando a las nubes
públicas.
Sea cual sea el lugar donde están los servidores
públicos, deben tener una protección adecuada de
los ataques y atacantes que existen hoy en día.
Cuando hace 5 años se hablaba mucho de los hackers que lo hacían por diversión o curiosidad, hoy
en día la mayoría de los atacantes tienen una motivación muy diferente. Ya sea por lucrar del ataque,
para afectar la reputación de una empresa, por
motivos políticos, o por acciones ilegales, los atacantes tienen más recursos y mayor motivación que
antes.
Algunos de los ataques de los que hay que protegerse incluyen:
Ataques que explotan malas configuraciones o mala
programación: Un servidor con programación deficiente puede dejar expuesta información sensitiva o
confidencial, permitir a atacantes de tomar control
del servidor y de las redes internas, y modificar el
contenido de los mismos.
Ataques a vulnerabilidades conocidas y desconocidas: Aplicaciones y servidores pueden tener vulnerabilidades descubiertas y reportadas, y que requieren parches del fabricante para prevenirse. Aún
peor, algunas vulnerabilidades no son conocidas
por los usuarios y fabricantes (las llamadas día
zero) y los atacantes pueden abusar de ellas hasta
ser descubiertas.
Ataques a la disponibilidad: No siempre es necesario conseguir información interna, aprovechar una
vulnerabilidad o modificar el contenido de una aplicación. Con solamente prevenir de que usuarios
legítimos accedan los servidores, ya los atacantes
pueden causarle a entidades daños significativos,
ya sean económicos (por la pérdida de las ganancias de transacciones perdidas) o de reputación
(porque la información que ellos tienen que publicar
no está disponible). Dentro de los ataques a la disponibilidad, los que más peligro tienen hoy en día
son los ataques DDoS, DIstributed Denial of Service, o Ataques Distribuidos de Negación de Servicio,
donde cientos, miles o millones de máquinas son
controladas para atacar simultáneamente un blanco
y saturar el ancho de banda disponible y así negarle
a los usuarios legítimos que lleguen al sitio.
Veamos también algunas de las diferentes protecciones que se pueden tener incluyen:
Murallas Contra Fuegos (Firewalls): Estos son el
primer elemento para la seguridad perimetral, y toda
empresa forzosamente debe tener un firewall protegiendo la entrada y salida del tráfico. Existen muchas variaciones, donde hoy en día las llamadas
Next Generation Firewalls y Unified Threat Management systems son los más conocidos y usados.
Web Application Firewalls: Diseñados para proteger específicamente a servidores web, estos dispositivos examinan el contenido web profundamente y
pueden detener una gran parte de los ataques a
estos servidores.
Intrusion Prevention Systems: Dispositivos dedicados a prevenir intrusos en la red, estos pueden
implementarse a nivel de red, o a nivel de host
(equipo). Hoy en día las funciones de IPS se están
cada vez más incorporando en los Firewalls de las
empresas para optimizar los recursos y hacer más
eficiente la administración.
Protección DDoS: Existen sistemas especializados
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
que pueden ayudar a proteger contra los ataques de
negación de servicio, con respuestas rápidas contra
estos ataques. Muchas veces se integran con soluciones en la nube que permiten sobrevivir los ataques de mayor ancho de banda.
Ya con esta información, podemos comenzar a
examinar algunos ataques reales, caso que nos
ayudan a entender la mentalidad, los métodos y las
reacciones que podemos tener.
3. CASO REAL #1: ATAQUE A LA BANCA
ELECTRÓNICA
Aquí les dare un línea de tiempo resumida de un
ataque real del que participamos para proteger a
una empresa que estaba bajo ataque, aunque con
resultados mixtos.
Viernes, 8pm
Recibimos una llamade del gerente de tecnología
de un banco, explicando que tienen una situación
crítica su Banca en Línea, y que la misma está bajo
un ataque de negación de servicio. Viendo la situación:
El ataque inició el jueves anterior a las 4pm. La
página de banca en línea estuvo fuera de servicio
desde ese momento.
El servidor bajo ataque está en un Data Center fuera del país, y el banco no tiene personal en el lugar.
La infraestructura estaba fuera del país, y el operador de Data Center no tenía opciones para proteger
la página en el datacenter. El banco no había contratado esa opción ni un soporte reactivo prioritario.
Se propuso la idea de redirigir el tráfico a Panamá al
Datacenter local del banco, para entonces
filtrar el ataque y pedir solamente las solicitudes
reales al sistema. La solución requería de la instalación de lo que se llama un Web Application Firewall
(WAF), que está específicamente diseñado para
proteger servidores web de ataques. Dado que no
existían equipos físicos en inventario para poder
instalar, se acordó la instalación de un WAF virtual
en una infraestructura de VMWare ESX. Las primeras 4 horas se usaron para descargar en instalar el
WAF, y entonces se pidió la redirección de las entradas DNS y que se use un nuevo URL para apuntar a la nueva estructura protegida.
Adicionalmente, el WAF detectó que los ataques
estaban controlados desde Russia, dado que todas
las solicitud atacantes venia de un ‘referrer’ *.ru, con
un dato de 6000 bytes en uno de los parámetros de
la aplicación. Después de todos los trabajos, solicitudes de certificados digitales, cambios de DNS,
replicaciones, etc., la página quedo operacional a
las 8am del sábado, o sea 12 horas después de
reportado el ataque, pero casi 40 horas después de
iniciado el mismo. Aquí vemos la importancia tener
un plan de reacción a ataques, y de reportar los
incidentes lo antes posible.
Domingo 6pm
Se recibió una llamada a las 6pm informando que la
banca en línea otra vez estaba fuera de servicio,
pero esta vez también estaba fuera de servicio la
página web principal del banco. Nos dimos cuenta
que los atacantes al ver que su ataque inicial había
sido detendio (por el cambio del URL de la página),
redirigiendo el ataque al nuevo URL y aumentaron
considerablemente el ancho de banda usado para
el ataque. La solución virtual simplemente no estaba diseñada para manejar tanto tráfico, y se solicitó
al banco que usaran el IPS y Firewall que ya tenían
en el datacenter, para proteger el WAF.
Lunes 8am
A las 8am, nos percatamos que no se había todavía
implementado una solución de firewall o IPS frente
al WAF virtual. Nosotros tomamos la decisión de
llevar un equipo físico de Firewall para ser implementado en el data center. Se configuró el equipo
con los IP’s necesarios, se creó una política que
solamente permitía la entrada de http y https a los
sitios virtuales creados en el WAF, con NAT saliente para el WAF hacia los datacenters.
La protección esencial que hizo el equipo fue con la
activación de su Blade IPS integrado. Se configuró
la protección de Geo Protection, de manera que se
permitieron las conexiones de los países Panamá,
Venezuela, República Dominicana, Estados Unidos
y Canada solamente, bloqueando las conexiones de
todos los otros países.
Alrededor de las 10:00am, una vez que se bloquearon los países no deseados, se habilitaron los NATs
y se crearon las reglas, todos los sitios quedaron
totalmente funcionales. El CPU del equipo UTM-1
quedó alrededor de 20% de uso, con un promedio
de 500 conexiones concurrentes. Muy por debajo
del rendimiento posible del equipo.
Lunes 1.45pm
Después de la implementación del firewall, se mantuvo un monitoreo activo. Alrededor de la 1.45pm
perdimos contacto con el equipo y con los sitios
web. Inmediatamente nos desplazamos al data
center. El firewall se encontraba saturado y no respondía a los comandos. Reiniciamos el equipo, y
tuvo problemas en levantar. Una vez que lo desconectamos de la red externa, levantó sin problemas.
Esto nos indicó que la cantidad de ataques había
aumentado exponencialmente, por lo que el equipo
no aguantó la carga en esa configuración. El equipo
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
estaba con un promedio de 95% del uso del CPU, y
con un promedio de 20,000 conexiones concurrentes, 40 veces el tráfico de la mañana.
Se procedió a bloquear las conexiones entrantes de
Estados Unidos, y se deshabilitó el registro del historial de esos ataques, para ayudar al rendimiento
del equipo. Una vez reconfigurado, el equipo regreso a un promedio de 20-30% de uso del CPU. Sin
embargo, sabíamos que esta configuración podía
ser temporal si se aumentaba el número de ataques, de países como Venezuela o Panamá.
Dado que existía la posibilidad de que el ataque
siguiera aumentando y saturara otra vez el equipo,
se decidió ser proactivo y se consiguió un equipo
con un rendimiento muy superior, con más de 16G
en firewall y 9G en IPS. Este equipo es muy superior al rendimiento que se necesitaría para detener
el ataque. El equipo quedó con un uso de CPU de
menos de 1%.
Martes
Posteriormente a la implementación, el ataque de
negación de servicio fue detenido en su totalidad.
Miercoles
Se recibió en la mañana una solicitud para una
reunión en el banco. La reunión comenzó a las
4pm, y se extendió hasta las 8pm. En la misma, se
solicitó nuestra opinión experta sobre un caso que
se dio aledaño a los ataques de negación que afectaron al banco. La documentación que nos presentaron nos permitió analizar el flujo de tiempo de esta
manera:
Existe una transferencia de un cliente a un proveedor establecido el miércoles
El jueves, el cliente salió de viaje a España
El jueves, alrededor de las 11am, se nota una transferencia al mismo proveedor del miércoles, por un
monto bajo. Pero después de manda una transferencia nueva a otra cuenta, por cientos de miles de
dólares.
El ataque de negación de servicio comienza alrededor de las 4pm del jueves 13 de abril.
Posteriormente, cuando el ataque era detenido, se
daban transferencias adicionales. En total, entre el
jueves, sábado, domingo y lunes, más de 1 millón
de dólares fue transferido.
El cliente no reconoce las transferencias del jueves
en adelante.
Análisis del ataque
En base a estos datos, se puede hacer la siguiente
reconstrucción de los hechos.
En algún momento previo al jueves, delincuentes
obtuvieron las credenciales del usuario en cuestión.
Y probablemente es un usuario interno dado que
también sabía del viaje del cliente.
El jueves se ejecuta la transferencia al proveedor
habitual para establecer si los accesos obtenidos
seguían siendo válidos, y si el monto realmente era
deducido de la cuenta bancaria.
Se consultó el balance en línea y se dieron cuenta
que efectivamente se transfirió el monto.
Posteriormente ejecutan una transferencia de
$10,000 a una cuenta nueva, para probar que su
intento de sacar dinero sería exitoso. Verifican que
efectivamente la transferencia se realizó.
Entonces, hacen rápidamente dos transferencias de
cientos de miles de dólares.
Es importante de notar que hasta este momento, la
página web y la página de banca en línea no fueron
atacados. Fueron transacciones que se validaron
con las credenciales apropiadas y que se ejecutaron
dentro de los parámetros del banco.
El ataque de negación de servicio comenzó la tarde
del 13 de abril. Podemos decir que las razones del
ataque fueron o Negar el acceso de la víctima al
sitio de ebanking, para evitar que se dé cuenta de
las transferencias y trate de evitar junto con el banco el pago de las mismas.
Ocupar al personal de tecnología para desviar su
atención de estas transacciones que tal vez podían
ser detectadas como sospechosas.
Los atacantes no podían calcular cuando el ataque
sería detenido, y seguramente fue detenido antes
de lo que ellos calcularon, dado que el sábado y
domingo la página estuvo funcional la mayor parte
del día.
El lunes, cuando otra vez se restauró el servicio,
aprovecharon para hacer otras transferencias y casi
limpiaron la cuenta de los fondos.
Cabe notar también que el ataque de negación de
servicio no fue el causante de la pérdida de fondo,
si no que fue un evento adicional que los atacantes
crearon después de tener las credenciales del usuario. El costo del ataque de negación de servicio
probablemente estuvo entre los $10,000 a $50,000
para contratar una red Botnet que ejecute dicho
ataque. El retorno de la inversión de los atacantes
justifica ese precio con creces.
Recomendaciones
Primero, para evitar la situación que se dio referente
a transferencias internacionales autorizadas con
claves robadas:
Se recomienda que transacciones a nuevas cuentas
o proveedores sean verificadas manualmente por
teléfono, o que tengan un periodo de espera de 24 a
48 horas.
Se recomienda avisar mediante correo electrónico
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
y/o SMS al dueño de la cuenta por cada transferencia electrónica
Se recomienda implementar un sistemas de
passwords únicos (One-Time Passwords) para evitar el robo de contraseñas (tokens, tarjetas de coordenadas, biométrico, etc.).
Para protegerse de ataques de negación de servicio, se recomienda:
Implementar un sistema de IPS frente a la aplicación de banca electrónica y/o página web
Independizar el acceso a Internet de la página web
versus la infraestructura de uso interno del banco
4. CASO REAL #2: ANONYMOUS EN PANAMÁ
El Hacktivismo es ahora la segunda razón más
común para poderosa para los atacantes. Veamos
una notificación que recibimos del CSIRT sobre
ataques que Anonymous enviaría múltiples ataques,
en apoyo a demostraciones que se estaban dando
en Panamá en contra del gobierno. Esta es la alerta:
Reportes Gráficos
Cantidad de ataques bloqueados por día:
Mapa de los países de donde llego el ataque
En preparación a esto, nosotros Soluciones Seguras, activamos en el lugar de todos nuestros clientes gubernamentales, planes de alerta con los equipos que tenían y con los fabricantes, para cualquier
eventualidad o ataque que se pudiera dar el día
anunciado.
Cuando llega el día, Anonymous anuncia que atacará 3 víctimas, cada uno por 2 horas de duración. El
ataque de Anonymous funcionaría de la misma
manera que otros, donde miembros de la organización y otros voluntarios atacan de forma coordinada
a los blancos designados. Dado que los mismos
miembros no se conocen entre sí, necesitan un
medio de comunicación, que normalmente es un
cuarto de chat de IRC (Internet Relay Communication). Y este chat lo anunciaron por Twitter para los
miembros interesados. Naturalmente, estábamos
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
muy interesados en esa información!
Qué medidas tomamos nosotros, como empresa de
seguridad informática? Primero, enviamos un comunicado a todos nuestros usuarios, alertándolos
de la situación. Segundo, establecimos un horario
especial en la oficina, dado que los ataques serían
sábado a mediodía. Tercero, en los clientes de alta
riesgosidad, enviamos ingenieros al sitio para estar
directamente respondiendo en caso de ser necesario.
El día del ataque, por Twitter se comparte un enlace
web que ejecuta una herramienta LOIC (Low Orbit
Ion Cannon) con las victimas designadas. La idea
de Anonymous es conseguir un ‘Tango Down’, un
blanco caído. Se envían ataques de 45Mbps, de
múltiples países, como se muestra en la gráfica
abajo.
Los tres objetivos que se atacaron fueron primero el
sitio de Minera Panamá, después la Presidencia de
la República de Panamá, y finalmente la Asamblea
de Panamá. De los tres, solamente el sitio de la
Presidencia sobrevivió los ataques, según esta noticia publicada:
Aquí podemos ver en enlace que se usó para anunciar la página que usarían los voluntarios para participar en el ataque.
Aquí se puede ver un poco de las gráficas de los
ataques:
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”
Faskha, Eli | “Ataques Reales: Análisis, Lecciones y Protección”
Esta experiencia nos permite ver que aun un ataque
coordinado de Anonymous puede ser detenido, y
que hay varias herramientas que podemos usar
para protegernos. Otra podría ser las soluciones de
protección en la nube que desvían el tráfico para
bloquear lo que es malicioso.
5. SÍNTESIS CURRICULARES DEL AUTOR
Ing. Faskha, Eli: Cuenta con más de 10 años de
experiencia en Internet y Seguridad de Internet.
Durante el ataque se vieron muchos comentarios en
el Chat de IRC, y compartiremos estos durante la
presentación.
Hablemos un poco sobre las protecciones que se
hicieron:
Geoprotección ayudó bastante: La habilidad de
bloquear conexiones de países enteros, permitió
dejar el sitio disponible para países que realmente
queríamos que accesen el servidor
(Panamá,m Centroamérica, etc), pero bloqueando a
países que son comunes para ataques, como Rusia, China, Pakistan y otros.
Protección específica contra ataques de negación
de servicio, diseñada para rápidamente bloquear los
paquetes de los ataques LOIC. Estos se podían ver
directamente:
Dentro de sus roles, desarrolló y liderizó el portal
más grande de Internet en Panamá en el 2000, y
fue Gerente Regional del Afiliado de Verisign para
Centro América. En el 2001 fundó Soluciones Seguras, una de las primeras empresas en Panamá dedicadas a exclusivamente a Seguridad de Internet.
En el 2005 comenzó una labor activa con la Editorial
Syngress, y hoy en día ha participado en más de
media docena de libros disponibles, como Configuring Check Point NGX, Guide to Security+, y the
Best Damm Firewall Book II.
Como socio de negocios de Check Point Software
Technologies y Nokia, se ha involucrado activamente en el área de entrenamiento. Como instructor de
seguridad informática, ha recibido a participantes de
más de una docena de países, e impartido cursos
desde Canadá hasta Argentina.
Mantiene múltiples certificaciones de seguridad de
la industria, como CISSP, Certified Ethical Hacker,
Security+, y Check Point Certified Master Architect.
“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”