Acciones posibles del informe del Analizador de superficie de ataque [cerrado]

-1

Estoy usando el analizador de superficie de ataque de Microsoft, y me gustaría comprender mejor cuál sería la mejor manera de mitigar los hallazgos.

Por ejemplo, si en mi informe obtengo Directories Containing Objects With Weak ACLs , Description: The folder C:\Program Files (x86)\My_Folder contains files and/or folders with ACLs that allow tampering by multiple non-administrator accounts. La parte "Action:" del informe es la siguiente: The ACL should be tightened. Do not allow users to write to start points, files or directories that influence control over other users.

En este caso, ¿sería una solución adecuada usar una utilidad como icacls para cambiar la (s) ACL (s) del acceso de la carpeta principal al acceso de solo administrador usando un script de PowerShell?

Un ejemplo diferente que tengo es el Services Vulnerable To Tampering , Description: The service My_Service is vulnerable to tampering by multiple non-administrator accounts.

la parte "Action:" del informe simplemente dice The relevant ACL(s) must be tightened.

En este caso, estamos hablando de servicio (s), y no tengo idea de a dónde ir con ese ...

¡Gracias por su tiempo y ayuda!

    
pregunta 0siris 06.06.2018 - 19:45
fuente

1 respuesta

1

Para los archivos, llame a icacls o, ya que está usando Powershell, implemente el cambio utilizando [System.Security.AccessControl.*] son dos opciones válidas. También puede usar la ventana de Propiedades del Explorador de Windows, pestaña Seguridad, que permite editar las ACL.

Para el servicio de Windows, es más complicado pero posible. El comando sc.exe (Control de servicio) puede mostrar y editar las ACL del servicio; Consulte aquí para obtener más información. Sin embargo, es un proceso desordenado e incluso más propenso a cometer errores que usar algo como icacls porque necesita configurar la ACL completa a la vez, en lugar de manipular entradas individuales. Tampoco hay otra manera fácil de manipular las ACL del servicio (más allá de usar SCM APIs para llamar a SetServiceObjectSecurity ). La propia ACL se almacena en un blob no legible por humanos en el registro.

Una pregunta más importante, sin embargo, es ¿por qué son esas ACL tan débiles? Un programa de buen comportamiento [1] no modificaría la ACL en su directorio de instalación para permitir que los no administradores escriban allí; por defecto eso no está permitido. De manera similar, un programa de buen comportamiento no crearía un servicio de Windows con una ACL débil (la gran mayoría de los servicios probablemente tienen ACL predeterminadas, lo que no permite que los no administradores manipulen la configuración del servicio). En lugar de intentar solucionar los problemas manualmente, es mejor averiguar de dónde proceden y evitar que se cometa el error en primer lugar.

[1] Steam es un excelente ejemplo de un programa de muy mal comportamiento, desde el punto de vista de la seguridad; Creo que, de hecho, debilita su ACL de directorio de instalación y posiblemente también una ACL de servicio.

    
respondido por el CBHacking 06.06.2018 - 22:44
fuente

Lea otras preguntas en las etiquetas