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

Paulino Calderón Palecalderon@websec.mx @calderpwn

¡Gracias!