TICS413 - Seguridad en TICs

Seguridad de Software
Andrés del Villar León
Ciclo del Software

Integración y Operación y
Requisitos Diseño Implementación
pruebas mantenimiento

Vulnerabilidades de Vulnerabilidades de Vulnerabilidades de

Diseño Implementación Operación

Vulnerabilidades de Diseño

• El software no es seguro a pesar que hace la

tarea para el cual fue diseñado, pero su
diseño no es el adecuado.
• Se debe tener cuidado con los supuestos que
se hagan en los ambientes o en las
interacciones que tiene.
Ventanas de Oportunidad

• Tiempo de Chequeo vs Tiempo de Uso

(TOCTOU)
• Normalmente se presentan en operaciones de
acceso a archivos, en situaciones donde se hace
validación primero y luego de acceso.
• Son difíciles de eliminar.
• Se recomienda realizar operaciones atómicas
y utilizar el chequeo de errores en vez de la
validación.
Uso de componentes vulnerables

• El desarrollo actual se basa en unir diferentes

piezas como si se tratara de un Lego.
• Así como se protege el software que se
desarrolla, es necesario asegurar que los
componentes que se usen estén protegidos.
• Tener en cuenta que ocurre con el soporte.
Exceso de confianza en las bibliotecas

• Son útiles para realizar tareas y no reinventar

la rueda.
• Cuidado: También son vulnerables.
• Usualmente no se verifican las versiones ni
las vulnerabilidades.
Exceso de confianza en frameworks

• Algunos frameworks conocidos: Ruby on

Rails, Django, NodeJS, Android SDK, iOS SDK,
etc...
• ¿Tienen documentación de seguridad?
• Pensamiento mágico:
• ”No, si el framework trae seguridad integrada, no
es neceario preocuparse de nada”
Exceso de confianza en CMS

• Ej. Wordpress, Drupal, Joomla…

• ¿Qué consideraciones de seguridad hay que
tener en cuenta?
• ¿Les hacemos un cariñito de vez en cuando?
Exceso de confianza en paneles de
control

• Ej. CPanel, PHPMyAdmin

• Muy utilizados en servicios de hosting
• Excesiva cantidad de privilegios
• Frecuentemente en entornos https sin
protección
No uso de mecanismos de cierre

• Puede ser una invitación a utilizar ataques

automatizados de fuerza bruta, o aún peor,
DoS
• Consejos
• Nivel de corte: bloquear temporalmente la
cuenta del usuario (¿después de cuantas veces?)
• Logear la IP de donde provienen las peticiones
múltiples, bloquearlas o filtrarlas.
• Utilizar throttling
Acceso directo a activos
Vulnerabilidades de Implementación

• Generalmente el software se comporta como

debería, pero hay un problema de seguridad
en la forma en como lo hace.
• Ejemplos:
• Números aleatorios de Kerberos
• Gusano de Morris
Buffer Overflow

• Se rebalsan los registros de memoria con lo

cual se desvía la ejecución hacia código inútil
o malicioso
• Importante controlar y manejar las entradas.
Cross Site Scripting (XSS)

• Clásico ataque a páginas web.

• Inserción de código que permite ejecutar
código que se encuentra en otra ubicación
como si estuviera en el servidor original.
• Basa su éxito en la confianza que tiene el
usuario en el sitio en el que está navegando.
SQL Injection

• Otro clásico de los ataques.

• Inyección de código que permite obtener
información de la base de datos, o ejecutar
instrucciones del tipo DML o DDL.
• Objetivos:
• Obtener información confidencial
• Ingresar datos maliciosos
• Tomar control de la base de datos
Vulnerabilidades Operacionales

• Surgen con el uso del software.

• Están más relacionadas con la interacción del
software con su ambiente de ejecución que
con el código fuente.
• Normalmente se presentan como
configuraciones inseguras.
Configuraciones Inseguras

• Usuarios y contraseñas por default:

• Oracle:
• scott/tiger
• sys/change_on_install
• system/manager
• Acceso remoto utilizando la cuenta root.
• Instalación de todo el software con cuenta
root.
Configuraciones Inseguras

• Recomendaciones
• Cambiar contraseñas por default
• Nunca permitir que root se pueda conectar de
manera remota
• Crear cuentas para instalar los sistemas.
• Asignar los mínimos privilegios.
• Tener un checklist para verificar que todos los
puntos vulnerables fueron revisados y
configurados correctamente.
Interacciones Inseguras

• Vulnerabilidades en el software:
• Sistema operativo
• Bibliotecas
• Software Base
• Supuestos al usar o interactuar con otro
software.
• Comunicación vía canales no seguros
Interacciones Inseguras

• Cambios en el ambiente
• Fallas en el control de acceso
• Recomendaciones
• Parchar, parchar, parchar
• Tener diagramas de interacción entre los
componentes de un sistema.
Defacements

• Modificación maliciosa del contenido de

sitios web
• Aprovechan
• CMS sin soporte
• Vulnerabilidades en las plataformas
• Webshell
Passwords

• Aprovechar las debilidades de las passwords

o su almacenamiento en servicios.
• Los métodos más comunes son:
• Ataques de fuerza bruta
• Ataques de diccionario
• Tablas arcoiris
Extracción de información

• “Password incorrecta” o “Usuario no existe”

• “Página no encontrada” vs ”Usted no está
autorizado a ver esta información”
• Errores que entreguen información de las
rutas completas a archivos.
• Errores de base de datos (normalmente con
códigos SQL incluidos).
Negación de Servicio (D)DoS

• Saturar artificialmente los recursos de un

sistema con diferentes tipos de llamadas.
• DoS: Una única máquina saturando un
sistema.
• DDoS: Varias máquinas diferentes saturando
un sistema.
• Objetivo: Evitar que el servicio responda
peticiones legítimas.
DDoS Casuales

• Se producen por una mala planificación de los

recursos necesarios para atender una
demanda.
• Caso típico: Black Friday, Venta de Tickets en
espectáculos de alta demanda.
Filtración por abandono

• Se dejan olvidados en el sistema recursos

utilizados durante la fase de desarrollo.
• Casos típicos:
• Archivos utilizados en el proceso de desarrollo
• Funciones o código de debugging activo.
Exceso de información en los logs

• Se almacena información sensible en los logs

para seguimiento futuro
• Casos típicos:
• Rut y número de serie del CI
• Número de tarjeta de crédito, fecha de
vencimiento, eventualmente el CVV
¿Qué pasa con el OpenSource?

• Normalmente desarrollado por voluntarios,

aunque algunos cuentan con soporte de
organizaciones.
• La seguridad es costosa de implementar y
probar, y no permite incorporar nuevas
funcionalidades con rapidez.
• Ante una vulnerabilidad nueva, ¿con qué
velocidad se cierran los hallazgos?
¿Qué pasa con el OpenSource?

• Si se debe aplicar una corrección de

seguridad y el sistema no funciona, ¿Quién
me da soporte?
• Se puede usar, definitivamente, pero requiere
de una estrategia de actualización frecuente.
Caso: Heartbleed

• Afectó OPENSSL (específicamente a la versión

de OPENSSL 1.0.1), rutina de cifrado
ampliamente utilizada.
• Permitía tener acceso a toda la información
que iba supuestamente protegida por el
cifrado.
 Problemas de OpenSSL

• Mantenido sólo por 4 personas (uno de ellos

full time)
• Mayor interés en incorporar nuevas
características.
• No se incorporan las correcciones enviadas
en el repositorio del código.
• Los bugs se “pudren” en el issue tracker
(hasta 4 años)
Bob Beck: “LibreSSL - An OpenSSL replacement”
¿Por qué es difícil hacer software
seguro?

• Interconectividad
• Extensibilidad
• Complejidad
Interconectividad

• Mayor cantidad de dispositivos conectados a

la red.
• Más servicios online, mayor exposición a ser
atacados desde cualquier parte del mundo.
• Consumo de servicios específicos, por
ejemplo, clave única, puede generar una
vulnerabilidad si el consumidor no está bien
protegido.
Extensibilidad

• Uso de plugins para extender funcionalidad,

fuera de control para el desarrollador.
Complejidad

• El software tiende a
crecer en líneas de
código.
• Mientras más líneas
de código más
posibilidades de
bugs.
¿Porqué los buenos desarrolladores
escribimos mal código?

• Factores Psicológicos.
• Programar es una actividad difícil y frustrante.
• Nunca debemos confiar ciegamente en el código
de otro (pero que pasa cuando desconfían de mi
código)
• Generalmente se aborda la “ruta feliz”
• Los chicos buenos tienden a descansar en la
abstracción … los chicos malos en los detalles
 Prioridades para los desarrolladores

• Funcionalidades (Requisitos hecho realidad)

• Rendimiento
• Usabilidad
• Uptime
• Mantenibilidad
• Seguridad

John Wilander, “Security People vs Developers”

Como asegurar el software
Validar agresivamente

• La principal fuente de problemas y vector de

ataque son los inputs de los usuarios:
• SQL Injections
• Shell Injections
• NOSQL Injections
• Cross-Site Scriptions
• CSRF
• ORM Injections
Manejo de errores

Información sensible
¡EXPUESTA!
KISS = Keep It Simple, Stupid

• Si no necesitas esa función, no la

implementes.
• Más simple => menos cosas pueden fallar, y si
fallan es más fácil descubrirlas y repararlas
Almacenar secretos en forma adecuada

• Guardar passwords usando KDF’s

• Implementar controles de acceso a
documentos sensibles
• Respaldando usando criptografía
• Compartimentalizando: no permitir el acceso
indiscriminado a los datos por parte de las
personas de la organización
Compartimentalización

• Modularizar a fondo.
• Ojo con los recursos compartidos
• Passwords
• Privilegios
• Usuarios
• Grupos
• Datos
• Cuidado con los equipos de desarrollo de
software
Limitar los recursos consumidos

• Protegerse contra la fuerza bruta.

• Clipping: cierre de la cuenta después de X
intentos de login
• Throttling: por cada intento se disminuye el
ancho de banda disponible
• Devolver cada uno de los recursos que se
utilizan:
• Archivos, conexiones a base de datos, etc.
Utilizar componentes conocidos

• No reinventar la rueda.
• No crear algoritmos criptográficos caseros.
• Los componentes conocidos permiten reducir
tiempo y costos.
• Pero…
Estar alertas a vulnerabilidades

• Nada asegura que los componentes utilizados

no tengan vulnerabilidades.
• Irrelevante si son cerrados o de código abierto
• Si no tenía vulnerabilidades al momento de
instalarse en producción, es posible que las
tenga en el futuro.
• Suscribirse a fuentes de avisos de alertas de
seguridad y tener claro los componentes
utilizados.
Soportar todo el software

• El desarrollado internamente o el
desarrollado por terceros.
• Revisar constantemente en busca de
vulnerabilidades o suscrito a avisos.
• Corregir las vulnerabilidades
• Corregirlo nosotros
• Aplicar parches
• Reemplazar el software
Seguridad en el transporte

• Usar SSL/TLS sobre todo en las páginas de

logeo de aplicaciones o sitios web.
• SSL/TLS siempre, en aplicaciones internas y
externas.
• Los certificados digitales no son tan caros.
• Ojo con las versiones de SSL/TLS que se
utilizan
Seguridad por capas

1;DROP TABLE users

Validación de Entradas

Sanitización de Entradas

Establecer Permisos para cuentas a nivel de Base de Datos

No confiar en los secretos
Ojo con los privilegios
Revisar siempre el acceso a recursos

• Una dirección se puede

modificar en la basrra de URL’s y
descubrir información:
• Documentos generados
• Información de configuración
• Respaldos del sitio web
incluyendo contraseñas
Asegurar configuraciones

• Ojo con las configuraciones por default.

• Credenciales
• Puertos abiertos
• Módulos innecesarios
• Consolas de administración (ej: PHPMyAdmin)
• Timeout de sesiones inadecuado
• Auditar y remover todo lo que no es
necesario.
Acordarse de los usuarios

• Hacer la interfaz de usuario simple y clara

• Definir seguridad base y permitir flexibilizarla
• No apurar al usuario
• Evitar el uso de diálogos modales
• Permitir revertir la acción más reciente
 ¿Cómo asegurar el software?

Código Fuente Binarios/Ejecutables/Servicios

Pruebas de Código Pruebas de Penetración
Pruebas de Caja Blanca “White Box” Pruebas de Caja Negra “Black Box”
Ethical Hacking

Pruebas internas Software Pruebas externas

Pruebas internas

• Conocida también como análisis de caja

blanca.
• Se revisa el código, configuraciones, diseño
en búsqueda de vulnerabilidades basado en
la arquitectura del sistema.
Análisis Estático (SCA)

• Objetivo:
• Identificar vulnerabilidades en el código sin
ejecutarlo.
• Los defectos se corrigen, en general, en
tiempo de compilación.
• Las vulnerabilidades puedes estar durmiendo
por años.
SCA Humano

• Búsqueda:
• Puntos en el programa en los cuales recibe input
del usuario
• Puntos en el programa en los cuales recibe input
de alguna otra fuente no confiable
• Síntomas de problemas (Vulnerabilidades
inherentes a código)
• Evaluación:
• ¿Es este punto del programa una vulnerabilidad?
SCA Humano

• Limitaciones
• Proceso aburrido, tediosos, difícil y propenso a
errores.
• Se requiere mucho conocimiento acerca de
seguridad de software (y paciencia)
SCA Automatizado

• Analiza software sin intentar ejecutarlo

• Analiza código fuente y, a veces, binarios
• Ventajas:
• Aplica chequeos en forma consistente y a fondo
• Al examinar el código, apunta a la causa de la
vulnerabilidad en vez de a sus síntomas
• Puede encontrar errores temprano en el desarrollo
• Al momento del análisis de vulnerabilidad, permite el
análisis rápido de mucho código
SCA Automatizado

• Limitaciones
• Seguridad 100%, ¿se acuerdan?
• Aún dan por el orden de 10% de falsos positivos
• A veces el desarrollador debe adaptarse al SCA más
que viceversa
• Una herramienta automatizada puede ser rápida,
buena, barata. Elija sólo 2.
SCA: Herramientas

• RATS, Flawfinder (C, C++, PHP, Python...)

• Findbugs + Find Security Bugs (Java)
• FXCop (.NET, desactualizada)
• Brakeman (Rails)
• DjangoSCA (Django – Python)
• PHP Code Sniffer + phpcs-security-audit
• JSPrime (NodeJS y otros frameworks JS)
• Fortify, Veracode (Multilenguaje)
Pruebas Externas

• Conocido como análisis de caja negra

• Se tiene acceso a los binarios, a la aplicación en
funcionamiento pero no al código.
• Buscan identificar vulnerabilidades en el
comportamiento de la aplicación
Scanner

• Es una herramienta que intenta inducir fallas de

seguridad ingresando valores aleatorios o
predefinidos a la aplicación
• Cómo funciona:
• Identifica las fuentes de entrada para el software
• Genera entradas maliciosas
• Monitorea posibles fallas
• Reporta las fallas encontradas
¿Qué se puede escanear?

• Entradas de usuario desde web (peticiones GET,

POST...)
• Entradas desde linea de comando para
programas
• Archivos “crafteados” (PDF, Office, XML...)
• Expresiones Regulares
Desafíos a la hora de escanear

• ¿Cuándo se puede considerar que un scanner

lleva corriendo el tiempo suficiente?
• ¿Qué pasa si el scanner ya terminó de correr y no
encontramos fallas?
• Ya, encontramos la falla. Ahora, ¿dónde la
corregimos?
• ¿Cuándo terminamos de escanear la app?
Scanners disponibles

• Archivos, Expresiones Regulares

• SDL MiniFuzz, SDL Regex Fuzzer
• Web
• Acunetix, OWASP ZAP, W3AF, Websecurify, Nikto,
SQLMap, Subgraph Vega...
• Móvil
• Android: Intent Fuzzer, Monkey
• iOS: ZZUF, Sulley
OWASP ZAP

• Permite escanear aplicaciones web en base a las

vulnerabilidades establecidas en el OWASP Top
10
• 2 modos de operación:
• Rápido: Apuntar y escanear
• Proxy: Intercepta peticiones HTTP y “aprende” el
mapa del sitio. Ideal para escaneos de áreas
autentificadas.
wpscan

• Permite escanear sitios WordPress en busca de

vulnerabilidades:
• En el servidor
• En la versión misma de la plataforma
• En los plugins instalados
SQLMap

• Herramienta que permite automatizar el proceso

de descubrimiento de SQL Injections en
aplicaciones
• Permite:
• Obtener dumps
• Enumerar usuarios, privilegios, tablas...
¿Qué hacer si llega un reporte de
vulnerabilidad de mi software?

• Tener un plan de mitigación

• Como evito que una vulnerabilidad se presente en mi
sistema, reduzco la posibilidad de explotación o la
resuelvo en corto plazo.
• Tener un plan de respuesta a incidentes
• Que hago mientras el incidente se encuentra en
curso.
Plan de mitigación

• Mantener al equipo de desarrollo educado en

seguridad del software.
• Tener un equipo de respuesta a incidentes.
• Darle soporte a todo el software.
• Preocuparse que el diseño permita al software
actualizarse.
• Anticiparse. Buscar constantemente vulnerabilidades
en el software y encontrarlas antes que un tercero.
Plan de mitigación

• Mantener al equipo de desarrollo educado en

seguridad del software.
• Tener un equipo de respuesta a incidentes.
• Darle soporte a todo el software.
• Preocuparse que el diseño permita al software
actualizarse.
• Anticiparse. Buscar constantemente vulnerabilidades
en el software y encontrarlas antes que un tercero.
Respuesta a incidentes

Creación del Pruebas del

parche parche
Publicación del
Recepción Triaje
parche
Manejo de relación Creación de
con el denunciante contenido
Lecciones
aprendidas
Consideraciones

• Todos los mails a security@micompañía.cl deben ser

monitoreados
• A la hora del triaje utilizar herramientas de análisis de
riesgos
• Se recomienda fomentar la divulgación responsable
Como determinar el riesgo

Riesgo = Posibilidad x Impacto

OWASP Risk Rating Methodology

• Es una metodología directamente aplicada a

seguridad de software
• En ella se basan para generar el OWASP Top 10
• Permite cierta flexibilidad, al separar impacto técnico
del impacto de negocio
OWASP Risk: Posibilidad

• Factores de Agentes Amenazantes

• Nivel de habilidad de los agentes amenazantes
• Motivación: ¿Cuál es su recompensa?
• Oportunidad: Qué recursos y acceso tienen a su disposición
• Tamaño: ¿Cuántos son los potenciales atacantes?
• Factores de Vulnerabilidad
• Facilidad de descubrir la vulnerabilidad
• Facilidad de explotar la vulnerabilidad
• ¿Cuán conocida es la vulnerabilidad?
• ¿Es detectable (logueable) el ataque?
OWASP Risk: Impacto

• Factores Técnicos
• Pérdida de confidencialidad
• Pérdida de integridad
• Pérdida de disponibilidad
• Pérdida de responsabilidad (¿es trazable el ataque a un individuo?)
• Factores de negocio
• Daño financiero
• Daño a la reputación de la empresa
• Incumplimiento de estándares o regulaciones
• Violación a la privacidad resultante del ataque
5
Nivel de habilidad

2
Motivación

7
Oportunidad

Agente
Factores de

Amenazante

1
Tamaño

3
Facilidad de descubrimiento

6
Posibilidad

Facilidad de explotación

9
Conocimiento
Factores de
Vulnerabilidad

Detección de intrusión

Total Posibilidad

2 4.38 9
Pérdida de Confidencialidad
Ejemplo de análisis

7
Pérdida de Integridad
5
Pérdida de Disponibilidad
Riesgo

Pérdida de responsabilidad
Factores técnicos

Total Impacto técnico

7.3
1

Daño financiero
2

Daño a la reputación
Impacto

No cumplimiento
5

Violación de privacidad
Factores de negocio

Total impacto de negocio

Total Impacto
2.25 4.75

Severidad del Riesgo

Medio
Objetivos del Parche a lanzar

• Corregir la vulnerabilidad
• Corregir vulnerabilidades asociadas
• Evitar regresiones
• Introducir nuevas vulnerabilidades
¿Cómo fomentar la divulgación?

• Problema económico
• Seguridad valorada → recursos para fomento
• “Vengan y atáquennos”
• Eso nunca... ¿Seguridad 100%?
• Organizar Bug Bounties
• Internos y externos
 Google Vulnerability Reward Program

• Inicialmente pensado para vulnerabilidades en

Google Chrome
• Ahora es para todas las apps Google online
• Recompensas desde los USD 100 hasta los USD
20.000
• Divulgación responsable o no hay lucas

Google: “Vulnerability Reward Program”

 Caso Instagram

• Un investigador en seguridad
reportó una vulnerabilidad de
Session Hijacking en la app móvil
de Instagram
• Facebook responde: “Denegada”
• Investigador se lanza a escribir una
herramienta de secuestro masivo
de sesiones
Naked Security: “How anyone can hack your Instagram account”
Plan de Emergencia “Panic Mode”

Observación

Alerta y movilización

Evaluación y estabilización

Resolución
Seguridad ágil
 Desarrollo ágil: Manifiesto

• Individuos e interacciones sobre procesos y

herramientas
• Software funcionando sobre documentación
extensiva
• Colaboración con el cliente sobre negociación
contractual
• Respuesta ante el cambio sobre seguir un plan

Kent Beck y otros, “The Agile Manifiesto”

 Desarrollo ágil: Principios

• Priorizar feedback
• Entrega rápida y minimalista
• Desarrollo iterativo
• Propiedad comunitaria
• “Si duele, hazlo más seguido”
• Inspeccionar y adaptar

Bell, Bird, Smith, Brunton-Spall, “Agile Application Security”

Desarrollo ágil: Metodologías

• Extreme Programming (XP)

• Kanban
• Lean Software Development
• Scrum
• DevOps
Ejemplo: Scrum
DevOps

Veracode, “Secure DevOps Survival Guide: A Field Manual for Developers”

DevOps

• Entrega continua (Continuous Delivery)

• Automatización y monitoreo
• Infraestructura como código (Infrastructure as Code)
• Ciclos cortos de desarrollo y frecuencia de entregas
mayor
• Cloud, virtualización, microservicios...
Seguridad vs Agilidad

• Resistencia al cambio vs cambios continuos

• Departamento de ITSEC vs Equipo ágil
• Procedimientos vs automatización
• Procedimientos vs entregas cortas
• Conocimientos acerca de riesgos vs falta de ellos
• Blockers vs enablers
SecDevOps, DevOpsSec, DevSecOps

• La entrega continua permite corregir fallas (y

vulnerabilidades) más rápido
• Propiedad descentralizada del código
• Seguridad: Ya no puede ser “outsourceada”
• Anti-historias de usuario
• En vez de decir “no”, reemplazarlo por “sí, y también”
o “sí, pero...”
Veracode, “Secure DevOps Survival Guide: A Field Manual for Developers”