Pedro Sánchez & Eduardo Abril - Autopsia de una intrusión: A la sombra del chacal [RootedCON 2010]

Autopsia de una intrusión
A la sombra del chacal

Eduardo Abril

Pedro Sánchez

Madrid 18 de Marzo, 2010

Congreso de Seguridad ~ Rooted CON’2010

Eduardo Abril Pedro Sánchez
He trabajado como sysadmin, Soy un apasionado de las técnicas forense
hecho auditorías de seguridad,
* He trabajado en empresas como
securizado servidores, ...
consultor de seguridad informática
Actualmente, trabajo en una
especializado en métodos forense, redes
importante institución financiera trampa, detección de intrusiones,
como auditor de seguridad (IDS, desarrollo de normas ISO 27001 y
pen-testing) metodologías sobre arquitecturas de
seguridad.
* Soy miembro del capítulo Español de la
Honeynet Project
* He publicado diversas herramientas y
scripts de seguridad en ForensicFocus
* Actualmente desarrollo mi labor como
http://hacking-avanzado.blogspot.com/ responsable de seguridad


¿Que hacemos?

Trabajamos (nuestra empresa) para cuatro
entidades financieras de las que son dueños y
clientes.

Securizamos (lo intentamos) a más de 6.000
puestos de trabajo en 1.700 sucursales

2.000 Cajeros automáticos y 18.000 TPV's

Más de 80.000 clientes en Banca Electrónica

¿Que hacemos?

Tenemos un equipo que define las normas para
administrar, bastionar, regular , prevenir y dar
continuidad a las entidades y sus clientes

Nuestro mayor carga de trabajo proviene de
Computers Forensics y del ethical Hacking

Colaboramos activamente con las fuerzas del
estado, especialmente con la Guardia Civil


¿Que hacemos?



Agenda

1.- Estado de la seguridad actual

2.- Medidas actuales en las Bancas Electrónicas
2.1.- Ejemplo reciente

3.- KRAV defensa ante el fraude


1.- Estado de la seguridad

Estado de la seguridad actual


¿Que vemos?
16.000 Ataques al mes a las web's
Casi el 100% de Ip's provienen de Rusia y China
El 2% de Ataques de denegación de servicio
El 80% Ataques de troyanos en clientes (un 4% es phising)
El el 18% restante ataques de SQL Inyection, RFID, etc.
Los casos forenses se han multiplicado en los dos últimos años por 10
(forensico a PC' portatiles, dispositivos,Moviles, PDA's)
Las fugas de información están a la orden del día
Empleados descontentos, Administradores...etc
Gerentes que desconfían de los admins


La seguridad tradicional ha
muerto

 Desactivar servicios
 Quitar paquetes innecesarios
 Cambiar banners
 Firewalls de red
 HIDS (Host IDS)
 ...


Si cambias tu banner...

 Apache con PHP,
windows con .asp …
 Da exactamente igual


¿IDS's?
 No queremos añadir
un usuario a /etc/
passwd
 No queremos una
shell
 No nos interesa
escanear la red


Solo queremos una cosa:
'Vuestro dinero'

 TARJETAS DE
CRÉDITO
 COMPRAS
FRAUDULENTAS
 EXTORSIÓN


¿Y que ahí de los XSS, SQL-i?

 Auditorías trimestrales
 Escaneo manual y automatizado de XSS, SQL-
injection, ...
 Lenguajes de programación cada vez más
seguros
 Firewalls de aplicación (WEB, FTP, …) en
TODAS las entidades financieras
 Mod-security
 Juniper
 ...

¿Quien es la
victima más fácil?


La seguridad tal y como la
conocemos
HA MUERTO

SÓLO UN
COMPLETO
IGNORANTE
INTENTARÍA
ENTRAR EN UN
BANCO


El usuario domestico...

 SOFWARE PIRATA
CON TROYANOS
 0-DAYS (ADOBE,
IEXPLORE, …)
 EL PROPIO
USUARIO


Nuevos troyanos

 Keylogger, Captura
imágenes
 Consola de
administración remota
 Totalmente
indetectables
 Hechos por
profesionales


¿Es suficiente la seguridad
actual de los usuarios?

 Equipo actualizado
 Software legal
 Antivirus
 Firewall
 ...


2.- Medidas actuales

Medidas actuales en Banca
Electrónica


Medidas actuales en BE

 Validación usuario/password
 Teclados virtuales
 Tarjeta de coordenadas
 DNI-e
 Tarjetas Chip (EMV)
 Verificación por SMS, tokens, algún día ...

¿De verdad es suficiente?


TRES Ejemplos REALES

 Autopsy Case 1: Te juro, yo no hice esa
transferencia
 Autopsy Case 2: El concepto es el
concepto (Airbag)
 Autopsy Case 3: Mi web tiene un
'bujerito' sersua

¿De verdad es suficiente?


Case 1: yo no hice esa transferencia
Una empresa cuyo gerente indica que no hizo una
transferencia de 12.000 Euros de su cuenta a una
cuenta cuyo destino es Rumanía.
• eniantodas las medidas de seguridad básicas:
T
Cortafuegos, Antivirus.
• rimer incidente visual: Los programadores
P
desactivan el antivirus para compilar más rápido ¿?
• e revisa el equipo del gerente, ya que a priori es
S
donde se realizan normalmente las operaciones de
Banca Electrónica
• in previo aviso durante la revisión se produce un
S
pantallazo azul, el gerente indica que desde hace un
tiempo es habitual los reinicios


Autopsy Case 2

El concepto es el concepto (Airbag)


Usuario
UN EJEMPLO REAL
pass

Login 1
º
Usuario
pass

2
Usuario
pass

Login

º
A2


Login

¡¡ Dame A2 !!

Bloq. usuario Usuario
Pass
-------
3º
A2

Usuario

4º
Pass
A2

Login

A2


Autopsy Case 3

Mi web tiene un bujerito sersua


Case 3

• utopsia del ataque:
A

• ASO 1:
P 2.- El servidor maligno le hace
entrega de una página falsa, que
simula al banco. En esta le pide el
nombre de usuario y contraseña

4.- El servidor maligno 'pilla' los
datos y los envía al servidor
legitimo

1.- El cliente hace

3
'click' en un vinculo
sobre un falso
correo

3.- El cliente
introduce los
datos y pulsa el
botón enviar


Case 3
• ASO 2:
P
2.- El servidor maligno
'parsea' los datos y los
maqueta dinámicamente sobre
una pagina en PHP que le sera
mostrada con todos los datos
del cliente

5.- El malo envia el
3.- El cliente nuevo valor (dni) e
recibe la página intenta hacer una
con sus datos y trasferencia
un campo más en automatica
el que le piden el
DNI
4.- El cliente 1.- El servidor legitimo valida
introduce los el nombre de usuario y
datos y pulsa el contraseña y muestra la
botón enviar posición global y se la envía al
cliente


Case 3
• ASO 3:
P
2.- El servidor maligno
'parsea' los datos y los
maqueta dinámicamente sobre
una pagina en PHP que le sera
mostrada con todos los datos
del cliente

5.- El malo envia el
3.- El cliente nuevo valor (token) y
recibe la página realiza una
con sus datos y transferencia
un campo más la automaticamente
solicitud de su
token
4.- El cliente 1.- Dado que este cliente es
introduce los VIP y dispone Token de un
datos y pulsa el solo uso le solicita el uso del
botón enviar mismo


Y sí, el cliente ...

 Tenía todos los parches de seguridad
 Tenía antivirus instalado
 Tenía firewall activado
 No tenía software “raro” bajado de internet

Pero ...


 0-days
 Remote Administration Tools (RATs) indetectables
 Botnets, VPNs, Shells, ...
 CCVs, datos personales, ...


Y todo el mundo tiene
otro precio


Además...


Seamos realistas
 Troyanos hechos por
profesionales
 Indetectables hasta
tiempo después
 Mercadeo de 0-days
 Conocen la operativa
del banco
 No hay forma de
perseguirles


Como minimizamos el fraude
suponiendo que...

 El cliente está infectado
 Y el cliente no dispones de
validación por SMS, dni-
electrónico, …


2.- Defensa Personal

Herramienta de gestión del fraude

Krav


KRAV


Krav

 Las soluciones tienen que ser proactivas, es
decir saber los movimientos de los clientes y
poder predecir sus abusos por parte de las
mafias
 Una entidad financiera conoce el historial
económico de sus clientes, por lo tanto
podemos utilizarlo
 Si añadimos algo de inteligencia podemos
disponer de un sistema de alarmas


¿Que es Krav?
KRAV es una base de datos elaborada por un sistema que califica
cada operación de nuestras tarjetas con una puntuación (score)
situado entre 0 y 99 que mide el riesgo de fraude de la misma. A
mayor puntuación mayor riesgo de fraude.

La calificación puede derivarse o bien de la red o bien de las reglas

Red es un sistema neuronal, es decir que califica las operaciones en
función del conjunto de la información que posee y que se enriquece
con cada nueva operación que se califica.

Reglas son instrucciones concretas que ordenan a Krav que califique
con un nivel determinado cuando se dan circunstancias concretas .


¿Que es Krav?
Krav califica cada operación con la mayor de las dos
calificaciones: Red o Reglas

Krav no opera en tiempo real. Refresca sus análisis cada hora
aproximadamente.

La base de datos contiene únicamente las operaciones de las
transferencias que tiene al menos una operación con un "score"
de 10 o superior.

Krav es realmente una alarma de transacciones


Requisitos

 Open Source (Linux+Apache+Mysql+PHP)
 Fácil de extender
 Adaptable a distintos entornos bancarios
 Heurísticas fácilmente configurables
 Posibilidad de hacer consultas
 Capaz de procesar todas las transferencias en
tiempo real
 Ampliamente documentado


Base de datos
Datos de la transferencia
 hash(Cuenta de origen)

 hash(Cuenta de destino)

 Importe

 Divisa

 Concepto

Datos proporcionados por el navegador
 Navegador

 Versión

 Idioma

 Sistema operativo


Base de datos (cont.)

Geolocalización del cliente y otros
 Dirección IP

 País

 Ciudad

 Timestamp de la transferencia

Y, finalmente, un campo que indica la probabilidad
asignada de que sea una transferencia ilícita. Este
campo se va actualizando conforme recibimos más
información.


Y ésta es la pinta
que tiene ...


Necesitamos unas
cuantas cosas

 Validar e insertar transferencias
 Geolocalización (código de maxmind.com)
 Sacar info del navegador
 Asignar pesos
 Procesos batch para correlar cuentas,
personas, transferencias, …


Geolocalización

 El código y las bases de datos pueden
bajarse de maxmind.com
 No es perfecta. P.ej., algunos clientes salen
por el proxy de telefónica.


Información del Navegador


Peso inicial...

 Si el idioma del navegador es ruso, rumano, …
 Si la hora de la transferencia es entre 2 y 6 de
la mañana …
 Si la entidad de origen es distinta de la de
destino …
 Si el sistema operativo es linux restamos …
 Si el navegador es opera restamos …
 Si el país de destino de la transferencia no es
España ...

 Cantidad de la transferencia …
 Cuenta de destino u origen marcada como
sospechosa
 ...

 Cantidad de la
transferencia …
 Cuenta de destino u
origen marcada como
sospechosa
 ...


Procesos Batch

 Algunos procesos (correlación de datos) son
demasiado pesados para hacerlos online.

¿alguna cuenta recibe “demasiadas” transferencias de
otros bancos?
¿algún cliente tiene demasiadas transferencias con
puntuación alta?
¿Transferencias consecutivas desde lugares alejados?
Lo que se nos ocurra, es open source ...


Motor escalable

 Transferencias a sí mismo
 Transferencias de importe muy bajo entre
clientes
 Varias operaciones canceladas consecutivas
 De repente, cambia la cuenta de destino o la de
origen (errores autorización)
 Otros errores “típicos” …


Y al final?

 Tenemos una VM fácilmente configurable para
ser adaptada a nuestro entorno.
 Avisos online a los operadores
 Cuesta trabajo configurarla (no podía ser
perfecto …)
 Estamos desarrollando el asistente de
configuración
 Dispondremos en los siguientes meses un CD-
Live disponible desde sourceforge


Conclusiones

• Con una visión de seguridad hacia el usuario de
banca electrónica pensamos que vive en 'Irak'
• No podemos invertir horas y horas en forensics de
troyanos que a la hora ya han mutado
• La capa perimetral cada vez es más segura
(regulaciones como PCI-DSS, auditorías, revisiones
de código fuente,..etc)
• Tenemos que ser proactivos y alertar por otros
canales (Forensics preventivos)


¿Preguntas?

• Mas información en:
– conexioninversa.blogspot.com
– hacking-avanzado.blogspot.com


Pedro Sánchez & Eduardo Abril - Autopsia de una intrusión: A la sombra del chacal [RootedCON 2010]

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (13)

Semelhante a Pedro Sánchez & Eduardo Abril - Autopsia de una intrusión: A la sombra del chacal [RootedCON 2010]

Semelhante a Pedro Sánchez & Eduardo Abril - Autopsia de una intrusión: A la sombra del chacal [RootedCON 2010] (20)

Mais de RootedCON

Mais de RootedCON (20)

Último

Último (20)

Pedro Sánchez & Eduardo Abril - Autopsia de una intrusión: A la sombra del chacal [RootedCON 2010]