Conferencia presentada por Héctor Paredes en SG Next.

1. Ya eres parte de la evolución
Liquid Day
La importancia del desarrollo
seguro de aplicaciones
¿Por qué debo pensar como hacker?
Héctor Paredes
@heryxpc
#sgnext

2. Agenda
• Introducción
• ¿Qué es una vulnerabilidad?
• Situación actual
• Vulnerabilidades en aplicaciones
• Vulnerabilidades famosas
• Vulnerabilidades comunes
• Ejemplos
• Buenas prácticas

3. Objetivo
● Concientizar en la
importancia de la
seguridad en
desarrollo de
Software.
● Presentar consejos
para hacer software
más seguro.

4. TEN MIEDO...

5. ¿Qué es una vulnerabilidad?
● Vulnerabilidad es un error
de software (bug) que
puede ser directamente
usado por un hacker para
ganar acceso o dañar a un
sistema.
Fuente: https://cve.mitre.org/about/terminology.html - Common Vulnerability and Exposure
dictionary, MITRE, 2016

6. Situacion actual- ¡CRISIS!
● Las vulnerabilidades y amenazas han ido en aumento.
● Hay mayor cobertura mediatica.
− Lo que le paso a Sony, http://fortune.com/sony-hack-part-1/
− Tu contraseña de LinkedIn está en la nube,
http://motherboard.vice.com/read/another-day-another-hack-117-
million-linkedin-emails-and-password,
https://haveibeenpwned.com/
− ¿Algo más local?, ¡A hackear la democracia en LatinoAmerica!,
http://www.bloomberg.com/features/2016-como-manipular-una-
eleccion/
Fuente:CVE-Details http://www.cvedetails.com/browse-by-date.php

7. ¿Qué estamos haciendo?
El utilizar equipos especializados, herramientas, pruebas de
penetración es de gran ayuda...pero nada es infalible.
Fuente: FireEye Mandant M-Trends 2016, f, https://www2.fireeye.com/rs8/48-DID-
242/images/Mtrends2016.pdfhttps://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/Infographic-
mtrends2016.pd
• Los ambientes sufren
cambios.
• Existe el factor humano.
• Hay muchas vertientes de
ataque.
• Confiar en la seguirad
perimetral

8. Vulnerabilidades en las aplicaciones
● Ponle un nombre Fancy!
● Hearthbleed - http://heartbleed.com/
● Error en el proceso de hearbeat para
mantener la conexión TLS viva en OpenSSL
que permitía leer secciones de memoria
donde existian nombres y llaves de acceso
de los servicios con tráfico encriptado.
● Pudo ser evitado por medio de pruebas
unitarias y análisis estático. *
* Fuentes: Goto Fail, Heartbleed, and Unit Testing Culture, Bland Mark,MartinFowler.com, 03 Junio 2014,
http://martinfowler.com/articles/testing-culture.html
The Roles of Static Analysis in Heartbleed, Saas Jeef, SANS Institute, 12 Febrero 2015 https://www.sans.org/reading-
room/whitepapers/threats/role-static-analysis-heartbleed-35752

9. Vulnerabilidades en las
aplicaciones
● Ghost - https://itservices.uchicago.edu/page/ghost-
vulnerability
● Error en una libreria de Glibc en las funciones
gethostbyname*() que, por medio de un bufferoverflow
permiten sobreescribir secciones de memoria que, a su
vez, permitian ejecutar código dentro de una aplicacion
compilada con GCC que usara glibc-2.2

10. Las Vulnerabilidades más comunes
(y explotadas)
● El CWE / SANS 25 (2011)
● Contiene información relacionada de errores
comunes de programación con vulnerabilidades
explotadas. https://cwe.mitre.org/data/lists/900.html
https://www.sans.org/top25-software-errors
● La OWASP (2013, pronto 2016/2017)
● Es practicamente un estandar para la seguridad en
internet.
● Lista los 10 riesgos web más críticos.
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
● Hybris Wiki tiene un sitio de como evitar las vulnerabilidades documentadas
de OWASP
• https://wiki.hybris.com/pages/viewpage.action?spaceKey=hybrisALF&title=The+OWASP+
Top+Ten+Recommended+Protection+Practices+for+Hybris

11. Ejemplos
● Buffer Overflow
● Escribiendo en lugares de memoria donde no debes.
● Se da regularmente por no validar el tamaño de de la
información que se esté recibiendo en una función con
manejo de memoria. (cambiando el valor de variables,
haciendo llamadas a otras funciones, tirando un
programa o servicio = DOS)
• https://www.owasp.org/index.php/Buffer_Overflows
%08x.%08x.%08x.%08x.%08x.%
08x.%08x.%08x.%08x.%08x.%0
8x.%08x.%08x.%08x.%08x.%08
x.%08x.%08x.%08x.%08x.%08x.
%08x.%08x.%08x.%08x.

12. Ejemplos
● XSS Cross Site Scripting
● Permite introducir código en la aplicación,
redireccionando al usuario a sitios maliciosos donde
pueda aprovecharse la legitimidad de la aplicación para
obtener información privada o sensible.
● Se da regularmente por no validar correctamente
información de entrada del usuario.

13. Ejemplos
● SQL Injection
● Permite utilizar consultas SQL 'inyectadas' a la
aplicación para obtener o modificar información en
una base de datos.
● Es muy comun cuando generamos las consultas con
información provista por el usuario sin validar los
parametros de entrada.

14. Prácticas
● Usar las últimas versiones de software /
bibliotecas en el desarrollo.
● Los gestores de dependencias (maven, gradle, npm)
son una herramienta muy util para ello.
● Validar que las librerias y herramientas que
usamos vienen de fuentes confiables
● Encriptar las contraseñas...y guardarlas
encriptadas.

15. Prácticas
● Pensar el daño que puede causar las fallas en mi
software.
● Las pruebas unitarias, revisiones de código, el
análisis estático son herramientas que están para
ayudarnos en fases tempranas a detectar posibles
vulnerabilidades.
● Las librerias pueden contener vulnerabiliades,
llevar un control de las versiones.

16. Prácticas
● No usar contraseñas por default en ambientes
productivos.
● El CERT - SEI (Universidad de Carnegie Mellon)
tiene una serie de estándares para el código
seguro en Java, C, C++, Perl y Android.
● https://www.securecoding.cert.org/confluence/display/java/SEI+CERT+Oracle
+Coding+Standard+for+Java
● Utilizar herramientas como Sonar o Findbug
pueden ayudar a encontrar errores simples.

17. Gracias
hparedes@tacitknowledge.com