Este documento describe métodos para construir software fiable, incluyendo pruebas de penetración que identifican vulnerabilidades a través de la simulación de ataques. Explica los análisis estáticos y dinámicos utilizados en las pruebas de intrusión, así como herramientas asociadas a cada fase del proceso. Concluye que las pruebas de penetración ayudan a detectar vulnerabilidades en aplicaciones web y a mejorar la seguridad mediante el seguimiento periódico de vulnerabilidades comunes.

1. Métodos para la Construcción de Software Fiable
Priscill Smilce Orue
Escuela Técnica Superior de Ingeniería Informática,
Universidad de Málaga,
Málaga - España
31 de enero de 2012
Introducción
La ingeniería de software busca diseñar, desarrollar e implementar he-
rramientas cada vez más ables, válidas, seguras y consistentes. Es por este
motivo que la ANSI denió el concepto de Fiabilidad del Software como: la
probabilidad de una operación libre de errores del software para un periodo
especíco de tiempo dentro de un entorno delimitado [6]. Dentro del contex-
to de la web, se aplican las Pruebas de Penetración o Pruebas de Intrusión
(en inglés Penetration Testing ). Por medio de tales pruebas, los evaluadores
descubren vulnerabilidades por medio de la simulación de ataques a una apli-
cación web determinada. Tales ataques se basan en técnicas automatizadas
que recolectan información sobre la web objetivo y analiza las respuestas de
la aplicación para determinar si los ataques fueron exitosos [2].
Este trabajo describe aspectos relacionados a conceptos de abilidad del
software, pruebas de penetración y análisis estáticos y dinámicos empleados
en pruebas de intrusión a aplicaciones web, como mecanismos de verica-
ción y comprobación de la seguridad. Además, se presentan herramientas
asociadas al tema, de manera a relacionar la teoría con la práctica. Para
la realización de este trabajo, la composición se llevó a cabo con el editor
A
L TEXy se consultaron diversas fuentes secundarias, con el n de ofrecer la
información mas actualizada posible.
1. Fiabilidad del software
A medida que la funcionalidad de las operaciones computacionales se
vuelven más esenciales y complicadas en la sociedad moderna y las aplicacio-
1

2. nes de software críticas aumentan en tamaño y complejidad, la abilidad del
software se vuelve más importante. La abilidad del software es un atributo
de la calidad del software, junto a la funcionalidad, usabilidad, rendimiento,
facilidad de mantenimiento, capacidad y documentación [6]. En los últimos
años, los costos del desarrollo de software y los costos de errores en el mismo
representan los mayores gastos. Por este motivo, se han llevado a cabo acti-
vidades de investigación en la ingeniería de la abilidad del software durante
los últimos 25 años, y más de 50 modelos estadísticos han sido propuestos
para estimar la abilidad del software. Este campo busca sistemáticamente
reducir o eliminar las fallas de sistemas que puedan afectar al rendimiento
de las aplicaciones [8].
2. Pruebas de Intrusión ( Penetration Tests )
Las aplicaciones Web son usadas para proveer funcionalidad que permite
a las empresas construir y mantener relaciones con sus clientes. La informa-
ción almacenada por las aplicaciones web es por lo general condencial, y
si es obtenida para usos malintencionados, su exposición podría resultar en
pérdidas signicativas tanto para clientes como empresas [2].
Una de las técnicas empleadas para lograr la abilidad de las aplicacio-
nes web son las Pruebas de Intrusión (en inglés Penetration Tests ). Estas
pruebas identican vulnerabilidades en sitios web por medio de las simula-
ciones de ataques. Aunque las pruebas de intrusión no pueden garantizar que
todas las vulnerabilidades sean identicadas en una aplicación, la misma es
popular entre los desarrolladores porque: (1) generalmente tiene una baja
tasa de reportes de falsa vulnerabilidad debido a que las descubre explotán-
dolas; (2) verica las aplicaciones dentro de un contexto, lo cual permite el
descubrimiento de vulnerabilidades que surgen debido al entorno desplegado
de la aplicación web; y (3) provee entradas concretas para cada reporte de
vulnerabilidad que puede guiar a los desarrolladores a corregir el código [2].
El proceso de la prueba de intrusión puede ser dividido en tres fases.
Halfond [2] plantea el esquema 1 para resumirlas:
Recolección de información: se selecciona una aplicación web a evaluar
y se obtiene información sobre la misma aplicando diversas técnicas, co-
mo la exploración automática (automatic scanning), rastreo web (web
crawling), e ingeniería social.
Generación de ataques: es el desarrollo de ataques a la aplicación bajo
evaluación. Esta fase puede ser automatizada al personalizar ataques
2

3. conocidos o al emplear scripts de ataques automatizados.
Análisis de respuestas obtenidas: una vez que los ataques han sido
efectuados, los evaluadores realizan un análisis de los resultados para
determinar si los ataques fueron exitosos y preparan un reporte nal
sobre las vulnerabilidades descubiertas.
Figura 1: Proceso de las Pruebas de Intrusión
3. Análisis estáticos de las Pruebas de Intrusión
Livshits [3] describe algunas pruebas de intrusión aplicando análisis está-
ticos para detectar vulnerabilidades, por ejemplo la técnica de Inyección SQL
(SQL Injection ), scripts de sitios (cross-site scripting ) y ataques separados
de HTTP (HTTP splitting attacks ). Estas técnicas están basadas en análisis
escalables y precisos. Los análisis estáticos pueden requerir o no acceso al
código fuente de la aplicación.
Cuando se accede al código fuente para efectuar las pruebas, lo primero
que se lleva a cabo es traducir dicho código a un modelo intermedio [1].
Se realizan varios tipos de análisis y nalmente se presentan los resultados.
Estos tres pasos están gracados en 2. La ventaja de este enfoque es que es
más rápido que una revisión manual del código fuente, y se puede analizar
el código sin ejecutarlo. Su desventaja es que analiza programas que fueron
escritos sin considerar la seguridad, y el evaluador puede encontrarse con
múltiples paradigmas y tecnologías, lo cual ralentiza el trabajo.
En el sistema propuesto por [3], los usuarios de la herramienta describen
los patrones de vulnerabilidad de mayor interés en PQL (Program Query
3

4. Figura 2: Proceso estático con acceso al código
Language, lenguaje para expresar patrones de eventos u objetos con sinta-
xis similar a Java [9]). La herramienta, tal como se lo graca en 3, aplica
consultas especicadas por los usuarios a Java bytecode y encuentra todas
las posibles coincidencias estadísticamente. Los resultados del análisis son
integrados a Eclipse, haciendo que todas las vulnerabilidades sean fáciles de
examinar y solucionar como parte del proceso de desarrollo. Su principal ven-
taja es que puede encontrar todas las violaciones de seguridad sin ejecutar
la aplicación, por lo que el acceso al código no es necesario.
Figura 3: Arquitectura de un análisis estático
4. Análisis dinámicos de las Pruebas de Intrusión
Tradicionalmente, las herramientas de análisis estático son usadas du-
rante el proceso de desarrollo de la aplicación para asegurar la calidad del
producto. Por otra parte, los análisis dinámicos se utilizan durante la fase de
despliegue, asegurando la protección de la aplicación web en tiempo de eje-
cución [7]. Halfond [2] agrega que el enfoque dinámico automatiza el análisis
de las respuestas obtenidas, para determinar si los ataques tuvieron éxito.
Un modelo propuesto que aplica el análisis dinámico toma los datos de
entrada del proceso de evaluación funcional de una aplicación web [7]. Es-
te enfoque se basa en los casos de evaluación preparados por el equipo de
4

5. pruebas. Los argumentos que favorecen este análisis son los siguientes:
1. Al enviar patrones de ataques reales, es posible evaluar datos de rutinas
de validación para lograr la exactitud, no tratarlos ciegamente.
2. La implementación de análisis dinámicos conoce la aplicación web por
dentro, entonces pruebas de intrusión más precisas pueden ser genera-
das. Estos son dos ejemplos que ilustran este concepto:
Suponiendo que en cierto módulo el parámetro HTTP está vin-
culado únicamente con la construcción de la respuesta HTTP,
entonces no tiene sentido evaluarlo con otros valores que ataques
XSS.
Los parámetros POST insertados dentro de una base de datos
como claves pueden ser identicados. Luego de este paso, se puede
aplicar un algoritmo especial de control para vericarlos.
En la Figura 4, se muestra un ejemplo del enfoque dinámico [7]. La prime-
ra fase consiste en las siguientes acciones: evaluación de casos preestablecidos,
generación de trazas de ejecución y posterior análisis. El objetivo consiste en
determinar el conjunto de posibles vulnerabilidades. Esto es logrado por la
aproximación de la aplicación web con un conjunto de DDGs interconecta-
dos ( del inglés Data Dependency Graph, Grafo de Dependencia de Datos).
Luego se aplica el modelo mejorado de Tainted Mode.
Figura 4: Esquema general de la integración de Pruebas de Intrusión con el
Análisis Dinámico
En la segunda fase, varios ataques son enviados a la aplicación web para
ser vericados. Se considera que hay vulnerabilidades si patrones maliciosos
5

6. fueron encontrados. El resultado es la lista de vulnerabilidades que fueron
validadas con éxito con las pruebas de intrusión y una lista adicional de
posibles vulnerabilidades. La posible vulnerabilidad es reportada como un
tópico por el modelo mejorado de Tainted Mode que no fue conrmado con
las pruebas de intrusión y puede ocurrir por dos causas: puede ser un falso
positivo, o puede ser el resultado de una base de datos de patrones maliciosos
incompleto que fue utilizado durante las pruebas de intrusión [7].
5. Herramientas para Pruebas de Intrusión
El Departamento de Seguridad Nacional de EEUU arma que muchas
organizaciones aplican un enfoque híbrido, entre análisis estáticos y diná-
micos. Este factor ha favorecido al desarrollo de estándares para mantener
una amplia colección de herramientas para las pruebas de intrusión [4]. El
PTES(del inglés Penetration Testing Execution Standard ) detalla las técnicas
y herramientas para las pruebas de intrusión [10]. La selección de las mismas
depende de la profundidad de las pruebas a ser aplicadas. Se consideran las
siguientes categorías:
Herramientas requeridas: lo primero es tener conocimiento de los sis-
temas operativos más usados, de uso de máquinas virtuales, equipos
de radio frecuencia y software dedicado. Las máquinas virtuales facili-
tan tener múltiples instancias de sistemas operativos ejecutándose en
una estación de trabajo. Dentro del contecxto del software, hay va-
rias herramientas disponibles. Algunas más comunes son: metaesploit
(conjunto de herramientas de explosión remota), nexpose (scanner de
vulnerabilidad), nessus (localizador y documentador de vulnerabilida-
des), openvas (scanner de vulnerabilidades), Social-Engineer Toolkit
(útil para realizar ataques contra el elemento humano).
Recolección de Inteligencia: es la fase en el cual los datos o inteligen-
cia son recolectados para guiar las acciones de evaluación. Incluye in-
formación sobre empleados,productos, planes, etc. A nivel más amplio,
agrega información sobre empresas competidoras dentro del mercado.
En este nivel, se aplican los conceptos del OSINT (del inglés Open
Source Intelligence ), que busca todos los datos sobre la empresa y sus
competidores en fuentes de información públicas.
Análisis de vulnerabilidades: se emplea para identicar y evaluar los
riesgos de seguridad a partir de las vulnerabilidades detectadas con las
6

7. herramientas anteriores. Se divide en dos áreas: identicación y valida-
ción. El segundo busca reducir el número de vulnerabilidades identi-
cadas a aquellas que son reales. Para la evaluación de vulnerabilidades
se emplean herramientas como el OpenVAS (Open Vulnerability As-
sessment System) o el Nessus, aplicable sobre Windows y Linux.
Explotación: existen varias técnicas de explotación (fuzzing, sning,
etc) y cada una de ellas tiene su propio conjunto de herramientas.
Por ejemplo, para la técnica de Fuerza Bruta, que consiste en cambiar
nombres de usuarios y contraseñas hasta encontrar una coincidencia, se
tiene la herramienta Brutus (Windows), Medusa, NCrack, etc, que ata-
can diversos servicios (ejemplos: FTP, HTTP, HTTPS, ICQ, IRC,
IMAP, LDAP, MS-SQL, MySQL, NCP, NNTP, Oracle, POP3,
PostgreSQL, SSH, etc.)
Post-Explotación: son las actividades que se llevan a cabo una vez que
el sistema ha sido accedido o comprometido. Las actividades dependen
del sistema operativo, pueden ir del rango del whoami hasta obtener
listados de cuentas locales y extraer las contraseñas del registro.
Reporte: existen dos niveles para reportar los hallazgos, que son eje-
cutivo y técnico; el primero tiene un enfoque administrativo-gerencial
en el que se explica en vocabulario simple las implicancias de los resul-
tados y se sugiere una ruta de acción. En el segundo, se incluyen los
datos hallados, junto con muestras de pantallas para dar soporte a los
resultados encontrados.
Conclusiones
Las Pruebas de Intrusión (Penetration Tests ) sirven para detectar vul-
nerabilidades en aplicaciones web y ayudan a la toma de decisiones que
conciernen a la seguridad de las mismas. Las técnicas estudiadas en este
trabajo fueron los análisis estáticos y dinámicos, con una gran variedad de
herramientas disponibles para cada fase del proceso de pruebas, cubriendo
aspectos técnicos como humanos. Los reportes de resultados de las pruebas
son considerados para reducir todo posible la cantidad de puntos débiles
de una aplicación web. Por lo tanto, es importante conocer con detalle las
técnicas y herramientas de Penetration Testing desde el momento en que se
recolectan los datos de la empresa objetivo, hasta el contenido de los reportes
a ser entregados. Otra recomendación es hacer un seguimiento periódico de
7

8. las vulnerabilidades más comunes. Por ejemplo, la Fundación OWASP publi-
ca cuales son las vulnerabilidades de seguridad más críticas en aplicaciones
web [5].
Referencias
[1] Jeremiah Grossman and Jacob West. Correlating static and dynamic
analysis results. Sitio web; accedido 19-Dic-2011.
[2] William G. J. Halfond*, Shauvik Roy Choudhary, and Alessandro Or-
so. Improving penetration testing through static and dynamic analysis.
Software Testing, Verication and Reliability, 21(3):195 214, Septem-
ber 2011.
[3] V. Benjamin Livshits and Monica S. Lam. Finding security vulnerabi-
lities in java applications with static analysis. SSYM'05 Proceedings of
the 14th conference on USENIX Security Symposium, 14, 2005.
[4] U.S Department of Homeland Security National Cyber Security Divi-
sion (NCSD). Build security in, 2011. Sitio Web; accedido 19-Dic-2011.
[5] Fundación OWASP. Las 10 vulnerabilidades de seguridad mas criticas
en aplicaciones web, 2007. Sitio Web; accedido 12-Ene-2012.
[6] Jiantao Pan. Software reliability, Spring 1999. Sitio Web; accedido
10-Ene-2012.
[7] Andrey Petukhov and Dmitry Kozlov. Detecting security vulnerabilities
in web applications using dynamic analysis with penetration testing,
2008. Sitio Web; accedido 11-Ene-2012.
[8] Hoang Pham. Software reliability, Diciembre 1999. Sitio Web; accedido
10-Ene-2012.
[9] Sourceforge. Pql: Program query language. Sitio web; accedido 11-Ene-
2012.
[10] Penetration Testing Execution Standard. Penetration testing execution
standard, 2011. Sitio Web; accedido 19-Dic-2011.
8