Saltar a contenido

02.-De aplicación

1.11. Para desempeñar nuestra labor de hacker ético de forma profesional debemos mantenernos informados de las brechas de seguridad y vulnerabilidades que afectan al software y al hardware, puesto que esas mismas vulnerabilidades nos las encontraremos, tarde o temprano, en alguna de nuestras auditorías. Investiga sobre vulnerabilidades graves que hayan aparecido recientemente (CVSS superior a 7) y muestra los siguientes datos:
  • Nombre de la vulnerabilidad (si se ha bautizado), CVE y CVSS.
  • Breve descripción de en qué consiste, a qué software afecta (versiones) y con qué categoría de CWE se corresponde.
  • Atribución del descubrimiento, añadiendo la referencia original a la publicación correspondiente si es posible, y si esa persona u organización tiene otros descubrimientos interesantes.

Los resultados de este ejercicio son abiertos, ya que existen numerosas vulnerabilidades y otras muchas que irán apareciendo. A continuación, se muestra un ejemplo de cómo podría presentarse esta respuesta con dos vulnerabilidades mencionadas en la unidad (Zerologon y Log4shell).

Zerologon. CVE-2020-1472.

  • CVSS: 10.0 (base score).

  • CWE-330 (Use of Insufficiently Random Values).

  • Versiones afectadas: Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2016:1903, Windows Server 2016:1909, Windows Server 2016:2014, Windows Server 2019.

  • Descripción: esta vulnerabilidad se aprovecha de un fallo de implementación en la criptografía del protocolo Netlogon Remote Protocol, que se emplea para la autenticación de usuarios y máquinas en redes de dominio de Microsoft Windows, y, en particular, en la elección del vector de inicialización del algoritmo criptográfico empleado: AES-CFB8. Descubrimiento: fue descubierta en septiembre de 2020 por Tom Tervoort, analista de seguridad en la empresa Secura. Previamente había descubierto una vulnerabilidad similar en el protocolo Netlogon clasificada en el CVE-2019-1424.

  • Referencia: https://www.secura.com/blog/zero-logon.

Log4shell. CVE-2021-44228.

  • CVSS: 10.0 (base score).
  • CWE: CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement), CWE-20 (Improper Input Validation), CWE-400 (Uncontrolled Resource Consumption), CWE-502 (Deserialization of Untrusted Data).
  • Versiones afectadas: 2.0 a 2.15 (excepto 2.12.2, 2.12.3 y 2.3.1).
  • Descripción: la vulnerabilidad afecta a la librería log4j utilizada por desarrolladores Java para registrar eventos e información relevante en logs. La explotación se realiza a través de una petición HTTP, permitiendo la ejecución remota de código sin necesidad de autenticación en el servidor (Unauthenticated RCE).
  • Descubrimiento: el investigador chino Chen Zhaojun de Alibaba Cloud Security Team fue el primero en reportar la vulnerabilidad a Apache el 24 de noviembre. El gobierno chino castigó a la empresa por no informar previamente al Estado, lo que habría permitido la ejecución de zeroday en una cantidad enorme de dispositivos.
  • Referencia: https://www.incibe.es/incibe-cert/blog/log4shell-analisis-vulnerabilidades-log4j
1.12. Una de las labores del hacker ético, una vez que ha terminado el test de intrusión, es elaborar y presentar un informe al cliente donde se recogen las vulnerabilidades y los problemas de seguridad encontrados y las recomendaciones para solucionar o mitigar esas vulnerabilidades. Para conocer las características que tienen estos informes, puedes analizar alguno de los informes profesionales publicados en Internet. Trata de responder a algunas preguntas, como:
  • ¿Qué aspecto tiene el informe en cuanto a estilo, redacción, estructura y extensión?
  • ¿Qué metodología de pentesting se ha aplicado?
  • ¿Cómo se identifican y clasifican las vulnerabilidades?
  • ¿Se ofrecen mitigaciones a los problemas de seguridad encontrados?
  • Escribe tus propias conclusiones acerca de cómo debe elaborarse y las características que debe tener un informe que tuvieras que escribir.

Ejemplo de solución

Este es un informe de ejemplo de la empresa TrustFoundry en la que se realiza un test de intrusión a una aplicación web llamada “EasyTransfer”. Para el test de intrusión se facilita la dirección IP que debe ser auditada, 107.170.68.146. El documento está estructurado en dos grandes secciones. En primer lugar un resumen del trabajo realizado que incluye la metodología y el resumen ejecutivo, y un resumen con las vulnerabilidades encontradas. En el resumen se incluye una tabla con las fechas más importantes del proceso de auditoría: reunión inicial, comienzo del test de intrusión, finalización del test de intrusión y envío del informe. En cuanto a la metodología empleada, se indica que dispone de las siguientes fases: Pre-Assessment, Enumeration, Unauthenticated Testing, Authenticated Testing, Reporting. No se sigue ninguna de las metodologías estudiadas pero sí se indica que se siguen las buenas prácticas de seguridad del OWASP Top 10. Además, en esta misma sección se presenta un listado genérico de herramientas que pueden ser utilizadas durante el test de intrusión, muchas de las cuales son estudiadas más adelante, como BeEF (The Browser Explotation Framework Project), dirbuster/gobuster, Nessus, Nikto, nmap y sqlmap. El sumario ejecutivo ofrece un resumen de alto nivel de las vulnerabilidades encontradas, así como de las buenas prácticas que se han identificado en el entorno auditado. Se han encontrado 10 vulnerabilidades, siendo el Top 3:

  1. La más grave permite la inyección de comandos a usuarios autenticados.
  2. La segunda más grave permite leer ficheros arbitrarios en el sistema por un procesamiento incorrecto de XML.
  3. La tercera permite a un atacante saltarse el proceso de reseteo de contraseñas debido a criptografía débil.

Además, el resumen también ofrece tablas y gráficos que resumen los datos analizados, lo que ayuda a tener una visión global de la auditoría. El resumen de vulnerabilidades encontradas incluye una tabla con la categoría de la vulnerabilidad y la gravedad de esta. En esta tabla, las vulnerabilidades se encuentran ordenadas de mayor a menor índice de gravedad, algo que es recomendable realizar si tenemos que elaborar algún informe. A continuación, el informe ofrece información detallada para cada vulnerabilidad. En cada una de ellas aparecen las siguientes secciones:

  • Severity. Gravedad de la vulnerabilidad, puede ser Critical, High, Medium, Low, Informational. El documento no explica cómo se realiza esta clasificación y no menciona valores de CWE o CVSS, lo que sería recomendable.
  • Finding Information. Se explica dónde se encuentra la vulnerabilidad y cómo activarla.
  • Evidence. En esta sección se realiza la demostración o prueba de concepto (PoC) de la explotación de la vulnerabilidad. Incluye capturas de pantalla y una explicación paso a paso de todo el proceso.
  • Affected URLs. Un listado de las URL o endpoints que están afectados por la vulnerabilidad. Esta sección es adecuada, puesto que se trata de una aplicación web, pero no aparecerá en todos los informes que se realicen.
  • Impact. Aquí se explica el impacto que supone para el sistema que un atacante logre explotar esta vulnerabilidad. Por ejemplo, comprometer el sistema completamente, exfiltrar datos del servidor, etc.
  • Recommendations. Se ofrecen las medidas y recomendaciones adecuadas para solucionar o mitigar el problema de seguridad.
  • Additional Information. En algunos casos aparece esta sección donde se presentan direcciones URL con más información relacionada con la vulnerabilidad en cuestión.

Aparte de elaborar el análisis del informe, un complemento a esta actividad puede ser que el alumnado realice una exposición con sus conclusiones para que compartan entre ellos los diferentes estilos, formatos, tipos de vulnerabilidades encontradas y pueda ser mucho más enriquecedor.

1.13. Este ejercicio se puede realizar en grupos: un grupo asume el rol de la empresa de ciberseguridad y el otro el rol de la empresa que desea contratar un test de intrusión. El segundo grupo debe plantear un supuesto sobre cómo es su empresa, qué estructura tiene, los sistemas con los que trabaja, etcétera.
  • Elabora un cuestionario previo que ayude a determinar el tipo y alcance de la auditoría que se realizará, así como los equipos y servicios que se auditarán.
  • Tras la entrevista, elabora una tabla con los activos internos y externos de la organización, y otra información necesaria para elaborar el acuerdo.

  • Elabora un acuerdo de auditoría, donde se recogerán los activos implicados en ella, el tipo de auditoría que se realizará sobre cada activo y la duración del mismo.

  • Recursos para la actividad:

  • Modelo 1
  • Modelo 2

En esta actividad, el alumnado en grupo, o individualmente, puede asumir los dos roles, el de empresa auditada y el de empresa de ciberseguridad. La actividad anterior de análisis de informes puede ser un buen punto de partida. No hay una solución única a este ejercicio, ya que dependerá mucho de la creatividad del alumnado, por lo que daremos algunas líneas que sirvan para orientar su realización. El alumnado puede inspirarse en empresas conocidas, donde trabajen o hayan trabajado o realizado prácticas de empresa, siempre y cuando no vulneren las políticas de privacidad de estas y no desvelen datos confidenciales. Otro lugar de referencia que puede ayudar a inspirar o documentar al alumnado es analizar las condiciones de los programas de recompensas que tienen las empresas en plataformas como Bugcrowd, HackerOne, Intigriti, etc., y que se han mencionado en la unidad. En ellas pueden verse lo que se paga por cada tipo de vulnerabilidad, los activos que están dentro del ámbito del programa y los que quedan fuera, así como aquellos reportes que no se consideran vulnerabilidades sin un análisis más profundo. Algunos programas que se pueden consultar a modo de ejemplo:

  • Suivo. https://app.intigriti.com/programs/suivo/suivoweb/detail
  • Tomorrowland. https://app.intigriti.com/programs/tomorrowland/tomorrowland/detail

  • Grupo Kinepolis. https://app.intigriti.com/programs/kinepolis/website/detail Otro lugar muy interesante para documentar la actividad son las convocatorias de entidades públicas para la realización de test de intrusión de sus servicios. Se puede pedir al alumnado que haga una búsqueda de investigación y se inspire en los recursos encontrados. Por ejemplo, aquí se indican algunas de ellas muy interesantes.

  • Pliego de condiciones para un test de intrusión a Loterías y Apuestas del Estado: https://contrataciondelestado.es/wps/wcm/connect/bdcb7521-7811-43dc-9c98-397112832819/DOC20160107124924pliego+test+vulnerabilidades+e+intrusion.pdf?MOD=AJPERES

  • Test de intrusión en los sistemas de información de la Diputación de León. https://www.dipuleon.es/file/p-vgUPL1mlg;jsessionid=FAF4A397C71B52A484FF41B4077E4383
  • Test de intrusión en la red WiFi del servicio de aguas municipales de Vitoria-Gasteiz. https://www.euskadi.eus/anuncio_contratacion/test-intrusion-wifi/web01-tramite/es/
  • Servicio de revisión técnica de seguridad del sistema de información GEA de la Consejería de la Presidencia, Administración Pública e Interior de la Junta de Andalucía. https://www.juntadeandalucia.es/haciendayadministracionpublica/apl/pdc_sirec/perfiles-licitaciones/detalle-licitacion.jsf?idExpediente=000000263747

Por último, enumeramos algunas de las preguntas que pueden ser interesantes para elaborar el documento: - ¿Ha realizado la empresa alguna auditoría de seguridad previamente? En caso afirmativo ¿cuáles fueron los resultados? - ¿Cuál es el rango y número de direcciones IP que deben ser auditadas? - ¿Qué servicios se ejecutan en esas direcciones IP que deben ser auditados (HTTP, DNS, VPN, SMTP...)? - En auditorías internas, ¿cuál es el número de equipos a ser auditados?¿Qué sistema operativo y software corre en dichos equipos? ¿Existe algún documento o plan de seguridad que deba revisarse?

1.14. Realiza todos los retos básicos de la plataforma Atenea continuando con el laboratorio de la unidad.

Reto 5. ASCII Para pasar este reto deberás encontrar los caracteres correspondientes a la siguiente codificación ASCII:

080 097 115 115 119 111 114 100 032 112 097 114 097 032 115 117 112 101 114 097 114 032 101
108 032 114 101 116 111 058 032 084 104 101 065 083 067 073 073 084 097 098 108 101 033

La web http://www.unit-conversion.info/texttools/ascii/ contiene una herramienta para convertir ASCII a texto en la que se puede introducir los dígitos de la codificación. Se obtiene el mensaje:

Password para superar el reto: TheASCIITable!

$ echo -n TheASCIITable! | md5sum
bac4354dbd68068622f69e0c18dab871 -

Solución: flag{bac4354dbd68068622f69e0c18dab871}

Reto 6. Hex Para pasar este reto deberás decodificar la siguiente cadena hexadecimal:

50617373776f72643a2044346d7054686548337821

Accedemos a un conversor hexadecimal a texto, por ejemplo: http://www.unit- conversion.info/texttools/hexadecimal/ Obtenemos la siguiente cadena: Password: D4mpTheH3x! También se puede usar el comando xxd con la opción -r para convertir de hexadecimal a binario, y -p para mostrar el texto correspondiente a dicha codificación.

$ echo -n 50617373776f72643a2044346d7054686548337821 | xxd -r -p
Password: D4mpTheH3x!

Y obtenemos el MD5 de la contraseña.

$ echo -n D4mpTheH3x! | md5sum
6020e8ded1d1dc711271c3f6c6d0a4ce -

Solución: flag{6020e8ded1d1dc711271c3f6c6d0a4ce}

Reto 8. Entropía Usamos el comando ent en Linux para obtener la entropía de cada fichero.

Listado de archivos Comando ent file_entropy.py
aircraft-2806035_1920.jpg 7.970380 7.97038043643
blue-2705642_1920.jpg 7.956820 7.95681981138
cello-2830670_1920.jpg 7.978028 7.97802786028
chess-2730034_1920.jpg 7.912812 7.91281227014
chestnut-2740751_1280.jpg 7.972699 7.97269867537
fire-2777580_1920.jpg 7.970071 7.9700705656
fly-agaric-2817723_1920.jpg 7.968973 7.96897289084
seemed-2823949_1280.jpg 7.972986 7.9729858271
waffle-heart-2697904_1280.jpg 7.956901 7.95690057534 
$ echo -n cello-2830670_1920.jpg | md5sum
462b9e713bd4a8d06f8ef506be634b66 -

Solución: flag{462b9e713bd4a8d06f8ef506be634b66}

Reto 9. Magic Number
Usamos el comando file para ver qué información nos ofrece:

$ file magicnumber-67351bf4490e9405b4195d544a1c290e
magicnumber-67351bf4490e9405b4195d544a1c290e: ISO Media, MP4 v2 [ISO 14496-14]

Usamos el comando hexdump:

$ hexdump -C magicnumber-67351bf4490e9405b4195d544a1c290e | head
00000000 00 00 00 20 66 74 79 70 6d 70 34 32 00 00 00 00 |... ftypmp42....|
00000010 6d 70 34 32 6d 70 34 31 69 73 6f 6d 61 76 63 31 |mp42mp41isomavc1|
00000020 00 00 12 75 6d 6f 6f 76 00 00 00 6c 6d 76 68 64 |...umoov...lmvhd|
...
00000090 00 00 00 02 00 00 00 21 69 6f 64 73 00 00 00 00 |.......!iods....|

En negrita hemos marcado los bytes correspondientes al número mágico para el tipo de fichero MP4v2:

$ echo -n 00000020667479706D703432 | md5sum
c2cc5e2f05d57fa0ed169bd17efa57eb -

Solución: flag{c2cc5e2f05d57fa0ed169bd17efa57eb}

Reto 10. Strings
Usamos el comando strings de Linux:

$ strings lookinside-64d0177d2ee53c67e46d5748183d0098 | grep www
www.thisisthedomainyouarelookingfor.com

Convertimos la URL a MD5:

$ echo -n www.thisisthedomainyouarelookingfor.com | md5sum
053a600c94f86724a8ead596fb178e4c -

Solución: flag{053a600c94f86724a8ead596fb178e4c}

Reto 11. Metadatos
Comprobamos los metadatos con la herramienta exiftool:

$ exiftool LoremIpsum-1e40fa12a5e7ce47ebcaaace81f6fd06.pdf

La solución la encontramos en el apartado Author:

$ echo -n Aldus Corporation | md5sum
ea930a810edfb6bc250effaf1e504027 -

Solución: flag{ea930a810edfb6bc250effaf1e504027}

Reto 12. Metadatos 2
Usamos la herramienta exiftool para obtener la información del archivo:

$ exiftool balloon-fc416bf4b40d82bcaa2b941bd38a42cd.jpg

La solución la encontramos en el valor Camera Model Name:

$ echo -n ILCE-6000 | md5sum
a00f40c5781331e16c25b73516e6202f -

Solución: flag{a00f40c5781331e16c25b73516e6202f}

Reto 13. Variable
Para este reto, identificamos el tipo de dato erróneo en las declaraciones de variables. La declaración de int max = "1000"; es incorrecta ya que el literal "1000" representa una cadena.

$ echo -n max | md5sum
2ffe4e77325d9a7152f7086ea7aa5114 -

Solución: flag{2ffe4e77325d9a7152f7086ea7aa5114}

Reto 14. Variable 2
Para encontrar el equivalente en BASH de PRINT "Atenea" en BASIC, utilizamos:

$ echo -n 'echo "Atenea"' | md5sum
bbf02728ac533b306fb112c4a5b66926 -

Solución: flag{bbf02728ac533b306fb112c4a5b66926}

Reto 15. Python
Ejecutamos el siguiente script en Python y añadimos print(result) al final:

import base64
from Crypto import Random
from Crypto.Cipher import AES
AKEY = 'mysixteenbytekey'
iv = 'what_a_cool_iv!!'
def decode(cipher):
    obj2 = AES.new(AKEY, AES.MODE_CFB, iv)
    return obj2.decrypt(base64.urlsafe_b64decode(cipher))
result = decode("5fMfiISsxcG4gKWAXwkL1Bu6zW26FlhG1613")
print(result)

Se obtiene la salida: b'Password: pythonSnakeBite77'. Calculamos su MD5:

$ echo -n pythonSnakeBite77 | md5sum
6cff35575e778bd78557444667db48bd -

Solución: flag{6cff35575e778bd78557444667db48bd}

Reto 16. C
Compilamos y ejecutamos el siguiente código en C:

#include <stdio.h>
void main() {
    int a = 65535;
    printf("Password : %d\n",a << 7);
}

Obtenemos la salida Password : 8388480, y convertimos el valor en MD5:

$ echo -n 8388480 | md5sum
cd703af39fe04b065fc563993d236f37 -

Solución: flag{cd703af39fe04b065fc563993d236f37}

Reto 17. Java
Decompilamos el código Java y encontramos la variable ThisIsTheVariableYouAreLookingFor = "30853506b923083a";. Luego, generamos el hash MD5:

$ echo -n 30853506b923083a | md5sum
a4bd3cbd2dc7b2be8f20db69aac9d356 -

Solución: flag{a4bd3cbd2dc7b2be8f20db69aac9d356}

1.15. Realiza tu segunda máquina boot2root con el reto Simple CTF de TryHackMe (Reto CTF en TryHackMe - SimpleCTF). En este reto se explota una vulnerabilidad del CMS instalado en la máquina que permite recuperar y crackear los hashes de las credenciales SSH de los usuarios. Una vez en el sistema, la escalada de privilegios se lleva a cabo con sudo.