investigación y descubrimiento de vulnerabilidades

Investigación y Descubrimiento de Vulnerabilidades

Lic. Julio C. ArditaLic. Julio C. [email protected]@cybsec.com

2


Segurinfo 2007 – Tercer Congreso Argentino de Seguridad de la Información – www.segurinfo.org.ar

AgendaAgenda

- El mundo de las vulnerabilidades de seguridad

- Descubriendo vulnerabilidades

- Experiencias en la investigación de vulnerabilidades

3



El mundo de lasvulnerabilidades

de seguridad

4



Es un falla o limitación en el diseño, procedimiento o implementación

de un sistema.

El mundo de las vulnerabilidades de seguridad

¿Qué es una vulnerabilidad?

¿Qué es una vulnerabilidad “explotable”?

Es aquélla que representa un riesgo de seguridad para un sistema. En

caso de ser aprovechada o “explotada” podría violarse la seguridad

de la información que reside en el mismo.

¿Qué es un “exploit”?

Es el programa o técnica utilizado para aprovechar una

vulnerabilidad.

5



Cantidad de vulnerabilidades de seguridad reportadas

© http://www.securityfocus.com/print/news/11436

0100020003000400050006000700080009000

2001 2002 2003 2004 2005 2006

Vulnerabilidades CERT


6



Tendencias en el descubrimiento de vulnerabilidades

200719XX 2006200119951989

AplicacionesBases de

DatosAplicaciones

Clientes

Sistemas

Operativos

Networking Aplicaciones

Web


7



Técnicamente hablando, un 0-day es un exploit que aprovecha una

nueva vulnerabilidad para la cual no existe un parche o solución.

Ejemplo: Microsoft Security Bulletin MS06-001 (WMF)

Zero-days (“0-day”s)

28-12-05

Aviso de MS

donde se informa

la vulnerabilidad.

6-1-06

MS lanza un Boletín

y los parches.

xx-xx-06

Usuarios finales aplican

los parches.

WildPúblico – Masiva

explotación Parches – Media

explotación

Baja

Explotación


8



Las condiciones que determinar el “valor” son las siguientes:

Afectación (software de uso masivo)

Origen de la explotación (remota o local)

Posibilidad de ejecutar código

Conocimiento de la vulnerabilidad en el mercado

El valor de una vulnerabilidad de seguridad


9



Verisign iDefense Vulnerability Contributor Program (VCP)

Desde 2002. Durante el 2006, compró 81 vulnerabilidades.

TippingPoint ZDI – Zero Day Initiative. Desde 2005.

En 2006, compró 54 vulnerabilidades.

NetRagard SNOSOFT Exploit Acquisition Program.

Desde 2007. Broker de vulnerabilidades.

Precio por vulnerabilidad de hasta U$S 75.000.

Compra de conocimiento

© http://www.securityfocus.com/print/news/11437


10



Publicación responsable

Muchas “personas” buscando vulnerabilidades

Investigación básica (“grep” research)

Mayor disponibilidad de herramientas automatizadas

Google Code Search

Novatos centrados en búsqueda de vulnerabilidades en

aplicaciones web (45%)

Concursos “El mes de... Windows, Browsers, Databases, etc”

Descubrimiento de vulnerabilidades hoy


11



DescubriendoVulnerabilidades

12



Descubriendo vulnerabilidades

Metodologías para el descubrimiento de vulnerabilidades

Básicamente existen dos formas de detectar vulnerabilidades:

White-Box (Auditoría del código fuente)

Black-Box (Inyección de fallas, Ingeniería reversa,

Function Hooking y Análisis de parches)

Para cada una de estas metodologías de detección de vulnerabilidades existen herramientas que realizan el trabajo de manera automatizada. Sin embargo, de nuestra experiencia se desprende que el mejor resultado se obtiene combinando herramientas automatizadas y análisis manual.

13



Vulnerabilidades más comunes

Buffer Overflows

Format Strings

Off-by-one

Conversiones entre distintos tipos de datos (signed,

unsigned, long, short)

Double free

Errores lógicos

y muchas, muchas más…


14



White-Box Auditoría de código fuente

Este método para encontrar vulnerabilidades en software posee la

siguiente ventaja:

- Alcance, ya que es posible encontrar vulnerabilidades que de

otra forma serían muy difíciles de encontrar.

Pero también presenta las siguientes desventajas:

- Se requieren conocimientos relativamente avanzados de

programación y del lenguaje que se desea auditar.

- Consume una gran cantidad de tiempo.

- No se evalúan los problemas de compilación ni escenarios

de implementación.


15



Auditoría de código fuente

Mencionaremos dos metodologías para el análisis de código de forma

manual:

•Bottom-up, en la cual se comienza leyendo el código de la

función principal del programa y luego se leen en orden de

llamada todas las funciones del programa.

• Top-down, se seleccionan funciones específicas que por la

experiencia del investigador podrían llegar a poseer

vulnerabilidades y se focaliza el análisis únicamente en ellas.


16



Auditoría de código fuente

Existen herramientas que realizan la tarea de auditoría de código en

forma automatizada, las mismas poseen las siguientes propiedades:

- Dependientes del lenguaje de programación.

- Fallan en descubrir errores en la lógica del programa.

- Barren con gran velocidad el código fuente generando una

auditoria del código en segundos.

- Generan falsos positivos los cuales deben ser verificados por el

investigador de forma manual.

Debemos encontrar un balance entre las herramientas automáticas y

el trabajo de los investigadores.


17



Black-Box

El análisis de vulnerabilidades Black-Box presenta un nivel de

dificultad mucho mayor: la ausencia del código fuente.

El investigador tiene acceso únicamente al conjunto de ejecutables y/o

librerías (y con suerte alguna información de debugging...).

Frente a este desafío se pueden utilizar diferentes enfoques:

- Inyección de fallas (Fuzzing).

- Ingeniería Reversa.

- Function Hooking.

- Análisis de parches.


18



Inyección de fallas - Fuzzing

Desde principios de 1990 esta metodología es utilizada para detectar

vulnerabilidades en software.

Básicamente la idea es ingresar fallas utilizando todos los métodos

de entrada que el software provea. Por ejemplo, si el software sobre

el cual deseamos encontrar vulnerabilidades es un servidor Web,

podremos ingresar fallas por medio del puerto 80 TCP.

GET / HTTP/1.1

GGGGGGGGGGGGGGGGGGGGGGGET / HTTP/1.1

GET /////////////////////// HTTP/1.1

GET / HHHHHHHHHHHHHHHHHHHHHHHTTP/1.1

GET / HTTP///////////////////////1.1

GET / HTTP/11111111111111111111111.1

GET / HTTP/1.......................1

GET / HTTP/1.11111111111111111111111

Request original

Requests modificados


19



Inyección de fallas - Fuzzing

Las herramientas automatizadas para inyección de fallas (fuzzers),

actualmente se encuentran en pleno desarrollo y aún son algo

primitivas, pero sin duda alguna, ahorran una gran cantidad de

tiempo. Algunas de las herramientas que utilizamos son:

SPIKE

Autodafe

Fuzzers desarrollados internamente.

Estas herramientas realizan un trabajo repetitivo y en general es

posible encontrar vulnerabilidades utilizándolas. De todas formas,

nada puede reemplazar a una persona debidamente capacitada y

experimentada para detectar vulnerabilidades en software.


20



Ingeniería Reversa

La Ingeniería Reversa es el proceso que intenta reproducir el diseño

de un sistema a partir del producto terminado.

Se originó para brindar compatibilidad con diversos sistemas de

código cerrado y carentes de documentación.

El objetivo es realizar la siguiente transformación:

…mov [ebx+7], almov [ebx+8], ebxmov [ebx+12], eaxmov al, 11lea ecx, [ebx+8] lea edx, [ebx+12] int 0x80…

void funcion1(char *str) {int i;…if (i == 20) {

*str = ‘a’;}…funcion2(str);

}


21



Ingeniería Reversa

Una vez que se obtiene una aproximación del código original, se

analiza si el mismo posee vulnerabilidades.

Ventajas:

- Conocimiento “exacto” del funcionamiento de la Aplicación.

- Identificación de vulnerabilidades lógicas o extremadamente

complejas de detectar por fuzzing.

Desventajas:

- Profundo conocimiento de Assembler, compiladores y

programación.

- Proceso arduo y tedioso.

- Complejidad para identificar código “alcanzable”.


22



Function Hooking

Esta técnica se basa en reemplazar funciones en librerías por

nuestras propias funciones. El objetivo es interceptar las llamadas,

analizar los parámetros recibidos y derivar la ejecución a la

verdadera función.

Microsoft Research ha desarrollado una herramienta que permite

realizar este tipo de análisis: Detours.

Con esta herramienta, nuestra librería (dll) se inyecta en el espacio de

direcciones del proceso objetivo.


23



Ejemplo de Function Hooking

Aplicacióna auditar

(buggy.exe)LibBuggy.dll

call convertirString(...)

retorna


24



Ejemplo de Function Hooking

Aplicacióna auditar

(buggy.exe)LibBuggy.dll

MiAudit.dll

Función:ConvertString


retorna


retorna


25



Análisis de Parches

Cuando una nueva vulnerabilidad es reportada, el fabricante desarrolla

el parche y lo libera para que los usuarios puedan actualizarse y

protegerse.

Estructura e implementación de un parche, según el tipo de Aplicación

Aplicaciones de Código Abierto:

- Archivos .diff. Implementación y recompilación.

- Binarios. Reemplazo completo del binario vulnerable.

Aplicaciones de Código Cerrado:

- Binarios. Reemplazo completo del binario vulnerable.


26



Si el parche soluciona la vulnerabilidad...agrega o elimina código. La

técnica consiste en analizar la “diferencia” entre el parche y el

componente vulnerable.

Diferentes procedimientos y herramientas:

Archivos .diff- Análisis directo del código fuente agregado o eliminado.

Binarios:

- Comparar versiones. Herramientas automáticas (BinDiff,

EBDS).

- Analizar el código modificado (si, a leer assembler otra vez).

Análisis de Parches


27



Experiencias en la investigación de vulnerabilidades

28




CYBSEC-LABS

CYBSEC-LABS es un área de CYBSEC, cuyo objetivo es investigar y

desarrollar nuevas técnicas y herramientas de Seguridad Informática

para suplir al área de Consultoría.

Paralelamente se realizan investigaciones sobre productos o

sistemas utilizados masivamente, analizando la seguridad de los

mismos en busca de nuevas vulnerabilidades.

Durante el año 2006 hemos descubierto 16 vulnerabilidades, las

cuales afectan a sistemas críticos.

29



Vulnerabilidad en Microsoft Windows - Servicio DHCP Cliente

• Severidad: Alta

• Tipo de Vulnerabilidad: Buffer Overflow.

• Afecta: Todas las versiones de Microsoft Windows (2000, XP,

2003).

• Posibilita la ejecución de código en forma remota.


30



Vulnerabilidad en SAP – Internet Graphics Service (IGS)

• Severidad: Alta

• Tipo de Vulnerabilidad: Buffer Overflow.

• Afecta: Todas las plataformas de SAP IGS (AIX, HP-UX, Linux,

Windows, etc).

• Posibilita la ejecución de código en forma remota.

INTERNET O LAN


31



Vulnerabilidad en IPS TippingPoint

• Severidad: Alta

• Tipo de Vulnerabilidad: Falla de diseño• Afecta todas las versiones del hardware previo al reporte de la

vulnerabilidad al vendor

• Posibilita el bypass de las funcionalidades de bloqueo y detección

del IPS


32



RFC es el protocolo de comunicación utilizado por SAP para la

interconexión interna de SAP y también entre SAP y sistemas externos.

Investigación de vulnerabilidades en la interfaz y en la librería de RFC.

Duración del proyecto: 3 meses.

Resultado: 7 vulnerabilidades descubiertas y reportadas. 6 con parche

disponible a la fecha.

Release coordinado con SAP para Abril de 2007.

Desarrollo y lanzamiento de una herramienta para realizar PenTest

a sistemas SAP.

Investigación sobre RFC de SAP


33



Nuevas vulnerabilidades. Durante 2007, en CYBSEC descubrimos:

- 2 vulnerabilidades que afectan a MS Windows.

- 1 vulnerabilidad al cliente de SAP (SAPGui).

- 1 vulnerabilidad nueva en SAP.

Las mismas están siendo solucionadas por los Vendors y

próximamente saldrán los avisos correspondientes.

Desarrollo de herramientas para el descubrimiento de nuevas

vulnerabilidades.

Lo que viene...


34



Conclusiones

- La cantidad de vulnerabilidades va a seguir en aumento. Es necesario definir e implementar un política efectiva de Patch Management.

- Las empresas desarrolladoras deben capacitarse más y actualizarse sobre las nuevas vulnerabilidades existentes.

- Se deben aplicar metodologías y herramientas de testing para realizar evaluaciones de seguridad a los productos antes de lanzarlos al mercado.

¿¿Preguntas?Preguntas?

www.cybsec.com

Lic. Julio C. ArditaLic. Julio C. [email protected]@cybsec.com

CYBSEC S.A. Security SystemsCYBSEC S.A. Security Systems

investigación y descubrimiento de vulnerabilidades

Documents