CLASE 4

Repositorios de Código Mal Configurados

Septiembre/2019. Durante meses el gigante bancario canadiense Scotiabank

almacenó propiedad digital de alta sensibilidad en una serie de repositorios
GitHub abiertos y accesibles al público, exponiendo potencialmente su código
fuente interno, sus credenciales de acceso y sus claves de acceso. Los
repositorios contenían cientos de archivos, algunos de los cuales contenían
código que estaba destinado a aplicaciones móviles para usuarios de Centro y
Sudamérica.

Parte del código se utilizó para integrar los

sistemas bancarios con los servicios de pago
ofrecidos por Samsung, Google Pay, Visa,
Mastercard y otros. Además del código, los
activos digitales expuestos incluían claves de
acceso para una BD SQL Server y credenciales
de inicio de sesión para servicios e instancias
de BD.
2
 Repositorios de Código Mal Configurados

Enero/2021. El código fuente de varias aplicaciones y servicios de Nissan

North America se filtraron debido a una configuración incorrecta del servidor
Git de la empresa. La filtración se originó en un servidor Git (una instancia de
Bitbucket) que quedó expuesto en Internet con la combinación
predeterminada de nombre de usuario y contraseña (admin / admin).

Entre los datos almacenados en el repositorio

se encontraban el código fuente de las
aplicaciones móviles de Nissan, partes de la
herramienta de diagnóstico Nissan ASIST,
servicios Nissan connect things, Infiniti NCAR,
ICAR, entre otros activos como herramientas
de venta, captación y retención de clientes,
datos de investigación de mercado, y el portal
de logística de vehículos.

3
 Repositorios de Código Mal Configurados

“Los repositorios de código público, y de intercambio de datos pueden facilitar

enormemente DevSecOps y acelerar el desarrollo de software ágil. Sin
embargo, también traen consigo un amplio espectro de riesgos empresariales
críticos de fugas de datos involuntarias o descuidadas, exacerbados por
desarrolladores con insuficiente formación en seguridad”.
(Ilia Kolochenko, Directora ejecutiva de ImmuniWeb)

Immuniweb es una herramienta web que permite

saber qué presencia tiene un dominio en la Dark
Web.

https://www.immuniweb.com/

4
 Índice de Contenidos

• Repaso Sesión Anterior

• ¿Es costosa la Seguridad?
• Estándar de Verificación de Seguridad
• Desarrollo Seguro de Aplicaciones Locales
• Trabajo

5
 Repaso Sesión Anterior

6
 Repaso Sesión Anterior

• La Seguridad como Proceso General

• Lineamientos para Seguridad en el Desarrollo
• Directrices de Programación Segura
• Validaciones de Entrada
• Código Comentado
• Mensajes de Error
• Contenido URL
• Sentencias SQL
• Desarrollo Seguro en JAVA
• Impresión de Mensajes de Salida
• Encapsulación
• Manejo de Excepciones

7
 ¿Es costosa la Seguridad?

8
 ¿Es costosa la Seguridad?

¿A qué se debe el incremento gradual de los ataques en las aplicaciones?

Conectividad. El incremento del avance tecnológico ha hecho que millones de

usuarios accedan a información confidencial procesada por aplicaciones a
través de diferentes puntos en internet.

Gran porcentaje de aplicaciones vulnerables. 2 de 3 aplicaciones WEB son

vulnerables a ataques, debido a que hasta el momento no se ha considerado la
seguridad como un factor medular en las aplicaciones desarrolladas.

Desconocimiento. De la mentalidad de los atacantes, existe muy poco personal

capacitado con relación a la seguridad de aplicaciones y/o desarrollo seguro.

9
 ¿Es costosa la Seguridad?

Desarrollar software seguro es caro, pero “caro” es relativo. Si lo comparamos

contra el escenario de no hacerlo y que nada pase, entonces sí representa un
costo mayor, ya que requieres de un tiempo de desarrollo y entrega más largo,
dinero para herramientas, entrenamiento, análisis externos, etc.

En general, argumentar que “nos van a

hackear” no resulta convincente para
conseguir el presupuesto necesario.
Pero, ¿qué pasa si la informacion de tu
sistema es distribuida, modificada o
eliminada sin tu consentimiento? El
impacto puede ser de reputación y/o
legal (si la informacion es filtrada) o de
experiencia el usuario (si el servicio se
degrada). En ambos casos hay un impacto
monetario asociado.
10
 ¿Es costosa la Seguridad?

A fines de 2017 se dio a conocer que millones de cuentas de Uber fueron

comprometidas en 2016, y no con alguna estrategia sofisticada, sino
simplemente accesando al código fuente en un repositorio privado en Github y
obteniendo de allí credenciales correspondientes al almacenamiento de los
datos en AWS.
Uber reveló que pagó a los hackers US$ 100.000
para “destruir los datos”. Además, tuvo que
llegar a un acuerdo con la Comisión Federal de
Comercio de EEUU, que investigaba las
acusaciones sobre un probable engaño a los
clientes por este incumplimiento y ocultamiento
de información. Tuvo que pagar 148 millones de
dólares para resolver la investigación sobre la
filtración de datos.

11
 ¿Es costosa la Seguridad?

Cuando hablamos de seguridad, en general se nos vienen a la cabeza los

passwords, certificados, o firewalls en la parte física. Algunas veces nos
acordamos de los parches y actualizaciones si es que tenemos algún conocido o
amigo trabajando en redes o soporte.

El caso de Uber es bueno para

ejemplificar que esto va mas allá: es
necesario que nuestro equipo de
desarrollo entienda lo que implica crear
software seguro. Practicas como el no
tener credenciales en el código fuente, no
usar la configuración por defecto de los
componentes o validar que no tengan
vulnerabilidades públicamente conocidas
son extremadamente sencillas e
igualmente ignoradas.
12
 ¿Es costosa la Seguridad?

La seguridad no es algo que pueda dejarse “para después”. Es por ello que desde
temprano en el ciclo de desarrollo del proyecto deben considerarse temas de
seguridad. Muchas veces nos apoyamos solamente en la validación de nuestro
equipo de pruebas (QA) o en el proceso de code review de los desarrolladores,
pero sin un entrenamiento adecuado en ninguno de los casos las personas
sabrán que revisar.

Normalmente (y erróneamente) tendemos a

pensar que la seguridad es responsabilidad de
alguien más, pero no es así. Todos dentro del
equipo de desarrollo soy igual de
responsables.

En general los sistemas operativos y plataformas que utilizamos a diario

invierten mucho dinero en protegerse de las amenazas, ¿cuánto invierte tu
equipo en lo mismo? Todo depende del riesgo.
13
 ¿Es costosa la Seguridad?

Maquiavelo decía que todos los seres humanos somos malos. Aunque es un
punto que puede considerarse debatible, existe un modelo que de cierta
manera le da la razón: es conocido como 10:80:10, y nos dice que del 100% de
los usuarios o involucrados con el sistema:
• 10% no intentarán ningún ataque, sin importar las razones.
• 80% son oportunistas.
• 10% te atacarán sin importar nada.

Podemos asumir entonces que adicional a los “diabólicos” hackers que andan
sueltos por el mundo:
• Tus usuarios buscarán tomar ventaja de la aplicación si les resulta
provechoso.
• Un empleado molesto tomará represalias.
• Un consultor que tenga acceso buscará información que le pueda servir.
14
 Estándar de Verificación de Seguridad

15
 Estándar de Verificación de Seguridad

Ya conocemos el problema, ¿cuál es la solución?. Existen diferentes

herramientas, metodologías, y frameworks que nos ayudan a desarrollar
software seguro. En este curso nos vamos a apoyar en el OWASP Application
Security Verification Standard.

¿Qué es OWASP?
Open Web Application Security Project (OWASP) es una organización sin
ánimo de lucro a nivel mundial dedicada a mejorar la seguridad de las
aplicaciones y del software en general. Su misión es hacer que la seguridad
dentro de las aplicaciones sea más visible para que, así, las organizaciones y los
particulares puedan tomar decisiones sobre conceptos de seguridad basándose
en información verídica y contrastada.

16
 Estándar de Verificación de Seguridad

El Estándar de Verificación Seguridad en Aplicaciones (ASVS por sus siglas en

inglés), es un esfuerzo comunitario por establecer un marco de referencia para
los requisitos de seguridad, controles funcionales y no funcionales necesarios al
diseñar, desarrollar y testear aplicaciones web modernas.

El ASVS define 3 nivel de verificación de

seguridad:
Nivel 1. Se encuentra dirigido a todo tipo de
software.
Nivel 2. Es para aplicaciones que contienen
datos sensibles, que requieren protección.
Nivel 3. Es para las aplicaciones más críticas,
que realizan transacciones de alto valor,
contienen datos médicos confidenciales, o
cualquier aplicación que requiera el más alto
17 nivel de confianza.
 Estándar de Verificación de Seguridad

Nivel 1: Oportunista
Una aplicación alcanza ASVS nivel 1 si se defiende adecuadamente contra
vulnerabilidades de seguridad de aplicaciones que son fáciles de descubrir (y se
incluyen en el OWASP Top 10).

Este nivel es apropiado típicamente

para aplicaciones donde se requiere
escasa confianza en el uso correcto de
los controles de seguridad, para
proporcionar un análisis rápido a un
conjunto de aplicaciones de una
organización, o asistir en la elaboración
de una lista de requerimientos de
seguridad como parte de un esfuerzo
de múltiples fases.
18
 Estándar de Verificación de Seguridad

Nivel 2: Standard
Una aplicación alcanza ASVS nivel 2 si se defiende adecuadamente contra la
mayoría de los riesgos asociados con el software de hoy en día.

Asegura que controles de seguridad se

encuentran en el lugar adecuado, sean
efectivos y sean utilizados dentro de la
aplicación.

Este nivel es generalmente apropiado para

aplicaciones que manejan transacciones
business-to-business, información de salud,
implementan funciones sensibles o críticas
para el negocio o incluyen el proceso de otros
activos sensibles.
19
 Estándar de Verificación de Seguridad

Nivel 3: Avanzado
Es el más nivel de verificación más alto dentro de ASVS. Esta reservado
normalmente para aplicaciones que requieren niveles significativos de
verificación de seguridad, como las que se encuentran dentro de áreas
militares, salud, seguridad, infraestructuras, etc. Las organizaciones pueden
requerir del nivel 3 para aplicaciones que realizan funciones críticas, donde una
falla de seguridad podría afectar significativamente sus operaciones y hasta su
supervivencia.

Una aplicación en el nivel 3 de

ASVS, requiere un análisis de
mayor profundidad, arquitectura,
codificación y testing en todo
nivel.

20
 Estándar de Verificación de Seguridad

El ASVS tiene un amplio abanico de posibles usos, pero uno de los más
importantes es servir de apoyo para la capacitación en desarrollo seguro de
software. Muchos cursos de "codificación segura" son simplemente cursos de
hacking ético con un ligero toque de consejos sobre codificación. Esto no ayuda
mucho a los desarrolladores de sistemas. En cambio, cursos de desarrollo
seguro pueden usar la guía ASVS con un fuerte enfoque en los controles
proactivos en esta.

En esta sesión vamos a revisar de manera

global los 19 requisitos de verificación
detallada que conforman el ASVS, disponibles
en la versión más actualizada (3.0.1).

En la plataforma se dispondrá la guía

actualizada para consultar cada uno de los
controles asociados.
21
 Estándar de Verificación de Seguridad

V1: Arquitectura, diseño y modelado de amenazas

El objetivo de este control es asegurar que una aplicación verificada satisfaga
los siguientes requisitos de alto nivel:

• Nivel 1, los componentes de la aplicación

son identificados y tienen una razón de ser.

• Nivel 2, se ha definido la arquitectura y el

código se adecúa a ésta.

• Nivel 3, la arquitectura y el diseño son los

indicados, se utilizan y resultan eficaces.

22
 Estándar de Verificación de Seguridad

V2: Requisitos de verificación de autenticación

Autenticación es el acto de establecer o confirmar, algo (o alguien) como
auténtico, esto es, que lo que reclama sobre aquello es verdadero. Se debe
asegurar que la aplicación satisface los siguientes requisitos de alto nivel:

• Verifica la identidad digital del remitente

de una comunicación.

• Asegura que sólo los usuarios autorizados

son capaces de autenticarse y que las
credenciales sean transportadas de forma
segura.

23
 Estándar de Verificación de Seguridad

V3: Requisitos de verificación de gestión de sesiones

Uno de los componentes básicos de cualquier aplicación web es el mecanismo
por el cual controla y mantiene el estado de un usuario al interactuar con ésta.
Esto se refiere a manejo de sesiones y se define como el conjunto de todos los
controles que rigen el estado completo de interacción entre un usuario y la
aplicación basada en la web. Se debe asegurar que la aplicación verificada
satisface los siguientes requerimientos de manejo de sesiones de alto nivel:

• Las sesiones son únicas para cada

individuo y no conjeturadas o compartidas.

• Las sesiones son invalidadas cuando ya no

son necesarias y el tiempo es limitado
durante los períodos de inactividad.

24
 Estándar de Verificación de Seguridad

V4: Requisitos de verificación del control de acceso

Autorización es el concepto de permitir acceso a los recursos únicamente a
aquellos que les ha sido permitido utilizarlos. Se debe asegurar que la aplicación
verificada satisface los siguientes requisitos de alto nivel:

• Personas que acceden a recursos poseen

credenciales válidas para hacerlo.

• Los usuarios se encuentran asociados con

un conjunto bien definido de roles y
privilegios.

• Los metadatos de roles y permisos se

encuentran protegidos de ataques de
25 reutilización o manipulación.
 Estándar de Verificación de Seguridad

V5: Requisitos de verificación para manejo de entrada de datos maliciosos

La debilidad más común de seguridad de las aplicaciones web es la falla en
validar apropiadamente el ingreso de datos que provienen del cliente o del
ambiente antes de ser utilizada. Esta debilidad conduce a casi todas las
vulnerabilidades encontradas en aplicaciones web, tales como cross site
scripting (XSS), inyecciones SQL, inyección de intérprete, ataques
locale/Unicode, ataques a sistemas de archivos y desbordamientos de
búfers. Se debe asegurar que la aplicación verificada satisface los siguientes
requisitos de alto nivel:

• Todas las entradas son correctamente validadas y adecuadas para el

propósito previsto.

• No debe confiarse en datos de una entidad externa o del cliente y deben

26 ser tratados como tales.
 Estándar de Verificación de Seguridad

V7: Requisitos de verificación para la criptografía en el almacenamiento

El objetivo de este control es asegurar que una aplicación verificada satisfaga
los siguientes requisitos de alto nivel:

• Que todos los módulos criptográficos fallen

de forma segura y que los errores sean
gestionados correctamente.

• Que se utilice un generador de números

aleatorios adecuado cuando se requiere la
aleatoriedad.

• Que el acceso a claves se gestiona de forma

segura.
27
 Estándar de Verificación de Seguridad

V8: Requisitos de verificación de gestión y registro de errores

El objetivo principal de la gestión y registro de errores es proporcionar una
reacción útil para los usuarios, administradores y equipos de respuesta a
incidentes. El objetivo no es crear cantidades masivas de registros, sino crear
registros de alta calidad, con información útil y desechando ruido.

Los registros de bitácora de alta calidad a

menudo contienen datos confidenciales y
también deben ser protegidos según las leyes
de privacidad de datos o directivas. Si los
registros contienen datos privados o
confidenciales, cuya definición varía de país a
país, éstos se convierten en parte de la
información sensible y por lo tanto resulta muy
atractiva para los atacantes.
28
 Estándar de Verificación de Seguridad

V8: Requisitos de verificación de gestión y registro de errores

Para los registros de bitácora se deben considerar las siguientes directrices:

• No recoger o registrar información

confidencial si no es necesaria.

• Garantizar que toda la información

registrada se gestiona de forma segura y
es protegida según su clasificación de
datos.

• Asegurar que los registros de bitácora no

sean almacenados indeterminadamente,
sino que posean un ciclo de vida útil lo más
29 corta posible.
 Estándar de Verificación de Seguridad

V9: Requisitos de verificación de protección de datos

Hay tres elementos clave para la protección de datos: Confidencialidad,
Integridad y Disponibilidad (CIA por sus siglas en inglés). Este estándar asume
que la protección de datos se aplica en un sistema de confianza, como un
servidor, que ha sido protegido debidamente y dispone de protecciones
suficientes.

Cuando una aplicación transmite o almacena

información sensible dentro de dispositivos
inseguros, como equipos compartidos,
teléfonos y tabletas, la aplicación es
responsable de que los datos almacenados en
estos dispositivos sean cifrados y no pueden
ser fácilmente o ilícitamente obtenidos,
alterados o divulgados.

30
 Estándar de Verificación de Seguridad

V9: Requisitos de verificación de protección de datos

Se debe asegurar que la aplicación verificada satisface los siguientes requisitos
de protección de datos de alto nivel:

• Confidencialidad: Los datos deben ser

protegidos de observación no autorizada o
la divulgación tanto en tránsito como
cuando están almacenados.
• Integridad: Los datos deben protegerse
siendo creados maliciosamente, alterados
o eliminados por los intrusos no
autorizados.
• Disponibilidad: Los datos deben estar
disponibles para usuarios autorizados
cuando sea necesario.
31
 Estándar de Verificación de Seguridad

V10: Requisitos de verificación de seguridad de las comunicaciones

Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos
de alto nivel:

• Que se utilice TLS donde se transmite

información sensible.

• Que se utilicen algoritmos y cifradores

fuertes en todo momento.

32
 Estándar de Verificación de Seguridad

V11: Requisitos de verificación de configuración de seguridad HTTP

Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos
de alto nivel:

• El servidor de aplicaciones está

convenientemente endurecido de una
configuración preestablecida.

• Toda respuesta HTTP contiene su tipo

de contenido establecido utilizando un
conjunto de caracteres seguro.

33
 Estándar de Verificación de Seguridad

V13: Requisitos de verificación para Controles Maliciosos

Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos
de alto nivel:

• La actividad maliciosa se debe manejar con seguridad y adecuadamente para

no afectar el resto de la aplicación.

• No posee bombas de tiempo ni otros ataques basados en tiempo.

• No realiza "phone home" a destinos malintencionados o no autorizados.

• La aplicación no posee puertas traseras, huevos de pascua, ataques salami o

fallos de lógica que pueden ser controlados por un atacante.
34
 Estándar de Verificación de Seguridad

V13: Requisitos de verificación para Controles Maliciosos

El código malicioso es extremadamente raro difícil de detectar. La revisión
manual línea por línea del código puede ayudar a encontrar bombas lógicas,
pero incluso el más experimentado revisor de código tendrá que esforzarse
para encontrar código malicioso aunque sepa que existe.

35
 Estándar de Verificación de Seguridad

V15: Requisitos de verificación para lógica de negocios

Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos
de alto nivel:

• El flujo de la lógica de negocio es secuencial y en orden.

• La lógica de negocios incluye límites para detectar y evitar ataques

automatizados, como las continuas transferencias de fondos pequeños.

• Flujos de lógica de negocios de alto valor han considerado casos de abuso y

agentes maliciosos y poseen protecciones contra la falsificación, alteración,
repudio, revelación de información y ataques a la elevación de privilegios.

36
 Estándar de Verificación de Seguridad

V16: Requisitos de verificación de archivos y recursos

Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos
de alto nivel:

• Datos no confiables deben ser

gestionados como tales y de forma
segura.

• Datos obtenidos de fuentes no

confiables sean almacenan fuera del
webroot y posean permisos limitados.

37
 Estándar de Verificación de Seguridad

V17: Requisitos de verificación Móvil

Las aplicaciones móviles deben:

• Deben tener el mismo nivel de controles de seguridad tanto en el cliente

móvil como en el servidor, mediante la aplicación de controles de seguridad
en un entorno de confianza.

• Activos de Información sensible almacenados en

el dispositivo debe realizarse de un modo
seguro.

• Todos los datos sensibles transmitidos desde el

dispositivo deben ser hechos teniendo en mente
la seguridad en la capa de transporte.
38
 Estándar de Verificación de Seguridad

V18: Requisitos de verificación de servicios Web

Asegúrese de que la aplicación verificada, de utilizar servicios web REST o
SOAP posean:

• Autenticación adecuada, gestión de sesión y autorización de todos los

servicios web.

• Validación de entrada de datos de todos los

parámetros que transiten de zonas de menor
a mayor confianza.

• Interoperabilidad básica de la capa de

servicios web SOAP para promover el uso de
la API.
39
 Estándar de Verificación de Seguridad

V19: Requisitos de configuración

El objetivo de este control es asegurar que la aplicación verificada:

• Utilice bibliotecas y una plataforma actualizada.

• Una configuración segura por omisión.

• Un hardening suficiente de tal forma que

los cambios realizados por un usuario no
resulten en exposiciones innecesarias o
creen debilidades de seguridad o fallas a
los sistemas subyacentes.

40
 Estándar de Verificación de Seguridad

Los siguientes requisitos fueron sacados de la última versión del estándar ya

que se encuentran abordados indirectamente en otros controles:

V6: Requisitos de verificación del control de acceso

V12: Requisitos de verificación de configuración de seguridad

V14: Requisitos de verificación de seguridad interna

41
 Desarrollo Seguro de Aplicaciones
Locales

42
 Desarrollo Seguro de Aplicaciones Locales

Se entiende por Aplicaciones Locales a aquellas aplicaciones que se ejecutan

en la máquina y desde la máquina; aplicaciones de línea de comandos o de
escritorio que un usuario local ejecuta. Son aplicaciones que se instalan en el
sistema informático del usuario, bien sea en un servidor de una red local o en
un equipo aislado. Otro término utilizado para este tipo de aplicaciones es
Aplicaciones On Premise o Aplicaciones de Escritorio.

Cuando se habla de seguridad en

aplicaciones web, se trata más de explotar
formatos de salida que modifican el
comportamiento del navegador (XSS), o
aspectos relacionados con el hecho de que
se trata de una comunicación remota y las
consecuencias de esta comunicación si no
está correctamente protegida.

43
 Desarrollo Seguro de Aplicaciones Locales

En aplicaciones locales, vamos a hablar a bajo nivel, no en protocolos de red,

sino en arquitectura de sistemas. Por lo mismo, necesitamos conocer las
estructuras lógicas con las que funciona un sistema operativo, cómo funciona
realmente un compilador, cómo es posible modificar el puntero a instrucciones
del procesador y las consecuencias que esto puede tener, entre otras cosas.

El objetivo principal de un atacante que

explota este tipo de aplicaciones es lo que se
conoce como escalada de privilegios. Los
usuarios ejecutan aplicaciones con los
permisos que tengan para ellos, o dicho de otro
modo, los programas, al ejecutarse, tienen los
mismos permisos en el sistema que el usuario
que los ejecuta.

44
 Desarrollo Seguro de Aplicaciones Locales

Un programa instanciado por un usuario no tiene permisos en circunstancias

normales para acceder a un recurso al que dicho usuario no pueda acceder. Sin
embargo, hay aplicaciones que necesitan un permiso superior para funcionar
correctamente. Un ejemplo simple: Un usuario normal no tiene acceso para leer
el archivo donde se guardan las contraseñas, pero un programa ejecutado por
él debe poder acceder para permitirle cambiar su propia contraseña.

Son precisamente estos programas los

más peligrosos en un sistema, ya que se
ejecutan con permisos distintos
(normalmente más potentes) que los de
los usuarios que los invocan, y si se explota
una vulnerabilidad en una de estas
aplicaciones, el usuario puede sacar
ventaja de distintas maneras de los
permisos con los que corre la aplicación.
45
 Desarrollo Seguro de Aplicaciones Locales

La escalada de privilegios no es la única razón por la que un atacante pudiera

estar interesado en buscar este tipo de vulnerabilidades. Si el programa tiene
una interfaz hacia el exterior, como un servidor FTP, ETC, SSH, etc., el atacante
puede conseguir un acceso remoto gracias a este tipo de problemas, o una
denegación de servicio (forzar al servicio a dejar de hacer su trabajo,
corrompiendo el flujo de su ejecución, produciendo una excepción que le
impide seguir corriendo, haciéndole que agote sus recursos).

Poder modificar el flujo de un programa puede

ser interesante sin tener que proporcionar
privilegios superiores a los actuales, ya que se
puede hacer que el programa actúe de forma
distinta a la que está pensado, y saltar así
posibles mecanismos de autenticación y o
autorización, acceso a recursos, etc.

46
 Desarrollo Seguro de Aplicaciones Locales

Acceder a zonas de la memoria del programa puede aportar información

sensible sobre claves que el programa puede estar utilizando, o acceder a datos
de otros usuarios que estén utilizando la aplicación de forma concurrente.

Asimismo, no todo es explotar los

programas por dentro. Muchas veces las
aplicaciones se apoyan en recursos
externos, como archivos temporales o
claves en el registro para su ejecución, y
esto presenta un nuevo vector de ataque
si dichos recursos no se manejan con
cuidado.

47
 Desarrollo Seguro de Aplicaciones Locales

Prevención de desbordamientos de buffer: stack y heap

Sin duda, el número uno de las vulnerabilidades locales que permiten ejecución
de código son las vulnerabilidades de desbordamientos (overflows en inglés), se
basan en un pobre o inexistente control de los tamaños respectivos de datos y
contenedores de datos cuando éstos se mueven de un sitio a otro en la
memoria.

La naturaleza de la vulnerabilidad a
explotar está relacionada con el
funcionamiento a bajo nivel de las
estructuras del sistema operativo,
como la pila (stack) o el montón (heap),
y por tanto, afectan únicamente a
lenguajes que permitan este control
sobre la memoria y dichas estructuras,
tales como C o C++.
48
 Desarrollo Seguro de Aplicaciones Locales

Prevención de desbordamientos de buffer: stack y heap

Programas escritos en código manejado como C# o que tienen algún tipo de
conversión a bytecode como Java o PHP no son, en principio, vulnerables a este
tipo de fallos. Sí lo son los intérpretes de estos lenguajes, y es posible encontrar
formas de explotar características del lenguaje de programación que resulten
en la ejecución de las vulnerabilidades del intérprete del lenguaje.

Se produce un desbordamiento de
memoria cuando, en una estructura de
datos de un tamaño determinado, se
intentan alojar datos que requieren un
contenedor mayor. En función de dónde se
produzca este desbordamiento, las
estructuras del sistema operativo serán
unas u otras, y por tanto, la forma de
explotarlos cambia de manera
49 considerable.
 Desarrollo Seguro de Aplicaciones Locales

Prevención de desbordamientos de buffer: stack y heap

Normalmente, lo que un atacante hace es codificar su propio código en la
cadena si ésta tiene el tamaño suficiente, y sobrescribir la dirección de retorno
con la dirección en la pila donde empieza esta cadena, llevando así el programa
a una ejecución totalmente controlada.

Los desbordamientos de heap tienen

exactamente la misma naturaleza, pero en lugar
de aprovechar la estructura de la pila y los
registros que en ella se almacenan para tomar
control del programa, para conseguir el mismo
efecto, aprovechan la estructura del heap y,
cómo se reserva y libera la memoria, o cómo se
llama a los destructores cuando un objeto ya no
tiene más referencias.

50
 Desarrollo Seguro de Aplicaciones Locales

Prevención de desbordamientos de buffer: stack y heap

¿Qué puedo hacer para prevenirlo?. Hay una serie de funciones vulnerables que
los hackers pueden explotar para sobrellenar los búferes. Por lo mismo, se debe
minimizar el uso de funciones de la familia de memcpy(), bcopy(), memcopy(),
memmove(), strcpy (), strcat (), sprintf () y vsprintf () o las funciones de lectura
de entrada del usuario getc(), fgetc(), getchar() y read().

Implemente herramientas de compilación

para dar advertencias cuando se use código
que exponga este tipo de vulnerabilidades.
Algunas de estas herramientas va a generar
código que prohíbe que personas ajenas
tengan acceso a direcciones ilegales y
apaguen código que intenta dicha
ejecución.
51
 Desarrollo Seguro de Aplicaciones Locales

Prevención de desbordamientos de buffer: stack y heap

Es necesario verificar adecuadamente la terminación en bucles y los límites de
las matrices antes de escribir el acceso. Se trata de una de las áreas más
difíciles, y en algunos casos, el problema y su solución están en módulos por
completo diferentes.

El uso del lenguaje C o C++, donde se permite el

uso de punteros a memoria, habría que dejarlo
sólo para cierto tipo de sistemas de alto
rendimiento, donde se necesite programar a bajo
nivel la gestión de la memoria.

Además, siempre es recomendable tener en

consideración el uso de herramientas de
inspección de código.
52
 Desarrollo Seguro de Aplicaciones Locales

Prevención de vulnerabilidades en las cadenas de formatos

Prácticamente todos los lenguajes de programación incluyen una familia de
funciones para el tratamiento de cadenas de formato (format strings), tales
como su impresión por pantalla, su registro en un archivo de log, copia de
cadenas a otras cadenas, etc.

Estas cadenas pueden crearse a partir de

partes estáticas definidas como texto en el
propio código fuente, aunque normalmente
toda o parte de la cadena es realmente
contenido dinámico que depende bien de la
entrada del usuario, o bien de otras
variables del programa dependientes de la
ejecución.

53
 Desarrollo Seguro de Aplicaciones Locales

Prevención de vulnerabilidades en las cadenas de formatos

Si bien acceder a la memoria del proceso es un riesgo considerable, el mayor
problema que exponen las vulnerabilidades de cadenas de formato es el control
del flujo del programa. Al igual que en los desbordamientos de buffer, es posible
modificar el valor del puntero de instrucciones almacenado en la pila, y el
responsable de esto en las cadenas de formato es un especificador poco
conocido: "%n".

Este especificador se asocia a una variable en la

lista de parámetros como el resto de
especificadores, pero en lugar de leer el valor de
la variable e imprimirlo en la cadena formateada,
lo que hace es escribir en la variable asociada el
número de caracteres escritos hasta su
aparición.

54
 Desarrollo Seguro de Aplicaciones Locales

Prevención de vulnerabilidades en las cadenas de formatos

¿Qué puedo hacer para prevenirlo?. La solución al problema de las cadenas de
formato no es usar un equivalente en funciones más seguras, sino simplemente
especificar siempre el formato que se quiere utilizar, y nunca, absolutamente
nunca, permitir que el formato dependa de cualquier variable que el usuario
pueda haber podido manipular, y usar este formato sin filtrar.

Detectar cadenas de formato usadas de

manera incorrecta es relativamente sencillo
mediante un análisis estático del código. Los
casos más frecuentes son la familia de printf
o syslog. Sin embargo, los programadores
pueden crear sus propias funciones con
listas dinámicas de parámetros y utilizarlas
de forma vulnerable, y esto es más
difícilmente detectable por un analizador de
55 código.
 Desarrollo Seguro de Aplicaciones Locales

Prevención de vulnerabilidades en las cadenas de formatos

Nunca se deben pasar entradas de usuario directamente a un función de
formateo, además debe asegurarse de hacerlo en cada nivel de manipulación de
salida formateada.

Es importante asegurarse que las cadenas de

formato que utiliza la aplicación se lean desde
lugares confiables, y que las rutas a las cadenas no
sean controladas por el atacante.

Por último, quizás se debe considerar el uso de

lenguajes de más alto nivel que tiendan a ser menos
vulnerables a este problema.

56
 Desarrollo Seguro de Aplicaciones Locales

Prevención de condiciones de carrera

El termino condición de carrera (race condition) no se define propiamente
como una vulnerabilidad, sino como un problema de programación,
normalmente asociado a un fallo en el programa en ejecución causado por esta
condición. Entra en el contexto de la seguridad cuando esta condición hace que
se pueda tomar ventaja del comportamiento inesperado.

Es un comportamiento inesperado cuando se produce

una dependencia entre dos o más eventos cuyo orden
en el tiempo no está determinado. El programador
asume que un evento A va a ocurrir antes que un
evento B, y mientras sea así, su aplicación se
comportara correctamente, pero si la ejecución de los
eventos A y B depende de causas no deterministas, su
orden en el tiempo se puede alterar, haciendo que el
evento B ocurra antes que el evento A.
57
 Desarrollo Seguro de Aplicaciones Locales

Prevención de condiciones de carrera

Las consecuencias de tal inesperada sucesión pueden ir desde el interbloqueo,
ya que B supone que A ha ocurrido y puede estar esperando la salida
condicional de algo que sucedió en A, pero que dado el presente orden de
ejecución nunca ocurrirá, hasta el fallo total del programa, por ejemplo
accediendo a referencias nulas a objetos que debían haberse inicializado en el
evento supuestamente anterior, y muchas e inesperadas variantes.

Las aplicaciones multihilo son buenas candidatas

a condiciones de carrera, ya que los hilos corren
en paralelo, y no siempre los programadores
tienen un buen control (a veces ni siquiera un
buen entendimiento) de cómo la aplicación va a
ejecutar y terminar cada uno de los hilos.

58
 Desarrollo Seguro de Aplicaciones Locales

Prevención de condiciones de carrera

¿Qué puedo hacer para prevenirlo?. Las condiciones de carrera se pueden
evitar mediante la serialización de la memoria o el acceso al almacenamiento.
Esto significa que si los comandos de lectura y escritura se reciben juntos, el
comando de lectura se ejecuta y completa primero de manera predeterminada.

Para evitar que se produzcan condiciones de

carrera, normalmente se debe bloquear los
datos compartidos para garantizar que solo
un hilo pueda acceder a los datos a la vez.

Existen herramientas de análisis dinámico

para aplicaciones multiproceso que detectan
automáticamente estos defectos de
concurrencia.
59
 Desarrollo Seguro de Aplicaciones Locales

Programación con mínimos privilegios

Uno de los conceptos más importantes en la protección de aplicaciones y
sistemas es el de la defensa en profundidad. Esto quiere decir que, si bien
nuestra aplicación puede contar con un mecanismo de protección para impedir
cierto tipo de ataques, es una buena práctica programar y configurar el resto de
la aplicación como si este mecanismo no existiera, o al menos teniendo en
cuenta que podría fallar.

Una de las técnicas más importantes a aplicar

para conseguir una buena defensa en
profundidad es la programación con mínimos
privilegios, consistente en configurar la
aplicación para que, en cada momento, sólo
pueda hacer aquello para lo que está pensada, y
nada más.

60
 Desarrollo Seguro de Aplicaciones Locales

Programación con mínimos privilegios

Supongamos una aplicación que se conecta a una base de datos para guardar,
consultar o modificar registros. La aplicación debe conectarse al gestor de base
de datos con un usuario y contraseña que tenga permisos sobre la base de
datos que va a utilizar, pero para nada esta aplicación necesita permisos sobre
otras bases de datos (o catálogos) alojadas en el mismo SGBD.

Es habitual encontrar aplicaciones que

conectan a las BD con usuarios con
privilegios absolutos, ya sean usuarios por
defecto (como root en MySQL), o usuarios
creados con dichos privilegios. Esto
significa que si la aplicación es vulnerable,
muy posiblemente toda la BD ha quedado
comprometida.

61
 Recuerde utilizar los foros de cada módulo
62
CLASE 4