En esta publicación, cubrimos OWASP Top 10 usando el material en TryHackMe OWASP Top 10 Habitación. Puede encontrar respuestas a las preguntas de la sala a continuación junto con una lista de reproducción en video de recorridos para obtener explicaciones detalladas.

También cubrimos las soluciones para TryHackMe OWASP Top 10 – 2021 habitación.

Notas de estudio de OSCP

El curso completo y práctico de pruebas de penetración de aplicaciones web

Según OWASP, las 10 principales vulnerabilidades de aplicaciones web son

Vulnerabilidades de inyección

Los fallos de inyección son muy comunes en las aplicaciones actuales. Estos fallos se producen porque la aplicación interpreta la entrada controlada por el usuario como comandos o parámetros reales. Los ataques de inyección dependen de las tecnologías que se utilizan y de cómo estas tecnologías interpretan exactamente la entrada. Algunos ejemplos comunes incluyen:
Inyección SQL: esto ocurre cuando la entrada controlada por el usuario se pasa a consultas SQL. Como resultado, un atacante puede pasar consultas SQL para manipular el resultado de dichas consultas.
Inyección de comandos: esto ocurre cuando la entrada del usuario se pasa a los comandos del sistema. Como resultado, un atacante puede ejecutar comandos arbitrarios del sistema en los servidores de aplicaciones.

Si un atacante puede pasar con éxito una entrada que se interpreta correctamente, podría hacer lo siguiente:
Acceda, modifique y elimine información en una base de datos cuando esta entrada se pasa a consultas de la base de datos. Esto significaría que un atacante puede robar información confidencial, como datos personales y credenciales.
Ejecutar comandos arbitrarios del sistema en un servidor que permitirían a un atacante obtener acceso a los sistemas de los usuarios. Esto les permitiría robar datos confidenciales y realizar más ataques contra la infraestructura vinculada al servidor en el que se ejecuta el comando.

La principal defensa para prevenir ataques de inyección es garantizar que la entrada controlada por el usuario no se interprete como consultas o comandos. Hay diferentes maneras de hacer esto:
Uso de una lista de permitidos: cuando se envía una entrada al servidor, esta entrada se compara con una lista de entradas o caracteres seguros. Si la entrada está marcada como segura, se procesa. De lo contrario, se rechaza y la aplicación arroja un error.
Eliminación de entrada: si la entrada contiene caracteres peligrosos, estos caracteres se eliminan antes de procesarlos.

Los caracteres o entradas peligrosos se clasifican como cualquier entrada que pueda cambiar la forma en que se procesan los datos subyacentes. En lugar de crear manualmente listas de permitidos o incluso simplemente eliminar la entrada, existen varias bibliotecas que realizan estas acciones por usted.

Inyección de comandos del sistema operativo

La inyección de comandos ocurre cuando el código del lado del servidor (como PHP) en una aplicación web realiza una llamada al sistema en la máquina de alojamiento. Es una vulnerabilidad web que permite a un atacante aprovechar esa llamada al sistema realizada para ejecutar comandos del sistema operativo en el servidor. A veces, esto no siempre terminará en algo malicioso, como un whoami o simplemente la lectura de archivos. Eso no está tan mal. Pero lo que pasa con la inyección de comandos es que abre muchas opciones para el atacante. Lo peor que podrían hacer sería generar un shell inverso para convertirse en el usuario con el que se ejecuta el servidor web. Un simple ;nc -e /bin/bash es todo lo que se necesita y ellos son dueños de su servidor; algunas variantes de netcat no admiten la opción -e. Puede utilizar una lista de estos shells inversos como alternativa.

Una vez que el atacante tiene un punto de apoyo en el servidor web, puede iniciar la enumeración habitual de sus sistemas y comenzar a buscar formas de moverse. Ahora que sabemos qué es la inyección de comandos, comenzaremos a analizar los diferentes tipos y cómo probarlos.

Respuestas de la tarea 5

¿Qué archivo de texto extraño hay en el directorio raíz del sitio web?
drpepper.txt
¿Cuántos usuarios no root/no servicio/no demonio hay?

0
¿Con qué usuario se ejecuta esta aplicación?

www-datos
¿Cómo está configurado el shell del usuario?

/usr/sbin/nologin
¿Qué versión de Ubuntu se está ejecutando?

18.04.4
Imprime el MOTD. ¿Qué bebida favorita se muestra?

Dr Pepper

Autenticación rota

La autenticación y la gestión de sesiones constituyen componentes centrales de las aplicaciones web modernas. La autenticación permite a los usuarios obtener acceso a aplicaciones web verificando sus identidades. La forma más común de autenticación es mediante un mecanismo de nombre de usuario y contraseña. Un usuario ingresaría estas credenciales y el servidor las verificaría. Si son correctas, el servidor proporcionará al navegador de los usuarios una cookie de sesión. Se necesita una cookie de sesión porque los servidores web utilizan HTTP(S) para comunicarse y no tienen estado. Adjuntar cookies de sesión significa que el servidor sabrá quién envía qué datos. Luego, el servidor puede realizar un seguimiento de las acciones de los usuarios.

Si un atacante puede encontrar fallas en un mecanismo de autenticación, podría obtener acceso a las cuentas de otros usuarios. Esto permitiría al atacante acceder a datos confidenciales (según el propósito de la aplicación). Algunas fallas comunes en los mecanismos de autenticación incluyen:

Ataques de fuerza bruta: si una aplicación web utiliza nombres de usuario y contraseñas, un atacante puede lanzar ataques de fuerza bruta que le permiten adivinar el nombre de usuario y las contraseñas mediante múltiples intentos de autenticación.
Uso de credenciales débiles: las aplicaciones web deben establecer políticas de contraseñas seguras. Si las aplicaciones permiten a los usuarios establecer contraseñas como 'contraseña1' o contraseñas comunes, entonces un atacante puede adivinarlas fácilmente y acceder a las cuentas de los usuarios. Pueden hacerlo sin fuerza bruta y sin múltiples intentos.
Cookies de sesión débiles: las cookies de sesión son la forma en que el servidor realiza un seguimiento de los usuarios. Si las cookies de sesión contienen valores predecibles, un atacante puede configurar sus propias cookies de sesión y acceder a las cuentas de los usuarios.
Puede haber varias mitigaciones para los mecanismos de autenticación rotos según la falla exacta:

Para evitar ataques de adivinación de contraseñas, asegúrese de que la aplicación aplique una política de contraseñas segura.
Para evitar ataques de fuerza bruta, asegúrese de que la aplicación aplique un bloqueo automático después de una cierta cantidad de intentos. Esto evitaría que un atacante lance más ataques de fuerza bruta.
Implementar autenticación multifactor: si un usuario tiene múltiples métodos de autenticación, por ejemplo, usando nombre de usuario y contraseñas y recibiendo un código en su dispositivo móvil, entonces sería difícil para un atacante obtener acceso a ambas credenciales para acceder a su cuenta. .

Respuestas de la tarea 7

¿Cuál es la bandera que encontraste en la cuenta de Darren?
fe86079416a21a3c99937fea8874b667
Ahora intenta hacer el mismo truco y mira si puedes iniciar sesión como Arthur.

No se necesita respuesta
¿Cuál es la bandera que encontraste en la cuenta de Arthur?

d9ac0f7db4fda460ac3edeb75d75e16e

Exposición de datos confidenciales

Cuando una aplicación web divulga accidentalmente datos confidenciales, lo llamamos "exposición de datos confidenciales". Suelen ser datos directamente vinculados a los clientes (por ejemplo, nombres, fechas de nacimiento, información financiera, etc.), pero también podrían ser información más técnica, como nombres de usuario y contraseñas. En niveles más complejos, esto a menudo implica técnicas como el "ataque del hombre en el medio", mediante el cual el atacante forzaría las conexiones del usuario a través de un dispositivo que controla y luego aprovecharía el cifrado débil de cualquier dato transmitido para obtener acceso a la información interceptada. (si los datos están encriptados en primer lugar…). Por supuesto, muchos ejemplos son mucho más simples y se pueden encontrar vulnerabilidades en aplicaciones web que pueden explotarse sin ningún conocimiento avanzado de redes. De hecho, en algunos casos, los datos confidenciales se pueden encontrar directamente en el propio servidor web...

Respuestas de la tarea 11

Eche un vistazo a la aplicación web. El desarrollador se dejó una nota indicando que hay datos confidenciales en un directorio específico.

¿Cuál es el nombre del directorio mencionado?
/activos
Navegue hasta el directorio que encontró en la pregunta uno. ¿Qué archivo se destaca por contener datos confidenciales?

aplicación web.db
Utilice el material de apoyo para acceder a los datos confidenciales. ¿Cuál es el hash de contraseña del usuario administrador?

6eea9b7ef19179a06954edd0f6c05ceb
Rompe el hachís.
¿Cuál es la contraseña en texto plano del administrador?

qwertyuiop
Inicie sesión como administrador. ¿Qué es la bandera?

THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

Inyección de entidad externa XML

Un ataque de entidad externa XML (XXE) es una vulnerabilidad que abusa de las funciones de los analizadores/datos XML. A menudo permite que un atacante interactúe con cualquier backend o sistema externo al que la aplicación pueda acceder y puede permitirle al atacante leer el archivo en ese sistema. También pueden provocar un ataque de denegación de servicio (DoS) o podrían utilizar XXE para realizar una falsificación de solicitudes del lado del servidor (SSRF) que induce a la aplicación web a realizar solicitudes a otras aplicaciones. XXE puede incluso habilitar el escaneo de puertos y conducir a la ejecución remota de código.

Hay dos tipos de ataques XXE: dentro de banda y fuera de banda (OOB-XXE).
1) Un ataque XXE dentro de banda es aquel en el que el atacante puede recibir una respuesta inmediata a la carga útil XXE.

2) ataques XXE fuera de banda (también llamados XXE ciegos), no hay una respuesta inmediata de la aplicación web y el atacante tiene que reflejar la salida de su carga útil XXE en algún otro archivo o en su propio servidor.

Respuestas de la tarea 13

Forma completa de XML
Lenguaje de marcado extensible
¿Es obligatorio tener un prólogo XML en documentos XML?

No
¿Podemos validar documentos XML con un esquema?

Sí
¿Cómo podemos especificar la versión XML y la codificación en un documento XML?

prólogo XML

Respuestas de la tarea 14

¿Cómo se define un nuevo ELEMENTO?
!ELEMENTO
¿Cómo se define un elemento RAÍZ?

!TIPO DE DOCUMENTO
¿Cómo se define una nueva ENTIDAD?

!ENTIDAD

Ejemplo de cargas útiles XXE

<!DOCTYPE replace [ ]>
 <userInfo>
  halcón
  &nombre;
 </userInfo>

<?xml version=”1.0″?>
<!DOCTYPE root [ ]>
&leer;

Respuestas de la tarea 16

Intente mostrar su propio nombre utilizando cualquier carga útil.
No se necesita respuesta
Vea si puede leer el /etc/passwd

No se necesita respuesta
¿Cuál es el nombre del usuario en /etc/passwd?

halcón
¿Dónde se encuentra la clave SSH de Falcon?

/home/halcón/.ssh/id_rsa
¿Cuáles son los primeros 18 caracteres de la clave privada de Falcon?

MIIEogIBAAKCAQEA7

Vulnerabilidad de control de acceso roto

Los sitios web tienen páginas que están protegidas de los visitantes habituales; por ejemplo, solo el usuario administrador del sitio debería poder acceder a una página para administrar a otros usuarios. Si un visitante de un sitio web puede acceder a la página o páginas protegidas que no está autorizado a ver, los controles de acceso se rompen.

Un visitante habitual que pueda acceder a páginas protegidas puede provocar lo siguiente:
Poder ver información confidencial
Acceder a funciones no autorizadas
OWASP ha enumerado algunos escenarios de ataque que demuestran debilidades en el control de acceso:

Escenario #1: la aplicación utiliza datos no verificados en una llamada SQL que accede a información de la cuenta:
pstmt.setString(1, request.getParameter(“cuenta”));
Resultados del conjunto de resultados = pstmt.executeQuery( );

Un atacante simplemente modifica el parámetro 'cuenta' en el navegador para enviar el número de cuenta que desee. Si no se verifica adecuadamente, el atacante puede acceder a la cuenta de cualquier usuario.
http://example.com/app/accountInfo?acct=notmyacct

Escenario #2: un atacante simplemente fuerza la navegación hacia las URL de destino. Se requieren derechos de administrador para acceder a la página de administración.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si una persona que no es administrador puede acceder a la página de administración, esto es una falla (referencia a escenarios).

En pocas palabras, el control de acceso roto permite a los atacantes eludir la autorización, lo que les permite ver datos confidenciales o realizar tareas como si fueran un usuario privilegiado.

Vulnerabilidad de IDOR

Los sitios web tienen páginas que están protegidas de los visitantes habituales; por ejemplo, solo el usuario administrador del sitio debería poder acceder a una página para administrar a otros usuarios. Si un visitante de un sitio web puede acceder a la página o páginas protegidas que no está autorizado a ver, los controles de acceso se rompen.

Un visitante habitual que pueda acceder a páginas protegidas puede provocar lo siguiente:
Poder ver información confidencial
Acceder a funciones no autorizadas
OWASP ha enumerado algunos escenarios de ataque que demuestran debilidades en el control de acceso:

Escenario #1: la aplicación utiliza datos no verificados en una llamada SQL que accede a información de la cuenta:
pstmt.setString(1, request.getParameter(“cuenta”));
Resultados del conjunto de resultados = pstmt.executeQuery( );

Un atacante simplemente modifica el parámetro 'cuenta' en el navegador para enviar el número de cuenta que desee. Si no se verifica adecuadamente, el atacante puede acceder a la cuenta de cualquier usuario.
http://example.com/app/accountInfo?acct=notmyacct

Escenario #2: un atacante simplemente fuerza la navegación hacia las URL de destino. Se requieren derechos de administrador para acceder a la página de administración.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si una persona que no es administrador puede acceder a la página de administración, esto es una falla (referencia a escenarios).

En pocas palabras, el control de acceso roto permite a los atacantes eludir la autorización, lo que les permite ver datos confidenciales o realizar tareas como si fueran un usuario privilegiado.

Mira las notas de otros usuarios. ¿Qué es la bandera?

bandera {cincocuatrotres}

Configuración incorrecta de seguridad

Las configuraciones incorrectas de seguridad se diferencian de las otras 10 vulnerabilidades principales porque ocurren cuando la seguridad podría haberse configurado correctamente pero no lo fue.

Las configuraciones erróneas de seguridad incluyen:

Permisos mal configurados en servicios en la nube, como depósitos S3
Tener habilitadas funciones innecesarias, como servicios, páginas, cuentas o privilegios.
Cuentas predeterminadas con contraseñas sin cambios
Mensajes de error demasiado detallados que permiten a un atacante obtener más información sobre el sistema.
No utilizar encabezados de seguridad HTTP o revelar demasiados detalles en el servidor: encabezado HTTP
Esta vulnerabilidad a menudo puede generar más vulnerabilidades, como credenciales predeterminadas que le brindan acceso a datos confidenciales, XXE o inyección de comandos en páginas de administración.

Para obtener más información, recomiendo echar un vistazo a la entrada top 10 de OWASP sobre configuración incorrecta de seguridad.

Contraseñas predeterminadas
Específicamente, esta VM se centra en las contraseñas predeterminadas. Estos son un ejemplo específico de una mala configuración de seguridad. Podrías y deberías cambiar las contraseñas predeterminadas, pero la gente suele no hacerlo.

Es particularmente común en dispositivos integrados y de Internet de las cosas, y la mayoría de las veces los propietarios no cambian estas contraseñas.

Es fácil imaginar el riesgo de las credenciales predeterminadas desde el punto de vista de un atacante. Poder obtener acceso a paneles de administración, servicios diseñados para administradores de sistemas o fabricantes, o incluso a la infraestructura de red, podría resultar increíblemente útil para atacar una empresa. Desde la exposición de datos hasta el RCE sencillo, los efectos de las credenciales predeterminadas pueden ser graves.

En octubre de 2016, Dyn (un proveedor de DNS) quedó fuera de línea debido a uno de los ataques DDoS más memorables de los últimos 10 años. La avalancha de tráfico provino principalmente del Internet de las cosas y de dispositivos de red como enrutadores y módems, infectados por el malware Mirai.

¿Cómo se apoderó el malware de los sistemas? Contraseñas predeterminadas. El malware tenía una lista de 63 pares de nombre de usuario/contraseña e intentó iniciar sesión en servicios de telnet expuestos.

El ataque DDoS fue notable porque dejó fuera de línea muchos sitios web y servicios importantes. Amazon, Twitter, Netflix, GitHub, Xbox Live, PlayStation Network y muchos más servicios quedaron fuera de línea durante varias horas en 3 oleadas de ataques DDoS en Dyn.

¡Hackea la aplicación web y encuentra la bandera!

ellos {4b9513968fd564a87b28aa1f9d672e17}

Secuencias de comandos entre sitios explicadas

Las secuencias de comandos entre sitios, también conocidas como XSS, son una vulnerabilidad de seguridad que normalmente se encuentra en las aplicaciones web. Es un tipo de inyección que puede permitir a un atacante ejecutar scripts maliciosos y ejecutarlos en la máquina de la víctima.

Una aplicación web es vulnerable a XSS si utiliza entradas de usuario no desinfectadas. XSS es posible en Javascript, VBScript, Flash y CSS. Hay tres tipos principales de secuencias de comandos entre sitios:
XSS almacenado: el tipo de XSS más peligroso. Aquí es donde se origina una cadena maliciosa en la base de datos del sitio web. Esto sucede a menudo cuando un sitio web permite entradas del usuario que no están desinfectadas (eliminar las "partes defectuosas" de la entrada del usuario) cuando se insertan en la base de datos.
XSS reflejado: la carga maliciosa es parte de la solicitud de la víctima al sitio web. El sitio web incluye esta carga útil en respuesta al usuario. En resumen, un atacante necesita engañar a una víctima para que haga clic en una URL para ejecutar su carga maliciosa.
XSS basado en DOM: DOM significa Modelo de objetos de documento y es una interfaz de programación para documentos HTML y XML. Representa la página para que los programas puedan cambiar la estructura, el estilo y el contenido del documento. Una página web es un documento y este documento puede mostrarse en la ventana del navegador o como fuente HTML.
Para obtener más explicaciones y ejercicios de XSS, consulte la sala XSS.

Cargas útiles XSS
Recuerde, las secuencias de comandos entre sitios son una vulnerabilidad que puede aprovecharse para ejecutar Javascript malicioso en la máquina de la víctima. Consulte algunos tipos de cargas útiles comunes utilizados:

Ventana emergente (): crea una ventana emergente de mensaje Hola mundo en el navegador de un usuario.
Escribir HTML (document.write): anula el HTML del sitio web para agregar el tuyo propio (esencialmente desfigurando toda la página).
XSS Keylogger (http://www.xss-payloads.com/payloads/scripts/simplekeylogger.js.html): puede registrar todas las pulsaciones de teclas de un usuario, capturando su contraseña y otra información confidencial que escriba en la página web.
Escaneo de puertos (http://www.xss-payloads.com/payloads/scripts/portscanapi.js.html): un mini escáner de puertos local (más información sobre esto se cubre en la sala TryHackMe XSS).
XSS-Payloads.com (http://www.xss-payloads.com/) es un sitio web que tiene cargas útiles, herramientas, documentación y más relacionados con XSS. Puede descargar cargas útiles XSS que toman instantáneas desde una cámara web o incluso obtener un puerto y un escáner de red más capaces.

Navegue hasta http://MACHINE_IP/ en su navegador y haga clic en la pestaña "XSS reflejado" en la barra de navegación; Cree una carga útil XSS reflejada que provocará una ventana emergente que diga "Hola".

Hay másToXSS de lo que piensas
En la misma página reflectante, cree una carga útil XSS reflejada que provocará una ventana emergente con la dirección IP de su máquina.

ReflectanteXss4TheWin
Ahora navegue hasta http://MACHINE_IP/ en su navegador y haga clic en la pestaña "XSS almacenado" en la barra de navegación; hacer una cuenta.

Luego agregue un comentario y vea si puede insertar algo de su propio HTML.

HTML_T4gs
En la misma página, cree un cuadro emergente de alerta que aparezca en la página con las cookies de su documento.

W3LL_D0N3_LVL2
Cambie "XSS Playground" a "Soy un hacker" agregando un comentario y usando Javascript.

sitios web_pueden_ser_fácilmente_defaced_with_xss

Vulnerabilidad de deserialización insegura

“La deserialización insegura es una vulnerabilidad que ocurre cuando se utilizan datos que no son de confianza para abusar de la lógica de una aplicación” (Acunetix., 2017)

Esta definición sigue siendo bastante amplia, por decir lo menos. Simplemente, la deserialización insegura consiste en reemplazar los datos procesados por una aplicación con código malicioso; permitiendo cualquier cosa, desde DoS (denegación de servicio) hasta RCE (ejecución remota de código) que el atacante puede utilizar para afianzarse en un escenario de pentesting.

Específicamente, este código malicioso aprovecha el proceso legítimo de serialización y deserialización utilizado por las aplicaciones web. Explicaremos este proceso y por qué es tan común en las aplicaciones web modernas.

OWASP clasifica esta vulnerabilidad como 8 sobre 10 por las siguientes razones:

  • Baja explotabilidad. Esta vulnerabilidad suele darse caso por caso: no existe una herramienta o un marco confiable para abordarla. Debido a su naturaleza, los atacantes deben tener una buena comprensión del funcionamiento interno del ToE.
  • El exploit es tan peligroso como lo permite la habilidad del atacante y, más aún, el valor de los datos expuestos. Por ejemplo, alguien que sólo puede provocar un DoS hará que la aplicación no esté disponible. El impacto comercial de esto variará en la infraestructura: algunas organizaciones se recuperarán bien, otras, sin embargo, no.

¿Qué es vulnerable?

En resumen, en última instancia, cualquier aplicación que almacene o obtenga datos donde no existen validaciones o controles de integridad para los datos consultados o retenidos. Algunos ejemplos de aplicaciones de esta naturaleza son:

  • Sitios de comercio electrónico
  • Foros
  • API
  • Tiempos de ejecución de aplicaciones (Tomcat, Jenkins, Jboss, etc.)

Si una cookie tuviera la ruta webapp.com/login, ¿cuál sería la URL que tiene que visitar el usuario?
webapp.com/login
¿Cuál es el acrónimo de la tecnología web sobre la que funcionan las cookies seguras?

HTTPS

Tarea 25 Banderas

1.ª bandera (valor de la cookie)
THM{good_old_base64_huh}
Segunda bandera (panel de administración)

THM{heres_the_admin_flag}

Bandera de tarea 26

bandera.txt
4a69a7ff9fd68

Componentes con vulnerabilidades conocidas

Ocasionalmente, es posible que descubra que la empresa/entidad que está realizando la prueba esté utilizando un programa que ya tiene una vulnerabilidad bien documentada.

Por ejemplo, digamos que una empresa no ha actualizado su versión de WordPress durante algunos años y, al utilizar una herramienta como wpscan, descubre que es la versión 4.6. Una investigación rápida revelará que WordPress 4.6 es vulnerable a un exploit de ejecución remota de código (RCE) no autenticado y, mejor aún, puede encontrar un exploit ya creado en exploit-db.

Como puede ver, esto sería bastante devastador, porque requiere muy poco trabajo por parte del atacante, ya que muchas veces, como la vulnerabilidad ya es bien conocida, alguien más ha aprovechado la vulnerabilidad. La situación empeora aún más cuando te das cuenta de que es bastante fácil que esto suceda; si una empresa omite una sola actualización de un programa que utiliza, podría ser vulnerable a cualquier número de ataques.

Por lo tanto, OWASP ha calificado esto con un 3 (es decir, alto) en la escala de prevalencia: es increíblemente fácil para una empresa perderse una actualización de una aplicación.

Respuestas de la tarea 29

¿Cuántos caracteres hay en /etc/passwd (use wc -c /etc/passwd para obtener la respuesta)
1611

Registro y monitoreo insuficientes

Cuando se configuran aplicaciones web, se debe registrar cada acción realizada por el usuario. El registro es importante porque, en caso de un incidente, se pueden rastrear las acciones de los atacantes. Una vez que se rastrean sus acciones, se puede determinar su riesgo e impacto. Sin iniciar sesión, no habría forma de saber qué acciones realizó un atacante si obtuvo acceso a aplicaciones web específicas. Los mayores impactos de estos incluyen:

Daño regulatorio: si un atacante ha obtenido acceso a información de identificación personal del usuario y no hay registro de esto, no solo se ven afectados los usuarios de la aplicación, sino que los propietarios de la aplicación pueden estar sujetos a multas o acciones más severas según las regulaciones.
Riesgo de nuevos ataques: sin iniciar sesión, la presencia de un atacante puede pasar desapercibida. Esto podría permitir a un atacante lanzar más ataques contra propietarios de aplicaciones web robando credenciales, atacando infraestructura y más.
La información almacenada en los registros debe incluir:

Códigos de estado HTTP
Marcas de tiempo
Nombres de usuario
Puntos finales API/ubicaciones de páginas
Direcciones IP
Estos registros contienen información confidencial, por lo que es importante garantizar que se almacenen de forma segura y que se almacenen varias copias de estos registros en diferentes ubicaciones.

Como habrás notado, el registro es más importante después de que se haya producido una infracción o un incidente. El caso ideal es contar con un seguimiento para detectar cualquier actividad sospechosa. El objetivo de detectar esta actividad sospechosa es detener al atacante por completo o reducir el impacto que ha causado si su presencia se ha detectado mucho más tarde de lo previsto. Ejemplos comunes de actividad sospechosa incluyen:

múltiples intentos no autorizados para una acción particular (generalmente intentos de autenticación o acceso a recursos no autorizados, por ejemplo, páginas de administración)
solicitudes de direcciones IP o ubicaciones anómalas: si bien esto puede indicar que alguien más está intentando acceder a la cuenta de un usuario en particular, también puede tener una tasa de falsos positivos.
Uso de herramientas automatizadas: determinadas herramientas automatizadas pueden identificarse fácilmente, por ejemplo, utilizando el valor de los encabezados User-Agent o la velocidad de las solicitudes. Esto puede indicar que un atacante está utilizando herramientas automatizadas.
Cargas útiles comunes: en aplicaciones web, es común que los atacantes utilicen cargas útiles de Cross Site Scripting (XSS). La detección del uso de estas cargas útiles puede indicar la presencia de alguien que realiza pruebas maliciosas o no autorizadas en las aplicaciones.
Detectar simplemente actividad sospechosa no ayuda. Esta actividad sospechosa debe clasificarse según el nivel de impacto. Por ejemplo, determinadas acciones tendrán un mayor impacto que otras. Estas acciones de mayor impacto deben responderse lo antes posible, por lo que deberían generar una alarma que llame la atención de la parte pertinente.

Ponga en práctica este conocimiento analizando este archivo de registro de muestra.

¿Qué dirección IP está utilizando el atacante?
49.99.13.16
¿Qué tipo de ataque se está llevando a cabo?

Fuerza bruta

TryHackMe OWASP TOP 10 2021 | Respuestas de la habitación

Mira las notas de otros usuarios. ¿Qué es la bandera?

bandera {cincocuatrotres}

Eche un vistazo a la aplicación web. El desarrollador se dejó una nota indicando que hay datos confidenciales en un directorio específico. 

¿Cuál es el nombre del directorio mencionado?

/activos

Navegue hasta el directorio que encontró en la pregunta uno. ¿Qué archivo se destaca por contener datos confidenciales?

aplicación web.db

Utilice el material de apoyo para acceder a los datos confidenciales. ¿Cuál es el hash de contraseña del usuario administrador?

6eea9b7ef19179a06954edd0f6c05ceb

Rompe el hachís.
¿Cuál es la contraseña en texto plano del administrador?

 qwertyuiop

Inicie sesión como administrador. ¿Qué es la bandera?

THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

¿Qué archivo de texto extraño hay en el directorio raíz del sitio web?

drpepper.txt

¿Cuántos usuarios no root/no servicio/no demonio hay?

0

¿Cómo está configurado el shell del usuario?

apache

¿Cómo está configurado el shell del usuario?

/sbin/nologin

¿Qué versión de Alpine Linux se está ejecutando?

3.16.0

¿Cuál es el valor de la bandera en la cuenta de José?

THM{Not_3ven_c4tz_c0uld_sav3_U!}

¿Cuál es el nombre del archivo de la base de datos (el que tiene la extensión .db) en el directorio actual?

todo.db

Modifique el código para leer el contenido del aplicación.py archivo, que contiene el código fuente de la aplicación. ¿Cuál es el valor de la bandera_secreta variable en el código fuente?

THM{Just_a_tiny_misconfiguration}

¿Cuál es el contenido del archivo /opt/flag.txt?

THM{¡Pero_1ts_n0t_myf4ult!}

¿Cuál es la bandera que encontraste en la cuenta de Darren?

fe86079416a21a3c99937fea8874b667

¿Cuál es la bandera que encontraste en la cuenta de Arthur?

d9ac0f7db4fda460ac3edeb75d75e16e

¿Qué es el hash SHA-256 de https://code.jquery.com/jquery-1.12.4.min.js?

sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=

Intente iniciar sesión en la aplicación como invitado. ¿Cuál es la contraseña de la cuenta del huésped?

invitado

¿Cuál es el nombre de la cookie del sitio web que contiene un token JWT?

sesión-jwt

¿Cuál es la bandera que se presenta al usuario administrador?

THM{No_tomar_cookies_de_extraños}

¿Qué dirección IP está utilizando el atacante?

¿Qué tipo de ataque se está llevando a cabo?

Fuerza bruta

Explora el sitio web. ¿Cuál es el único host al que se le permite acceder al área de administración?

servidor local

Marque el botón "Descargar currículum". ¿A dónde apunta el parámetro del servidor?

almacenamiento-seguro-de-archivos.com

Usando SSRF, haga que la aplicación envíe la solicitud a su AttackBox en lugar del almacenamiento seguro de archivos. ¿Hay claves API en la solicitud interceptada?

THM{Hola_soy_solo_una_clave_API}

Tutoriales de listas de reproducción de vídeos

, ,
Mostrar Comentarios

Motasem

Acerca del Autor

Creo notas de ciberseguridad, notas de marketing digital y cursos online. También brindo consultoría de marketing digital que incluye, entre otros, SEO, Google y meta anuncios y administración de CRM.

Ver Artículos