Share amministrative e security best practices
Quando ci si appresta a gestire l’hardening di workstation e server una configurazione che sicuramente impone un’analisi approfondita è quella che riguarda le share amministrative ed in particolare se sia opportuno o meno disabilitarle. Infatti sebbene un approccio orientato alla massima sicurezza poterebbe a propendere per una disabilitazione delle share amministrative (DriveLetter$, ADMIN$, IPC$, NETLOGON, SYSVOL, PRINT$, FAX$) occorre valutare se non siano utilizzate da taluni programmi o servizi.
Nel mio post Share amministrative avevo analizzato come disabilitare le share amministrative premettendo che occorre valutare se lo scenario specifico sia possibile non utilizzare le share amministrative oppure se sia preferibile mettere tali share in sicurezza.
Nella KB842715 Overview of problems that may occur when administrative shares are missing relativa a sistemi Windows Server 2003, Windows XP e precedenti veniva indicato che l’assenza delle share amministrative sulle workstations o sui server era causa di una serie di issue. Il motivo di tali issue era anche descritto nella KB816113 How to use Registry Editor to restore administrative shares in Windows Server 2003:
“By default, Windows automatically creates special hidden administrative shares that administrators, programs, and services can use to manage the computer environment or network.”
Nella KB816524 How to remove administrative shares in Windows Server 2003 relativa a sistemi Windows Server 2003 e nella KB954422 How to remove administrative shares in Windows Server 2008 relativa a sistemi Windows Server 2008 e Windows Server 2008 R2 venivano fornite informazioni su come rimuovere le share amministrative, ma veniva anche raccomandato di non rimuoverle:
“Generally, we recommend that you do not modify these special shared resources.”
Quindi le indicazioni di Microsoft propendono per mantenere tali le share amministrative perché sebbene nelle ultime versioni del sistema operativo Windows in taluni scenari è possibile disabilitare alcuni programmi o servizi potrebbe lecitamente utilizzarle in quanto non rapprentano una funzionalità deprecata del sistema. Si veda ad esempio il caso di Veeam Backup & Replication, nella the KB 1230 of Veeam KB 1230 – Win32 error: The network path was not found. Code 53 viene appunto indicato la necessità che sul sistema sia presente la share amministrativa ADMIN$:
“Make sure you can connect to the admin share (for example, \\Server Name\admin$) with the same credentials as provided to Veeam Backup & Replication for VSS.”
Ne consegue che se non è possibile stabilire con certezza se è possibile disabilitare le share amministrative l’approccio più corretto è quello di prevedere delle policies di sicurezza che riducano la superficie di attacco delle share amministrative.
Al tal proposito si veda ad esempio il documento Hardening Microsoft Windows 10 version 1709 Workstations pubblicato dall’Australian Cyber Security Centre (ACSC) in cui non viene suggerito di disabilitare le share amministrative, ma bensì viene indicato di disabilitare le connessioni anonime alle per impedire la raccolta di informazioni:
“An adversary can use anonymous connections to gather information about the state of workstations. Information that can be gathered from anonymous connections (i.e. using the net use command to connect to the IPC$ share) can include lists of users and groups, SIDs for accounts, lists of shares, workstation policies, operating system versions and patch levels. To reduce this risk, anonymous connections to workstations should be disabled.”
Neppure nelle Misure minime di sicurezza ICT per le pubbliche amministrazioni pubblicate da AgID (Agenzia per l’Italia digitale) o nel documento EUD Security Guidance: Windows 10 – 1803 pubblicata dal National Cyber Security Centre (NCSC) viene suggerita disabilitazione delle share amministrative.
E’ possibile avere ulteriori informazioni sulle tecniche di accatto che hanno come obbiettivo le share amministrative al seguente MITRE ATT&CK framework – TECHNIQUES – Lateral Movement – Windows Admin Shares
“Adversaries may use this technique in conjunction with administrator-level Valid Accounts to remotely access a networked system over server message block (SMB) to interact with systems using remote procedure calls (RPCs), transfer files, and run transferred binaries through remote Execution. Example execution techniques that rely on authenticated sessions over SMB/RPC are Scheduled Task, Service Execution, and Windows Management Instrumentation. Adversaries can also use NTLM hashes to access administrator shares on systems with Pass the Hash and certain configuration and patch levels.
The Net utility can be used to connect to Windows admin shares on remote systems using net use commands with valid credentials.”
“Mitigation
Do not reuse local administrator account passwords across systems. Ensure password complexity and uniqueness such that the passwords cannot be cracked or guessed. Deny remote use of local admin credentials to log into systems. Do not allow domain user accounts to be in the local Administrators group multiple systems.
Identify unnecessary system utilities or potentially malicious software that may be used to leverage SMB and the Windows admin shares, and audit and/or block them by using whitelisting tools, like AppLocker, or Software Restriction Policies where appropriate.”
“Detection
Ensure that proper logging of accounts used to log into systems is turned on and centrally collected. Windows logging is able to collect success/failure for accounts that may be used to move laterally and can be collected using tools such as Windows Event Forwarding. Monitor remote login events and associated SMB activity for file transfers and remote process execution. Monitor the actions of remote users who connect to administrative shares. Monitor for use of tools and commands to connect to remote shares, such as Net, on the command-line interface and Discovery techniques that could be used to find remotely accessible systems.”