Entonces, ejecuté un análisis de Nessus no autenticado contra una pieza crítica de la infraestructura como parte de una prueba de lápiz, pero estoy recuperando algunas cosas extrañas y parece que no puedo volver a crear el problema para demostrarlo. al cliente.
La máquina que estoy probando es una máquina HP-UX, pero Nessus está marcando que se puede acceder a una 'copia de seguridad' del recurso compartido específico mediante una sesión NULA ( Nessus pluginID 42411 ) y que el contenido del recurso compartido es de lectura / escritura (continúa para enumerar los contenidos correctos del recurso compartido (confirmado por el administrador )). Esto es explotar el servicio en TCP 445.
Ahora, en general, si estoy intentando establecer una sesión NULA desde una máquina basada en Windows a una máquina basada en Windows que sea vulnerable, ejecutaré el siguiente comando
C:\> net use \hostname\IPC$ "" /USER:""
Luego, simplemente puedo navegar por los recursos compartidos simplemente abriendo un diálogo de ejecución y dirigiéndome a \ hostname \ y veo un buen listado. No tanto en este caso. No puedo ver el contenido del recurso compartido ni abrirlo.
Obviamente, esta es una máquina HP-UX, lo que significa que este hallazgo ya está un poco perdido, pero sin embargo, todavía está viendo cosas que no debería ser y no sé cómo volver a hacerlo. crear esto Las CVE asociadas ( 1999-0520 y 1999-0519 ) no parecen contener información útil sobre cómo explotar esto. ¿Las sesiones NULL son solo un problema de Windows o es un cliente de Samba? ¿Cómo puedo reproducir este problema en una máquina de prueba de Linux o en mi máquina de prueba de Windows para demostrar la vulnerabilidad al cliente?
La otra vulnerabilidad identificada por Nessus es el "acceso arbitrario al archivo de Samba Symlink Traversal Travesal" ( Plugin ID 44406 ). Muestra que es capaz de leer el contenido de / etc / passwd y que el contenido está nuevamente confirmado, pero no estoy seguro de cómo reproducirlo nuevamente. Según el aviso de Samba el problema ocurre cuando un cliente tiene permiso para escribir en un directorio (presumiblemente el recurso compartido de "copia de seguridad" mencionado anteriormente) y cree enlaces simbólicos a los recursos locales. Parece que este código demostrará el problema.
¿Es correcto que la reparación de la autenticación de la sesión NULL solucione el problema de Symlink (al menos para los atacantes no autenticados)?