$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. Demasiada vida de sesión. Todo un año es mucho. Si la cookie se secuestra con éxito, es posible que el atacante tenga acceso prolongado a la cuenta de usuario.
2. Falta la bandera httpOnly. Si se establece en VERDADERO, solo se podrá acceder a las cookies a través del protocolo HTTP. Es decir, las cookies en este caso no estarán disponibles para lenguajes de script como JavaScript.
3. Sin cookie hashing.
4. Falta de establecer la bandera segura. El indicador de seguridad indica que se debe enviar una cookie desde el cliente a través de una conexión HTTPS segura. Si se establece en VERDADERO, la cookie del cliente se enviará al servidor solo si se establece una conexión segura.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

La primera pregunta con la que el cuestionario se reunió con futuros pasantes se refería a las vulnerabilidades web principales y ampliamente conocidas. La única dificultad aquí es la necesidad de verlos en el código fuente en PHP. Sin embargo, nadie estableció la tarea de "ocultar errores".

Aquí hay una lista de vulnerabilidades que se pueden detectar en este listado en orden de frecuencia de detección:

El hashing de contraseñas usando el algoritmo MD5 fue notado incluso por candidatos lejos de la web. Sin embargo, también hubo matices interesantes, por ejemplo, muchos candidatos usaron términos muy incorrectos, tratando de describir los problemas en sus propias palabras. Las "vulnerabilidades de algoritmo", las "funciones unidireccionales", "la existencia de colisiones" y otros giros extraños entraron en batalla, luego de un examen más detallado, no son más que un conjunto de palabras grandes que no revelan la esencia. Por supuesto, aquí fuimos a una reunión y no encontramos fallas en aquellas personas que se están preparando para emprender el camino para aprender la sabiduría de la seguridad de la información. Para obtener una "compensación", bastaría mencionar la amenaza, que en caso de comprometer la base de datos, los atacantes pueden resolver los hash md5 en un tiempo aceptable y se pueden obtener contraseñas (o cadenas equivalentes) en texto claro. Y, por supuesto, muchos mencionaron la falta de sal y fuerza bruta basada en el uso de tablas de arcoiris. También percibimos dichos comentarios positivamente, especialmente si el encuestado explicó por qué esto es una amenaza.

Posible inyección de SQL. Es difícil agregar algo; Al realizar una llamada a la base de datos, la entrada del usuario de inicio de sesión y contraseña se concatena directamente con la solicitud. Si es poco probable que pueda manipular el valor de la contraseña en esta etapa (se le quita un hash), entonces introducir una inyección en el nombre de usuario no será difícil para un atacante potencial.

Salida de información de depuración innecesaria que conduce a un ataque XSS. Al leer cuidadosamente la lista, se podría prestar atención a la llamada de eco, que muestra la solicitud generada a la base de datos en comentarios HTML en la página. Por supuesto, tal conclusión de información adicional a la página es completamente opcional y, muy probablemente, simplemente olvidada por el desarrollador después de realizar las pruebas. Dicha información adicional es muy beneficiosa para el atacante y permite una mejor comprensión de cómo funciona la aplicación. Sin embargo, desafortunadamente, esto es solo la mitad del problema. El hecho es que un atacante puede manipular el contenido de la variable de consulta, y su contenido no se puede filtrar ni escapar antes de mostrarse al usuario; existe un posible ataque XSS. Sin embargo, su explotación puede llegar a ser un dolor de cabeza debido a la función strtoupper mal ubicada. El vector inyectado por el atacante estará en mayúscula, y si esto no es un problema para las etiquetas HTML, entonces Javascript está muy ofendido por tal atractivo. Esto se puede verificar fácilmente utilizando la consola del navegador.



Bueno, al menos, aparentemente, el atacante tendrá que recurrir a los llamados "ataques sin script" o técnicas sofisticadas para evitar el filtrado (en este caso, JSFUCK lo haría), por lo que el hecho de un riesgo de seguridad no cancela esto.

Un error en la lógica del mecanismo de gestión de la sesión fue la parte más interesante de la tarea. Su descubrimiento requirió no solo leer la fuente línea por línea, sino también comprender la lógica de todo el listado. Uno podría sentir que algo estaba mal al notar la configuración de una cookie que contiene la identificación de usuario codificada en base64 en el bloque recordarme. Un análisis más detallado de la lógica de este mecanismo nos lleva a la idea: "¿Resulta que un atacante que conoce o atraviesa la identificación puede iniciar sesión en cualquier cuenta sin ingresar un nombre de usuario y contraseña?". Sí, de hecho, un atacante puede generar independientemente un usuario de cookies a su lado y asignarle cualquier valor de identificación codificado por base64. Enviar una solicitud con dicha cookie sin nombre de usuario y contraseña activaría la función do_login e iniciará sesión en la cuenta de otra persona.

La mención de estas 4 vulnerabilidades en la respuesta de los candidatos influyó directamente en sus puntajes.

Sin embargo, mucho dependía de la calidad de la respuesta. Mencionando formas de rectificar la situación, comentarios sobre factores adicionales que afectan la viabilidad de un ataque, el uso de los términos correctos y la capacidad de estructurar sus pensamientos, comentarios sobre debilidades adicionales o amenazas potenciales: todo esto calienta nuestros corazones y conduce a un aumento en la calificación final.

En el trabajo del auditor a menudo hay que lidiar con nuevas tecnologías, y la capacidad de comprenderlas es muy importante. Incluyendo esta pregunta en el cuestionario, asumimos que la mayoría de los candidatos apenas escuchó sobre la tecnología de los tokens JWT, excepto por el nombre. Por lo tanto, esta pregunta, en primer lugar, estaba dirigida a la capacidad de buscar y analizar información de fuentes públicas. Como resultado, una persona que perdió la emisión de Google a pedido de "JWT" ​​y "vulnerabilidad jwt" podría llegar a las siguientes conclusiones:

1. Este token no tiene un algoritmo de firma, por lo que un atacante puede modificar cualquier campo dentro del token, lo cual no es asumido por el concepto de tokens JWT.

2. Los campos dentro del token contienen la contraseña del usuario en texto claro, almacenar dicha información en el token es, como mínimo, una mala práctica. En la mayoría de los casos, puede rechazar dicha decisión y, por lo tanto, aumentar su nivel de seguridad.

3. Recordando la falta de una firma y nuestra capacidad para modificar los campos dentro del token, es lógico suponer que cambiar el valor de isAdmin puede aumentar nuestros privilegios a privilegios de administrador.

4. Otra idea interesante que pocas personas mencionaron en su respuesta se refiere al hecho de la capacidad de transferir la entrada del usuario en los campos de un token JWT. En una situación normal, un atacante no puede influir en los datos del token de ninguna manera, lo que significa que los desarrolladores a menudo pueden descuidar la introducción de verificaciones adicionales en el código de los controladores. Esto plantea la idea simple: pero intentemos realizar ataques clásicos no a través de parámetros GET / POST, sino a través de campos de token. Esto puede dar un resultado inesperadamente bueno. Este enfoque creativo con la justificación correcta de nuestras acciones fue muy apreciado por nosotros al evaluar este y otros temas.

Muchos candidatos en sus respuestas organizaron un breve recuento de cómo está estructurado el token JWT, y dónde se usa, fue interesante para nosotros leerlo y, sin embargo, antes que nada, evaluamos los aspectos de la respuesta con respecto a la seguridad.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

Consideremos, en orden, cuáles son los principales problemas visibles en las consultas dadas:

1) De hecho, dado que el identificador numérico del usuario "10012" se observa en la solicitud, ¿el primer paso es verificar si es posible cambiar la contraseña de otro usuario? ¿Puede ser suficiente especificar la identificación de otra persona ?
Las vulnerabilidades de la clase IDOR son bastante fáciles de explotar y a menudo tienen una gran criticidad.

2) La solicitud para cambiar la contraseña se realiza mediante el método POST, no se observa el token CSRF y el tipo de contenido es "text / plain". Existe la posibilidad de fingir tal solicitud.

En consecuencia, para cambiar la contraseña de la víctima, es suficiente para que el atacante los convenza de que solo visiten el enlace "malicioso".

3) En los encabezados de respuesta, el servidor revela la versión del software utilizado . Esto puede denominarse vulnerabilidad en un momento, pero es mejor ocultar tales pancartas: los atacantes pueden encontrar fácilmente las conocidas vulnerabilidades de 1 día en ellas, además el valor del software utilizado simplifica enormemente la planificación de nuevos ataques.

4) Estaríamos muy contentos de ver la oración "¿Qué sucederá si cambiamos el formato de datos de JSON a XML ?"

El hecho es que los marcos modernos son inteligentes, omnívoros y pueden procesar datos en diferentes formatos. Y al analizar XML, a menudo se permite una vulnerabilidad XXE peligrosa. Con su ayuda, el intruso puede "ir" a la red interna, puede leer archivos de configuración del servidor y, ocasionalmente, ejecutar RCE.

5) También quería ver un comentario como "¿Por qué no se comprueba el conocimiento de lo antiguo al cambiar la contraseña?"

En cuanto a la "Variante No. 2", hay una "trampa" en ella: los encabezados CORS se usan aquí, y el Tipo de contenido de la solicitud ya está configurado en "aplicación / json".

El error que cometió la gran mayoría de los candidatos es la respuesta del formulario "¡Ese es el asterisco en Allow-Origin, lo que significa que puede enviar solicitudes desde cualquier sitio!"

No, no puedes. En primer lugar, falta el encabezado Allow-Credentials: True, lo que significa que el navegador debe ejecutar la solicitud "con cookies", por lo que la solicitud sería anónima, sin una sesión. Y en segundo lugar, incluso si ese encabezado estuviera presente, el navegador seguiría prohibiendo el envío de cookies, solo por el "asterisco". Su combinación está prohibida y se ignora el navegador.

El objetivo de la pregunta era determinar la familiaridad del aprendiz con las técnicas modernas (y no tan) para llevar a cabo ataques MitM. Veamos escenarios potenciales basados ​​en un volcado de tráfico existente:

1) suplantación de ARP
La suplantación de ARP es la forma más antigua y fácil de implementar ataques MitM. Consiste en enviar una solicitud ARP gratuita al host A.

La dirección IP del host B es la dirección IP, y nuestra dirección MAC es la dirección MAC. Dicha solicitud le permite modificar la tabla ARP en el host A, forzándolo a enviar solicitudes a nuestro dispositivo cuando intente contactar al host B. El host B suele ser la puerta de enlace predeterminada.

Herramientas recomendadas: bettercap, arpspoof

2) LLMNR, NBNS spoofing
Link-Local Multicast Name Resolution y NetBIOS Name Service son los protocolos utilizados para resolver nombres de host en la red local. A diferencia del protocolo DNS, no hay un servidor dedicado que almacene toda la información; en cambio, la solicitud se transmite a todos los hosts en la red, si el nombre de host en la solicitud coincide con el nombre de host del dispositivo, enviará una respuesta.

Como se señaló correctamente en la respuesta, el atacante puede responder a tales solicitudes enviando su dirección IP en la respuesta, lo que conducirá al hecho de que en el futuro la víctima se pondrá en contacto con el dispositivo del atacante en lugar del dispositivo cuyo nombre de host apareció en la solicitud. Además, un atacante puede solicitar la autenticación NTLM de la víctima, lo que hace que el dispositivo de la víctima envíe un hash NTLM, que puede utilizarse para la fuerza bruta.

Herramientas recomendadas: respondedor

3) WPAD spoofing
La suplantación de identidad de WPAD se puede atribuir a un caso especial de suplantación de LLMNR y NBNS. El protocolo Web Proxy Auto Discovery se usa para configurar automáticamente un servidor proxy HTTP.

El dispositivo envía una solicitud LLMNR / NBNS con el nombre de host wpad, recibe la dirección IP correspondiente e intenta acceder al archivo wpad.dat a través de HTTP, que almacena información sobre la configuración del proxy.

Como resultado, un atacante puede realizar falsificaciones de LLMNR / NBNS y proporcionar a la víctima su archivo wpad.dat, como resultado, todo el tráfico HTTP y HTTPS pasará por el atacante.

Herramientas recomendadas: respondedor, mitm6

4) Anuncio de enrutador
Como puede ver en el volcado, hay dispositivos con IPv6 habilitado en la red. Mientras esté en la red, puede intentar enviar mensajes al anuncio de enrutador IPv6 de la víctima para cambiar la puerta de enlace predeterminada o el servidor DNS.

Los mensajes de anuncio de enrutador (RA) son parte del mecanismo SLAAC (configuración automática de direcciones sin estado), que es necesario para obtener automáticamente direcciones IPv6 en una red, sin utilizar un servidor DHCPv6 o en conjunto con él. Esto se logra enviando periódicamente mensajes RA de multidifusión al enrutador, que contienen la dirección de puerta de enlace predeterminada, el prefijo de red, la dirección del servidor DNS y el prefijo de dominio.

Herramientas recomendadas: paquete sin procesar

5) suplantación de identidad DHCP
Además, en un volcado, las solicitudes de DHCP Discover del mismo dispositivo se repiten en algunos intervalos. Puede sacar conclusiones sobre la ausencia de un servidor DHCP en esta red y responder a la próxima solicitud de Discover especificando a la víctima como una puerta de enlace predeterminada al dispositivo.

Herramientas recomendadas: Yersinia

6) falsificación de HSRP
Además, los paquetes HSRP se pueden ver en el volcado. El protocolo de enrutador Hot Standby puede aumentar la disponibilidad de enrutadores que actúan como la puerta de enlace predeterminada. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . Pero! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

Ejemplo

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . Pero , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)