2017 International Conference on Information Systems and Computer Science
Acometiendo un ERP
Evaluando la seguridad de un software desarrollado en APEX 5
Undertaking an ERP
Evaluating the security of APEX 5 developed software
Esteban Crespo 1, 2, Catalina Astudillo 1, 2, Marcos Orellana 1, 2
1
LIDI, 2 Escuela de Sistemas y Telemática
Universidad del Azuay
Cuenca, Ecuador
ecrespo@uazuay.edu.ec, cvastudillo@uazuay.edu.ec, marore@uazuay.edu.ec
Resumen — La seguridad de la información es una preocupación
creciente en empresas y organizaciones, siendo más alta aun
cuando se vincula a plataformas financieras donde existe
información sensible. El presente trabajo resume las técnicas
utilizadas en el pentesting realizado tanto al servidor que aloja al
producto informático, como al software ERP desarrollado en la
herramienta APEX 5 por la Universidad del Azuay. Se han
contemplado seis etapas que sugiere una prueba de penetración: i)
la conceptualización, que es la etapa que permite definir el alcance
de las pruebas a realizar; ii) la preparación del laboratorio en la
que se definen algunas de las herramientas que servirán para el
inicio de las pruebas de seguridad; iii) la obtención de información
que hace referencia a las etapas de reconocimiento y escaneo en la
que se identifican posibles objetivos para luego explorar con
mayor profundidad algunas características intrínsecas que
puedan ser aprovechadas; iv) el análisis de las vulnerabilidades
encontradas en la etapa anterior; v) la explotación de esas
vulnerabilidades mediante la selección de herramientas; y vi) la
post explotación, etapa en la que se contempla la destrucción de
evidencias del ataque y la conservación de la conexión y los accesos
logrados para extraer información. Todas estas pruebas fueron
efectuadas dentro de las instalaciones de la Universidad del Azuay,
considerando el ambiente de desarrollo en el que actualmente se
encuentra el proyecto ERP.
Palabras clave: Pentesting, Seguridad Informática, APEX, ERP,
Hacking.
Abstract — Actually, information security is an increasing concern
in organizations and enterprises, higher even in financial
platforms, where resides a big amount of sensible data. In this
paper, we contemplate the different techniques used in the
pentesting performed into the server that hosts the software and
the ERP software, developed by Universidad del Azuay, using
APEX 5 as development platform, including the six penetration
test stages: I) conceptualization, stage that allows defining the
scope of the tests to be performed. II) Preparation of the
laboratory, which defines some of the tools that we used to initiate
security tests. (III) Obtaining information, that refers to the stages
of recognition and scanning, in which possible objectives will be
identified and then to explore in greater depth some intrinsic
978-1-5386-2644-3/17 $31.00 © 2017 IEEE 174
DOI 10.1109/INCISCOS.2017.24
characteristics that can be exploited. (IV) Analysis of the
vulnerabilities encountered in the previous stage. (V) Exploitation
of those vulnerabilities through the selection of appropriate tools
to achieve this purpose. And vi) The post-exploitation stage, where
the destruction of evidence of attack, the conservation of the
connection and the accesses obtained to extract information are
contemplated; tests explained here were carried out within the
facilities of the Universidad del Azuay, considering the
development environment in which the ERP project is currently
located.
Keywords: Pentesting, Information Security, APEX, ERP,
Hacking
I. INTRODUCCIÓN
La seguridad de la información y la seguridad informática se
basan en tres principios fundamentales: i) la disponibilidad, que
hace referencia a que la información debe estar dispuesta en el
momento que se la requiera, ii) la confidencialidad que se refiere
al acceso autorizado a la misma, y iii) la integridad, que hace
relación a que la información debe ser alterada bajo
conocimiento. Además, se debe considerar que la información
es el recurso más valioso para una organización, y es más valioso
para quien la tenga en el momento oportuno, además de que
tenga conocimiento de cómo utilizarla; por lo tanto, como
propone Francis Bacon la “información es poder” [1], que para
una empresa u organización es sinónimo de ventaja competitiva.
Las empresas están obligadas a anticiparse a los diversos
escenarios de riesgo de información, debido a una vertiginosa
evolución de la informática, el constante cambio tecnológico, y
el rápido crecimiento de las múltiples transacciones de negocio,
en los que la información y los dispositivos computacionales
están inmersos en escenarios como ataques de hackers, usuarios
del sistema, amenazas lógicas, y una gran variedad adicional.
Pero, debido a la falta de conocimiento sobre cómo protegerla
adecuadamente o a la complejidad exigida por muchas normas
internacionales y mejores prácticas de desarrollo, múltiples
organizaciones descuidan asegurarla tal como lo determinó
Crespo [1] en su estudio para la propuesta de la metodología
ECU@Risk.
Una de las técnicas de evaluación que apoyan al análisis de
brechas de seguridad es el pentesting, análisis que debe ser
realizado por una persona con conocimientos técnicos, pero con
principios éticos. Esta última característica diferencia a un
atacante común, conocido en esta época como un “hacker de
sombrero negro”, que es una persona que irrumpe la seguridad
de la organización con el fin de beneficiarse de la información
en ella almacenada.
Este trabajo resume la experiencia de las pruebas de
penetración aplicadas a un software ERP desarrollado en Oracle
APEX 5 por la Universidad del Azuay, considerando tanto la
técnica de caja negra como la de caja blanca y la de caja gris. La
primera etapa del ataque consistió en hacer un escaneo a ciegas
(caja negra), solamente contando con la dirección IP del servidor
que aloja a este software, la misma que fue provista por la
directora del proyecto UDA ERP.
El trabajo realizado se limita a cinco pruebas, sugeridas por
[2] y [3]: i) identificación del contexto; ii) identificación de las
vulnerabilidades en el código; iii) evaluación cross-site
scripting XSS; iv) inyección SQL y v) denegación de servicios
DDoS.
Con la información obtenida en el ataque, se pudieron
identificar servicios y puertos de escucha que posiblemente no
serían revelados en una prueba de caja blanca; comprobando que
la lista no contenía únicamente al TCP 8080. Por otro lado, la
información entregada en la técnica de caja blanca ha servido
para confirmar los resultados obtenidos en la técnica de caja
negra.
El proyecto ERP es una iniciativa de la Universidad del
Azuay que se viene desarrollando desde el año 2015 como una
solución a las MPYMES del sector manufacturero, quienes por
lo general no cuentan con los recursos económicos suficientes
como para adquirir un software de estas características.
Este trabajo se enfoca a: i) establecer una guía de pruebas de
penetración basada en herramientas para este efecto; y ii)
documentar las pruebas de penetración realizadas al software
ERP que se viene desarrollando en la Universidad del Azuay. El
documento logrado se clasifica de la siguiente manera: i) el
método utilizado; ii) la conceptualización del escenario de
pruebas; iii) la definición del laboratorio de pruebas; iv) los
resultados obtenidos en las diversas fases del pentesting; y v) las
conclusiones obtenidas en las pruebas de evaluación a una
aplicación desarrollada en Oracle APEX 5.
II. MÉTODO UTILIZADO
Como trabajos relacionados a esta evaluación de seguridad
se puede citar al realizado por Viera y Serrao con título “Web
security in the finance sector [4]”, que analiza la seguridad web
en aplicaciones del sector financiero; por otro lado está el trabajo
de López [5] con título “Pentesting on web applications using
ethical - hacking“, que hace referencia al pentesting en
aplicaciones web utilizando hacking ético; y al de Väli y
175
Lopensky [6], que explica la manera de implementar un
analizador de vulnerabilidades y evaluar aplicaciones
desarrolladas con APEX.
En base a la experiencia adquirida por los autores
anteriormente mencionados, para estas pruebas de penetración
se han aplicado los métodos de caja negra (black box), de caja
blanca (white box) y de caja gris (gray box). Según Caballero
[7], la prueba de caja negra consiste en realizar los ataques sin
conocer la estructura interna de la organización, y es realizada
solo con el conocimiento de una dirección IP o la URL provista
por el personal del proyecto o el personal de TI.
La prueba de caja blanca consiste en realizar las pruebas de
ataque considerando toda la información proporcionada, esto es,
diagramas, detalles sobre el hardware, software, sistemas
operativos, firewalls, etc. Esto ayuda a que los ataques sean
objetivos, sin embargo, pueden quedar algunos detalles sueltos
debido a que no se consideran otros elementos que podrían ser
descubiertos con la técnica de ataque de caja negra [7].
Para Caballero [7], la prueba de caja gris simula a un ataque
realizado por un empleado descontento, el cual tiene un nivel de
privilegios adecuado, además de contar con permisos de acceso
a la red interna. La información obtenida en el ataque permitió
identificar servicios y puertos de escucha que posiblemente no
serían revelados en una prueba de caja blanca.
La información provista por esta última técnica permitió
confirmar los resultados obtenidos con la técnica de caja negra.
En relación con la prueba de caja gris, se puede considerar a las
pruebas internas con un usuario que tenga acceso a la aplicación,
el mismo que utilizará los privilegios con los que cuenta, pero
con sentido malicioso.
Como parte de la metodología se incluye también un estudio
descriptivo cuantitativo con la cual se ejecutará un experimento
de interrelaciones, comparando los resultados de las diferentes
herramientas utilizadas en cada una de las etapas del ataque,
además de la aplicación de la metodología explicativa y
concluyente, donde se evidenciarán los resultados de la causa y
el efecto que tiene la prueba de penetración.
III. ETAPA DE CONCEPTUALIZACIÓN
La etapa de conceptualización es sumamente importante
porque aquí se definen los objetivos de la prueba de penetración
[8]. Ha sido importante preguntar al equipo de desarrollo del
ERP: ¿Qué le preocupa? ¿Qué parte de la infraestructura o del
sistema es de la que sospecha vulnerabilidades? ¿Existen
dispositivos delicados que deban ser considerados mientras se
realiza el pentesting?
Además de lo señalado anteriormente, es importante conocer
el ámbito de direcciones IP que se van a analizar y vulnerar, el
horario de pruebas, la información del contacto que monitoreará
las actividades constantemente, y, sobre todo, contar con la
autorización escrita. Si el objetivo no forma parte de la
organización contratante, es importante que este tercero conozca
formalmente las pruebas a las que será sometido [8].
Se define, por lo tanto, realizar las pruebas al servidor de
desarrollo que mantiene la Universidad del Azuay para el
proyecto UDA ERP, equipo que mantiene una dirección IP Resultados obtenidos
privada en la red 172.16.x.x, permitiendo el acceso al aplicativo NMAP Sparta
mediante el puerto 80, únicamente dentro de los predios de la 22, 25, 1521, 3700,
institución. Además, se ha indicado que el software está 3820, 3920, 4848,
Puertos 22, 25, 1521, 4848, 7676,
desarrollado en la herramienta Oracle APEX. abiertos 8080, 8181
7676, 7776, 8080,
8181, 8686, 13335,
IV. PREPARACIÓN DEL LABORATORIO 17210, 29573
Tipo de
TCP TCP
puertos
La preparación del laboratorio exige la identificación de las Sistema Virtualizado en Oracle Virtualizado en Oracle
herramientas que serán utilizadas para la ejecución del Operativo Virtual Box Virtual Box
pentesting. Para esta validación de seguridad se ha considerado
el uso de herramientas Open Source, incluyendo a KALI Linux,
distro que contiene más de 300 herramientas para pentesting [9].
Topología n/a
Por otro lado, se ha considerado el uso de VEGA, una
herramienta que permite el escaneo de vulnerabilidades y que
otorga una plataforma para pruebas de seguridad de entornos
web, que permite la ejecución automatizada de scripts de análisis
Servidor
de inyección SQL (SQL Injection) o scripts cruzados (Cross-Site web
Glassfish 4.1.1 Glassfish 4.1.1
Scripting). Se suma el análisis del contexto con Nikto, que es un Métodos
escáner actualizable para la detección de vulnerabilidades de HTTP POST, GET POST, GET
servidores web. aceptados
Acepta
En relación con las pruebas al código fuente, se ha utilizado solicitudes Si Si
OWASP ZAP, APEX SERT y Web Developer Plug In. OWASP ICMP
ZAP es una suite que permite realizar pruebas de seguridad en
aplicaciones y servicios WEB, APEX SERT (Security
Evaluation and Recomendation Tool) es una herramienta que VI. IDENTIFICACIÓN DE VULNERABILIDADES
sirve para evaluar las aplicaciones desarrolladas específicamente
en APEX, y Web Developer Plug In, desarrollada por Chris
Pederik, que sirve para la evaluación de un sitio web, que, para En base a la información obtenida, se procedió con la
este trabajo, será aplicado específicamente en el análisis de identificación de las vulnerabilidades para los escenarios
cookies. propuestos, los mismos que se detallan a continuación.

V. OBTENCIÓN DE INFORMACIÓN
A. Identificación de vulnerabilidades en el código fuente

Para las pruebas de Pentesting al software ERP de la

Universidad del Azuay, se han considerado cinco escenarios: i)
identificación del contexto, ii) identificación de las
vulnerabilidades en el código fuente, iii) análisis de
vulnerabilidades mediante la técnica Cross-Site Scripting –
XSS, iv) análisis de vulnerabilidades mediante la técnica de
inyección SQL, y v) pruebas de denegación de servicio o DDoS.
A. Identificación del contexto
Para la identificación del contexto se ha utilizado la técnica
de caja negra, y los resultados obtenidos se han comparado con
la técnica de caja blanca y caja gris. Con la aplicación de las
herramientas NMAP y SPARTA, incluidas en el distro Kali, se
han obtenidos los siguientes resultados:
Tabla 1: Identificación del Contexto
Resultados obtenidos
NMAP Sparta
Puertos
7 17
encontrados
Generalmente los desarrolladores realizan pruebas de
seguridad software una vez que el mismo ha sido creado, otros
cuando se encuentra en etapa de despliegue; sin embargo, puede
terminar como una práctica ineficaz y restrictiva debido a su
costo. Una de las mejores alternativas para evitar problemas con
los “bugs” o fallos que aparecen en el software de producción,
es el de mejorar su ciclo de vida de desarrollo de software
(SDLC), perfeccionando los niveles de seguridad en cada una de
las etapas que sugiere el proyecto OWASP [3]: i) Definir, ii)
Diseñar, iii) Desarrollar, iv) Implementar, y v) Mantener.
En esta etapa se realizó una indagación al objetivo, aplicando
inicialmente la herramienta “Nikto”, que ha arrojado las posibles
vulnerabilidades de código fuente que tiene el objetivo.
Posteriormente se utilizó OWASP Zed Attack Proxy, con
métodos GET y POST, cuyos resultados fueron cabeceras de
contenido X-Content-Type-Options y cabeceras X-Frame-
Options no establecidas, lo que podría facilitar ataques de
secuestro ClickJacking o exponer información de la aplicación
de forma involuntaria [3].
En cuanto a la validación de datos, se tomó como ejemplo la
validación de un número de cédula de identidad ecuatoriana, en
el cual se detectó la omisión en la validación del número de
cédula, aceptando sin inconvenientes el número 1212121212,

176
número resultante del algoritmo de Luhn conocido también
como módulo 10, y que es utilizado en el cálculo del código de
control, utilizado en la validación de números de cédula o
tarjetas de crédito [10].
En cuanto a la validación de contraseñas, la fortaleza de las
mismas puede ser un impedimento para el atacante, debido a la
cantidad de transacciones que le tomaría realizar. Así, según
Spendolini [11], una contraseña con solo 5 caracteres de
longitud, y solo con letras minúsculas del alfabeto (por ejemplo,
la contraseña por omisión de un enrutador: “admin”), puede ser
vulnerada en 0.000124 segundos utilizando fuerza bruta si se
trata de un escenario fuera de línea, y en un escenario en línea,
en 3.43 horas la contraseña estaría vulnerada.
Una característica interesante propia de APEX es la
generación de tokens aleatorios para cada sesión de usuario. Así
por ejemplo, la URL de la aplicación
“http://localhost:8080/apex/f?p=101:2:9342982341417:::::”
indica que f?p=101 es el ID de aplicación, 2 hace referencia al
ID de la página, y 9342982341417 que en este caso es el valor
aleatorio generado como único para una sesión establecida,
número que no se genera si no se utiliza el asistente de desarrollo
[11].
B. Identificación de vulnerabilidades de código cruzado
Se aplicó la herramienta VEGA considerando los módulos
de inyección “XSS injection checks” a fin de determinar si el
sitio es vunerable a ataques XSS, así como también se utilizaron
los módulos “HTTP trace probes” para solicitar al servidor la
repetición de la solicitud TRACE de nuevo al cliente, situación
usada comúnmente por las cookies de sesión. “HTTP Header
Checks” fue usado para validación de vulnerabilidades de
cabecera, “HTTP Authentication Over Unencrypted HTTP” y
“Cleartext password over HTTP” para identificar
vulnerabilidades sobre protocolos no cifrados.
Además, ha dado como resultado la alerta de que se no se ha
especificado un conjunto de caracteres para las respuestas del
servidor, lo que puede generar un problema de seguridad si el
recurso afectado contiene contenido generado dinámicamente
por los usuarios.
C. Identificación de vulnerabilidades de inyección SQL
Utilizando VEGA, y seleccionando los módulos “Blind SQL
Injection Timing”, “Blind SQL Text Injection Differential
Checks” y “Blind SQL Injection Arithmetic Evaluation
Differential Checks”.
Posteriormente se aplicó SQLMAP, asignando los
parámetros “--technique=BEUS” y un nivel de agresividad de
ataque elevado “--level 3”.
Como resultados, la aplicación desarrollada en APEX no ha
presentado vulnerabilidades ante ataques de inyección SQL.
177
D. Identificación de vulnerabilidades de denegación de
servicio.
Para comprobar el nivel de seguridad ante ataques de
denegación de servicio, en base a la información obtenida, se
aplicaron las técnicas de ataque “ICMP Flooding”, “SYN
Flooding” y “Ping of death”.
La herramienta hping3 generó paquetes a discreción, es
decir, crear y analizar paquetes TCP/IP. Para evadir al firewall,
será necesario generar peticiones aleatorias que terminarán en la
dirección 8080, puerto de escucha de la aplicación. Para generar
dichas peticiones, se ha ejecutado el comando con la opción “--
rand-source”. De acuerdo a lo que se puede observar en la figura
1, el tráfico capturado visualiza las direcciones aleatorias, las
mismas que el firewall las considerará como normales.
Figura 1: Tráfico capturado de las direcciones aleatorias generadas
Así, se realizó el primer ataque de denegación de servicio.
Para ello, se aplica el parámetro “--flood” para la inundación
ICMP. Como resultado, el equipo objetivo deja de responder.
A continuación, se atacó utilizando inundación SYN (SYN
Flood). Este tipo de ataque acciona un número elevado de inicios
de conexión que nunca son finalizados, dejando al servidor a la
espera del ACK final, de esta manera, se consume recursos de
forma inesperada y el usuario ya no puede acceder a la
información [12].
Utilizando el Metasploit Framework de Kali, con la
herramienta “use /auxiliary/dos/tcp/synflood”, se aumenta el
parámetro snaplen a 65535 bytes, y se reduce el tiempo de
emisión de paquetes a 100 ms. De esta manera, al ejecutar el
exploit, el servidor quedó nuevamente fuera de servicio.
Finalmente se procede con la prueba del “Ping de la muerte”.
Si bien se trata de una técnica antigua, puede darse el caso de
que el equipo objetivo no esté preparado para soportar el ataque.
Se hace la prueba enviando un ping constante al objetivo, con un
tamaño de paquete de 65535 bytes. En este caso no se produjo
una denegación de servicio.
E. Simulación de un ataque de fuerza bruta
Simulando un ataque de diccionario en la que se incluyen
todas las letras minúsculas del alfabeto y los números del 0 al 9,
es decir una combinación de 36 caracteres posibles, con la
aplicación Crunch disponible en el distro Kali, se ha generado
un total de 2.176’782.336 entradas de contraseñas posibles, que
posteriormente fueron utilizadas en el ataque de fuerza bruta
realizada con la aplicación Hydra. Hay que considerar que, para
esta prueba, se requiere un espacio de disco considerable, pues Puerto TCP 22 Abierto El puerto 22 no es cifrado y por 4 4
el archivo que contiene estas entradas fue superior a los 14Gb. lo tanto es propenso a ataques
MITM
Puerto TCP 25 Abierto El puerto 25 no es cifrado y por 3 3
lo tanto es propenso a ataques de
fuerza bruta
VII. MODELAMIENTO DE AMENAZAS Puerto TCP 25 Abierto El puerto 25 no es cifrado y por 3 3
lo tanto es propenso a ataques
MITM
Puerto TCP 8080 Abierto Reemplazo de un recurso 4 3 4 4
Según el Proyecto OWASP [3], el modelamiento de específico mediante el método
amenazas es una representación estructurada de toda la POST.
información que afecta a la seguridad de una aplicación, y que Puerto TCP 8080 Abierto Eliminación de un recurso 3 3 4 4
específico mediante el método
se ha vuelto bastante popular en los últimos años. Menciona que DELETE.
Microsoft ha publicado un libro sobre su proceso y que incluye Puerto TCP 8080 Abierto HTTP Method (‘Allow’ Header) 3 3
a este proceso como una actividad clave en su Ciclo de vida de Métodos de riesgo potencial:
PUT, DELETE
desarrollo seguro (S-SLDC).
Puerto TCP 8181 Reemplazo de un recurso 4 3 4 4
Microsoft [13], en su análisis de modelo de amenazas sugiere Abierto específico mediante el método
POST.
realizar 7 pasos: i) Recopilar información básica, ii) crear y Puerto TCP 8181 Abierto Eliminación de un recurso 3 3 4 4
analizar el modelo de amenazas, iii) analizar las amenazas, iv) específico mediante el método
identificar las técnicas y tecnologías de mitigación, v) DELETE.
Puerto TCP 8181 Abierto HTTP Method (‘Allow’ Header) 3 3
desarrollar el modelo de seguridad y las consideraciones de Métodos de riesgo potencial:
implementación, vi) implementar y probar las mitigaciones y PUT, DELETE
vii) mantener el modelo de amenazas sincronizado con el diseño. La cabecera anti secuestro Ataques clickjacking 2 2 2 2
de clic (anti-clickjacking
Según Alcides [14], el riesgo informático es “un conjunto de X-Frame-Options header)
no está presente
normas y procedimientos que son aplicados para salvaguardar El servidor presenta WebBrowsing Fingerprinting 2 2 2 2
un sistema informático, cuya finalidad es garantizar que todos posibilidades de fuga
los recursos que conforman el sistema informático sean mediante ETags
La cabecera de protección Ataques XSS 3 3 3 3
utilizados para el fin que fueron creados sin ninguna contra ataques Cross Site
intromisión” Scripting XSS no está
definida
Para la creación y el modelamiento de amenazas, se han Puerto TCP 1521 Abierto Envenenamiento TNS [16] 3 3 3 3
utilizado las herramientas sugeridas en la metodología Puerto TCP 3700 Abierto Portal of Doom. Usado 3 3 3 3
comúnmente por troyanos [17]
ECU@Risk [15], las mismas que permitieron valorar los riesgos El sitio utiliza SSL y la Denegación de servicios 3 1 3 3
en base a las amenazas identificadas y valoradas. Aplicando la cabecera de transporte
matriz de impacto (Figura 2) sugerida por la metodología, seguro estricto (Strict-
Transport-Security HTTP
Matriz de Impacto Valoración Header) no está definida.
La cabecera de opciones Denegación de servicios 3 1 3 3
E – Extremo 5 de tipo de contenido X-
Content-Type-Options no
A – Alto 4 está establecida
El nombre de host Suplantación de identidad 4 1 3 4
M – Moderado 3 ‘172.16.1.87’ no
B – Menor 2 concuerda con el nombre
del certificado
L – Leve 1 Servidor acepta Saturación ICMP 3 3 3 3
solicitudes ICMP
Figura 2: Matriz de impacto. Fuente: [15] Acepta Métodos POST y Inundación HTTP 3 3 3 3
GET
se pudo llegar a la tabla de valoración de amenazas (tabla 2), en TCP utiliza un Syn Flood 3 3 3 3
mecanismo de
las que se incluye la vulnerabilidad identificada, la amenaza que negociación de tres vías.
puede presentarse, y su impacto en términos de Servidor acepta Ping de la muerte 1 3 1 3
solicitudes ICMP
confidencialidad, disponibilidad e integridad. La última Servidor acepta Inundación IP 1 3 1 3
columna hace referencia al valor absoluto de la amenaza, que en solicitudes ICMP
resumen es el valor más alto obtenido de las tres perspectivas. Contraseñas débiles Fuerza bruta 4 2 2 4
Así también, de acuerdo a lo que sugiere la norma, no todas las Contraseñas débiles Ataque de diccionario 4 2 2 4
Cookies Predicción de credenciales 3 2 2 3
perspectivas son afectadas, según el tipo de activo de Interesting Meta Tags Revelación no intencionada de 2 1 1 1
información y la amenaza identificada. Detected información

Tabla 2: Identificación y valoración de amenazas VIII. CONTRAMEDIDAS

Vulnerabilidad Amenaza C D I V
Puerto TCP 22 Abierto El puerto 22 no es cifrado y por 4 4 En base a las vulnerabilidades y amenazas identificadas, se
lo tanto es propenso a ataques de
fuerza bruta.
sugiere priorizar las que mayor impacto pueden ocasionar a la
organización, en este caso, al software ERP y la infraestructura

178
que lo soporta; sin descuidar los correctivos que puedan
realizarse de una forma rápida, como, por ejemplo, denegar las
solicitudes ICMP en el firewall.
Como contramedidas, se han podido establecer las
siguientes:
• Cifrar el puerto de escucha del aplicativo (uso de
HTTPS), y agregar un certificado digital del tipo
Organization SSL, el mismo que permite evaluar la
autenticidad del sitio y la organización que lo respalda.
• Cifrar las bases de datos. Al habilitar esta opción, APEX
utilizará el TDE (Transparent Data Encryption) para
cifrar los archivos de datos asociados. TDE podría cifrar
todos los archivos de bases de datos que son escritos en
el disco, haciéndolos ilegibles a cualquiera que trate de
acceder a los mismos [11].
• Obligar el uso de contraseñas robustas, tanto en la
aplicación ERP como en las diferentes herramientas que
permiten la gestión de la infraestructura tecnológica que
lo soporta, como es el SSH o la base de datos. Según
[11], una contraseña similar a “Pa5sw0rD.!”, le tomará
al atacante 1.83 billón de siglos vulnerarla en modo
online, 18.28 siglos en modo offline y 1.83 años en un
escenario de arreglo de cracking masivo.
• Uso de un segundo factor de autenticación, como por
ejemplo el de envío de código de autorización por SMS,
con el fin de detener los ataques de repetición.
• Cerrar los puertos no utilizados
• Limitar las conexiones SSH al servidor, restringiendo a
los equipos remotos por dirección IP y MAC.
• Deshabilitar la opción de autocompletamiento de
campos en el código fuente del aplicativo.
• Evaluar y limitar el uso de los meta-tags y el tipo de
información que se está entregando en los mismos.
• Establecer el encabezado de respuesta HTTP X-Frame-
Options. Esto sirve para prevenir que la página pueda
ser abierta en un frame, o iframe, lo que evita los ataques
de clickjacking sobre el sitio web
• Establecer los parámetros de X-Frame de acuerdo a las
necesidades del negocio. Los parámetros son: i) DENY,
ii) SAMEORIGIN y iii) ALLOW-FROM URI.
• Para evadir los ataques XSS, se sugiere incluir la
siguiente cabecera: “header('X-XSS-Protection:
1;mode=block' );”.
• Es importante establecer un conjunto de caracteres
válidos para respuesta, como, por ejemplo: AddCharset
utf-8 .html.
• Asegurarse que el servidor de aplicaciones / web
establezca la cabecera Content-Type de forma
apropiada y que establezca el encabezado X-Content-
Type-Options en 'nosniff' para todas las páginas web. En
lo posible, se debe asegurar que el usuario final utilice
un navegador web moderno compatible con los
179
estándares, que no realice MIME-sniffing o que pueda
ser dirigido por la aplicación web / servidor web para
que no realice MIME-sniffing.
• Implementar un IDS/IPS para el análisis de tráfico
malicioso, esto permitirá alertar y bloquear los ataques
de inundación, a los cuales el servidor es vulnerable.
IX. CONCLUSIONES
La seguridad informática no consiste únicamente en la
implementación de herramientas tecnológicas como firewalls o
antivirus. Las contramedidas que aporten a la mitigación de
riesgos y amenazas son parte de una adecuada cultura en el
manejo de información, las técnicas de desarrollo de software,
el lenguaje de programación y la configuración de la
infraestructura computacional.
Según [2], uno de los puntos más críticos de exposición a la
web son los servidores web, que son las herramientas con las que
los usuarios interactúan, y que, además, la mayoría de los
problemas provocados no son por fallas de los servidores o
lenguajes utilizados, sino por malas prácticas de programación.
Una sola herramienta de análisis no es suficiente. Un
pentesting efectivo requiere de la combinación de estrategias y
herramientas para cada una de las etapas que conforma un
análisis. Se han identificado como herramientas importantes al
distro Kali Linux (NMAP, Sparta, HPING3, Wireshark, Hydra,
Metasploit Framework y Cookie Cadger), Mantra Linux (Nikto,
OWASP (Wapiti, W3AF), APEX-SERT, Web Developer Plug
In y VEGA.
Para la identificación y valoración de amenazas y riesgos se
utilizó la herramienta de modelamiento de amenazas de
Microsoft [13], y la metodología para gestión de riesgos de
información ECU@Risk [1].
Las buenas prácticas de seguridad Web no recaen
únicamente en la tecnología que se está utilizando. Muchas
veces al pensar solamente en la usabilidad, se deja de lado
muchos aspectos de seguridad; y cuando se incluyen muchos
aspectos de seguridad, obviamente la complejidad en el uso de
la aplicación para el usuario es elevada. Por esta razón, una
conclusión que puede rescatarse de [2], es el mantener un
equilibrio entre la funcionalidad y la seguridad.
Otra de las buenas prácticas es la de filtrar los datos. Como
se había visto, un número de cédula 1212121212 fue aceptado.
El filtrar los datos de entrada reduce el riesgo de contar con
información errónea en la plataforma.
La importancia del cifrado de datos es inminente. Se pudo
comprobar mediante el uso de un sniffer, y de acuerdo con [2],
cuando un atacante tiene la facilidad de realizar un ataque de
hombre en el medio, se debe preocupar por la exposición de los
datos durante el envío, transmisión y recepción de los mismos.
Por tal razón, es necesario utilizar un protocolo de cifrado de
información. Adicionando a esto, se ha podido ver que un sitio
web es susceptible a ser descargado completamente para luego
ser utilizado en ataques de tipo phishing; por tal razón, la
adopción de certificados digitales que validen, no solo el sitio
web sino además la organización, son obligatorios.
El ataque de fuerza bruta es otro factor que debe ser
considerado en la protección del servidor. Como se había visto,
el puerto SSH (utilizado para la administración remota) acepta
conexiones con las cuales se pudo ejecutar un ataque de este
tipo. Una contraseña simple puede ser fácilmente vulnerada, por
cuanto se recomienda el uso de contraseñas complejas, las
mismas que deben incluir caracteres alfabéticos en mayúsculas
y minúsculas, caracteres numéricos y caracteres especiales.
Una sesión APEX genera identificadores de sesión aleatorios
cuyas cookies expiran al momento de cerrar el navegador, lo que
reduce notablemente la posibilidad de ataques de fuerza bruta
efectivos. Si bien estas cookies no pudieron ser identificadas con
la herramienta Cookie Cadger, han logrado ser encontradas con
el plugin Web Developer de Chrome.
Con el uso de las herramientas VEGA, OWASP ZAP, se han
revelado el uso de los métodos GET, POST, PUT, DELETE
provistos por un sistema web para el acceso a la información. De
los anteriores, los dos últimos deben ser manejados con mucho
cuidado, pues PUT permite cargar contenidos y DELETE
eliminarlos. Estos métodos deben ser analizados y evaluados
antes de su puesta en producción.
Las dos herramientas indicadas anteriormente también han
permitido identificar las cabeceras HTTP expuestas. De estas, se
puede indicar que “Anti-MIME-Sniffing header X-Content-
Type-Options” aún no ha sido establecida a “no sniff”,
permitiendo que navegadores antiguos interpreten el contenido
de una forma diferente a la declarada originalmente.
Si bien una aplicación web puede estar bien desarrollada, la
infraestructura computacional que apoya a sus actividades
también puede verse afectadas si las mismas no son aseguradas
de la forma correcta. En las pruebas realizadas para este
escenario, se ha podido ver que el servidor es susceptible a
ataques de denegación de servicio. En estas pruebas, los ataques
de inundación SYN Flood y TCP Flood resultaron exitosas, por
lo tanto, el uso de un IDS/IPS es recomendado tal como lo
sugieren [18] y [19].
AGRADECIMIENTOS
Se agradece al Ing. Fernando Balarezo, coordinador del
departamento de Tecnologías de Información de la Universidad
del Azuay por el acceso dado para la ejecución de las pruebas
indicadas en este documento.
X. REFERENCIAS
[1] E. Crespo, «Ecu@Risk, Una metodología para la
gestión de Riesgos,» Enfoque UTE, pp. 107-121,
2017.
[2] UNAM-CERT, «Aspectos Básicos de la Seguridad en
Aplicaciones Web,» 25 Mayo 2016. [En línea].
180
Available:
https://www.seguridad.unam.mx/historico/documento/
index.html-id=17. [Último acceso: 14 07 2017].
[3] The OWASP Project, OWASP Testing Guide 4.0,
N/E: The OWASP Project, 2017.
[4] T. Vieira y C. Serrao, «Web security in the finance
sector,» de 11th International Conference for Internet
Technology and Secured Transactions, ICITST 2016,
Barcelona, 2017.
[5] R. López, «Pentesting on web applications using
ethical - hacking,» de Central American and Panama
Convention (CONCAPAN XXXVI), 2016 IEEE 36th,
Panamá, 2016.
[6] S. Väli y S. Lopienski, «Deploying APEX
Vulnerability Scanner,» CERN Student Report, 2016.
[7] A. Caballero, Hacking con Kali Linux, Lima, 2015.
[8] G. Weidman, Penetration Testing, A Hands-On
Introduction to Hacking (1), EEUU: No Starch Press,
2014.
[9] O. Security, «Kali Tools,» 2017. [En línea]. Available:
https://tools.kali.org/tools-listing. [Último acceso: 31
07 2017].
[10] K. Hussein, N. Sani, R. Mahmod y T. Abdullah,
«Enhance Luhn Algorithm for Validation of Credit
Cards Numbers,» de International Journal of
Computer Science and Mobile Computing, n/a, 2013.
[11] S. Spendolini, Expert Oracle Application Express
Security, Apress, 2016.
[12] J. Lemon, «Resisting SYN flood DoS attacks with a
SYN cache,» USENIX, pp. 89-98, 2001.
[13] Microsoft, «SDL Threat Modeling Tool,» 2017. [En
línea]. Available: https://www.microsoft.com/en-
us/sdl/adopt/threatmodeling.aspx.
[14] G. Alcides, Seguridad informática, Antioquía,
Colombia: Universidad de Antioquía, 2009.
[15] E. Crespo, Artist, Metodología de Seguridad de la
Información para la gestión del Riesgo Informático
aplicable a MPYMES. [Art]. Universidad de Cuenca,
2016.
[16] L. Rocha, «Count Upon Security,» 29 Mayo 2014. [En
línea]. Available:
https://countuponsecurity.com/2014/05/29/simple-
and-practical-attack-part-2/.
[17] F. Gallo, Inseguridad Informática, España, 2011.
[18] S. Chakrabarti, M. Chakraborty y I. Mukhopadhyay,
«Study of snort-based IDS,» ACM, pp. 43-47, 2010.
[19] A. Mansoor, M. Muthuprasanna y K. Vijay, «High
Speed Pattern Matching for Network IDS/IPS,» IEEE
Xplore, 2006.