PDF de programación - Taller: Auditoría de Código Fuente

CyberCampES 2014

5-7 diciembre

Madrid

¿YO?

• Simón Roses Femerling

Fundador & CEO, VULNEX www.vulnex.com

•

• Blog: www.simonroses.com


@simonroses | @vulnexsl

•

• Ex: Microsoft, PwC, @Stake



• Beca del DARPA Cyber Fast Track (CFT) para investigar sobre

seguridad en el ciclo de desarrollo de software
http://www.simonroses.com/es/2014/06/mi-visita-al-
pentagono/


• Ponente: Black Hat, RSA, HITB, OWASP, AppSec USA, SOURCE,

DeepSec, TECHNET


OBJETIVOS DE LA CHARLA

• Cómo realizar una auditoría de
código fuente de forma práctica


• Métodos, métricas y herramientas









AGENDA

1. Seguridad en el ciclo de desarrollo
2. ¡Una de métricas!
3. Auditoría de código fuente práctica
4. Inteligencia aplicada a la auditoría
5. Conclusiones



1. ¡EL CÓDIGO CADA VEZ MÁS COMPLEJO!

Software

SLOC

Firefox

14 Millones

Windows Server 2003

50 Millones

Debian 7.0

419 Millones

Mac OS X 10.4

86 Millones

Linux Kernel 2.6.25

13.5 Millones

Linux Kernel 3.6

15.9 Millones

1. TAMAÑO DEL CÓDIGO FUENTE

http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

1. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1. OPENSAMM

1. MICROSOFT SDL

1. ¡SE TRATA DE AHORRAR DINERO!

 1. PRUEBAS DE SEGURIDAD VS AUDITORÍA
DE CÓDIGO

PRUEBAS DE
SEGURIDAD

AUDITORÍA DE

CÓDIGO

PROS

• Rápido
• < Precio



• Amplia cobertura
• Conocimiento

CONTRAS

• Cobertura limitada
• A ciegas

• Lento
• > Precio


1. ¿DOCUMENTACIÓN, POR FAVOR?

1. ¿MOMENTO DE UNA AUDITORÍA?

1. ¿POR DÓNDE EMPEZAR?

• Ficheros
• Redes
• Procesos
• Cifrado
• Autenticación
• ??












 1. ¿CÓDIGO FUNCIONAL?

1. ¿HERRAMIENTAS?

 2. CONOCIMIENTO DEL CÓDIGO

• ¿Qué API se esta utilizando?



• ¿Número de funciones?



• ¿Entrada / salida de las funciones?



• Relación entre funciones



• ¿Qué dicen los comentarios?



• Complejidad del código






 2. MÉTRICAS DE CÓDIGO (COMIENZO AUDITORÍA)

• Tema controvertido ¡pero necesario!



• Tipos de métricas:



– LOC / KLOC / MLOC : línea de código, mil líneas de código, millón de líneas

código

– Complejidad de la función (Cyclomatic Complexity)
– Número de:

Líneas (LOC, KLOC, MLOC)

•
• Código

Líneas vacías
•
• Comentarios

Funciones

•
• Clases

Instrucciones

•
• …

– Longitud de las líneas
– …






 2. COMPLEJIDAD DEL CÓDIGO

• Se cuenta el número de caminos linealmente independientes que

puede tomar el código
– If....else
– switch
– case
– catch
– while
– do
– ….



• Se trata de obtener una idea de la complejidad de las funciones

•


¡Complejidad es el enemigo de la seguridad!


• Creado por Thomas McCabe (NSA – 1976)

http://www.literateprogramming.com/mccabe.pdf



 2. UMBRAL DE COMPLEJIDAD DEL CÓDIGO

 2. NOTACIÓN PARA ANÁLISIS DE CÓDIGO
FUENTE

www.mccabe.com/ppt/SoftwareQualityMetricsToIdentifyRisk.ppt

 2. ANÁLISIS VISUAL DE CÓDIGO FUENTE

BINARIO

CÓDIGO FUENTE

 2. SOURCE MONITOR

 2. CODE ANALYZER I

 2. CODE ANALYZER II

 2. DEMO 1: SOURCE MONITOR

 2. DEMO 2: CODE ANALYZER

 2. DEMO 3: LINE COUNTER

 2. MÉTRICAS DESPUÉS AUDITORÍA CÓDIGO I

• Defect Density (DD): numero de fallos confirmados durante un

período de tiempo dividido por el tamaño del software


• Período:

– Tiempo concreto (un mes, semanas, etc.)
– Una fase del SDLC
– Todo el SDLC



• Tamaño:

– Número funciones
– Número de LOC






Número de fallos

Defect Density =





Tamaño

 2. MÉTRICAS DESPUÉS AUDITORÍA CÓDIGO II

• Risk Density (RD): Similar al Defect Density pero medido en

función del riesgo (alto, medio, bajo)


• RD = X Riesgos / LOC o X Riesgos / Funciones



• Ejemplo:

– 5 Riegos Altos por 5000 LOC
– 3 Riesgos Medios por 10 Funciones










 2. MÉTRICAS, OWASP

 3. ¿QUÉ HACE MEJOR UNA AUDITORIA DE CÓDIGO?

• Casi 100% cobertura del código



• Método sistemático para encontrar fallos



• Mejor para encontrar fallos de diseño



• Podemos encontrar todos los fallos de la misma categoría



• La única forma de encontrar según qué fallos







 3. PROCESO DE AUDITORÍA CÓDIGO FUENTE –
OWASP

https://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents

 3. BUSCANDO VULNERABILIDADES

Estático

Leer código

Desensamblar

Binario

Dinámico

Depurador

Manual

Automatizado

Estático

Análisis

Dinámico

Pruebas
Negativas

Pruebas
Positivas

Symbols

código

Públicos

symbols

Fuzzing

Desensamblar

Binario

Tonto

Inteligente

 3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Solución

Equipo

Seguimiento

Auditoría

 3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Solución

Equipo

Seguimiento

Auditoría

 3. EL PLAN

1. Definir ámbito



2. Definir equipo



3. Definir tiempo



4. Definir amenazas



5. Definer herramientas (software y hardware)






 3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Solución

Equipo

Seguimiento

Auditoría

 3. EL EQUIPO

1. 1..N



2. Roles

1.
2.
3.
4.

Auditor Líder
Desarrolladores
Arch, seguridad, jefes proyecto, dev y testers
Auditores junior y senior


3. Habilidades

Tecnología (Web != App Móvil != Aplicación)
Lenguaje (ASM != C/C++ != Java != .NET)
Seguridad (Cifrado, Validación datos, AuthN, AuthZ, etc.)
Vulnerabilidades (OWASP Top 10, Corrupciones memoria, etc.)

1.
2.
3.
4.


4. Recomendado tener diferentes perfiles



5. Formación








 3. SESIONES

1. Grupos pequeños (2-4)



2. Cada uno con su propio equipo / herramientas



3. Un buen auditor entre 100 y 1000 líneas código (LOC) hora



4. Tiempo

Recomendación

Tiempo

Microsoft

Microsoft

1-3 horas seguidas / día

2 horas mañana / 2 horas tarde (4 horas total)

MITRE

3000 LOC día

Wikipedia

150 LOC / hora








5. 3-5 sesiones auditoría código a la semana



6. 2-4 reuniones a la semana (10 min – 1 hora máx.)





 3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Solución

Equipo

Seguimiento

Auditoría

 3. FASES DE LA AUDITORÍA

• Conocimiento



2.

• Identificando

vectores ataque

• Priorizar
auditoría

4.

• Vulnerabilidades

1.

3.

 3. FASES DE LA AUDITORÍA

• Conocimiento




2.

• Identificando

vectores ataque

• Priorizar
auditoría

4.

• Vulnerabilidades

1.

3.

 3. CONOCIMIENTO CÓDIGO

• Métodos

– Estático -> Leer código
– Dinámico -> Entorno pruebas, ejecución



• Documentación

– Modelos de amenazas
– Diseño
– Funcionalidad
– Testing
– Auditoría anteriores ¿?



• Enumerar entorno y tecnologías

– Sistemas
– Lenguajes, librerías
– Búsqueda de CVE





 3. EL SOFTWARE YA NO SE ESCRIBE, SINO QUE SE
COMPONE

 3. FASES DE LA AUDITORÍA

• Conocimiento



2.

• Identificando

vectores ataque

• Priorizar
auditoría

4.

• Vulnerabilidades

1.

3.

 3. IDENTIFICANDO VECTORES DE ATAQUE

• Modelo de Amenazas



• Puntos de Entrada/Salida

– Datos no confiables
– Nivel de acceso



• Análisis estático automatizado



• Léxico

– Patrones
– Expresiones regulares



• Historia del código

– Vulnerabilidades
– Auditorías





 3. ¿QUÉ NOS OFRECE EL MODELO DE AMENAZAS?

•

Incluye interfaces y niveles de privilegio


• Componentes



• Riesgos



• Ayuda a:

–

–

–

–

Entender el sistema
Todo el mundo en el mismo punto
Identificar riesgos potenciales
Focalizar el trabajo







Código solo accesible por usuarios
autenticados

1001010010111011001
0101010101010111100
0100001010010100010
1000110100100010100
0101001010000101110

Código accesible por todo el
mundo

1001010010111011001
0101010101010111100
0100001010010100010
1000110100100010100
0101001010000101110

 3. MICROSOFT SDL TM

http://blogs.microsoft.com/cybertrust/2014/04/15/introducing-microsoft-threat-modeling-tool-2014/

 3. GREP KUNG-FU

Add2Ptr\(.*,.*->.*\)
alloc.*(.*\*.*sizeof(WCHAR))
\+.*wcslen\(.*\)
\*.*wcslen \(.*\)
wcslen\(.*\).*\*
ISSUE
NOTICE
FUTURE
TODO
REVIEW
BUGBUG
FIXFIX
FIX
GUBGUB
HACKHACK




user
admin
pwd
http
ftp
key
secret
port
root
anon
pass




 3. DEMO 4: BAREGREP

 3. DEMO 5: VISUAL GREP

 3. FASES DE LA AUDITORÍA

• Conocimiento



2.

• Identificando

vectores ataque

• Priorizar
auditoría

4.

• Vulnerabilidades

1.

3.

 3. PRIORIZAR AUDITORÍA

• Más revisión
– Código viejo
– Por defecto
– Elevado privilegios
– Acceso anónimo
– Escucha en red
– UDP
– C/C++ / ASM
– Historial de fallos
– Complejo
– Interfaz sin documentar
– Contiene información sensible
– Código difícil de mantener


• Menos revisión
– Código nuevo
– Cerrado por defecto
– Mínimos privilegios
– Acceso autenticado
– No escucha en red
– TCP
– Código gestionado
– Historial limpio
– Código simple
– Interfaces documentados
– No contiene información

sensible

– Código fácil de mantener





 3. PASES DE LA AUDITORÍA

• Multi-pase



– Pase #1

• Uso de herramientas análisis

estático/dinámico

– Pase #2

• Buscar patrones de vulnerabilidades

– Pase #3

• Análisis en profundidad de código

potencialmente con riesgo





 3. FASES DE LA AUDITORÍA

• Conocimiento



2.

• Identificando

vectores ataque

• Priorizar
auditoría

4.

• Vulnerabilidades

1.

3.

 3. VULNERABILIDADES I

• OWASP Top 10

– Web: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
– App Móviles:

https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-
_Top_Ten_Mobile_Risks

•


.NET Code Review
– http://msdn.microsoft.com/en-us/library/ff648637.aspx



• OWASP Top 10 for .NET developers

– http://www.troyhunt.com/2011/12/free-ebook-owasp-top-10-for-net.html


• Secure Coding Guidelines for Java

– http://www.oracle.com/tec