Laboratorio II: Un Hacking ético

Nicolle Camila Mayol Morillo

Ingeniería de Sistemas
Facultad de Ingeniería
Universidad de Medellín

Ciberseguridad
Juan Gabriel Ossa
27 de septiembre de 2020
Laboratorio II Universidad de Medellín Facultad de Ingeniería

TABLA DE CONTENIDO

CUESTIONARIO.............................................................................................................................3
1. ¿Cuales son los 10 ataques más relevantes de OWASP?...................................................3
2. ¿En qué consiste cada uno de los ataques más relevantes de OWASP?............................3
3. Investigue qué es el cubo de McCumber y ubique el ataque de Windows en cada una de
sus caras...................................................................................................................................8
EVIDENCIAS................................................................................................................................10
1. Evidencias Ataque Windows...........................................................................................10
1. Evidencia que muestre la cosola AWS con el direccionamiento Publico y privado del servidor........10
2. Evidencia del proceso de creación del ejecutable modificado............................................................10
3. Evidencia de la ejecución de putty en el servidor windows................................................................11
4. Evidencia de la creación de un usuario en windows...........................................................................12
5. Evidencia del ataque exitoso...............................................................................................................12
6. Evidencia de la captura de texto digitado...........................................................................................13
7. Evidencia de la captura de hashes de contraseñas.............................................................................13
8. Evidencia de la ruptura de las contraseñas.........................................................................................14
2. Evidencias WebGoat.......................................................................................................15
1. Listado de las 4 lecciones elegidas.......................................................................................................15
2. Evidencia de cada paso para cada lección...........................................................................................15
3. Evidencias Juice Box.......................................................................................................21
1. Listado de retos elegidos con su respectivo puntaje...........................................................................21
2. Explicación de los pasos seguidos para lograr un ataque exitoso.......................................................21
3. EVIDENCIA DEL ATAQUE EXITOSO.......................................................................................................28
4. Evidencia del tablero de puntaje (score-board) con el listado de ataques elegidos en estado
completado........................................................................................................................................................33

2
Laboratorio II Universidad de Medellín Facultad de Ingeniería

CUESTIONARIO

Responda cada una de las siguientes preguntas y relacione la bibliografía consultada

1. ¿Cuales son los 10 ataques más relevantes de OWASP?

Tal como es mostrado en a página de WebGoat, los diez ataques más relevantes para el año 2017
son los siguientes [CITATION Jac20 \l 3082 ]:

1. A1 Injection
2. A2 Broken Authentication
3. A3 Sensitive Data Exposure
4. A4 XML External Entities (XXE)
5. A5 Broken Access Control
6. A6 Security Misconfiguration
7. A7 Cross-Site Scripting (XSS)
8. A8 Insecure Deserialization
9. A9 Using Components with Known Vulnerabilities
10. A10 Insufficient Logging & Monitoring

2. ¿En qué consiste cada uno de los ataques más relevantes de OWASP?

Según la página oficial de OWASP, los ataques más relevantes consisten en, respectivamente
[ CITATION The20 \l 3082 ]:

1. A1 Injection:

Las fallas de inyección, como la inyección de SQL, NoSQL, OS y LDAP, ocurren cuando se
envían datos que no son de confianza a un intérprete como parte de un comando o
consulta. Los datos hostiles del atacante pueden engañar al intérprete para que ejecute
comandos no deseados o acceda a los datos sin la debida autorización.

Ilustración 1: Resúmen Inyección [ CITATION Jac20 \l 3082 ]

3
Laboratorio II Universidad de Medellín Facultad de Ingeniería

2. A2 Broken Authentication:

Las funciones de la aplicación relacionadas con la autenticación y la gestión de sesiones a

menudo se implementan de forma incorrecta, lo que permite a los atacantes
comprometer contraseñas, claves o tokens de sesión, o aprovechar otras fallas de
implementación para asumir las identidades de otros usuarios de forma temporal o
permanente.

Ilustración 2: Resúmen Ruptura de Autenticación[ CITATION Jac20 \l 3082 ]

3. A3 Sensitive Data Exposure:

Muchas aplicaciones web y API no protegen adecuadamente los datos confidenciales,

como los financieros, de salud y PII. Los atacantes pueden robar o modificar esos datos
débilmente protegidos para cometer fraude con tarjetas de crédito, robo de identidad u
otros delitos. Los datos confidenciales pueden verse comprometidos sin protección
adicional, como el cifrado en reposo o en tránsito, y requieren precauciones especiales
cuando se intercambian con el navegador.

Ilustración 3: Resúmen Exposición de Datos Sensibles [ CITATION Jac20 \l 3082 ]

4
Laboratorio II Universidad de Medellín Facultad de Ingeniería

4. A4 XML External Entities (XXE):

Muchos procesadores XML más antiguos o mal configurados evalúan las referencias de
entidades externas dentro de los documentos XML. Las entidades externas se pueden
utilizar para divulgar archivos internos mediante el controlador de URI de archivos,
recursos compartidos de archivos internos, escaneo de puertos internos, ejecución remota
de código y ataques de de negación de servicios.

Ilustración 4: Resúmen Entidades Externas XML (XXE) [ CITATION Jac20 \l 3082 ]

5. A5 Broken Access Control

Las restricciones sobre lo que los usuarios autenticados pueden hacer a menudo no se
aplican correctamente. Los atacantes pueden aprovechar estas fallas para acceder a
funciones y / o datos no autorizados, como acceder a las cuentas de otros usuarios, ver
archivos confidenciales, modificar los datos de otros usuarios, cambiar los derechos de
acceso, etc.

Ilustración 5: Resúmen Control de Acceso Roto [ CITATION Jac20 \l 3082 ]

5
Laboratorio II Universidad de Medellín Facultad de Ingeniería

6. A6 Security Misconfiguration

La configuración de seguridad incorrecta es el problema más común. Esto suele ser el

resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o
ad hoc, almacenamiento en la nube abierta, encabezados HTTP mal configurados y
mensajes de error detallados que contienen información confidencial. No solo todos los
sistemas operativos, marcos, bibliotecas y aplicaciones deben configurarse de forma
segura, sino que también deben parchearse / actualizarse de manera oportuna.

Ilustración 6: Resúmen Configuración de Seguridad Incorrecta [ CITATION Jac20 \l 3082 ]

7. A7 Cross-Site Scripting (XSS)

Los defectos de XSS ocurren cuando una aplicación incluye datos que no son de confianza
en una nueva página web sin la validación o el escape adecuados, o actualiza una página
web existente con datos proporcionados por el usuario mediante una API de navegador
que puede crear HTML o JavaScript. XSS permite a los atacantes ejecutar scripts en el
navegador de la víctima que pueden secuestrar sesiones de usuarios, desfigurar sitios web
o redirigir al usuario a sitios maliciosos.

Ilustración 7: Resúmen Cross Site Scripting (XSS) [ CITATION Jac20 \l 3082 ]

6
Laboratorio II Universidad de Medellín Facultad de Ingeniería

8. A8 Insecure Deserialization

La deserialización insegura a menudo conduce a la ejecución remota de código. Incluso si

las fallas de deserialización no dan como resultado la ejecución remota de código, pueden
usarse para realizar ataques, incluidos ataques de reproducción, ataques de inyección y
ataques de escalada de privilegios.

Ilustración 8: Resúmen Deserialización Insegura [ CITATION Jac20 \l 3082 ][ CITATION The20 \l 3082 ]

9. A9 Using Components with Known Vulnerabilities

Los componentes, como librerías, marcos y otros módulos de software, se ejecutan con los
mismos privilegios que la aplicación. Si se explota un componente vulnerable, dicho
ataque puede facilitar la pérdida de datos o la toma de control del servidor. Las
aplicaciones y API que utilizan componentes con vulnerabilidades conocidas pueden
socavar las defensas de las aplicaciones y permitir varios ataques e impactos.

Ilustración 9: Resúmen Uso de Componentes con Vulnerabilidades Conocidas [ CITATION Jac20 \l 3082 ]

7
Laboratorio II Universidad de Medellín Facultad de Ingeniería

10. A10 Insufficient Logging & Monitoring

Un registro y una supervisión insuficientes, junto con una integración faltante o ineficaz con
la respuesta a incidentes, permiten a los atacantes atacar aún más los sistemas, mantener
la persistencia, cambiar a más sistemas y manipular, extraer o destruir datos. La mayoría de
los estudios de infracciones muestran que el tiempo para detectar una infracción es de más
de 200 días, generalmente detectados por partes externas en lugar de procesos internos o
monitoreo.

Ilustración 10: Resúmen Registro y Monitoreo Insuficiente [ CITATION Jac20 \l 3082 ]

3. Investigue qué es el cubo de McCumber y ubique el ataque de Windows en

cada una de sus caras.

El cubo de McCumber es un marco de ciberseguridad desarrollado por John McCumber en 1991,

el cual utiliza un cubo de Rubik como una forma de conceptualizar la complejidad de las
organizaciones y sus necesidades de información y objetivos de seguridad, e identificar los
muchos factores involucrados. El cubo reúne las metas deseadas (confidencialidad, integridad y
disponibilidad), estados de información (almacenamiento, transmisión y procesamiento) y
salvaguardas (políticas y prácticas, factores humanos y tecnología). [ CITATION Cap \l 3082 ]

El cubo de McCumber se desarrolló como respuesta a los intentos de finales de los 80 y principios
de los 90 de definir la relación entre las disciplinas de las comunicaciones y la seguridad
informática. Como ocurre con todos los modelos, el valor radica en su capacidad para adaptarse al
entorno de la información independientemente de las tecnologías específicas involucradas. El
modelo es necesariamente tridimensional para capturar la verdadera naturaleza de la interacción
de los elementos en la seguridad de los sistemas de información. [ CITATION McC04 \l 3082 ].

8
Laboratorio II Universidad de Medellín Facultad de Ingeniería

9
Laboratorio II Universidad de Medellín Facultad de Ingeniería

Ilustración 11: Cubo McCumber [ CITATION McC04 \l 3082 ].

Para ubicar el ataque en las diferentes caras del cubo, inicialmente se realizó un desglose de la
taxonomía del ataque, el cual se describe a continuacion:

1. Acceso utilizando vulberabilidades del SO víctima

2. Consolidación del acceso
3. Robo de información
4. Utilización fraudulenta de la información obtenida

A partir de esta taxonomía, se pueden organizar los métodos de ataques y sus consecuencias, así
como los controles que debieron de haber existido para evitar o minimizar su impacto, de la
siguiente manera:

10
Laboratorio II Universidad de Medellín Facultad de Ingeniería

EVIDENCIAS

2. Evidencias Ataque Windows

1. Evidencia que muestre la cosola AWS con el direccionamiento Publico

y privado del servidor

Tabla 1: Direcciones de los servidores

2. Evidencia del proceso de creación del ejecutable modificado

Ilustración 12: Creación del archivo putty_e.exe

Ilustración 13: Copia a la máquina local del archivo putty_e.exe

11
Laboratorio II Universidad de Medellín Facultad de Ingeniería

3. Evidencia de la ejecución de putty en el servidor windows.

Ilustración 14: Copia del archivo modificado a la máquina Windows

Ilustración 15: Ejecución del Putty_e.exe en Windows

12
Laboratorio II Universidad de Medellín Facultad de Ingeniería

4. Evidencia de la creación de un usuario en windows.

Ilustración 16: Lista de Usuarios en el Servidor Windows

5. Evidencia del ataque exitoso

Ilustración 17: Sesión del Meterpreter inicializado en Ubunt

13
Laboratorio II Universidad de Medellín Facultad de Ingeniería

6. Evidencia de la captura de texto digitado

Ilustración 18: Archivo de texto plano en Windows

Ilustración 19: Texto capturado en la máquina linux

7. Evidencia de la captura de hashes de contraseñas

Ilustración 20: Captura de los hashes de contraseña

14
Laboratorio II Universidad de Medellín Facultad de Ingeniería

Ilustración 21: Guardado de los hashes de contraseña en un archivo plano

8. Evidencia de la ruptura de las contraseñas.

Ilustración 22: Contraseña del user1 rota

15
Laboratorio II Universidad de Medellín Facultad de Ingeniería

3. Evidencias WebGoat

1. Listado de las 4 lecciones elegidas

2. Evidencia de cada paso para cada lección

1. (A1) SQL Injection (Intro)

a. Step 2: What is SQL?

b. Step 3: Data Manipulation Language (DML)

16
Laboratorio II Universidad de Medellín Facultad de Ingeniería

c. Step 4: Data Definition Language (DDL)

d. Step 5: Data Control Language (DCL)

e. Step 9: String SQL Injection

17
Laboratorio II Universidad de Medellín Facultad de Ingeniería

f. Step 10: Numeric SQL injection

g. Step 11: Compromising confidentiality with String SQL injection

h. Step 12: Compromising Integrity with Query chaining

18
Laboratorio II Universidad de Medellín Facultad de Ingeniería

i. Step 13: Compromising Availability

2. (A1) SQL Injection (Advanced)

a. Step 3: Pulling data from other tables

19
Laboratorio II Universidad de Medellín Facultad de Ingeniería

b. Step 5: Logging as Tom

c. Step 6: Questionnaire

20
Laboratorio II Universidad de Medellín Facultad de Ingeniería

3. (A2) Authentication Bypasses

a. Step 2: 2FA Password Reset

4. (A3) Insecure Login

21
Laboratorio II Universidad de Medellín Facultad de Ingeniería

4. Evidencias Juice Box

1. Listado de retos elegidos con su respectivo puntaje.

2. Explicación de los pasos seguidos para lograr un ataque exitoso.

1. DOM XSS
11. Pegamos la cadena de caracteres <iframe src="javascript:alert(`xss`)"> en el campo de
búsqueda de la página
12. Damos click a buscar
13. Esto realizará la inserción del código y este se ejecutará.

22
Laboratorio II Universidad de Medellín Facultad de Ingeniería

5. Zero Feedback
1. Abrimos el formulario de Customer.
14. Abrimos Burp Suite mientras inspeccionamos el sitio.
15. Llenamos el formulario y enviamos un feedback cualquiera
16. Modificamos los parámetros de la petición en Burp Suite

6. Login Admin
1. Primero, vamos a la página de login.
17. Escribimos en el campo de email la sentencia de inyección SQL ' or 1=1—
18. Escribimos cualquier carácter en el campo de contraseña

23
Laboratorio II Universidad de Medellín Facultad de Ingeniería

7. Bonus Payload
1. Pegamos la cadena de caracteres <iframe width="100%" height="166" scrolling="no"
frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https
%3A//api.soundcloud.com/tracks/771984076&color=
%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=t
rue&show_reposts=false&show_teaser=true"></iframe> en el campo de búsqueda de
la página
19. Damos click a buscar
20. Esto realizará la inserción del código y este se ejecutará, reproduciendo una música

8. Error Handling
1. Intentamos iniciar session con ‘ (comillas únicas) en el campo de email y cualquier cosa
en el campo Password.

9. Password Strength
1. Como ya realizamos el ataque de Login Admin, ya poseemos el correo del
administrador, el cual es admin@juice-sh.op
21. La página nos deja saber que el administrador usó una contraseña no muy buena.
Hacemos varios intentos con contraseñas comunes hasta encontrar la contraseña del
administrador, la cual es ‘admin123’

10. Forged Feedback

1. Vamos al formulario de Contact Us
22. Inspeccionamos el DOM del formulario en el browser para detectar el siguiente campo
de texto, justo en la parte superior: <input _ngcontent-c23 hidden id="userId"
type="text" class="ng-untouched ng-pristine ng-valid">
23. En las herramientas de desarrollo, eliminamos el atributo oculto de la etiqueta <input>
anterior.
24. El campo ahora debería estar visible. Escribimos el identificador de la base de datos de
cualquier usuario y envíamos el feedback.

11. Login Jim

24
Laboratorio II Universidad de Medellín Facultad de Ingeniería

1. Primero debemos intentar obtener el correo de Jim. Para ello, vamos a la página de
productos y buscamos entre los reviews el correo de Jim.

25. Una vez obtenido el correo de Jim, ejecutamos una inyección SQL en el campo de
correo: jim@juice-sh.op’-- y cualquier cosa en el campo de Password

25
Laboratorio II Universidad de Medellín Facultad de Ingeniería

12. Login Bender.

1. Al igual que el reto anterior, buscamos el correo de Bender entre los reviews de los
productos.
26. Una vez obtenido el correo de Bender, ejecutamos una inyección SQL en el campo de
correo: bender@juice-sh.op'--y cualquier cosa en el campo de Password

13. View Basket

1. Vamos a la página del carrito y abrimos las Development Tools del browser. Ubicamos
las Session Storage en la pestaña de Application

26
Laboratorio II Universidad de Medellín Facultad de Ingeniería

27. Buscamos un valor numérico llamado bid y modificamos su valor.

14. Admin Registration

1. Creamos un usuario y monitoreamos la petición en BurpSuite
28. Iniciamos sesión con el usuario creado y buscamos la petición POST del login
29. La enviamos al Repeater de BurpSuite para modificar la petición para obtener las
credenciales

27
Laboratorio II Universidad de Medellín Facultad de Ingeniería

30. Abrimos POST api/Users para ver las credenciales

31. Copiamos cookies desde GET /rest/user/whoami HTTP/1.1 y lo copiamos en POST

api/Users
32. Después de realizar cambios y enviar, podemos observar que hay un campo
denominado ROLE.
33. Intentamos modificar el campo ROLE para ponerlo como ADMIN y enviamos la
solicitud.

28
Laboratorio II Universidad de Medellín Facultad de Ingeniería

3. EVIDENCIA DEL ATAQUE EXITOSO

1. DOM XSS attack

15. Zero Stars

29
Laboratorio II Universidad de Medellín Facultad de Ingeniería

16. Login Admin

17. Bonus Payload

30
Laboratorio II Universidad de Medellín Facultad de Ingeniería

18. Error Handling

19. Password Strength

31
Laboratorio II Universidad de Medellín Facultad de Ingeniería

20. Forged Feedback

21. Login Jim

32
Laboratorio II Universidad de Medellín Facultad de Ingeniería

22. Login Bender

23. View Basket

24. Admin Registration

33
Laboratorio II Universidad de Medellín Facultad de Ingeniería

4. Evidencia del tablero de puntaje (score-board) con el listado de ataques

elegidos en estado completado

34
Laboratorio II Universidad de Medellín Facultad de Ingeniería

Referencias

OWASP NZ. (09 de Febrero de 2020). Introduction to the OWASP Top Ten. Obtenido de OWASP:
https://owasp.org/www-chapter-new-zealand/assets/slides/2020-02-09%20-
%20Introduction%20to%20the%20OWASP%20Top%20Ten.pdf

The OWASP Foundation. (2020). OWASP Top Ten. Obtenido de OWASP: https://owasp.org/www-
project-top-ten/

Capitol Technology University. (s.f.). Learning the language of cybersecurity. Obtenido de

Capitology Blog, Capitol Technology University: https://www.captechu.edu/blog/learning-
language-of-cybersecurity#:~:text=McCumber%20Cube.&text=The%20cube%20brings
%20together%20desired,human%20factors%2C%20and%20technology).

McCumber, J. (2004). Assessing and Managing Security Risk in IT Systems: A Structured

Methodology. Boca Ratón: Taylor & Francis Group, LLC.

35