pedro sánchez & eduardo abril - autopsia de una intrusión: a la sombra del chacal [rootedcon...

Congreso de Seguridad ~ Rooted CON’2010

Autopsia de una intrusión A la sombra del chacal

Eduardo Abril

Pedro Sánchez

Madrid 18 de Marzo, 2010



Eduardo Abril

He trabajado como sysadmin, hecho auditorías de seguridad, s e c u r i z a d o s e r v i d o r e s , . . . Actualmente, t rabajo en una importante institución financiera como auditor de seguridad (IDS, pen-testing)

Pedro Sánchez

Soy un apasionado de las técnicas forense

* He trabajado en empresas como consultor de seguridad informática especializado en métodos forense, redes trampa, detección de intrusiones, desarrollo de normas ISO 27001 y 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 responsable de seguridad http://hacking-avanzado.blogspot.com/


¿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


¿De verdad es suficiente?

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

Medidas actuales en BE


¿De verdad es suficiente?

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

TRES Ejemplos REALES


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. • Teniantodas las medidas de seguridad básicas: Cortafuegos, Antivirus. • Primer incidente visual: Los programadores desactivan el antivirus para compilar más rápido ¿? • Se revisa el equipo del gerente, ya que a priori es donde se realizan normalmente las operaciones de Banca Electrónica • Sin previo aviso durante la revisión se produce un pantallazo azul, el gerente indica que desde hace un tiempo es habitual los reinicios


Autopsy Case 2

El concepto es el concepto (Airbag)


Usuario pass

Usuario pass

Usuario pass

A2

UN EJEMPLO REAL

1º

2º

Login

Login


Usuario Pass A2

A2

¡¡ Dame A2 !!

Usuario Pass -------

A2

Bloq. usuario 3º

4º

Login

Login


Autopsy Case 3

Mi web tiene un bujerito sersua


Case 3

• Autopsia del ataque:

• PASO 1:

1.- El cliente hace 'click' en un vinculo sobre un falso correo

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

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

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

3


Case 3 • PASO 2:

3.- El cliente recibe la página con sus datos y un campo más en el que le piden el DNI

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


1.- El servidor legitimo valida el nombre de usuario y contraseña y muestra la posición global y se la envía al cliente

5.- El malo envia el nuevo valor (dni) e intenta hacer una trasferencia automatica


Case 3 • PASO 3:

3.- El cliente recibe la página con sus datos y un campo más la solicitud de su token

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


1.- Dado que este cliente es VIP y dispone Token de un solo uso le solicita el uso del mismo

5.- El malo envia el nuevo valor (token) y realiza una transferencia automaticamente


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...

Technology