Attack Surface Analyzer segnala possibili azioni [chiuso]

-1

Sto usando l'Attack Surface Analyzer di Microsoft e vorrei ottenere una migliore comprensione di quale sarebbe il modo migliore per mitigare i risultati.

Ad esempio se nel mio rapporto ottengo 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 report è la seguente: The ACL should be tightened. Do not allow users to write to start points, files or directories that influence control over other users.

In questo caso, una soluzione appropriata sarebbe quella di utilizzare un'utilità come icacls per modificare l'ACL (s) della cartella principale dell'accesso a Administrator solo l'accesso utilizzando uno script PowerShell?

Un altro esempio che ho è Services Vulnerable To Tampering , Description: The service My_Service is vulnerable to tampering by multiple non-administrator accounts.

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

In questo caso stiamo parlando di servizi (s), e non ho idea di dove andare con quello ...

Grazie in anticipo per il tuo tempo e qualsiasi aiuto!

    
posta 0siris 06.06.2018 - 19:45
fonte

1 risposta

1

Per i file, chiamando icacls o - poiché stai usando Powershell - implementando la modifica tu stesso usando [System.Security.AccessControl.*] sono entrambe opzioni valide. È anche possibile utilizzare la finestra Proprietà di Windows Explorer, scheda Sicurezza, che consente di modificare gli ACL.

Per il servizio Windows, è più complicato ma possibile. Il comando sc.exe (Controllo servizi) può visualizzare e modificare gli ACL del servizio; vedi qui per ulteriori informazioni. È un processo complicato, tuttavia, e ancora più incline agli errori rispetto all'utilizzo di qualcosa come icacls perché è necessario impostare l'intero ACL in una sola volta, invece di manipolare le singole voci. Non c'è altro modo semplice per manipolare gli ACL di servizio (oltre all'uso di API SCM per chiamare SetServiceObjectSecurity ). L'ACL stesso è memorizzato in un blob non leggibile dall'uomo nel registro.

Una domanda più importante, tuttavia, è perché gli ACL sono così deboli? Un programma ben educato [1] non modifica l'ACL nella sua directory di installazione per consentire ai non amministratori di scrivere lì; per impostazione predefinita non consentito. Allo stesso modo, un programma ben educato non creerebbe un servizio Windows con un ACL debole (la maggior parte dei servizi probabilmente ha ACL di default, che non consentono ai non amministratori di manomettere la configurazione del servizio). Piuttosto che cercare di risolvere i problemi manualmente, potrebbe essere meglio capire da dove provengono e impedire che l'errore venga commesso in primo luogo.

[1] Steam è un eccellente esempio di un programma molto mal funzionante, dal punto di vista della sicurezza; Penso che in effetti indebolisca la sua directory di installazione ACL e possibilmente anche un ACL di servizio.

    
risposta data 06.06.2018 - 22:44
fonte

Leggi altre domande sui tag