UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas

SEGURIDAD INFORMÁTICA

Los Pecados Capitales en la Seguridad del Software

Integrantes

1. Katherine Rodríguez López 20111250J

2. Alex Alonso Vega Jiménez 20072554G
3. Marco Antonio Ramirez Ramos 20121142E
4. Alexander Ramos Canepa 19961007B
5. Carlos Pando Morales 20072531G
6. Raul Alexis Canelo Bernal 20121142E

Profesor: Ing. Trigo Perez, Carlos

2018 I
 Los pecados capitales en la seguridad del software

1. Sobrecarga de búfer: En seguridad informática y programación, un

desbordamiento de búfer (del inglés buffer overflow o buffer overrun) es un error
de software que se produce cuando un programa no controla adecuadamente la
cantidad de datos que se copian sobre un área de memoria reservada a tal efecto
(buffer): Si dicha cantidad es superior a la capacidad pre asignada, los bytes
sobrantes se almacenan en zonas de memoria adyacentes, sobrescribiendo su
contenido original, que probablemente pertenecían a datos o código almacenados
en memoria. Esto constituye un fallo de programación.
En las arquitecturas comunes de computadoras no existe separación entre las
zonas de memoria dedicadas a datos y las dedicadas a programa, por lo que los
bytes que desbordan el buffer podrían grabarse donde antes había instrucciones,
lo que implicaría la posibilidad de alterar el flujo del programa, llevándole a realizar
operaciones imprevistas por el programador original. Esto es lo que se conoce
como una vulnerabilidad.
Una vulnerabilidad puede ser aprovechada por un usuario malintencionado para
influir en el funcionamiento del sistema. En algunos casos el resultado es la
capacidad de conseguir cierto nivel de control saltándose las limitaciones de
seguridad habituales. Si el programa con el error en cuestión tiene privilegios
especiales constituye en un fallo grave de seguridad.

2. Captura de excepciones: El manejo de excepciones es una técnica

de programación que permite al programador controlar los errores ocasionados
durante la ejecución de un programa informático. Cuando ocurre cierto tipo de
error, el sistema reacciona ejecutando un fragmento de código que resuelve la
situación, por ejemplo retornando un mensaje de error o devolviendo un valor por
defecto. Si no se maneja de la manera adecuada entonces la excepción sube de
nivel mostrando información interna de manera no deseada.

3. Comando de inyección: Un defecto de inyección de código ocurre cuando es

posible enviar datos inesperados a un intérprete. Estos son muy comunes en
código antiguo. Se encuentran frecuentemente en consultas SQL, LDAP, Xpath o
NoSQL; comandos de sistema operativo; analizadores sintácticos de XML;
cabeceras SMTP; parámetros de funciones; etc. Estos defectos son fáciles de
encontrar cuando se examina el código, sin embargo son difíciles de descubrir
mediante pruebas funcionales. Existen utilidades de escaneo que pueden ayudar a
encontrar estos defectos.
 Una inyección de código puede resultar en la pérdida o corrupción de datos, falta
de responsabilidad en acciones o denegación de acceso. Una inyección puede
incluso tomar control total de un nodo.
Las técnicas de inyección de código son populares en el hacking y cracking para
conseguir acceder a información restringida, para aumentar los privilegios o para
conseguir acceder a sistemas restringidos.

4. Cross-site scripting (XSS): XSS es un ataque de inyección de código malicioso para

su posterior ejecución que puede realizarse a sitios web, aplicaciones locales e
incluso al propio navegador.
Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación
web y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio
web, mensajería instantánea o un correo electrónico. Así mismo, puede provocar
una negación de servicio (DDos).

Operación de un ataque XSS

Generalmente, si el código malicioso se encuentra en forma de hipervínculo es

codificado en HEX (basado en el sistema de numeración hexadecimal, base 16) o
algún otro, así cuando el usuario lo vea, no le parecerá sospechoso. De esta
manera, los datos ingresados por el usuario son enviados a otro sitio, cuya pantalla
es muy similar al sitio web original.De esta manera, es posible secuestrar una
sesión, robar cookies y cambiar la configuración de una cuenta de usuario.
5. Error al manejar los errores: En los entornos de programación más recientes se ha
desarrollado una forma alternativa de manejar los errores, conocida como manejo
de excepciones, la cual funciona generando una excepción tan pronto aparece un
error. El sistema fuerza un salto hacia el bloque de excepciones más cercano del
código en el cual se toman las acciones apropiadas tendientes a solucionar o
alertar acerca del error producido. El sistema provee un "manejador" estándar por
defecto que toma todas las excepciones y que muestra los mensajes de error,
deteniendo la ejecución del programa. El no manejar correctamente los errores
produce una alternativa para ataques a la seguridad de la información

6. No proteger el tráfico de la red: La red es el punto de entrada a una aplicación. Por

lo tanto, los mecanismos de seguridad de la red son la primera línea de defensa
contra las amenazas potenciales del exterior. La seguridad de la red implica
proteger los protocolos y los canales de comunicación, así como dispositivos como
el direccionador, el firewall y el conmutador. Si esto no se realiza se tiene un gran
riesgo de ataque a nuestros aplicativos.

7. No se almacenan y protegen los datos de forma segura: La seguridad de datos,

también conocida como seguridad de la información o seguridad informática, es
un aspecto esencial de TI en organizaciones de cualquier tamaño y tipo. Se trata de
un aspecto que tiene que ver con la protección de datos contra accesos no
autorizados y para protegerlos de una posible corrupción durante todo su ciclo de
vida.

8. No se usaron números aleatorios criptográficamente fuertes: Seguridad de

datos incluye conceptos como encriptación de datos, tokenización y prácticas de
gestión de claves que ayudan a proteger los datos en todas las aplicaciones y
plataformas de una organización. Hoy en día, organizaciones de todo el mundo
invierten fuertemente en la tecnología de información relacionada con la
ciberdefensa con el fin de proteger sus activos críticos: su marca, capital intelectual
y la información de sus clientes. En todos los temas de seguridad de datos existen
elementos comunes que todas las organizaciones deben tener en cuenta a la hora
de aplicar sus medidas: las personas, los procesos y la tecnología.
No se usaron números aleatorios criptográficamente fuertes: Uno de los
procedimientos más comunes en el área de desarrollo web es la generación de
"Tokens" o cadenas de caracteres no repetibles y aleatorios que de forma única
puedan diferenciar a una entidad de otra sin duda alguna. Estos tokens son usados
por ejemplo para generación de identificadores de sesiones o de usuarios,
 identificadores de formularios y muchos otros usos en los que se requiera de una
identificación segura de la entidad que representen.
La calidad de los números producidos por los sistemas de generación de números
aleatorios se basa en la impredictibilidad o alto grado de entropía de los mismos, y
una rutina de generación de números aleatorios es más fuerte de forma
inversamente proporcional a la posibilidad de predicción de sus resultados.
Si nuestra aplicación requiere de "tokens" en los que se basan procesos de
seguridad de cierto riesgo (como por ejemplo en la producción de una matriz de
coordenadas únicas o tarjeta matricial) entonces nuestras rutinas de
generación deberían ser criptográficamente seguras. Lo que llamamos
predictibilidad es en términos criptográficos conocido como "entalpía" u orden, o
lo exactamente contrario a "entropía" o desorden. Mientras más entropía posean
nuestros resultados, menos predecibles serán. Por tanto, estadísticamente una
rutina de números aletorios es más segura en la medida que pueda presentar una
muestra lo más homogéneamente distribuida de números en una cantidad
determinada de intentos.

9. Problemas de cadenas de formato: Los problemas de cadena de formato

constituyen uno de los pocos ataques realmente nuevos que surgieron en años
recientes.
Al igual que con muchos problemas de seguridad, la principal causa de los errores
de cadena de formato es aceptar sin validar la entrada proporcionada por el
usuario. En C/C++ es posible utilizar errores de cadena de formato para escribir en
ubicaciones de memoria arbitrarias, y el aspecto más peligroso es que esto llega a
suceder sin manipular bloques de memoria adyacentes. Esta capacidad de
diseminación permite a un atacante eludir protecciones de pila, e incluso modificar
partes muy pequeñas de memoria. El problema también llega a ocurrir cuando las
cadenas de formato se leen a partir de una ubicación no confiable que controla el
atacante. Este último aspecto del problema tiende a ser más frecuente en
sistemas UNIX y Linux. En sistemas Windows las tablas de cadena de aplicación
suelen mantenerse dentro del programa ejecutable o de las bibliotecas de vínculo
dinámico (DLL, Dynamic Link Libraries) del recurso. Si un atacante reescribe el
ejecutable principal o de las DLL, tendrá la posibilidad de realizar ataques mucho
más directos que con errores de cadena de formato.
Aunque no esté trabajando con C/C++, los ataques de cadena de formato quizá
conduzcan a problemas importantes; el más obvio es engañar a los usuarios, pero
bajo ciertas circunstancias es posible que un atacante lance ataques de creación de
 script de sitio cruzado o de inyección de SQL, los cuales también se utilizan para
corregir o transformar datos.
El formateo de datos para despliegue o almacenamiento tal vez represente una
tarea un poco difícil; por tanto, en muchos lenguajes de computadora se incluyen
rutinas para reformatear datos con facilidad. En casi todos los lenguajes la
información de formato se describe a través de un tipo de cadena, denominada
cadena de formato. En realidad, la cadena de formato se define con el uso de
lenguaje de procesamiento de datos limitado que está diseñado para facilitar la
descripción de formatos de salida. Sin embargo, muchos desarrolladores cometen
un sencillo error: utilizan datos de usuarios no confiables como cadena de formato;
el resultado es que los atacantes pueden escribir cadenas en el lenguaje de
procesamiento de datos para causar muchos problemas.

10. Descuidar el control de cambios. Estos sistemas nos permiten administrar los
cambios realizados por los desarrolladores. Este control ayuda a eliminar la
posibilidad de confusiones que pueden resultar de alto costo para el proyecto y
asegurar que no existan inconsistencias en el sistema desarrollado, generadas por:

Actualizaciones simultáneas: Cuando varios integrantes del equipo trabajan sobre

un mismo elemento al mismo tiempo.

Problemas en la notificación de cambios: Cuando un problema fue resuelto para

algún elemento que es compartido por varios desarrolladores y alguno de ellos no
fue notificado de dicho cambio.

Múltiples versiones: Usualmente se tienen varias versiones del producto en

desarrollo, por ejemplo, una versión de desarrollo, y otra de test, y se quiere que
cuando haya un cambio en una éste se vea reflejado en las demás versiones.

Si no usamos un gestor de versiones será complicado mantener la integridad del

producto. Se podría perder el control y restricción sobre los cambios que se
realizan y también la habilidad de saber el porqué, cuando y quién realizó un
cambio.

11. Acceso inapropiado a los archivos: En ciertos sistemas el acceso a archivos

inapropiados se debe en base a malas configuraciones de acceso, suplantación de
identidad o incluso perdida o fuga de información. Esto puede representar un
grave problema de seguridad debido a que se puede prestar a manipulación de
archivos que conlleven a consecuencias mayores, o llegar a casos de filtración de
 datos dando una pésima imagen externa. Para evitar esto se pueden implementar
las siguientes técnicas:
• Posesión de un secreto, algo conocido por el usuario: contraseñas. Este
sistema tiene ciertas debilidades: Generalmente, los usuarios eligen
contraseñas fáciles de recordar. Los computadores modernos afrontan este
problema de diferentes formas. Una de ellas es cifrar la contraseña junto
con un número aleatorio de n bits. Otros computadores piden a los
usuarios que cambien periódicamente las contraseñas
• Posesión de un artefacto, algo que al poseerlo el usuario le permite acceder
al sistema; por ejemplo: tarjetas magnéticas o llaves físicas. Este tipo de
identificación funciona bien en sitios en donde el distintivo de
identificación se usa para otros propósitos Otras variantes son las tarjetas
inteligentes, que mantienen la contraseña del usuario secreta para el
sistema, ya que está almacenada en la propia tarjeta. Esto hace más difícil
descubrir las contraseñas.

12. Uso incorrecto de Secure Sockets Layer (SSL): Es un protocolo de seguridad que
hace que sus datos viajen de manera íntegra y segura, es decir, la transmisión de
los datos entre un servidor y usuario web, y en retroalimentación, la cual crea
claves para cifrar y descifrar información enviada y recibida, se obtiene a través de
certificados SSL.
SSL 3.0 fue la última revisión del protocolo de comunicación seguro SSL (“Secure
Sockets Layers”) resulta que este protocolo criptográfico, en el que hemos
confiado para hacer más segura la comunicación a través de Internet tiene una
grave vulnerabilidad en el protocolo de seguridad.
La vulnerabilidad en SSL 3.0 descubierta por los investigadores de Google es
diferente a Heartbleed, ya que no afecta a la parte servidor (que aloja, por
ejemplo, páginas web), sino a la parte cliente (navegadores de Internet, clientes de
correo, etc.), lo que la hace menos grave y fácil de solucionar.
El exploit podría ser usado para interceptar los datos sensibles que se supone que
son cifrados entre clientes y servidores.
El exploit permite a los atacantes iniciar un “downgrade” que le dice al cliente que
el servidor no soporta el protocolo TLS (Transport Layer Security) y los obliga a
conectarse a través de la versión 3.0 de SSL. Desde allí, realizan un ataque man in
the middle para descifrar las cookies seguras por HTTP. Google ha nombrado este
ataque como ataque POODLE (Padding Oracle On Degradado Encryption Legacy).
Básicamente consiste en aprovecharse de una característica que hace que, cuando
un intento de conexión segura falla, se proceda a intentar realizar de nuevo esa
 conexión pero con un protocolo de comunicación más antiguo. De esa forma, un
atacante podría ocasionar intencionadamente errores de conexión en protocolos
seguros como TLS 1.2, 1.1 y 1.0 y forzar así el uso de SSL 3.0 para aprovechar la
nueva vulnerabilidad.

13. Fuga de información. Esto se da cuando información confidencial y que sólo

debería estar disponible para integrantes de la organización son accedidos y
llevados a manos ajenas. Documentos o recursos son accesibles por personas no
autenticadas o autorizadas.

14. Errores enteros (desbordamientos/subdesbordamientos): Se produce un

desbordamiento cuando intenta una asignación que supera los límites del destino
de la asignación. un subdesbordamiento de búfer (Buffer underflow/underrun)
sucede cuando un búfer carga su información a una velocidad más baja que el
procesamiento de la misma, esto hace que el programa o dispositivo que procesa
dicha información se detenga momentánea y seguidamente por el hecho de que si
continúa, estaría haciendo una solicitud a un espacio de memoria nula
15. Condiciones de carrera: situaciones en las que dos o más procesos leen o escriben
en un área de memoria compartida y el resultado final depende de los instantes de
ejecución de cada uno.
La condición de carrera (race condition) ocurre cuando dos o más procesos
accedan un recurso compartido sin control de manera que el resultado combinado
de este acceso depende del orden de llegada. Uno de los grandes problemas que
nos podemos encontrar es que compartir recursos está lleno de riesgos. Por
ejemplo si dos procesos hacen uso al mismo tiempo de una variable global y
ambos llevan a cabo tanto operaciones de lectura como de escritura sobre dicha
variable el orden en que estas lecturas y escrituras es crítico puesto que se verá
afectado el valor de la variable. Esto se soluciona impidiendo que más de un
proceso acceda simultáneamente a las variables compartidas, garantizando la
exclusión mutua

16. Inyección SQL: La inyección de código SQL es un ataque en el cual se inserta código
malicioso en las cadenas que posteriormente se pasan a una instancia de SQL
Server para su análisis y ejecución. Todos los procedimientos que generan
instrucciones SQL deben revisarse en busca de vulnerabilidades de inyección de
código, ya que SQL Server ejecutará todas las consultas recibidas que sean válidas
desde el punto de vista sintáctico. Un atacante cualificado y con determinación
puede manipular incluso os datos con parámetros.
 La forma principal de inyección de código SQL consiste en la inserción directa de
código en variables especificadas por el usuario que se concatenan con comandos
SQL y se ejecutan. Existe un ataque menos directo que inyecta código dañino en
cadenas que están destinadas a almacenarse en una tabla o como metadatos.
Cuando las cadenas almacenadas se concatenan posteriormente en un comando
SQL dinámico, se ejecuta el código dañino.

Áreas problemáticas en el desarrollo de software:

17. Confianza en la resolución de direcciones de red: Las infraestructura de red se

basa en equipos electrónicos que distribuyen por la red las transmisiones de nivel
físico. Dado que el tráfico de la red atraviesa dichos equipos, éstos pueden ser
dotados de los procesos necesarios para inspeccionar los mensajes ARP y DHCP
generados desde equipos considerados de confianza para establecer las
correspondencias válidas entre direcciones físicas y de red.
Los equipos de red que incorporan esta funcionalidad son sustancialmente más
costosos ya que necesitan de mayores recursos de memoria y capacidad de
cómputo. Por otra parte, las asignaciones de direcciones de red estáticas, no
gestionadas por el servicio DHCP, deben configurarse manualmente y ser
distribuidas debidamente en los equipos de red.

18. Cambio de clave no autenticado. Un error común es permitir cambiar clave de

acceso a una aplicación sin solicitar al usuario que reingrese la clave antigua, esto
se exige para tener la seguridad que el usuario que realiza esta acción es el dueño
de la cuenta. Se recomienda que para cualquier operación que implique un cambio
significativo en la cuenta como método de acceso, nombre de usuario o
configuración de seguridad se solicite las credenciales de autenticación

19. Uso de URL mágicas y formularios ocultos: No hay nada que impida que un
usuario mire el contenido de origen y luego envíe un formulario "actualizado" con
una información modificada (utilizando Perl, por ejemplo) al servidor. Los campos
ocultos no están realmente ocultos en absoluto. Muchas aplicaciones basadas en
web llevan información de autenticación u otros datos importantes en las URL. En
algunos casos, estos datos no deben hacerse públicos, ya que pueden utilizarse
para secuestrar o manipular una sesión

La información es leída desde la web a través de un formulario o una URL. Los

datos se proporcionan desde un canal no seguro y son usados para autenticaciones
falsas.

20. Uso de sistemas basados en contraseñas débiles: el error más común que se
cometen en las empresas en temas de ciberseguridad.
 Si con las claves que utilizamos para nuestras cuentas personales ya hay que tomar
ciertas precauciones (y los datos revelan que no lo hacemos) con las que dan
acceso a la información de nuestra empresa, ya nos podemos imaginar.
Para ello, debemos seguir las recomendaciones habituales para crear una buena
contraseña:

 Evitar que contenga información personal sobre nosotros.

 No usar la misma clave en diferentes lugares.
 Que contenga números, símbolos y letras, todo ello mediante
una combinación de mayúsculas y minúsculas

21. Pobre usabilidad: La usabilidad se refiere a la capacidad de un software o sistema

interactivo (una web) de ser comprendido, aprehendido, usado
fácilmente y atractivo para un usuario, en condiciones específicas de uso. También
es la efectividad, eficiencia y satisfacción con la que un producto permite alcanzar
objetivos específicos a usuarios específicos en un contexto de uso específico.

Una de las amenazas más importantes a la hora de analizar los riesgos de una
aplicación son los errores de usuario. Y no sólo por su frecuencia de aparición, sino
por el elevado impacto que pueden llegar a causar. ¿No es acaso la poca usabilidad
de las aplicaciones una de las causas principales de que los usuarios cometan
errores? Por lo tanto, si mejoramos la usabilidad estaremos mejorando también la
seguridad de la aplicación, al disminuir la probabilidad de que el usuario cometa
errores. ¿Acaso no es más fácil cometer errores manejando una aplicación en línea
de comandos que utilizando una buena interfaz gráfica? ¿Cuántos errores de uso
se pueden llegar a evitar con un buen diseño, menús contextuales, ayudas
emergentes e interfaces intuitivas? Y en sentido contrario... ¿no es acaso un factor
de riesgo el hecho de que un usuario se pueda enfadar con la organización debido
a lo poco usables que son las aplicaciones que le facilita?