Archivi categoria: Cybersecurity

Implementare reti wireless sicure con 802.1x ed EAP-TLS con Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Per permettere l’accesso alle nostre reti wireless molto spesso utilizziamo delle chiavi di cifratura WPA2, che rimangono le stesse per diverso tempo, e che spesso vengono anche consegnate ad utenti ospiti delle nostre reti. Chiunque disponga della chiave può quindi accedere alla WLAN e non sempre nelle nostre infrastrutture ci preoccupiamo di cambiarla periodicamente, considerando anche che dovremmo farlo su tutti gli access point e su tutti i client.

Per garantire un metodo più affidabile di autenticazione e autorizzazione, da anni è possibile implementare una struttura di protezione WLAN basata sul protocollo 802.1x, uno standard IEEE per l’autenticazione dell’accesso alla rete che può anche essere utilizzato per la gestione delle chiavi di protezione WPA2. Il suo utilizzo non è limitato alle reti senza fili, ma può essere implementato in numerosi switch di fascia alta nelle reti LAN cablate. Per approfondimenti sul funzionamento del protocollo 802.1x vi rimando alla pagina https://it.wikipedia.org/wiki/IEEE_802.1x

In questo articolo vedremo come implementare l’uso del protocollo 802.1x per le nostre reti wireless (ma analogo ragionamento può essere fatto per le reti cablate) utilizzando un server di autenticazione RADIUS creato con Windows Server 2016 ed EAP-TLS. EAP-TLS offre un processo di autenticazione molto sicuro, che sostituisce le semplici password con certificati digitali lato client e lato server, tramite l’utilizzo di una Certification Authority (PKI), creando di fatto quella che viene chiamata Mutual Authentication.

EAP-TLS con Mutual Authentication è attualmente l’implementazione più sicura per l’accesso alle reti wireless o alle reti cablate. I client autenticano il server RADIUS ed il server RADIUS chiede ai client di autenticarsi, richiedendo loro un certificato digitale.

Pertanto questo tipo di autenticazione, basato su certificati digitali sia computer che utente, permette l’accesso solo a chi possiede il certificato corretto e, nel caso la connessione avvenga tramite rete wireless, subito dopo l’autenticazione viene rilasciata una chiave WPA2 unica per utente (o per computer) ed unica per ogni sessione di connessione!

Per creare una infrastruttura di accesso che supporti questo protocollo affronteremo diversi passaggi:

  1. Creazione della Certification Authority e relativa configurazione
  2. Configurazione dei gruppi di accesso in Active Directory
  3. Creazione del server RADIUS di autenticazione utilizzando il ruolo Network Policy Server (NPS)
  4. Rilascio dei certificati per i client
  5. Configurazione degli Access Point per il supporto all’802.1x
  6. Configurazione dei client per il supporto all’EAP-TLS nelle reti wireless

Figura 1: Schema dell’infrastruttura necessaria all’implementazione del protocollo 802.1 con EAP-TLS

Creazione della Certification Authority (CA)

Per creare una certification authority si utilizza il ruolo Active Directory Certificate Services. Procedete all’installazione del ruolo in una macchina Windows Server.

Figura 2: Installazione del ruolo Active Directory Certificate Services in Windows Server 2016

Aggiungete il Role Services di Certification Authority e di Certification Authority Web Enrollment, che vi darà la possibilità di rilasciare i certificati per i vostri client anche attraverso un’interfaccia web.

Figura 3: Aggiunta dei Role Services per il ruolo di CA

Terminata l’installazione sarà necessario configurare la nostra Certification Authority. Cliccate quindi sul link Configure Active Directory Certificate Services in the destination computer.

Figura 4: Installazione del ruolo completata. È necessario però configurarlo

Dopo aver cliccato sul link si aprirà un wizard di configurazione. Configurare entrambi i Role Services che avete appena installato, come mostrato in figura:

Figura 5: Scelta dei Role Services da configurare

Il primo passaggio consiste nell’indicare se volete creare una CA di tipo Enterprise o Standalone. Nel nostro ambiente di dominio utilizzeremo una CA di tipo Enterprise.

Figura 6: Scelta del tipo di Certification Authority da installare

Poiché si tratta del primo server che installiamo, scegliamo di creare una Root CA. Per chi è poco pratico di Certification Authority e vuole conoscere nel dettaglio le differenze, consiglio la lettura dell’articolo Types of Certification Authorities

Figura 7: Scelta del tipo di Certification Authority da utilizzare

Per poter rilasciare i certificati, la vostra Root CA deve avere una chiave privata. Scegliete di creare una nuova Private Key e proseguite con il wizard.

Figura 8: Creazione della nuova chiave privata per la Root CA

La scelta del provider per la crittografia può avere un impatto determinante per la sicurezza, le performance e la compatibilità dei certificati rilasciati dalla vostra CA. Lasciate le impostazioni predefinite e proseguite nel wizard. Poiché le Cryptographic Options sono molto importanti, vi rimando alla lettura dell’articolo Cryptographic Options for CAs

Figura 9: Scelta del provider per la crittografia

Scegliete il nome della vostra CA, in modo che sia facilmente riconoscibile.

Figura 10: Scelta del nome della Certification Autority

Scegliete il periodo di validità del certificato della Root CA

Figura 11: Scelta del periodo di validità del certificato della Root CA

Specificate dove volete che venga salvato il database ed il file di log della CA

Figura 12: Percorsi di installazione del database del file di log della CA

Confermate tutte le configurazioni che avete inserito nel wizard e cliccate sul pulsante Configure:

Figura 13: Conferma delle configurazioni degli Active Directory Certificate Services

Dopo pochi istanti avrete creato e configurato la vostra Certification Authority!

Figura 14: Creazione della CA completata

Configurazione del Network Policy Service (NPS)

Per implementare la nostra infrastruttura basata su RADIUS e protocollo 802.1x ci serviremo di un server Windows in cui installeremo il ruolo di Network Policy Service (NPS). Indipendentemente dal metodo di autenticazione che utilizzerete per le vostre reti wireless (EAP-TLS, PEAP-TLS oppure PEAP-MS-CHAP v2), sarà obbligatorio installare sul Server NPS un certificato digitale che ne permetta il riconoscimento come server di autenticazione.

Per questo motivo sarà necessario distribuire tramite la nostra CA il certificato corretto, creato dal template RAS and IAS Server. Un certificate template viene utilizzato dalla CA per definire il formato ed il contenuto del certificato, per specificare quale utente o quale computer potranno richiederlo e per definirne tutte le caratteristiche e gli usi. Per maggiori informazioni potete leggere l’articolo Certificate Templates Overview

Aprite quindi la console della Certification Authority e dal nodo Certificate Template fate clic col tasto destro scegliendo New –> Certificate Template to Issue

Figura 15: Scelta del nuovo certificate template da distribuire

Per permettere al vostro server NPS di ottenere il certificato valido per poter essere utilizzato con RADIUS server, aggiungetelo in Active Directory al gruppo RAS and IAS Servers. Il gruppo infatti ha la possibilità, di default, di ottenere il certificato dal template RAS and IAS Server che abbiamo appena distribuito.

Figura 16:Aggiunta del server NPS01 al al gruppo RAS and IAS Servers in Active Directory

Riavviate il server NPS in modo tale che possa ottenere nel proprio token Kerberos il SID del gruppo RAS and IAS Servers e, dopo esservi autenticati, aprite una nuova console MMC, aggiungete lo snap-in dei Certificati Computer e procedete alla richiesta del certificato per il server NPS01, come mostrato in figura:

Figura 17: Richiesta di un nuovo certificato sul server NPS01

Se avrete effettuato correttamente tutte le operazioni, vedrete tra le opzioni disponibili la possibilità di richiedere il certificato dal template RAS and IAS Server.

Figura 18: Richiesta del certificato dal template RAS and IAS Server

Installazione del ruolo di Network Policy and Access Services sul server RADIUS

Procedete all’installazione del ruolo Network Policy and Access Services sul server NPS01, come mostrato nelle due figure:

Figura 19: Aggiunta del ruolo Network Policy and Access Services

Figura 20: Aggiunta del ruolo NPS completata

Lanciate la console del Network Policy Server e dalla scheda Getting Started scegliete dal menù a tendina che volete implementare lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections. Cliccate sul link Configure 802.1x, come mostrato in figura:

Figura 21: Scelta dello lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections nella scheda Getting Started

Partirà un wizard che vi guiderà nella configurazione. Nella prima schermata scegliete lo scenario. Nel nostro caso vogliamo rendere sicura una rete wireless.

Figura 22: Scelta del tipo di connessione per l’802.1x

Nella seconda schermata aggiungere il vostro RADIUS Client, cioè l’Access Point che invierà le richieste di connessione al vostro server NPS. Indicate anche uno Shared Secret, che dovrete successivamente inserire nel pannello di configurazione dell’Access Point.

Figura 23: Aggiunta del RADIUS Client (Wireless Access Point)

Figura 24: Potete aggiungere tutti i RADIUS Client che volete utilizzare nella vostra rete wireless sicura

Nella terza schermata scegliete il metodo di autenticazione. Nel nostro caso utilizzeremo i certificati digitali da installare sui pc client che vogliono accedere alla rete wireless (protetta con 802.1x ed EAP-TLS). Scegliete Microsoft: Smart Card or other certifcate e dal pulsante Configure assicuratevi di selezionare il certificato corretto per il vostro server NPS (cioè il certificato generato dal template RAS and IAS Server della vostra CA):

Figura 25: Scelta del metodo di autenticazione

Nella quarta schermata scegliete il gruppo di utenti o di computer di Active Directory che sarà autorizzato ad accedere alla rete wireless. Io ho aggiunto il gruppo Domain Computers

Figura 26: Scelta del gruppo di Active Directory che sarà autorizzato ad accedere alla rete wireless

Se utilizzate le VLAN nella vostra infrastruttura, sarà necessario effettuare ulteriori configurazioni. Maggiori informazioni sono contenute nell’articolo Configure Network Policies

Figura 27: Configurazioni relative alle VLAN

A questo punto il vostro wizard sarà terminato e verranno create una Connection Request Policy ed una Network Policy, entrambe chiamate Secure Wireless Connections.

Figura 28: Configurazione del server NPS completata

Configurazione dei computer client

Terminata la configurazione del server RADIUS è necessario configurare i client. Come prima operazione ci occuperemo di distribuire i certificati ai client che saranno autorizzati ad accedere alla rete wireless. Per poterlo fare ci serviremo di un template e delle group policy. Per poter distribuire i certificati utilizzando le GPO dovremo creare un template adatto a tale scopo.

Creazione del template per la distribuzione dei certificati ai computer del dominio

Dalla console Certificate Templates duplicate il template chiamato Computer per poterne generare uno nuovo, come mostrato in figura:

Figura 29: Duplicazione del template Computer

Dalle proprietà del nuovo template, provvedete a configurare un nuovo nome, ad indicare una durata per i certificati emessi e ad aggiungere alla scheda Security il gruppo di Computer di Active Directory che potrà richiederne i certificati che verranno da esso generati. Se volete utilizzare le GPO per la distribuzione dei certificati non dimenticatevi di selezionare l’opzione AutoEnroll, come mostrato nelle figure seguenti:

Figura 30: Definizione del nome del nuovo template certificati

Figura 31: Permesso di esportare la chiave privata

Figura 32: Aggiunta del gruppo di Active Directory autorizzato e selezione dell’AutoEnroll

Figura 33: Scelta delle informazioni da inserire nei certificati emessi

Terminata la creazione del template, collegatevi alla console di gestione della Certification Authority e distribuite il nuovo template certificato che avete creato, come mostrato nelle figure seguenti:

Figura 34: Aggiunta del nuovo certificate template alla CA

Figura 35: I due certificate template creati e distribuiti dalla nostra CA

Distribuzione del certificato computer utilizzando le Group Policy

Per distribuire il certificato Computer nel nostro dominio tramite le Group Policy vi basta creare una nuova GPO, collegarla alla OU dove si troveranno i computer autorizzati ad utilizzare la rete wireless e da Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies modificare la voce Certificate Services Client – Auto-Enrollment come mostrato in figura:

Figura 36: Auto-Enrollment dei certificati tramite GPO

Tutti i template certificato che saranno configurati per l’Auto-Enrollment per i gruppi di computer di Active Directory verranno distribuiti tramite questo metodo. Nessuno ovviamente vi vieta di installare manualmente i certificati sui vostri computer.

Effettuate un gpupdate sui vostri computer, magari utilizzando la PowerShell Invoke-GPUpdate e assicuratevi che abbiano ricevuto un certificato digitale

Figura 37: Certificati digitali emessi dalla CA e distribuiti tramite Group Policy

Figura 38: Certificato ricevuto dal client tramite la GPO

Configurazione degli Access Point per il supporto all’802.1x

La configurazione dei Wireless Access Point per il supporto all’802.1x varia da modello a modello. In genere trovate la configurazione sotto la voce Wireless
Security, scegliendo WPA2-Enterprise, WPA-Enterprise oppure Open with 802.1X. Nel mio caso ho scelto di utilizzare una chiave WPA2, che verrà data al computer solo dopo che sarà avvenuta l’autenticazione. Ho ovviamente dichiarato qual è il server RADIUS da utilizzare (NPS01) e lo Shared Secret che avevo precedentemente impostato nel wizard di creazione della Network Policy.

Figura 39: Configurazione del Wireless Access Point per l’utilizzo di WPA2-Enterprise

Configurazione dei client per la connessione alla rete wireless

Per configurare manualmente il client a connettersi alla rete protetta con il protocollo 802.1x è necessario effettuare delle operazioni. Spostatevi nel pannello di controllo del vostro client (Io sto usando Windows 10 versione 1709), andate in Network and Sharing Center e scegliete di configurare una connessione manuale verso una rete wireless, come mostrato in figura:

Figura 40: Connessione manuale ad una rete wireless in Windows 10

Inserite il nome della rete wireless a cui volete collegarvi e scegliete come Security type la voce WPA2-Enterprise

Figura 41: Scelta del nome della rete wireless e del metodo di autenticazione

Nel passaggio successivo cliccate sul pulsante Change Connection setting

Figura 42: Modifica delle opzioni della connessione

Spostatevi nella scheda Security e assicuratevi che nel Security type ci sia WPA2-Enterprise, nell’Encryption type ci sia AES e in Authentication method ci sia Microsoft: Smart Card or other certificate. Cliccate sul pulsante Settings per selezionare se volete utilizzare una Smart Card oppure un certificato presente sul computer e controllate di aver selezionato Use Simple Certificate Selection, nel caso sul vostro computer siano installati diversi certificati.

Figura 43: Modifica delle configurazioni di Security per la rete wireless

Cliccando sul pulsante Advanced settings potrete anche forzare come metodo di autenticazione la Computer Authentication, come mostrato in figura:

Figura 44: Opzioni avanzate della scheda Security

Confermate le impostazioni cliccando su OK e provate a collegarvi alla rete wireless. Se tutto sarà stato configurato correttamente vi riuscirete a collegare in pochissimi istanti.

È possibile verificare le configurazioni della rete wireless in qualsiasi momento accedendo al Network and Sharing Center, cliccando sul nome della rete wireless e scegliendo Wireless Properties dalla scheda Wi-Fi status, come mostrato in figura:

Figura 45: Modifica delle configurazioni della rete Wi-Fi

Configurazione dei client per la connessione alla rete wireless tramite Group Policy

Per semplificare la connessione alla rete wireless protetta con 802.1x è possibile anche utilizzare le Group Policy. In effetti la connessione manuale è alquanto impegnativa, non alla portata di tutti gli utenti ed è necessario collegarsi a tutti i pc client per poterla effettuare. Con le GPO, esattamente come abbiamo fatto con i certificati digitali per i computer, l’operazione diventa invece molto semplice.

Create una Group Policy e collegatela alla OU dove si trovano i computer che volete configurare. Spostatevi nel ramo Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies e cliccando con il tasto destro scegliete Create a New Wireless Network Policy for Windows Vista and Later Releases, come mostrato in figura:

Figura 46: Creazione di una nuova Wireless Network Policy

Nella scheda che si aprirà, scegliete un nome per la vostra policy e cliccate su Add per aggiungere le configurazioni di una nuova rete wireless di tipo Infrastruttura, come mostrato in figura:

Figura 47: Aggiunta della nuova rete wireless

Nelle proprietà del nuovo profilo della rete wireless che volete aggiungere, inserite il nome dell’SSID della rete e cliccate sul pulsante Add

Figura 48: Aggiunta dell’SSID della rete wireless

Cliccate sulla scheda Security e configuratela con le informazioni visualizzate nella figura seguente:

Figura 49: Configurazione delle Security per la rete wireless

Completate la configurazione cliccando su OK.

Figura 50: Completamento della configurazione

Da questo momento il profilo verrà distribuito attraverso le group policy. Effettuate un gpupdate sui vostri computer client oppure utilizzate la PowerShell Invoke-GPUpdate dal domain controller e assicuratevi che i client possano accedere alla rete Wi-Fi protetta.

Conclusioni

La sicurezza è una condizione determinante per la protezione delle nostre infrastrutture e della nostra produzione. Filtrare l’accesso alle reti wireless o alle reti cablate servendosi del protocollo di autenticazione 802.1x con EAP-TLS certamente incrementa il lavoro da fare ma allo stesso tempo permette di essere sicuri che alle nostre reti possano accedere solo i computer autorizzati.

Creare un Guarded Fabric con l’Admin-trusted attestation e le Shielded VMs in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Introduzione

Spesso nei Datacenter il ruolo dei diversi amministratori è ben definito e le mansioni sono ben separate: ci sono gli Storage Administrator, i Network Administrator, i Backup Operator e i Virtualiztion-host Administrator. Ognuno di loro ha privilegi limitati quando lavora sui diversi server fisici. Nelle infrastrutture virtuali, in contrasto con quanto appena affermato, può capitare che spesso questi amministratori abbiano privilegi maggiori rispetto a quelli che gli dovrebbero essere permessi.

Scopo di questo articolo è mostrarvi come rendere più sicura l’infrastruttura virtuale e come creare un Guarded Fabric, cioè l’insieme degli host di virtualizzazione Hyper-V ed il loro Host Guardian Service (HGS), che può gestire e far girare macchine virtuali protette (Shielded VM)

Guarded Fabric

Con il rilascio di Windows Server 2016, Microsoft ha introdotto un nuovo modello di sicurezza per la virtualizzazione che è progettato per proteggere gli Hosts e le loro VM. Poiché una VM è un insieme di file, è necessario proteggerla da tutti quegli attacchi che possono avvenire via rete, sullo storage o mentre vengono salvate durante il backup. Questa è una necessità che prescinde dalla piattaforma di virtualizzazione utilizzata, sia che si tratti di Hyper-V, VMware o altre tecnologie di virtualizzazione. Se una macchina dovesse essere spostata fuori dall’azienda (sia accidentalmente che intenzionalmente), questa VM potrebbe essere eseguita in qualsiasi altro sistema non aziendale e quindi si potrebbe avere accesso ai dati contenuti nella VM.

Per proteggersi dalla possibilità che l’infrastruttura (Fabric) possa essere compromessa e si possa accedere ai file delle VM, Windows Server 2016 ha introdotto le Hyper-V Shielded VM, macchine virtuali (Generation 2) che hanno un virtual TPM (Trusted Platform Module), cifrate utilizzando Bitlocker Drive Encryption e che possono essere eseguite solo su alcuni Host di virtualizzazione approvati all’interno del Fabric.

Un Guarded Fabric è formato da un Host Guardian Service (HGS), che generalmente è un cluster a tre nodi, uno o più guarded hosts e una serie di Shielded VM. Vi consiglio prima di cominciare illaboratorio di dare un’occhiata all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2017/03/14/shielded-vms-a-conceptual-review-of-the-components-and-steps-necessary-to-deploy-a-guarded-fabric/

Attestation Modes nei Guarded Fabric

L’Host Guardian Service (HGS) supporta due tipi differenti di deployment (attestation modes) di un guarded fabric: TPM-Trusted Attestation (Hardware based) e Admin-Trusted Attestation (Active Directory based). Il TPM-Trusted Attestation è la modalità che offre la protezione migliore, ma richiede che gli Host Hyper-V utilizzino UEFI 2.3.1 e TPM 2.0. L’Admin-Trusted Attestation è pensato per supportare gli Host che non hanno un TPM 2.0. I Guarded Hosts che fanno girare le Shielded VM vengono approvati dall’HGS in base alla loro appartenenza a un gruppo di sicurezza di Active Directory.

Figura 1: Infrastruttura Guarded Fabric che utilizza Admin-Trusted Attestation (Active Directory based)

Host Guardian Service (HGS)

Il nuovo ruolo server HGS introdotto in Windows Server 2016 è composto dall’Attestation Service e dai Key Protection Services, che permettono ad Hyper v di far girare le Shielded VM. L’Attestation Service verifica l’identità e la configurazione dell’Host Hyper-V (Guarded Host) e il Key Protection Services (KPS) genera la transport key che è necessaria a sbloccare e a far girare le shielded VM. Le Shielded VM proteggono i dati delle macchine virtuali supportando il Virtual TPM che permette di abilitare Bitlocker Encryption sui dischi delle macchine virtuali.

Figura 2: Funzionamento dell’Host Guardian Service

Per i requisiti hardware e software di un server HGS si faccia riferimento all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs

Installazione del Server HGS

In questo articolo verrà mostrato come configurare un server HGS per supportare Admin-Trusted attestation.

Per installare il Server HGS (che nel mio caso è una macchina chiamata LON-SRV1 che è in workgroup) è sufficiente lanciare con privilegi elevati la cmdlet

Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart

Figura 3: Schema di funzionamento del laboratorio

Dopo il riavvio, aprite un command prompt di PowerShell con privilegi elevati e digitate i seguenti comandi:

$adminPassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

Install-HgsServer -HgsDomainName ‘contoso.com’ -SafeModeAdministratorPassword $adminPassword –Restart

Verrà a questo punto installato l’Host Guardian Service, che prevede l’installazione di una nuova foresta chiamata Contoso.com.

Figura 4: Installazione dell’Host Guardian Service, con relativa creazione del dominio

Figura 5: Installazione del Server HGS completata

NOTA: In ambiente di produzione, L’HGS dovrebbe essere installato in un cluster per assicurarsi che l’accesso alle Shielded VM sia mantenuto anche nel caso in cui uno dei nodi HGS non sia disponibile. Pertanto installate il ruolo Server HGS sul primo nodo, che sarà anche il domain controller del dominio HGS di gestione, e successivamente aggiungete gli altri nodi per dominio HGS esistente. Per aggiungere gli altri nodi al Cluster HGS seguite le istruzioni contenute nell’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes

Guardian

Guardian è il termine che viene utilizzato per descrivere la copia di certificati (uno per il signing, l’altro per l’encryption) che protegge la chiave di cifratura simmetrica che viene utilzizata per cifrare il virtual TPM (vTMP) delle Shielded VM. I Guardians contengono solo le chiavi pubbliche, mentre le chiavi private vengono conservate dall’Host Guardian Service (HGS).

Dopo aver nuovamente riavviato il Server HGS, loggatevi come amministratore di dominio (contoso\administrator). Avete bisogno di due certificati per poter inizializzare il vostro server HGS: uno per la firma ed uno per la crittografia. Come prima operazione dovrete creare un certificato (signing.contoso.com) che utilizzerete per la firma. Da un prompt di PowerShell con privilegi elevati digitate i seguenti comandi:

md c:\HGS

$certificatePassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

$signingCert New-SelfSignedCertificate -DnsName “signing.contoso.com”

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath ‘C:\HGS\signingCert.pfx’

Figura 6: Creazione ed esportazione del certificato per la firma completata

A questo punto create ed esportate il certificato che userete per la crittografia (encryption.contoso.com) utilizzando i seguenti comandi:

$encryptionCert New-SelfSignedCertificate -DnsName “encryption.contoso.com”

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath ‘C:\HGS\encryptionCert.pfx

Figura 7: Creazione ed esportazione del certificato per la cifratura completata

Per visualizzare i certificati appena creati potete utilizzare il comando certutil -viewstore “Shielded VM Local Certificates” oppure utilizzare una MMC vuota e lo snap-in dei certificati Computer, come mostrato in figura:

Figura 8: Visualizzazione dei certificati creati utilizzando il comando certutil

Figura 9 Visualizzazione dei certificati creati utilizzando lo snap-in dei certificati Computer

Inizializzazione dell’Host Guardian Service (HGS)

Il passaggio successivo consiste nell’inizializzazione del server HGS. Inizializzate il server HGS con la modalità Admin-Trusted attestation usando il comando PowerShell

Initialize-HGSServer -HgsServiceName ‘hgs’ -SigningCertificatePath ‘C:\HGS\signingCert.pfx’ -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath ‘C:\HGS\encryptionCert.pfx’ -EncryptionCertificatePassword $certificatePassword -TrustActiveDirectory

Figura 10: Inizializzazione del server HGS con la modalità Admin-trusted attestation

Terminata l’operazione di inizializzazione siete pronti ad utilizzare il vostro Server HGS! Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-initialize-hgs-ad-mode-default

Per verificare che tutto sia stato configurato correttamente potete lanciare il comando PowerShell Get-HgsTrace -RunDiagnostics

Figura 11: Inizializzazione del server HGS completata correttamente

Creazione del trust tra il dominio HGS ed il dominio in cui sono attestati gli Host Hyper-V

Per poter utilizzare la Admin-Trusted attestation (Active directory based) è necessario creare un trust unidirezionale tra il dominio del Fabric (nel mio caso Adatum.com) ed il dominio HGS (nel mio caso Contoso.com).

Figura 12: Trust unidirezionale tra il dominio del Fabric (Adatum.com) ed il dominio HGS (Contoso.com)

Configurate il DNS sul LON-SVR1 in modo tale da creare un conditional forwarder che possa risolvere il dominio adatum.com e create un trust di foresta unidirezionale dal dominio HGS verso il dominio fabric utilizzando i due comandi:

Add-DnsServerConditionalForwarderZone -Name “adatum.com” -ReplicationScope “Forest” -MasterServers 172.16.0.10

netdom trust contoso.com /domain:adatum.com /userD:adatum.com\Administrator /passwordD:Pa55w.rd /add

Figura 13: Crazione del trust tra il dominio del fabric ed il dominio HGS

Configurazione del Fabric Domain Server

Aggiungete sul domain controller del fabric (adatum.com) un conditional forwarder che possa risolvere il dominio contoso.com utilizzando il comando PowerShell

Add-DnsServerConditionalForwarderZone -Name ‘contoso.com’ -ReplicationScope “Forest” -MasterServers 172.16.0.11

Create nel dominio Adatum.com un nuovo gruppo chiamato HGSHosts e inserite nel gruppo gli Host di virtualizzazione Hyper-V che ospiteranno le Shielded VM (nel mio caso ho aggiunto LON-HOST1).

Figura 14: Creazione del gruppo che conterrà gli Host di virtualizzazione

Verificate con il comando Get-ADGroup HGShosts qual è il SID del gruppo appena creato. Il SID verrà utilizzato per configurare poi sul Server HGS (LON-SVR1) l’Attestation Host Group ed individuerà tutti gli Host autorizzati a far girare le Shielded VM.

Figura 15: Verifica del gruppo appena creato

Spostatevi quindi sul computer LON-SVR1 e digitate il comando Add-HgsAttestationHostGroup -Name HGSHosts –Identifier <SID>, sostituendo il paramento <SID> con il valore del SID del gruppo che avete precedentemente visualizzato.

Figura 16: aggionta dell’Host Attestation Group al Server HGS

Lanciate il comando Get-HgsTrace -RunDiagnostics per verificare che tutto sia stato configurato correttamente e dopo qualche minuto ricevere lo status di Pass in verde, come mostrato in figura:

Figura 17: Verifica della configurazione del Server HGS

A questo punto avrete terminato la creazione del server HGS e la creazione di un Fabric Domain Server con un Attestation Host Group.

Configurazione dei server Hyper-V (Guarded Host)

Per configurare Hyper-V all’utilizzo di un server HGS e trasformarlo in un Guarded Host in modo tale che possa ospitare Shielded VM, è sufficiente aggiungere ad una macchina Windows Server 2016 il ruolo di Host Guardian Service, sia utilizzando PowerShell con il comando Install-WindowsFeature HostGuardian –IncludeManagementTools –Restart sia utilizzando l’interfaccia grafica di aggiunta e rimozione dei ruoli.

Figura 18: Aggiunta del Ruolo di Host Guardian Service

Figura 19: Installazione del ruolo di Host Guardian Service e di tutti i prerequisiti

Terminata l’installazione ed il successivo riavvio, possiamo configurare il nostro Host Hyper-V come client HGS (Guarded Host) utilizzando il comando PowerShell

Set-HgsClientConfiguration -AttestationServerUrl ‘http://LON-SVR1.Contoso.com/Attestation’ -KeyProtectionServerUrl ‘http://LON-SVR1.Contoso.com/KeyProtection’

Figura 20: Aggiunta del client HGS

È possibile visualizzare in qualsiasi momento la configurazione eseguendo la cmdlet Get-HgsClientConfiguration

Creazione di una Shielded VM

Per creare una Shielded VM è necessario creare una macchina virtuale Generation 2. Nel mio caso la macchina si chiamerà ShieldedVM01

Figura 21: Creazione di una nuova VM Generation 2

Terminata la creazione della macchina procedete all’installazione del Sistema operativo

Figura 22: Installazione del Sistema operativo

Terminata l’installazione della VM ricordatevi di abilitare il Desktop Remoto, in quanto dopo che avremo reso la VM “shielded” non sarà più possibile utilizzare la console di Hyper-V per potervi accedere.

Figura 23: Abilitazione del Desktop remoto nella VM da proteggere

A questo punto arrestate la macchina virtuale, che potrà essere protetta solo se è spenta.

Protezione della VM

Dall’Host di virtualizzazione LON-HOST1 collegatevi al Key Protection Web Service ospitato sul Server HGS (LON-SVR1) e salvate la configurazione localmente utilizzando il comando:

MD C:\HGS

Invoke-WebRequest http://LON-SVR1.contoso.com/Keyprotection/service/metadata/2014-07/metadata.xml -OutFile ‘C:\HGS\HGSGuardian.xml’

Rendete a questo punto LON-HOST1 un local HGS Guardian, utilizzando il file xml che avete generato, digitando il comando PowerShell

$Owner =  New-HgsGuardian –Name ‘Owner’ –GenerateCertificates

$Guardian Import-HgsGuardian -Path ‘C:\HGS\HGSGuardian.xml’ -Name ‘TestFabric’ –AllowUntrustedRoot

Figura 24: Creazione dell’Host Guardian

Create un Key Protector, che definisce quale Fabric è autorizzato ad eseguire la macchina virtuale protetta con il comando:

# Creazione di un Key Portector, che stabilisce quale fabric potrà avviare la VM

$KP New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

# Abilitazione dello shielding della VM

Set-VMKeyProtector –VMName ShieldedVM01 –KeyProtector $KP.RawData

Il passaggio finale consiste nell’abilitare la Security Policy sulla VM e di fatto trasformarla in una Shielded VM.

# Configura la policy di sicurezza della VM

Set-VMSecurityPolicy -VMName ShieldedVM01 -Shielded $true

Figura 25: Configurazione della VM e trasformazione in una Shielded VM

Per abilitare il virtual TPM sulla macchina virtuale è invece sufficiente eseguire il comando Enable-VMTPM -VMName ShieldedVM01.

Adesso la macchina virtuale ShieldedVM01 può essere avviata e se aprite il Virtual Machine Connector riceverete una schermata come quella mostrata in figura, che vi avvisa che d’ora in poi potrete connettervi alla VM utilizzando solo il Desktop remoto.

Figura 26: La connessione in console è proibita sulle Shielded VM

Da questo momento la macchina è protetta e potrà essere eseguita solo sugli Host autorizzati. Infatti se provate ad avviare la macchina su un Host non autorizzato riceverete il seguente messaggio di errore:

Figura 27: Esecuzione di una Shielded VM su un Host non autorizzato e relativo messaggio di errore

Se provate a montare il disco di una VM che è stata protetta riceverete invece il seguente messaggio di errore

Figura 28: Il tentativo di montare il VHD di una Shielded VM fallisce con un errore

Shielded VM in Windows 10 Client Hyper-V

Da Windows 10, versione 1709, anche Client Hyper-V può ospitare le Shielded VM utilizzando l’Attestation con un Server HGS remoto, mentre prima di questa versione era possibile farlo solo utilizzando il local mode, cioè facendo in modo che le encryption key del vTPM venissero salvate localmente. Per approfondimenti vi rimando all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2018/01/05/shielded-vm-local-mode-and-hgs-mode/

Conclusioni

Windows Server 2016 è la versione più sicura tra i sistemi operativi server rilasciati da Microsoft e nell’era dell’Hybrid Cloud la sicurezza rappresenta la sfida maggiore proprio per la natura distribuita dei worloads su diverse piattaforme. Host Guardian Service e le Hyper-V Shielded VM rappresentano un’ottima soluzione per proteggere le macchine virtuali dagli attacchi esterni e dagli accessi non autorizzati da parte degli Hyper-V Administrators.

Come effettuare un PenTest – Parte 4: Enumerazione dei target

Facebooktwittergoogle_plusredditlinkedin

Siamo arrivati alla fase definita “Enumerating Target”. Tale fase è il processo per il quale vengono raccolte informazioni sulla macchina target come:

  • Elenco di Porte aperte (Port Scan);
  • Identificazione OS (fingerprint);
  • Servizi Applicativi Attivi.

Prima di affrontare questi tre punti, provando a descrivere alcuni approcci utili, è opportuno definire in maniera chiara la definizione di Port Scanning:

Port Scanning è un’attività che permette di determinare lo stato delle porte TCP o UDP su una macchina vittima. Una porta aperta significa che un host è in ascolto e dunque vi è un servizio accessibile. Al contrario una porta chiusa sta ad indicare che il target non è in ascolto su quella specifica porta.

Un esempio pratico di port scanning e il suo possibile risultato può essere questo:

Un attaccante, interrogando una porta aperta (dunque un servizio attivo su una potenziale vittima), è in grado di recuperare la versione di un Web Server (Esempio molto banale ma chiarificatore).

Se la versione del Web Server risulta vulnerabile, secondo le ultime scoperte, potrebbe essere possibile sfruttare la vulnerabilità.

Prima di affrontare una simulazione di scansione, occorre ricordare due concetti base a livello di trasporto nello STACK TCP/IP:

  • Il protocollo TCP è considerato statefull in quanto ha dei controlli interni inerenti la ritrasmissione dei pacchetti; utilizza il concetto del Three Way-HandShake ed è utilizzato, data la sua affidabilità, per trasmettere dati come HTTP, FTP o SSH.

  • Il protocollo UDP è al contrario Stateless. I pacchetti inviati non sono controllati e qualora un pacchetto vada perso, dovrà essere ritrasmesso dall’applicazione.

    Un modo per poter identificare porte aperte e relativi servizi, è utilizzando il network tool NMAP. La possibilità di conoscere la versione dei servizi esposti può essere un buon punto di partenza per ricercare eventuali vulnerabilità o exploit pubblici.

Nmap risulta essere uno dei tools più famosi e completi presenti nel panorama dell’IT security. Oltre al semplice port scan può essere usato anche per:

  • Host Discovery;
  • Identificazione di Host/Servizi;
  • Os (Operating System) Fingerprint;
  • Network Traceroute;
  • Custom Nmap Script.

Per installare NMAP basta eseguire il comando:

# apt-get update

# apt-get install nmap

# nmap

Nell’interrogare una porta, essa potrebbe rispondere in più modi, a seconda del suo stato. NMAP si preoccupa di interpretare le risposte e fornirci un riscontro User-Friendly.

Le porte possono essere:

  • Open: significa che ha la porta in ascolto ha accettato un pacchetto TCP o un UDP datagram;
  • Closed: significa che anche se la porta risulta accessibile, non vi è nessun servizio esposto;
  • Filtered: sta ad indicare che il tool non è in grado di identificare se la porta è aperta o no, in quanto vi può essere un packet-filter
  • Unfiltered: non riesce ad identificare se la porta è aperta o chiusa;
  • Open | Filtered: è solito ricevere questo stato quando nmap non è in grado di capire se la porta è aperta o filtrata. Accade quando vi è un drop dei pacchetti;
  • Closed | Filtered: in quest’ultimo caso, il tool non è in grado di determinare se la porta è filtrata o chiusa.

L’utilizzo basilare di Nmap è stato già affrontato in un precedente articolo che vi invito a leggere prima di proseguire la lettura di questo articolo: https://www.ictpower.it/sicurezza/testare-la-sicurezza-della-propria-rete-utilizzando-nmap.htm

Tipologie di Scansione: una per ogni occasione

Nmap utilizza numerose tipologie di scansioni: ognuna di esse ha una funzione specifica e con finalità ben precise.

  • TCP Connect scan (-sT): questa scansione va a stabilire un three-way handshake su tutte le porte specificate dall’attaccante. Risulta essere molto intrusiva, lenta e loggabile dalla vittima;
  • SYN Scan (-sS): è la tipologia di scansione utilizzata da Nmap per default, veloce e non intrusiva. Definita anche half-open in quanto vengono inviati pacchetti TCP con FLAG SYN, senza completare il three-way Handshake.

    In base alla risposta della vittima è facile capire se un servizio risulta essere in ascolto.

  1. Se la risposta ad un pacchetto SYN risulta essere SYN/ACK siamo in presenza di una porta aperta e con un servizio attivo;
  2. nel caso di risposta RST/ACK, significa che la porta non è in ascolto.
  3. Se dovessimo ricevere un pacchetto ICMP di tipo “destination unreacheble” potrebbe trovarci di fronte ad una porta filtrata.
  • TCP NULL Scan (-sN), FIN scan (-sF) o XMAS scan (-sX): sono 3 tipologie di scansione che agiscono sempre sui flag del protocollo TCP. NULL scan tende a non settare nessun bits di controllo. FIN Scan setta il FLAG FIN nel TCP, XMAS Scan setta i FLAG URG, FIN e PSH.
    • Se si riceve un pacchetto con FLAG RST, la porta risulta chiusa; se non si riceve risposta significa che la porta può essere aperta o filtrata.
  • TCP Maimon scan (-sM): è una tecnica di scansione basata sul settare i FLAG TCP con FIN/ACK.
    • Se riceviamo un pacchetto RST la porta risulterà chiusa;
    • se il pacchetto sarà droppato la porta è da considerarsi aperta. (Droppato da DROP, dunque scartato)
  • TCP ACK scan (-sA): Utilizzato prevalentemente per vedere se vi è un firewall di tipo stateful e quali porte sono filtrate.
    • Se riceviamo un pacchetto con FLAG RST la porta non è filtrata;
  • TCP Idle scan (-sI) : è una scansione indiretta, utilizzata per nascondere il vero attaccante. Utilizza infatti uno “Zombie”. Potrebbe essere un buon modo per mascherare alcune tracce.

Fino ad ora abbiamo descritto le scansioni più utilizzate con il protocollo TCP. Per il protocollo UDP le performance di scansione tendono ad essere molto inferiori.

Dunque mettetevi comodi…

Un buon consiglio potrebbe essere quello di concentrarsi su le porte standard o condurre una scansione in modo distribuito.

# nmap -sU 8.8.8.8 -p 53

[UDP scan sulla porta 53, host 8.8.8.8]

Ricorda: Nmap, per default, scansiona le top 1000 porte. Per specificare le porte usa il comando -p.

Bypass delle protezioni

Esistono alcune tecniche molto utili per Bypassare controlli basati su IDS o Firewall:

  • Fragment packets (-f): nmap si preoccuperà di dividerà i pacchetti in 8 byte o meno dopo l’header IP;
  • (–mtu): permette di specificare la dimensione della frammentazione di un pacchetto. Il Maximum Transmission Unit (MTU) deve essere un multiplo di otto o Nmap restituirà errore;
  • –source-port <portnumber> permette di specificare la porta sorgente. È utile per ingannare un firewall qualora esso accetti una determinata porta in ingresso;
  • –data-length: permette di specificare la grandezza dei pacchetti inviati;
  • –max-parallelism: con questa istruzione possiamo specificare quanti tentativi/prove possono esser fatte verso un target in un certo tempo;
  • –scan-delay <time>: può essere utile per ingannare IPS/IDS basati su rilevazione degli eventi con soglia.

Una combinazione tra una scansione ben studiata e delle impostazioni di evasione potrebbe garantirvi un ottimo risultato in poco tempo.

Per chi volesse, esiste la possibilità di avere una GUI per utilizzare Nmap. Parliamo di ZenMap. Oltre ad un’interfaccia più semplice ed intuitiva, vi è la possibilità di salvare profili o configurazioni personalizzate.

Inoltre vi è la possibilità di osservare una possibile topologia di rete scansionata.

Enumerazione SMB

Se stiamo andando a testare un ambiente con prevalenza di macchine Windows, questo approccio può essere molto utile. Si tratta di una enumerazione basata sul collezionare informazioni del protocollo Server Message Block.

Tale protocollo è usato per condividere file e stampanti in rete ed è utilizzato da Sistemi Windows.

Per affrontare un enumerazione SMB è possibile scaricare il tool nbtscan.

Per utilizzarlo, basta digitare:

# nbtscan 192.168.1.1-254

[Si noti come ho specificato un intervallo di IP]

Il risultato del comando restituisce il range di ip con le risposte alle query NetBIOS. La differenza sostanziale tra il comando nbtscan e nbtstat è che nello script nbtscan è possibile inserire un range di Ip.

Tale tipologia di enumerazione resta sconsigliata in quanto facilmente loggabile in una macchina vittima.

Esistono altre tecniche di enumerazione più avanzate come quella basata su SNMP (snmpcheck) o VPN (ike-scan) che non affronteremo. Per ulteriori dettagli vi rimando ai rispettivi tools:

Snmpcheck: https://tools.kali.org/information-gathering/snmp-check

Ike-scan: https://github.com/royhills/ike-scan

Siamo giunti al termine di questo articolo con la consapevolezza e l’abilità di poter identificare servizi esposti e possibilmente vulnerabili. Nel prossimo passo cercheremo di mappare tutte le possibili vulnerabilità presenti sulla macchina target per poi sfruttarle a nostro vantaggio.

Implementare Local Administrator Password Solution

Facebooktwittergoogle_plusredditlinkedin

Local Administrator Password Solution (LAPS) è un software Microsoft che permette di gestire le password degli amministratori locali in Windows. Quando installate il sistema operativo vi viene chiesto di inserire la password per l’utente amministratore locale del computer e spesso utilizzate questo account e la password impostata per potervi loggare localmente alla macchina se non riuscite a loggarvi al dominio. Gestire manualmente queste password, ammesso e non concesso che non sia un’unica password per tutti i vostri computer, è un’impresa non da poco quando si devono gestire centinaia se non migliaia di macchine. Immaginate cosa potrebbe succedere se la password venisse rivelata a persone indesiderate.

Local Administrator Password Solution (LAPS) permette di creare un repository centralizzato dove conservare le password per gli amministratori locali delle macchine (utenti che hanno il SID che finisce con .500) che sono collegate al dominio e vi permette di:

  • Avere una password univoca e quindi diversa su ogni computer che LAPS gestisce
  • Cambiare regolarmente la password dell’amministratore locale
  • Conservare le password in un attributo del computer in Active Directory
  • Configurare e controllare gli accessi alle password
  • Trasmettere in maniera sicura le password ai computer gestiti

LAPS funziona sia sulle versioni a 32 bit che a 64 bit di Windows 10, Windows 8, Windows 8.1, Windows 7, Windows Vista, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 e richiede che il livello funzionale del dominio sia almeno Windows Server 2003 o successivo.

Prima di utilizzare il tool sarà necessario aggiornare lo schema di Active Directory con la cmdlet Update-AdmPwdADSchema (inclusa nel modulo PowerShell che verrà installato insieme al tool) e distribuire il client MSI (magari utilizzando le Group Policy client-side extension).

Il tool è scaricabile dall’indirizzo https://www.microsoft.com/en-us/download/details.aspx?id=46899

Come funziona LAPS

Dopo aver distribuito il client sulle macchine da amministrare, ogni volta che avviene il refresh delle Group Policy, vengono effettuate le seguenti operazioni:

  • LAPS controlla se la password dell’amministratore è scaduta
  • Se la password è scaduta allora viene generata dinamicamente una nuova password, che viene conservata in un particolare attributo di AD del computer, e viene trasmessa al computer e quindi assegnata all’account amministrativo

Installazione di LAPS

Prima di poter configurare i computer, sarà necessario spostarli in una OU dedicata, a cui verranno successivamente associate le Group Policy per la gestione.

Scaricate LAPS e installate solo i tool di gestione. Nel mio caso l’ho installato sul domain controller. Disabilitate l’AdmPwd GPO Extension ed abilitate tutti management Tools, come mostrato in figura:

Figura 1: Schermata iniziale del tool Local Administrator Password Solution

Figura 2: Configurazione dei parametri del tool

Figura 3: Completamento dell’installazione

Terminata l’installazione del tool, lanciate un prompt di PowerShell con privilegi elevati ed eseguite i seguenti comandi:

Import-Module admpwd.ps

Update-AdmPwdADSchema

Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers” (Roma_Computers è l’organizational unit dentro la quale ci sono i computer da gestire)

Ricordatevi che per poter aggiornare lo schema dovete eseguire la cmdlet Update-AdmPwdADSchema con privilegi di Enterprise Admin o di Schema Admin.

Figura 4: Configurazione e aggiornamento dello Schema

A questo punto create una nuova GPO e collegatela alla OU che volete gestire. Io ho chiamato la GPO con il nome LAPS e l’ho collegata alla OU chiamata Roma_Computers. Editate la GPO e dopo esservi spostati nel ramo Computer ConfigurationàPoliciesàAdministrative TemplatesàLAPS, modificate il parametro Enable local admin password management mettendolo su Enabled e il parametro Password Settings scegliendo lunghezza e durata della password, come mostrato in figura:

Figura 5: Configurazione dei parametri della Group Policy per il LAPS

Distribuzione del client LAPS

Per distribuire il client potete utilizzare i metodi che preferite, sia con l’installazione manuale che con la distribuzione tramite Group Policy client-side extension o con altri metodi ESD (Electronic Software Distribution).

Procedete quindi all’installazione del software e, nel caso l’abbiate fatta manualmente, ricordatevi di aggiornare le policy con il comando gpupdate /force.

Figura 6: Distribuzione del client LAPS tramite GPO

Figura 7: Applicazione della GPO sui pc client

Dopo aver riavviato il client per permettere l’installazione dell’agent di LAPS, potete tornare sul vostro server di amministrazione (nel mio caso il domain controller) e da Start aprite LAPS UI.

Digitate il nome del computer da ricercare e fate clic su Search. Vi apparirà la password dell’amministratore locale e la scadenza, come mostrato in figura:

Figura 8: Verifica della password tramite LAPS UI

In alternativa all’interfaccia grafica è anche possibile utilizzare la cmdlet Get-AdmPwdPassword CL1 Out-Gridview

Figura 9: Utilizzo di PowerShell per la visualizzazione della password

Oppure è possibile visualizzare il valore dell’attributo ms-Mcs-AdmPwd del Computer Account in modalità visualizzazione avanzata della console di Active Directory Users and Computers.

Figura 10: Attibuto ms-Mcs-AdmPwd del computer account in AD

Per permettere ai computer di poter aggiornare la password dell’amministratore locale quando scade è sufficiente eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers

Figura 11: Abilitazione per l’autoaggiornamento della password

Per impostazione predefinita i gruppi Domain Admins ed Enterprise Admins possono visualizzare le password gestite tramite LAPS. Se volete delegare ad un gruppo specifico la possibilità di vedere le password dell’amministratore locale allora sarà necessario eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdReadPasswordPermission -Identity “Roma_Computers” -AllowedPrincipals “Roma_ITOps”

Figura 12: Delega amministrativa per LAPS

Conclusioni

Local Administrator Password Solution (LAPS) permette di semplificare enormemente la gestione delle password degli amministratori locali e soprattutto aumenta il livello di sicurezza delle postazioni di lavoro. Molto spesso l’utilizzo della stessa password, che si ripete da diversi anni, è una vulnerabilità sensibile delle nostre macchine e le espone alla possibilità di essere facilmente attaccate o di essere amministrate da utenti non autorizzati.

Maggiori informazioni le trovate al link https://technet.microsoft.com/it-it/mt227395.aspx

Active Directory – Tecniche di attacco e di difesa

Facebooktwittergoogle_plusredditlinkedin

L’Active Directory (AD) se non gestita e monitorata correttamente può diventare un vettore di attacco per l’infrastruttura aziendale. Di seguito elencheremo una serie di tipologie di attacco che possono sfruttare AD come vettore cercano di capire come possono essere prevenute e mitigate.

Attacchi su Active Directory volti a creare una BotNet

Questo tipo di scenari attacco sono stati analizzati da Ty Miller (Managing Director at Threat Intelligence Pty Ltd) e Paul Kalinin (Senior Security Consultant at Threat Intelligence Pty Ltd) nella sessione The Active Directory Botnet tenuta al blackhat USA 2017.

Tali attacchi si basano sul fatto che gli oggetti utente in Active Directory hanno come risaputo un gran numero di attributi che possono essere letti da tutti gli account utenti e computer del dominio, per contare il numero di attributi esposti da un account utente è possibile utilizzare il seguente comando PowerShell:

(Get-ADUser -Identity Username -Properties *).PropertyCount

Gli attributi di un oggetto utente in Active Directory possono essere di vario tipo come Stringa, Numerico, Boolean, Binario, etc. e ogni attributo può contenere dati di diversa dimensione da pochi bytes fino MBytes, di seguito una query PowerShell per vedere nome, tipo e dimensione massima degli attributi degli oggetti utente in Active Directory (a riguardo si veda il post Exploring Active Directory Data Types with PowerShell):

$schema =[DirectoryServices.ActiveDirectory.ActiveDirectorySchema]::GetCurrentSchema()

$schema.FindClass(‘user’).OptionalProperties | Select Name, RangeUpper | Sort RangeUpper -Descending

Gli attributi possono quindi essere utilizzati per l’injection dei dati da parte di una botnet al fine di utilizzarli successivamente da altri computer. Una Active Directory Botnet presenta infatti il seguente schema di funzionamento:

  1. Gli host compromessi fanno injection di dati negli attributi del loro account AD ed eseguono query nel dominio per identificare i sistemi compromessi
  2. Questo approccio permette al bot master e agli slave di identificare le macchine infette su cui lanciare i comandi le cui risposte saranno memorizzate negli attributi dell’account AD corrispondente all’endpoint e lette poi dall’host che aveva lanciato il comando
  3. Le Botnet possono anche implementare una funzione di copertura che consente comunicazioni confidenziali tra gli host e la possibilità di utilizzare proprietà personalizzate di Active Directory per eludere tentativi di rilevamento
  4. Questo tipo di attacco fornisce un potente canale di comunicazione che elude i Network Access Controls (NAC) e consente di implementare un Command & Control basato su Active Directory
  5. Grazie all’utilizzo degli attributi degli oggetti AD né la Domain separation né la network segmentation possono interrompere la comunicazione
  6. Dopo aver stabilità la comunicazione con la Botnet gli attributi binari vengono utilizzati per scaricare file posizioni remote tramite binary-to-text Base64 encoding
  7. A questo punto le bots possono comunicare esternamente tramite shell remote che vengono utilizzate anche per eseguire l’exfiltration dei dati all’esterno dell’infrastruttura

La prevenzione di questo tipo di attacchi non può che basarsi sul monitoraggio regolare delle modifiche sugli attributi degli oggetti utenti di AD che non dovrebbero subire Variazioni in modo regolare, ovvero occorre rispettare la quinta legge delle 10 Immutable Laws of Security Administration:

Law #5: Eternal vigilance is the price of security

Nativamente come indicato in Monitoring Active Directory for Signs of Compromise è possibile eseguire l’audit delle Directory Service Changes, ma si noti che vi sono alcune limitazioni (per maggior dettagli si veda Audit Directory Service Changes):

“This subcategory reports changes to objects in AD DS. The types of changes that are reported are create, modify, move, and undelete operations that are performed on an object. Directory service change auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL entries. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema. This subcategory applies only to domain controllers.”

Per maggiori dettagli suul’Auditing di AD si veda anche AD DS Auditing Step-by-Step Guide.

In alternativa è possibile utilizzare prodotti di terze parti, come ad esempio ADAudit Plus di ManageEngine, mentre al momento Advanced Threat Analytics (ATA) non rileva attività malevole basate sulla modifica degli attributi degli oggetti AD, per i dettagli sulle attività sospette rilevate da ATA si veda: Advanced Threat Analytics suspicious activity guide.

AD Discretionary Access Control Lists (DACL) Backdoors

Questo tipo di scenari attacco sono stati analizzati da Andy Robbins (Adversary Resilience Lead at SpecterOps) e Will Schroeder (Offensive Engineer at SpecterOps) nella sessione An ACE Up the Sleeve: Designing Active Directory DACL Backdoors tenuta al blackhat USA 2017 e nel post Active Directory Access Control List – Attacks and Defense del Microsoft Advanced Threat Analytics Team.

Tali attacchi si basano sull’utilizzo del Discretionary Access Control List (DACL) per eseguire privilege escalation in un ambiente di dominio utilizzando come vettore di attacco la creazione di un path di escalation basato sulle permissions degli oggetti AD (DACLs), ma prima di affrontare alcuni potenziali scenari di attacco occorre prima analizzare i concetti su cui questi attacchi si basano.

L’Access Control è implementato assegnando Security Descriptors agli oggetti AD, un Security Descriptor è un set di informazioni collegate ad ogni oggetto e che contiene quattro componenti di sicurezza:

  • Il Security identifiers (SIDs) dell’Object Creator (l’utente che ha creato l’oggetto) e del primary group dell’oggetto
  • La Discretionary Access Control List (DACL) costituita da access control entries (ACE) che rappresentano i SID di utenti e gruppi a cui sono consentiti o negati i diritti di accesso all’oggetto
  • La System Access Control List (SACL) costituita dagli utenti e gruppi a cui è consentito l’auding sull’oggetto
  • Un set di control bits che qualificano il significato di un descrittore di protezione o dei singoli membri.

Va precisato che gli accounts built-in privilegiati (Domain Admins, Enterprise Admins, etc) sono protetti dal Security Descriptor propagation (o SDProp) che forza le ACL per impedire modifiche non autorizzate ogni 60 minuti (per default) resettando le permissions a quelle del container AdminSDHolder contenuto nel System container della Domain Partition. Il processo esegue i task in modo recursivo su tutti i membri dei gruppi e disabilita l’eredità su tutti i protected accounts.

Uno scenario di attacco basato sulla Discretionary Access Control List (DACL) è quello che
si basa sulle deleghe di permissions su oggetti AD concessi ad account non-built-in privilegiati. AD consente ad un amministratore di delegare permission a normali account di dominio (utenti, gruppi, computer) senza la necessità di aggiungere tali account a gruppi amministrativi e tra le deleghe comunemente concesse vi sono “Reset Password” (spesso concessa agli utenti helpdesk) e la “Add New Member to a group” (spesso concessa ai proprietari dei business group).

Quindi nel caso in cui venga compromesso un account a bassi privilegi, ma con la delega “Add New Member to a group” che gli permette di aggiungere un utente ad un gruppo che ha a sua volta il privilegio di “Reset Password” su un gruppo che contiene utenti ad elevati privilegi è possibile creare un path di attacco volto alla compromissione di account privilegiati.

Di seguito un schema di esempio di questo path di attacco:

Come illustrato precedentemente un ipotetico attaccante non sarà in grado di eseguire una privileges escalation sui privileged built-in accounts le cui ACL sono protette da SDProp, quindi la modifica alle ACL di default del container AdminSDHolder è sconsigliata perché estende la superficie di attacco del dominio, va comunque precisato che non esistono motivi per cui sia necessario modificare le ACL di default del container AdminSDHolder come riportato nel post Active Directory Access Control List – Attacks and Defense:

“Why would you change AdminSDHolder manually? No idea.

You should be careful with changing the AdminSDHolder, the Exchange team faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. If you have a good reason (as we couldn’t find one) please leave us comments at ATAResearch@Microsoft.com.”

Anche in questo caso la prevenzione di questo tipo di attacchi deve innanzitutto basarsi sul monitoraggio dell’infrastruttura inteso come ricerca di potenziali path di attacco e per eseguire tali ricerche è possibile utilizzare un tool open source come BloodHound che utilizzando la teoria dei grafi ricerca relazioni nascoste o non desiderate in un ambiente Active Directory. Un altro tool open source per eseguire l’analisi dei path e delle relazioni in AD, a cui gli stessi autori di BloodHound si sono ispirati, è Active Directory Control Paths. Un terzo tool GUI basato su PowerShell per la creazione di report delle access control lists (DACLs) e delle system access control lists (SACLs) in un ambiente Active Directory è https://github.com/canix1/ADACLScanner, il cui utilizzo è descritto nel post Forensics: Active Directory ACL investigation.

Per l’identificazione di questo tipo di attacchi può anche essere impiegato ATA come indicato nel post Active Directory Access Control List – Attacks and Defense:

“ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.”

Conclusioni

Gli attacchi che hanno come obbiettivo Active Directory sono ovviamente molto pericolosi perché se messi in atto mettono nelle mani dell’attaccante il controllo completo dell’infrastruttura. Per prevenire tali attacchi è necessario gestire attentamente la propria infrastruttura, analizzarla attentamente al fine di scovare preventivamente possibili path di attacco o di escalation e monitorare attentamente comportamenti anomali al fine di bloccare rapidamente eventuali tentativi di compromissione di Active Directory. In altre parole occorre rispettare le 10 Immutable Laws of Security Administration e in particolare oltre alla già citata quinta legge anche la settima:

Law #7: The most secure network is a well-administered one

Dal momento che Active Directory rappresenta il fulcro su cui si basa la sicurezza dell’intera infrastruttura oltre al monitoraggio e analisi è bene adottare anche delle serie politiche per la gestione di account privilegiati a riguardo di veda Securing Privileged Access in cui viene descritto come implementare la protezione degli accessi privilegiati tramite l’utilizzo di account amministrativi separati per attività amministrative, l’adozione di Privileged Access Workstations (PAWs) (a riguarda si veda http://aka.ms/CyberPAW), l’adozione di Local Administrator Password Solution (LAPS) (a riguarda si veda http://aka.ms/LAPS) sia per le workstations che per i server al fine di evitare attacchi Pass-the-Hash and Pass-the-Ticket (per ulteriori informazioni inerenti all’implementazione di queste politiche di sicurezza di veda http://aka.ms/securitystandards).

Sempre nell’ottica di adottare anche delle serie politiche per la gestione di account privilegiati anche le indicazioni fornite nel post Protecting Domain Administrative Credentials circa la best practice di differenziare le credenziali di un amministratore di sistema in base al Tier per cui vengono utilizzate limitando i privilegi di tali credenziali alle sole attività che è necessario svolgere nel Tier:

  • Tier 0: attività amministrative su Active Directory
  • Tier 1: attività amministrative su server applicativi
  • Tier 2: attività non privilegiate di utilizzo dei servizi dell’infrastruttura informatica

Come già discusso anche l’adozione di strumenti di analisi dell’infrastruttura evoluti e basati su machine learning come Advanced Threat Analytics (ATA) possono essere utili nel monitoraggio di tentativi di compromissione, ma come indica la decima delle 10 Immutable Laws of Security Administration non bisogna basare le proprie difese affidandosi ciecamente ad un prodotto di sicurezza:

Law #10: Technology is not a panacea

ATA è sicuramente un ottimo strumento per la rilevazione di vari tipi di attacchi tra cui quelli relativi ad Active Directory (a riguardo si veda Advanced Threat Analytics suspicious activity guide) inoltre la tipicità di questo tipo di prodotto fa sì che sia lecito aspettarsi una sempre maggiore efficacia nel rilevamento dei tentativi di compromissione, ma come detto precedentemente occorre prevedere una difesa della propria infrastruttura basata su più livelli di protezione e monitoraggio. Infatti ATA, al momento, oltre a non avere specifiche funzionalità per il rilevamento di Active Directory BotNet basate sulla modifica degli attributi degli oggetti AD può essere eluso con particolari tecniche descritte nella sessione Evading Microsoft ATA for Active Directory Domination tenuta al blackhat USA 2017 da Nikhil Mittal.

Un nuovo modello per la sicurezza con AppDefense

Facebooktwittergoogle_plusredditlinkedin

Rodolfo Rotondo, ‎Senior Business Solution Strategist EMEA di ‎VMware

Il modello di sicurezza sta evolvendo significativamente. Da essere una delle tante preoccupazioni per molte aziende, la sicurezza è ora parte essenziale di ogni singolo elemento all’interno dell’ambiente IT, dai dati e dalle applicazioni alla rete e alle infrastrutture.

La frequenza crescente dei problemi legati alla sicurezza punta su un limite fondamentale dei modelli di sicurezza, che si focalizzano solo sulla ricerca delle minacce. Per offrire una protezione efficace, oggi le organizzazioni hanno bisogno di riuscire a ridurre la superficie di attacco che le applicazioni moderne espongono e trovare il modo per allineare i controlli di sicurezza alle applicazioni.

Facendo leva sull’infrastruttura virtuale per monitorare le applicazioni in esecuzione, VMware offre una visione chiara dell’applicazione e del suo comportamento, tramite un modello che consente di sapere se un’applicazione o uno dei suoi componenti si comporta in modo significativamente diverso dal suo comportamento previsto. Questo è reso possibile grazie all’aumento dell’utilizzo dell’automazione nell’applicazione e nella fornitura di infrastrutture, nei framework applicativi, nel machine learning, nella virtualizzazione e nel cloud.

Il risultato è AppDefense, che sfrutta le proprietà univoche della virtualizzazione per proteggere le applicazioni in esecuzione in ambienti virtualizzati e cloud. AppDefense offre un modello di sicurezza intent-based che si concentra su quello che l’applicazione dovrebbe fare piuttosto che su cosa fa chi attacca.

Un modello di sicurezza intent-based è reso possibile attraverso:

  • Un uso sempre maggiore dell’automazione nel provisioning delle applicazioni e dell’infrastruttura
  • L’uso di framework applicativi che forniscono viste più ricche e più autorevoli dello stato previsto
  • L’applicazione del machine learning che consente di ragionare sullo stato e il comportamento su un campione ampio
  • Un utilizzo crescente di virtualizzazione e cloud che fornisce maggiore application context e isolation.

Far leva su VMware vSphere fornisce ad AppDefense molte capacità esclusive. Primo, è in una posizione unica per avere una visione completa del ricco contesto applicativo. Inoltre, può sfruttare l’hypervisor per creare una zona protetta da cui salvare lo stato previsto e monitorare il comportamento in esecuzione. Infine, può sfruttare vSphere e NSX per automatizzare e orchestrare la risposta. Il risultato è che AppDefense può ridurre significativamente la superficie di attacco, rendendo l’identificazione delle minacce e la risposta più efficaci, e creando un modello per la sicurezza DevOps-friendly più agile.

Con AppDefense, le aziende possono ora avere un approccio più proattivo alla sicurezza e credo che probabilmente AppDefense avrà lo stesso impatto sullo stack di calcolo che VMware NSX e la micro-segmentazione hanno avuto per la rete.

Nel video seguente Tom Corn, Senior Vice President, Security Products VMware, illustra il funzionamento di VMware AppDefense:

Utilizzo e configurazione di Let’s Encrypt in ambiente Linux/Apache

Facebooktwittergoogle_plusredditlinkedin

In questo articolo abbiamo proposto l’utilizzo della Certification Authority Let’s Encrypt ed
una configurazione basata sull’implementazione del rilascio automatico di certificati per Internet Information Services.

Analogamente al Web server Microsoft possiamo utilizzare questa CA anche per ambienti Open, quindi Linux, OpenBsd, Nginx ed altri e quindi anche per il rilascio automatico di certificati nel Web server Apache

Nell’analisi della soluzione proposta è bene tenere in considerazione che l’estrema varietà di distribuzioni Linux, comporta anche differenze di implementazione della soluzione proposta, in questo caso i passi descritti sono riferiti ad una distribuzione Centos 6.9 e quindi applicabili all’ambiente RedHat, così come Oracle Linux Enterprise.

Il client ACME (Automated Certificate Management Environment), così come per l’ambiente Windows è disponibile anche in Linux un Client ed è scaricabile tramite Git

Per procedere alla sua installazione è necessario procedere come segue:

  • Installare HTTPD
  • Installare MOD_SSL
  • Installare i riferimenti al repository EPEL (Extra Packages for Enterprise Linux) da cui installeremo Git
  • replicare in locale il repository GIT per Let’s Encrypt in /usr/local

terminata la parte di semplice installazione è necessario procedere con i pochi passi necessari ad attivare e configurare il client in modo da permettere il primo rilascio ed il successivo rinnovo dei vari certificati.

È da tenere presente che:

As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in the DNS A and AAAA records, at its discretion. Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

Il DNS relativo all’ host/dominio per cui si richiede il certificato dovrà avere un record di tipo “A” e non sarà validato in caso di “CNAME”.

Al Punto 1 viene installato il Web Server Apache tramite il comando yum install HTTPD e verranno anche installate le eventuali dipendenze.

Mod_ssl previsto al punto2 è il modulo di gestione del protocollo SSL/TLS in Apache installabile con yum install mod_ssl

Punto 3, il repository EPEL contiene molte estensioni per i sistemi basati su sistemi Linux RedHat Centos e similari anche qui con il comando yum install epel-release otterremo la possibilità, sempre tramite yum di installare numerosi altri pacchetti in questo caso epel ci consente di installare GIT.

AL punto 4 Tramite il comando git clone https://github.com/letsencrypt/letsencrypt posizionandosi in /usr/local potremo replicare in locale la componente ACME con cui richiedere successivamente a Let’s Encrypt i certificati.

Figura 1 Replica da GIT di Let’s Encrypt

Configurazioni preliminari

Prima di procedere con la vera e propria richiesta alla CA dovremo però fare in modo che il WEB server risponda effettivamente anche per l’host per cui attiveremo HTTPS, questa impostazione, è all’interno del file di configurazione di Apache in httpd.conf, editandolo, dovremo definire un Virtual Host per il nostro sito attivo in http.

Figura 2 Impostazione VirtualHost Httpd

Richiesta del certificato HOST

Definita questa impostazione potremo procedere alla richiesta vera e propria del certificato utilizzando l’ambiente CertBot scaricato prima da GIT, posizionandoci quindi in /usr/local/letsencrypt dovremo eseguire il comando:

./letsencrypt-auto --apache -d linux1.robimassa.it

Dove specificheremo il tipo di Web Server utilizzato, ed l’FQDN dell’host che andremo a configurare

Per un elenco completo delle opzioni del client Let’s Encrypt potremo usare l’opzione –help

A questo punto verrà effettuata la richiesta verso la CA, sarà verificato se la configurazione DNS ed host sono corrette, ed in piena autonomia il client provvederà anche a modificare per noi la configurazione del file httpd.conf.

Durante la procedura di installazione sarà possibile scegliere se definire un redirect dalla porta 80 alla 443 o mantenere il precedente protocollo http ed insieme https.

Figura 3 Output comando di richiesta Certificato

Terminata la procedura di configurazione il file httpd.conf sarà modificato secondo le impostazioni volute

Figura 4 Modifica httpd.conf

La nuova impostazione di HTTPS con il certificato richiesto è definita in un file di configurazione che verrà incluso nella configurazione principale

Figura 5

Si noti che il certificato, la relativa chiave privata, la csr e più in generale tutto l’ambiente necessario alla gestione è creato all’interno di /etc/letsencrypt.

Rinnovo automatico del Certificato

Terminata la prima configurazione/richiesta il certificato rilasciato è valido per 3 mesi

Figura 6

il rinnovo può avvenire in modo automatico tramite un’attività impostata (anche quotidianamente) in cron, il comando da impostare è usr/local/letsencrypt-auto renew


ogni operazione che è compiuta dal client è “loggata” in /var/log/letsencrypt/letsencrypt.log

Conclusioni

Let’s Encrypt è una CA Free che può essere utilizzata liberamente da chiunque, il limite finora è nella possibilità di richiedere certificati di tipo Wildcard, ossia per un intero dominio ad esempio *. robimassa.it

Qualche mese fa è stato annunciato anche il rilascio per questo tipo di certificati a partire da gennaio 2018

Figura 7

Riferimenti:

https://letsencrypt.org/

https://certbot.eff.org/

Tecniche di attacco e difesa contro l’utilizzo di dispositivi USB

Facebooktwittergoogle_plusredditlinkedin

Nonostante l’utilizzo di porte USB per veicolare malware sia una tecnica di attacco non recente, sono ancora molti i casi in cui infrastrutture informatiche subiscono attacchi sfruttando le porte USB per inoculare malware nel sistema.

Sembra infatti che due dei dieci gruppi hacker più pericolosi specializzati in cyber spionaggio utilizzino anche chiavette USB infette per compromettere i sistemi. Mi riferisco ai seguenti gruppi:

  • SANDSORM (alias Quedagh, BE2 APT) un gruppo di hacker russi specializzato nel cyber spionaggio e sabotaggio che come tattiche e procedure (TTP) utilizza Watering holes, cd-rom e chiavette USB infette, vulnerabilità, zero- days, custom back door, worms e programmi per il furto di informazioni. Finora ha colpito governi, organizzazioni internazionali e il settore energetico in Europa e negli Stati Uniti ed è collegato agli attacchi ai media e alle infrastrutture energetiche in Ucraina.
  • HOUSEFLY (alias Equation) e anche questo gruppo americano utilizza come tattiche e procedure (TTP) Watering holes, cd-rom e chiavette USB infette, vulnerabilità, zero- days, custom back door, worms e programmi per il furto di informazioni. Finora ha colpito obiettivi d’interesse a livello nazionale.

Per dettagli sui vari gruppi hacker, origine, obbiettivi, tecniche e recenti attività si veda l’Internet Security Threat Report (ISTR) Volume 22 pubblicato ad aprile 2017 da Symantec.

Ovviamente gli attacchi condotti tramite device USB si basano sul fatto di riuscire ad inserire o a far inserire dagli utenti un device USB nel sistema, ma stando alla ricerca condotta della University of Illinois e dall’University of Michigan resa pubblica a maggio 2016 la 37th IEEE Security and Privacy Symposium risulta che il 48% delle persone che trova chiavette USB nei parcheggi prova ad inserirle nei propri computer e ad aprire il file contenuti . A riguardo si veda l’articolo Concerns about usb security are real: 48% of people do plug-in usb drives found in parking lots.

Inoltre come non dimenticare che il worm Stuxnet utilizzato nel 2010 per attaccare centrali nucleari è stato veicolato tramite chiavetta USB, per informazioni in merito si veda l’articolo The Real Story of Stuxnet pubblicato il 26 febbraio 2013 dall’ IEEE Spectrum.

Per la mia esperienza vi sono al momento quattro tipi di attacco basati sull’utilizzo dell’Universal Serial Bus (USB) come vettore di attacco.

Scenario 1: Malicious code

In questo scenario si sfrutta la chiavetta USB per diffondere malware che viene attivato quanto l’utente tenta di aprire o eseguire i file presenti sull’unità removibile, il malware può essere già presente sulla chiavetta o venire scaricato direttamente da Internet.

Per proteggersi da questo tipo di attacchi è possibile configurare l’antivirus per eseguire la scansione dei dispositivi removibili, disabilitare le funzionalità di Autoplay o disabilitare l’utilizzo di USB device. A riguardo si vedano:

Scenario 2: Attacchi tramite Social Engineering

In questo scenario si sfrutta una chiavetta USB per portare l’utente su un sito di phishing con l’intento di rubarle credenziali. In alternativa molto spesso vengono fornite con tecniche di Social Engineering all’utente delle chiavette ritenute “fidate” che contengo malware. A riguardo si veda ad esempio l’articolo SEToolkit – Hacking Windows Machines Using USB/CD Infectious Media Generator che spiega come utilizzare il progetto social-engineer-toolkit tramite la distribuzione Kali Linux per generare CD o chiavette USB malevole per sistemi Windows.

Anche in questo caso per proteggersi da questo tipo di attacchi è possibile configurare l’antivirus per eseguire la scansione dei dispositivi removibili, disabilitare le funzionalità di Autoplay o disabilitare l’utilizzo di USB device.

Scenario 3: HID (Human Interface Device) spoofing

Questo scenario prevede un attacco più sofisticato in cui un device USB è camuffato come una chiavetta USB, ma è in realtà una tastiera in grado di inviare la pressione di tasti per fornire all’attaccante un accesso remoto al computer della vittima.

Un’altra variante utilizzata per condurre questo tipo di attacchi quando si ha accesso fisico ad un computer attivo è quello di inserire una chiavetta USB che invia movimenti del mouse casuali (mouse jiggler) per impedire l’avvio dello screensaver e quindi il bocco della sessione. A titolo d’informazione i dispositivi come mouse jiggler possono anche venire utilizzati in indagini forensi per garantire la continuità dell’accesso a sistemi sotto indagine che poi vengono sequestrati mediante l’utilizzo di kit che consentono il trasporto dei sistemi garantendo la continuità dell’alimentazione elettrica (un esempio di tali kit è il HotPlug Field Kit Transport a live computer without shutting it down). Ovviamente le stesse tecniche utilizzate nelle indagini forensi potrebbero essere utilizzate per rubare computer o server.

Per proteggersi da questo tipo di attacchi e disabilitare l’utilizzo di USB device o controllare il tipo di device USB installabili a riguardo si veda:

In ambienti Linux, *BSD e OS X è stato sviluppato UsbKill un tool basato su script Python il cui scopo è realizzare un anti-forensic kill-switch che arresta il sistema nel caso rilevi una modifica sulle porte USB, per esempio un inserimento o una rimozione di un dispositivo. USBKill è disponibile nel seguente repository su GitHub https://github.com/hephaest0s/usbkill e può comunque essere utilizzato anche per proteggere sistemi dall’inserimento di dispositivi USB ignoti in particolare in sistemi non presidiati come, ad esempio, i server.

In ambiente Windows al seguente USB Shutdown : Yank USB Pendrive to Shutdown Windows è disponibile un tool simile che esegue lo shutdown   del sistema in caso vengano rilevati modifiche sulle porte USB, il tool è compilato a 32 bit ed è stato testato su Windows 7, 8, 8.1 e 10. Un altro interessante progetto open source in ambiente Windows il cui obbiettivo è bloccare rogue USB device è Beamgun che può bloccare attacchi basati sull’utilizzo di dispositivi USB che generano . Keystroke Injection (per esempio Rubber Duckies) o dispositivi USB con interfaccia ethernet che forniscono accessi remoti, eseguono attacchi di tipo man-in-the-middle e monitoraggio del sistema (per esempio LAN Turtle).

Per ulteriori informazioni su questo tipo di attacchi si vedano:

Scenario 4: Denial-of-service

Questo scenario prevede l’utilizzo di una chiavetta USB modificata per danneggiare computer della vittima tramite un sovraccarico elettrico sulla porta USB stessa, questo tipo di attacco nasce da un annuncio fatto da un ricercatore sulla sicurezza russo conosciuto come “Dark Purple” nel 2015 nel post USB killer (di cui è disponibile una traduzione in inglese al seguente USB Killer). Da allora l’hardware di tale device si è evoluto per essere sempre più letale ed oggi possibile acquistare device USB Killer V3.0 conformi al marchio CE dal sito https://usbkill.com con le seguenti caratteristiche:

  • Input voltage: 4.5 – 5.5 VDC
  • Output voltage: -215 VDC
  • Pulse Frequency: 8 – 12 times / second
  • Pulse current: ≥180A

Ovviamente non possono esserci protezioni software per tipo di attacco, la protezione migliore è valutare se il vendor hardware ha previsto a livello hardware una protezione da sovraccarichi elettrici sulle porte USB del proprio dispositivo (computer, laptop, smartphone, etc..). Sempre sul sito https://usbkill.com oltre all’USB Killer è anche possibile acquistare un Testing Shield che utilizzato in combinazione con l’USB Killer permette di testare se esiste o meno una protezione da sovraccarichi elettrici sulle porte USB.

In base a quanto affermato sul sito https://usbkill.com il 95% dei device hardware testati risulta vulnerabile ad attacchi di tipo USB power surge, mentre Apple sembra essere l’unica vendor che sta lavorando sulla protezione degli attacchi di tipo USB power surge (si veda USB Kill: Behind the scenes), ma sempre su https://usbkill.com è disponibile un USB Killer Adaptor Pack che permette di bypassare il chip di autenticazione su Phone 5, 6, 7 e 8 e il protocollo di autenticazione dell’USB-C.

Nel caso in cui sia possibile non utilizzare le porte USB è possibile bloccare l’inserimento di una UBS Killer impedendo l’uso della porta USB tramite dei USB Port Blocker removibili solo tramite un’apposita chiave (Lindy, Kensington e altri vendor distribuiscono questo tipo di protezione fisica), la disabilitazione da BIOS delle porte USB potrebbe anche rimuovere l’alimentazione alla porta, ma questo spetto va verificato perché dipende da come è stato implementato il BIOS. Ovviamente la miglior protezione sarebbe l’implementazione da parte dei vendor hardware di optoisolatori sulle porte USB.

Dispositivi hardware per la protezione delle porte USB

Gli attacchi su porte USB hanno spinto Robert Fisk a creare USG un hardware USB firewall portatile per porte USG che isola un device USB dal computer per impedire la compromissione di quest’ultimo. USG è disponibile nel seguente repository su GitHub https://github.com/robertfisk/USG e si basa sull’utilizzo di due microprocessori STM32F4 che comunicano con bus seriale ad alta velocità.

L’idea che sta alla base di USG è quella di supportare sull’interfaccia USB solo un numero limitato di comandi ritenuti sicuri per evitare dati malformati o non previsti che sono alla base degli USB Driver Exploits. Inoltre USG blocca gli attacchi basati su funzionalità nascoste supportando solo la connessione di un device e impedendo la modifica runtime della device class. Per quanto riguarda invece gli attacchi basati su comandi USB legittimi viene riportato che si sta ancora lavorando per sviluppare protezioni su questo fronte:

Type 3 Attacks: Evil Functionality in Plain Sight

Type 3 attacks also use completely legitimate USB commands, where the device you are using performs malicious actions. Defending against this type of attack requires rules specific to the attached device. For example, the mass storage class could encrypt blocks before they reach the USB device, rendering man-in-the-middle attempts futile. Or the human interface device (HID) class might block keystrokes arriving faster than a reasonable human typing speed. This firmware functionality is still under development.

Per maggiori dettagli si veda Technical Details for the Curious.

Per quanto riguarda la protezione da attacchi di tipo USB power surge tramite USB Killer viene riportato che l’USG non è stato progettato con questo scopo anche se la protezione potrebbe essere indiretta in quanto l’USG potrebbe bloccare buona parte della scarica elettrica danneggiandosi al posto del computer.

Q. Can the USG protect me from the USB Killer?

A. The USG was not designed to resist physical overvoltage attacks because they are obvious and easily contained. The information in your computer is more valuable than your computer itself, and the USG defends you against attacks that compromise your information.

But having said that, the USG will provide some protection. The voltage surge will pass through and damage two microprocessors and two ESD surge suppressors before it reaches your computer. The USG’s circuits will be destroyed, but the voltage surge will probably be reduced to a safe level at your computer’s port. If anyone does perform this test, you are welcome to tell me the result!

Al momento è disponibile per la vendita la versione 1.0 di USG che ha le seguenti caratteristiche:

The USG’s firmware supports the following devices, at USB 1 speeds (12Mbps):

  • Mass Storage – Flash drives and hard drives, 512byte sectors and 2TB max
  • Mice – 4 buttons with scroll wheel
  • Keyboards – 101 keys

Un altro dispositivo hardware per la protezione delle porte USB è USBCheckIn sviluppato da Federico Griscioli, Maurizio Pizzonia, Marco Sacchetti dell’Università degli Studi “Roma Tre” e reso pubblico alla 14th Annual Conference on Privacy, Security and Trust (PST) del 2016. USBCheckIn è al momento sviluppato come Preemptive research project. USBCheckIn blocca temporaneamente dispositivi non autorizzati e richiede un’interazione all’utente per inserire una sequenza di caratteri in modo che sono chi è a conoscenza di questa passphrase possa autorizzare l’utilizzo del dispositivo USB:

Essentially, USBCheckIn temporarily blocks the traffic coming from the device and at the same time asks the user to physically interact with it. For example, for a keyboard, it shows on its internal display a random sequence of characters that the user has to type with the keyboard. After the user has entered the correct sequence, USBCheckIn logically connects the USB device with the system, and the device can be used normally. If the user enters the wrong sequence, the device is not allowed to communicate with the host system.

If the device is malicious, the commands sent to the host will not pass the authorization process and will not reach the system, preventing any attack from being successful. To prevent brute force attacks, the user has a fixed number of attempts before the device is blocked. After that, he needs to press the button on USBCheckIn to try again the authorization process.

Per info su USBCheckIn si veda il sito http://www.dia.uniroma3.it/~pizzonia/usbcheckin.

Conclusioni

Sebbene le tecniche di attacco su USB siano note ormai da tempo sono comunque sfruttate e potenzialmente pericolose in particolare vengono sfruttare vulnerabilità zero-day o se è possibile per gli attaccanti accedere fisicamente ai computer, ovviamente la soluzione più semplice è quella di impedire fisicamente l’utilizzo delle porte USB se queste non sono necessarie. Se invece il sistema deve utilizzare dispositivi USB se possibile occorre fare in modo che utilizzi esclusivamente dispositivi USB ritenuti affidabili, quindi oltre a prevedere delle difese informatiche contro i rogue USB device è necessario anche evitare gli utenti debbano trovarsi ad utilizzarli e quindi lavorare in tal senso sulle procedure aziendali.

Purtroppo nei casi in cui può essere necessario utilizzare dispositivi USB potenzialmente non affidabili occorre pianificare procedure per il ripristino rapido di postazioni di lavoro nel caso vengano danneggiate o compromesse e confinare gli accessi all’infrastruttura di queste postazioni esposte agli attacchi veicolati tramite dispositivi USB in modo da non mettere a rischio l’intera infrastruttura.

Un caso pratico di questo di uno scenario in cui dispositivi USB potenzialmente pericolosi possano venire inseriti in computer connessi ad una rete dati è la gestione della Carta d’Identità Elettronica (CIE) che dovrà essere attivata in tutti i Comuni d’Italia entro il 2018 e che prevede nelle Modalità di acquisizione foto anche la possibilità da parte del cittadino di portare una fotografia su supporto digitale USB. Questa possibilità espone inevitabilmente i computer utilizzati per la gestione della CIE ad attacchi tramite rogue USB device o peggio ancora alle USB Killer mettendo a rischio, se non vengono prese le dovute contromisure, la rete dati degli uffici del Comune o il danneggiamento dei computer utilizzati per la gestione della CIE nel caso vengano inserite delle USB Killer. In scenari come questo sarebbe utile dotare i computer esposti ad attacchi tramite rogue USB device di device di protezione hardware delle porte USB come USG o USBCheckIn.