Cazando Bugs de Seguridad en Enterprise

Hunting Security Bugs
in the Enterprise
Hernán M. Racciatti
hracciatti@sicinformatica.com.ar
http://www.sicinformatica.com.ar
http://www.hernanracciatti.com.ar
2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

Copyright © 2007 Hernán M. Racciatti
Acerca del Autor
 Analista Programador, CEH, MCP, ESR, NSP

 Senior Security Consultant at SICinformática
 Miembro de ISECOM (Institute for Security and Open
Methodologies)
 Cordinador del Capitulo Argentino de OISSG (Open
Information System Security Group)

Agenda
 Introducción
 Definiciones
 Tendencias
 Causas del Software Inseguro
 Diferentes tipos de Testing
 Traditional Testing
 Security Testing
 Hunting Security Bugs
 Metodología vs Caos
 Que buscar?
 Threat Modeling
 White Box Testing
 Black Box Testing
 Conclusiones
 Referencias y Lectura Complementaria
 Preguntas

Algunas Definiciones Formales
 Vulnerabilidad
 Ausencia o debilidad de un control
 Condición que podría permitir que una amenaza se materialice con
mayor frecuencia, impacto o ambas.
 Amenaza
 Evento cuya ocurrencia podría impactar en forma negativa en la
organización (Las amenazas explotan o toman ventaja de las
vulnerabilidades)
 Riesgo
 Combinación de probabilidad de ocurrencia e impacto de una amenaza
 Exposición
 Instancia en la cual la información o activo de información es suceptible a
dañarse o perderse por el accionar de un agente de la amenaza.
 Contramedida / Salvaguarda / Control
 Cualquier tipo de medida que permita detectar, prevenir o minimizar el
riesgo asociado con la ocurrencia de una amenaza específica.

Algunas Definiciones No Tan Formales
 Vulnerabilidad
 Cuestiones que se obviaron en el diseño
 Cuestiones que se obviaron en la implementación
 Funcionalidad extra del software 
 Algo con que divertirse (Cuando el software fue desarrollado por otro…)
 Exploit
 Método o programa utilizado para aprovecharse de una vulnerabilidad
 Vulnerabilidad 0 day
 Vulnerabilidad para la cual no existe un parche público
 Vulnerabilidad que solo yo conozco
 Ok… es discutible… (full-disclosure)
 Exploit 0 day
 Método o programa utilizado para aprovecharse de una vulnerabilidad en
su “ventana de exposición”, hasta que un parche sea distribuido por el
fabricante e instalado por el propietario del sistema vulnerable.
 Amenaza inesperada a la seguridad.

Tendencia
 Las aplicaciones son liberadas al circuito comercial, a fin

de evitar que el competidor lo haga primero.
 Hackers/Researchers encuentran vulnerabilidades o
debilidades en el software.
 Aparece un website con el detalle de la vulnerabilidad y
como explotarla.
 Se libera el fix, Parche, SP o se publica el workaround.
 Este parche pasa a engrosar la pila de parches que el
administrador debe testear e instalar 
 Y en su empresa?

Causas del Software Inseguro
 Diseño orientado a funcionalidad
 Diseño Funcional = Diseño de Seguridad
 Ausencia de proceso de SDLC
 Ausencia de políticas de codificación segura
 Desarrolladores sin entrenamiento en seguridad
 Pobre conocimiento de las amenazas
 Pobres practicas de QA
 Tiempo y presupuesto acotados
 Escasez de especialistas
Software Inseguro
Diferentes tipos de Testing
 Accessibility Testing
 International Testing
 Performance Testing
 Upgrade Testing
 Functional Testing
 Operational Testing
 Security Testing

Traditional Testing
 Se focaliza principalmente en verificar que los requerimientos
funcionales son cubiertos.
 Generalmente responden a interrogantes tales como:
 Cumple la aplicación con todos y cada uno de los requerimientos
funcionales y de caso de uso?
 Hace el producto lo se supone que hace?
 En segunda instancia, se focaliza a su vez en aspectos tales como
performance, stress, backup, recuperación y demás cuestiones
operativas.
 Los testeadores de software, construyen casos de uso y escenarios,
basados en los requerimientos funcionales de la aplicación, a fin de
verificar metódicamente, que cada punto de la aplicación funciona
correctamente.
 Los requerimientos de seguridad en los entornos de testing
tradicional, son tratados levemente u omitidos por completo.
Security Testing
 Se focaliza principalmente en verificar que los requerimientos de
seguridad son cubiertos (Cuando estos existen…)
 A menudo referido como “Negative Testing” (Verificar que cosas
malas no puedan suceder)
 Hace el producto lo que NO se supone que hace?
 Un programa que implementa correctamente todo lo que debería (Requerimientos
funcionales y operativos), puede seguir siendo inseguro debido a lo que “no se
debería” o “no se permitiría” y sigue estando latente en el propio software.
 Un usuario legitimo NUNCA utilizaría el producto tal como es usado
en muchos de los escenarios evaluados como parte de un test de
seguridad (Las personas que hacen testeo tradicional tampoco)
 Los responsables del test de seguridad, construyen patrones de
ataque en cambio de casos de uso.
 El testeador, no debería pensar en si mismo solo como un verificador
(QA approach) sino también como un atacante (attack approach).

Hunting Security Bugs
 Quienes?  Por que?

 Hackers/Researchers  Es divertido
 Security Hobbyists   Curiosidad
 Representa un desafio
 Crackers intelectual
 Software Vendor  Es trabajo
 Security Consultants  Puede ser un
requerimiento
 Para que?
 Hacer el software mas seguro
 Divertirse
 Obtener Conocimiento
 Ganar dinero
 Cumplir con un requerimiento
Hunting Security Bugs in the Enterprise
 Quienes?
 Equipo especial
 Por que?
 Es trabajo
 Puede ser un requerimiento
 Para que?
 Hacer el software mas seguro
 Cumplir con un requerimiento

Hunting Security Bugs in the Enterprise (Cont.)
 Conformación del Equipo de Trabajo
 Capacidad de resolución de problemas
 Inquietudes por encima del promedio
 Deseoso de saber por que ocurren las cosas / Curiosidad
 Pensamiento no convencional
 Competencias Técnicas + Dedicación + Perseverancia + Poder de Abstracción
 Un poco de mente criminal podría ser de utilidad 
 Ok… busque algo parecido a un hacker…
 Entrenamiento
 Cambio de mentalidad (Pensar como un atacante)
 Conocimiento de amenazas (vulnerabilidades)
 Conocimiento de ataques (Técnicas)
 Herramientas
 Motivación
 Diversión
 Desafío intelectual
 HiTech Gifts 
 Dinero

Metodología vs Caos
 Ventajas del trabajo metodológico
 Trabajo Ordenado
 Pocas posibilidades de pasar por alto un test
 Necesario en ciertos ámbitos
 Beneficia el trabajo en equipo
 Ventajas del Caos

 Mas propicio en ciertas circunstancias
 Puede ser bastante divertido
 Realmente puede ayudar a dar con bugs interesantes
 Guiado por la intuición
 Caos Metodológico

Que Buscar?
Information Disclosure
LDAP Injection
Spoofing Heap Overflows Format Strings
Weak Permissions Authentication Bypass
Shared Sections
ActiveX Repropoursing
Off-by-one
Stack Overflows
Weak Crypthography Path Traversal
XSS
Logic Errors XML Injection
SQL Injection Commands Injection
Design Flaws
Integer Overflows Canonicalization
Threat Modeling
 TM es un proceso que puede ser utilizado para:

 Hacerse una idea de cómo una pieza de código funciona
 Identificar el modo en que el software interactúa con sus
diferentes componentes.
 Conocer el flujo de datos.
 Identificar como entran y salen los datos.
 Enumerar posibles amenazas a la seguridad.
 Mandatorio en las fases de planeamiento y diseño

Threat Modeling for Bug Hunting
 Conformación del equipo

 Responsable del Diseño
 Responsable del Desarrollo
 Responsable del Testing
 Creación de modelos rápidos y sencillos, a partir de los

cuales sea posible:
 Enumerar puntos de entrada y salida
 Identificar vulnerabilidades
 Enumerar las potenciales amenazas
 Priorizar las tareas de testing

Threat Modeling for Bug Hunting (Cont.)
http://blogs.msdn.com/ptorr/archive/2005/02/22/378510.aspx

White Box, Black Box & Gray Box
 White Box
 Conocido en el mundo QA
 A menudo conocido como Clear Box, Open Box o Informed Testing
 Acceso a la documentación de diseño y código fuente
 Exhaustive Threat Modeling
 Line-by-line Code Review / Automated Code Review
 Ventajas
o Acceso directo al código y documentación!
 Black Box
 Examinación del aplicativo desde el punto de vista de un outsider
 Utilización de herramientas para relevar la superficie de ataque y probar puntos de
entrada
 Ventajas
o Partes del sistema no incluidas en la documentación
o Funcionalidades no documentadas
o Funcionalidades de último momento
 Gray Box (Nota: Utilice el Código Fuente siempre que se encuentre disponible)

White Box Testing: Code & Document Review
 Que es?
 Interviews
 Code Review / Source Auditing / Static Code Analisys
 Como se practica?
 Manual linear review
 Following the input
 Looking for know dangerous function
 Automated code review
 Tools
 vi / Notepad / Code Assistant
 Checklist, Políticas Internas, etc.
 RATS (RatScan frontend), ITs4, flawfinder, etc.
 SWAAT, OUNCE, Fortify SCA

White Box Testing: Code Review
string sql = "select status from Users where UserName

='" + txtUserName.Text + "'";
SQL Injection
SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn);

myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@userName", SqlDbType.VarChar,12); parm.Value=txtUid.Text;
select status from Users where UserName=@userName

White Box Testing: Code Review (Cont.)
Response.Write( Request.Form["name"] );
XSS
Response.Write( HttpUtility.HtmlEncode( Request.Form["name"] ) );

White Box Testing: Code Review (Cont.)
int check_login( char *name) int check_login( char *name)

{ {
int x = 0; int x = 0;
char small_buffer[10]; char small_buffer[10];
if (strcmp(name, “admin”) == 0) if (strcmp(name, “admin”) == 0)

x = 1; x = 1;
strcpy(small_buffer, name); strncpy(small_buffer, name,

sizeof(small_buffer) – 1);
return x; small_buffer[sizeof(small_buffer
} ) – 1] = ‘\0’;
return x;
BoF }

Black Box Testing
 Que es?
 Dynamic Analysis
 Sin Acceso al código fuente
 Con acceso al binario (Cuando esta disponible)
 Como se practica?
 Testing del Aplicativo en Ejecución
 Auditoría del Binario / Ingeniería Reversa
 Tools
 Disassembler, Debugger
 Analizador de Protocolos
 Editor Hexadecimal
 Fuzzers
 Herramientas Generales (Ej.: Sysinternals)
 Herramientas Específicas
Black Box Testing Approach
 Comprender en profundidad que es lo que se esta

testeando
 Pensar maliciosamente acerca del objetivo
 Atacar el objetivo aplicando ideas maliciosas 
 Permanecer informado acerca de nuevos ataques

Black Box Testing Methodology
 Information Gathering
 Antes de la Instalación
 Find Entry Points
 Durante la Instalación (Superficie de Ataque)
 Despues de la  Files
Instalación  Sockets
 HTTP Requests
 Named Pipes
 Testing  APIs
 Observación
 Registry
 Reverse Engineering
 User Interface
 Stress
 Command Line
 Function Hooking (MS Arguments
Detours)
 Environment Variables
 Cliente o Server Falsos
 Fuzzing / Fault Injection

Tools
 Find Entry Points
 TcpView
 Registry Monitor
 File Monitor
 Strings
 Editor Hexadecimal
 Analizador de Protocolos
 Debugger
 Process Explorer
 Oleview
 Netstat
 lsof
 Fuzzers (Ej.: Fuzzer 1.1, COMbust, COMraider, Autodafe, SPIKE )

 Debugger (Ej.: ollydbg / immunity)
 Python

Demo
 Hunting Bugs in Remote Services

Demo
 Hunting Bugs in ActiveX Controls

Conclusiones
 El software es inseguro
 Desarrolladores deben ser entrenados en cuestiones de
seguridad
 La seguridad debe ser considerada desde el inicio del
proyecto
 Traditional Testing = Security Testing
 Bug Hunting in The Enterprise es posible
 White Box / Black Box / Gray Box
 [Marketing Here]
o Haga lo fácil y deje a expertos hacer lo difícil
o Si si… en SIClabs (at SICinformática) hacemos esto…
 Bug Hunting es divertido
 Bug Hunting puede ser su próximo medio de vida
Bonus
 Y si me quedo sin trabajo?

 Tipping Point ZDI – Zero Day Initiative
http://www.zerodayinitiative.com/
 Verisign iDefense Vulnerability Contributor Program (VCP)
http://labs.idefense.com/vcp/
 Mercado Negro 
http://nolink

Referencias y Lectura Complementaria
 Threat Modeling
Frank Swiderski and Window Snyder
Microsoft Press - ISBN: 978-0735619913
 The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities
Mark Dowd, John McDonald and Justin Schuh
Addison-Wesley Professional - ISBN: 978-0321444424
 Hunting Security Bugs
Tom Gallagher, Lawrence Landauer and Bryan Jeffries
Microsoft Press - ISBN:978-0735621879
 The Art of Software Security Testing: Identifying Software Security Flaws
Chris Wysopal, Lucas Nelson, Dino Dai Zovi and Elfriede Dustin
Symantec Press - ISBN: 978-0321304865
 Guerrilla Threat Modelling (or 'Threat Modeling' if you're American)
http://blogs.msdn.com/ptorr/archive/2005/02/22/378510.aspx
 COMRAIDER
http://labs.idefense.com/software/download/?downloadID=23
 Fuzzer 1.1
http://packetstormsecurity.org/UNIX/misc/fuzzer-1.1.tar.gz
 Ollydbg
http://www.ollydbg.de

Hernán M. Racciatti – hracciatti@sicinformatica.com.ar
http://www.sicinformatica.com.ar – http://www.hernanracciatti.com.ar
Preguntas ?


Cazando Bugs de Seguridad en Enterprise

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Cazando Bugs de Seguridad en Enterprise

Caricato da

Copyright:

Formati disponibili

Hunting Security Bugs

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Analista Programador, CEH, MCP, ESR, NSP

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Las aplicaciones son liberadas al circuito comercial, a fin

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Quienes?  Por que?

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Ventajas del Caos

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 TM es un proceso que puede ser utilizado para:

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Conformación del equipo

 Creación de modelos rápidos y sencillos, a partir de los

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

string sql = "select status from Users where UserName

SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn);

select status from Users where UserName=@userName

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

Response.Write( HttpUtility.HtmlEncode( Request.Form["name"] ) );

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

int check_login( char *name) int check_login( char *name)

if (strcmp(name, “admin”) == 0) if (strcmp(name, “admin”) == 0)

strcpy(small_buffer, name); strncpy(small_buffer, name,

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Comprender en profundidad que es lo que se esta

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Fuzzers (Ej.: Fuzzer 1.1, COMbust, COMraider, Autodafe, SPIKE )

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Hunting Bugs in Remote Services

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Hunting Bugs in ActiveX Controls

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

 Y si me quedo sin trabajo?

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

2° Encuentro Internacional de Seguridad Informática – Manizales, Colombia 3,4 y 5 Octubre 2007

Potrebbero piacerti anche

int check_login( char name) int check_login( char name)