Post on 08-Jan-2017
¿Cómo
Consejos prácticos para crear aplicaciones seguras.
programaraplicacionesseguras?
Paulino Calderón Pale 2015
PaulinoCalderónPalecalderon@websec.mx@calderpwn
Seguridad en softwareLos errores en software pueden llegar a ser muy costosos:
¿Qué tal los errores de seguridad?
Bug en software de sistema antibloqueo de frenos le costó a Toyota un aproximadamente 3 billones de dólares americanos. (2009).
Bug en software de trading le costó a Knight Capital Group Inc. cerca de 400 millones de dólares americanos.(2012).
Costo de un bug de seguridad en software
En etapa de diseño: En etapa de pruebas (QA):
En producción:
+$10000 USD para arriba
$1500 USD
Impacto al negocio
$100 USD
• Es más rápido.• Es más barato. • No realizo ejercicios de revisión de
código.• Porque afecta la experiencia de
usuario.• No conozco de esos temas.• Tengo appliances de seguridad que
me protegen.• No tengo procesos que involucren
la seguridad.• Es más difícil …
¿Por qué hacemos
aplicaciones
inseguras?
El factor humano
“Think about how stupid the average person is, and then realize that half of them are stupider than that”
El factor humanoHecho: Somos humanos, nos
equivocamos... frecuentemente.
NASA olvida convertir unidades y ocasiona que el Climate Orbiter se pierda en el espacio. (1998)
Recordemos brevemente eventos del pasado:
El error del doble gotofail de Apple que permite realizar ataques de MiTM a millones de usuarios. (2014)
Goto fail - Cortesía de Apple
¿Qué tanto importa el lenguaje?
Realidad: Un programador sin conocimiento sobre programación segura SIEMPRE producirá código inseguro.
¿Qué tanto importa el lenguaje?Existen mecanismos de seguridad implementados en lenguajes que deben considerarse en base a los requerimientos de cada proyecto:
● Type-safe object oriented programming
● Safe memory management● Safe object construction● Smart pointers/Safe
pointers● Entre otros...
¿Es culpa del lenguaje?
Revisemos estadísticas de vulnerabilidades existentes en diferentes lenguajes de programación.
¿Qué nos dicen estos números?
PHP: 406 vulnerabilidades entre 2000-2015
http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74
Ruby: 44 vulnerabilidades entre 2007-2014
http://www.cvedetails.com/product/12215/Ruby-lang-Ruby.html?vendor_id=7252
ASP.NET: 10 vulnerabilidades entre 2003-2010
http://www.cvedetails.com/product/3091/Microsoft-Asp.net.html?vendor_id=26
PHP: Tipos de vulnerabilidades
Ruby: Tipos de vulnerabilidades
ASP.NET: Tipos de vulnerabilidades
1. Muchos productos son una combinación de lenguajes y tecnologías.
2. Bases de datos como CVE no tienen registro de todas las vulnerabilidades.
3. A veces también los frameworks de desarrollo tienen vulnerabilidades.
4. Existen muchas más vulnerabilidades en implementaciones (no lenguaje).
Los números no necesariamente reflejan la realidad:
000101010111011100000011111101010101000001010101010101010101010100000001010101110111000000111111010101010000010101010101010101010101000000010101011101110000001111110101010100000101010101010101000010101011101110000001111110101010100000101010101010101010101010000000101010111011100000011111101010101
¿Importa el lenguaje de
programación?
000101010111011100000011111101010101000001010101010101010101010100000001010101110111000000111111010101010000010101010101010101010101000000010101011101110000001111110101010100000101010101010101010101010000000101010111011100000011111
Seguridad en software web y movilExisten controles de seguridad que hacen más robustas a nuestras aplicaciones:
• Autenticación• Autorización• Manejo de sesiones• Validación de datos• Auditoría y bitácoras• Criptografía• Ambiente de desarrollo• Canales de comunicación• Almacenamiento seguro
¿En qué nos estamos equivocando?
Creemos todo lo que leemos en internet
No confíes en extraños
(*) http://www.websec.mx/blog/ver/inseguridad-datos-sesion-codeigniter
● Malos consejos de seguridad hasta en sitios oficiales de proyectos.
● Un ejemplo, el popular framework Codeigniter distribuye la siguiente configuración por default. >>
Buenas prácticas
Siempre revisen lo que instalan.
No confien en configuraciones default.
Hashes de verificación de integridad de archivos críticos de la aplicación.Algún HIDS, solución casera en Bash, tripwire, etc.
No sigan guías sin cuestionar las prácticas de seguridad.
Implementar mecanismos de autenticación o autorización es
complicado
Utilizar frameworks no garantiza
seguridad
Existen muchas implementaciones inseguras. De nuevo no es el framework, es la
implementación.
● oAuth es un framework de autorización.
● OpenID es un framework de autenticación.
Utilizar frameworks no garantiza
seguridad
La vulnerabilidad Cover Rdirect está clasificada
como wontfix en muchos sitios.
¿Como es una buena
implementación?
Una buena implementación de autenticación y autorización:● Registra todas las actividades de
los usuarios sin revelar información privada.
● Verifica el origen, validez y expiración de sesiones.
● Genera alertas en caso de actividad sospechosa (Cuenta bloqueada por superar intentos de inicio de sesión, etc.).
● Tiene mecanismo de protección contra ataques de fuerza bruta.
● 2 factor auth (Si es requerida).● Autoriza el acceso a cada
recurso solicitado.
No aprendemos a validar datos
Validación de datos
Todos sabemos que debemos validar datos y sin embargo las
mismas vulnerabilidades siguen existiendo.
Validación de datos
La regla es muy simple:NO CONFIEN EN NINGÚN DATO DE
ENTRADA MANIPULABLE
● No usen listas negras. ● Usen los mecanismos de validación
disponibles en los frameworks pero no dependan de ellos completamente.
● Prueben sus expresiones regulares.● Monitoreen todos los puntos de entrada
Buenas prácticas
[20/01/2015 01:00:05] Fallo de inicio de sesion con usuario ‘admin’ y password ‘Administrad0r20’[20/01/2015 01:00:09] Fallo de inicio de sesion con usuario ‘admin’ y password ‘Administrad0r201’[20/01/2015 01:00:15] Inicio de sesion exitosa de usuario ‘admin’
Guardamos información
de más
+
O no guardamos
nada
[20/01/2015 04:00:05] La aplicación tuvo un error. Origen de conexión: 127.0.0.1[20/01/2015 04:00:09] La aplicación tuvo un error. Origen de conexión: 127.0.0.1[20/01/2015 04:00:15] La aplicación tuvo un error. Origen de conexión: 127.0.0.1
(IN)seguridad en bitácoras
Muchas veces los desarrolladores no piensan en los riesgos:
● Cualquier aplicación puede acceder a las bitácoras del sistema Logcat (Android).
● Bitácoras comprometidas a través de vulnerabilidades en aplicaciones web.
Aplicaciones móviles y web revelan información sensible en bitácoras:
● URLs de servicios, endpoints, APIs, etc.
● Credenciales de acceso a servicio.
● Nombres de variables de datos de entrada.
● Datos de usuario.● Trazas de error.
• Almacenar las bitácoras en otro dispositivo diferente de donde se corre la aplicación.
• Almacenar la información mínima necesaria para diagnosticar un problema. Incluir funcionalidad para generar trazas más completas.
• Comprobar que las bitácoras están siendo registradas correctamente.
• Desarrollar agente que envíe la información al corelacionador de bitácoras de la empresa (Si lo tienen).
Buenas prácticas
CryptoLa criptografía es difícil.
Si no han estudiado el tema, ¡No escriban sus propias funciones criptográficas!
Dejen ese trabajo a los EXPERTOS.
Sony’s ECDSA code
Volviendo brevemente al tema de confiar en extraños...
Lo que sí debe saber un desarrollador sobre criptografía como mínimo
● Diferencia entre criptografía asimetrica y simetrica.
● Diferencia entre métodos de cifrado.● Uso de políticas seguras para contraseñas y
passphrases. ● Estándares modernos de criptografía. www.keylength.com● Conocer las librerías robustas de criptografía
disponibles para su ambiente de desarrollo.
Hecho: La mayoría de aplicaciones inseguras no realizaron ejercicios de revisión de código fuente.
Software Testing
Tenemos hasta un día internacional dedicado al debugging...Literalmente encontraron un bicho pegado a la hoja de un programa.
Premio: ¿Qué fecha es el día internacional de debugging?
Programas bug bounty
Programas donde se ofrecen recompensas por encontrar bugs de seguridad.
Algunas empresas que han implementado este programa exitosamente:● Google● Facebook● Microsoft ● Otros muy interesantes como Internet Bug Bounty (https://internetbugbounty.org) dan recompensa por encontrar bugs en productos como Apache, Ruby, Python, PHP, entre otros).
Programas bug bounty
¿Podrían implementarlo en su empresa o lugar de trabajo?
Software testing
Unit testing aunque sea muy tedioso es una herramienta
invaluable para construir software seguro.
Necesitamos integrar a nuestro SDLC ejercicios de análisis estático y dinámico
Integration testing
Si automatizamos los procesos de ‘integration testing’ lograremos detectar muchos problemas.
Por ejemplo Jenkins puede ser utilizado en proyectos hechos en Java, ASP.NET, Perl y Python.
Softwarefuzzing
Automatizar pruebas al software con datos de entrada aleatorios y mal formados. El objetivo es analizar el comportamiento de la aplicación bajo diferentes datos de entrada mal formados.
Algunos fuzzers públicos:● spike● antiparser● Afl● Sulley● Melkor
!Para mejores resultados construyan los suyos!
Herramientas de análisis estático de código● Veracode● Source Code Analysis de
HP/Fortify● PVS-Studio● Security Advisor (Coverity)● Checkmarx● CLANG (C/C++/Obj-C)● Brakeman (Ruby)● Infer (Java, Obj-C)
Clang
Analizador estático de código para C/C++/Obj-C
● Encontrando heartbleed con Clang:http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/
Otros proyectos interesantes basados en Clang:● Xsecurityhttps://github.com/XSecurity/XsecurityIntegración con Xcode para detectar vulnerabilidades en aplicaciones iOS.● Inferhttps://github.com/facebook/inferAnalizador estatico de código para aplicaciones mobiles Android e iOS.
Infer
Analizador estático de código desarrollado por Facebook para Java,
C y Obj-C.
Descarga: https://github.com/facebook/infer
Infer
Grep para analizar
códigoGrep es nuestro amigo. Por ejemplo podríamos
utilizar algo como:
$grep –R –n –A3 –B3 –i ’$_GET\|$_POST’ .
En ambientes Windows: File Locator Lite
Análisis de código gratis
Websec tiene una base de datos con listas de nombres de funciones ‘peligrosas’ divididas por lenguaje de
programación (JAVA, RUBY, PHP, Python)
InsecureProgrammingDB https://github.com/cldrn/InsecureProgrammingDB
Adversidades para analizadores de código
● Metaprogramming puede complicar el proceso de auditoría de código fuente..
● Diferencias entre lenguajes de programación
Otras herramientas
● Navegadores de código fuente.● Seguridad de binarios
Ya hablamos de herramientas, pero ¿qué tal los procesos?
¿Por qué hacemos
aplicaciones inseguras?
La ausencia de procesos de negocio que respalden la seguridad siempre llevará a la creación de código inseguro.
La seguridad debe ser planeada desde el principio e integrada en la arquitectura de la aplicación.
Thread modeling
Método para analizar la seguridad de una aplicación que permite identificar, evaluar y mitigar los riesgos relacionados con la aplicación.
Retos al realizar
thread modeling
● No se conocen a fondo los procesos involucrados.
● No se conocen los riesgos.● Difícil asignar importancia si
se desconoce el nivel de explotación requerido.
Thread modeling en tu organización
1. Entiende tu aplicación.2. Identifica las amenazas.3. Desarrolla las medidas de
protección y mitigaciones.
Seguridad en el ciclo de vida de desarrollo de software● Evaluar el riesgo de nuevas aplicaciones.● Investigar requerimientos necesarios para tratar la
información según su sensibilidad.● Elaborar una guía de buenas prácticas a las que
todos deben apegarse.● Periódicamente evalúa y actualiza esa guía de
buenas prácticas.● Entrena a los programadores a tomar talleres técnicos
de programación segura en el entorno de trabajo.● Incluye aspectos de seguridad en evaluaciones de
QA.
Seguridad en el ciclo de vida de desarrollo de software
Herramientas pueden ayudar pero necesitan a una persona con conocimientos en seguridad informática en el equipo para validación.
Es importante no usar solo una herramienta.
REQUERIMIENTOS:Documentar/Identificar los requerimientos de seguridad del proyecto.Análisis de riesgo.
DISEÑO:Thread modeling.
DESARROLLO:Implementar mejores prácticas.Análisis estático de código.
TESTING:Análisis dinámico de la aplicación.Fuzzing.Análisis de vulnerabilidades.
DEPLOYMENT:Revisión de configuración de seguridad de aplicación y servidor.
Seguridad en el
entorno de desarrollo
La seguridad comienza desde nuestras casas. Es decir, nuestros ambientes de desarrollo.
Auditando las llaves públicas de todos los usuarios de Github:https://blog.benjojo.co.uk/post/auditing-github-users-keys
¿Qué aprendimos hoy?
Si quieren crear aplicaciones seguras deben:● No confien en extraños.● No confien en ningún dato de entrada manipulable. ● No confien en frameworks ciegamente. ● No implementen sus propias funciones de criptografía (A menos
que sean expertos en crypto).● Inviertan en entrenamiento sobre programación segura.● Almacenen sus bitácoras de forma segura. ● Verifiquen su sistema de autenticación y autorización.● Realicen ejercicios de auditoría de código. ● Consideren a la seguridad en su ciclo de desarrollo de software.● Consideren implementar un programa de recompensa por
reportar bugs.● No usen una sola herramienta.