Commenti a "Come proteggere PowerShell con una password"

[Zigul]

Come proteggere PowerShell con una password



La presenza di una richiesta di password è indice di protezione e di accesso controllato; perché allora non impostarne una anche per la shell, che è uno degli strumenti più cruciali per la sicurezza del nostro PC? L’ideale è che si tratti di una password diversa da quella dell’utente, in modo che se l’account viene compromesso, non è comunque automatico poter accedere anche alla shell con la medesima password. [continua..]

Inserite di seguito i vostri commenti.

[CUB3]

È per caso questo il metodo per bypassare la protezione?

Invocare Powershell con l’opzione -Noprofile

Bellissimo articolo anche questo, ricco di spunti interessanti che vanno al di là della protezione stessa; bravo!

Se posso permettermi un suggerimento, dato che utilizzi termini tecnici che l’utente medio potrebbe non conoscere (tipo LOFL [forse è LOTL?], reverse shell, …) se non vuoi spiegarli per non andare fuori dal tema centrale e rendere l’articolo troppo prolisso, potresti mettere un link per approfondire, magari a Wikipedia o qualche altra fonte che tu sai essere affidabile. Come dice sempre crazy.cat, bisogna avere come target la “casalinga di Voghera”!

[edit]
Mi è venuta in mente la variabile di ambiente $PROFILE; immagino che anche cambiando il percorso di default del file di profilo tramite registro, con questa variabile si possa risalire facilmente alla nuova posizione, sbaglio?

[crazy.cat]

Bellissimo articolo anche questo, ricco di spunti interessanti che vanno al di là della protezione stessa; bravo!

Confermo i complimenti anche io, zigul mi sta facendo scoprire cose nuove e interessanti a ogni articolo.

Come dice sempre crazy.cat, bisogna avere come target la “casalinga di Voghera”!

Il mio target dovrebbe ormai essere far capire le cose al nostro supporto di primo livello romeno, ma questa è una missione impossibile.
La casalinga di voghera ha ormai imparato come si usa un computer.

[CUB3]

Il mio target dovrebbe ormai essere far capire le cose al nostro supporto di primo livello romeno

Hai abbassato di molto l’asticella!

[Zigul]

Grazie a entrambi per i feedback; ho aggiunto i link per rendere l'articolo un po' più "casalinga-friendly".

@CUB3
La tua soluzione è corretta, si tratta essenzialmente di aggirare l'utilizzo del profilo di PowerShell, escludendolo con quell'opzione (lanciando il comando da CMD o da link) o agendo sul file che contiene lo script. Segnalo che c'è anche un "bypass" più immediato, che può essere attuato direttamente dopo che PowerShell ci ha colto di sorpresa aprendo la finestra di Show-Command.

[CUB3]

Non ho modo di provarlo ma se mi dici così, immagino…

… che si possa forzare la chiusura della finestra appara?
In questo caso non si potrebbe mettere un controllo che, se lo script fallisce, Powershell si chiude?

[Zigul]

Il semplice escamotage sta nel come chiudere quella finestra senza perdere anche l'uso della shell, considerando che cliccare su "Cancel" o "Ok", premere "ALT+F4" o "Esc", usare la "x" in alto a destra, comportano la chiusura della shell. Non trattandosi di provocare un errore, try/catch o trap non credo siano utilizzabili (ma andrebbe usata una restrizione più "invasiva").

[Zigul]

Mi è venuta in mente la variabile di ambiente $PROFILE; immagino che anche cambiando il percorso di default del file di profilo tramite registro, con questa variabile si possa risalire facilmente alla nuova posizione, sbaglio?

La variabile $PROFILE mi pare sia consultabile solo da "dentro" PowerShell, quindi a quel punto significa che è stata già aggirata la richiesta di password e dunque non è più tanto rilevante sapere dov'è annidato il file del profilo. Se invece si va a curiosare nel registro, l'utente corrente potrebbe "dirottare" il percorso della cartella del file del profilo, impostandolo altrove, rendendo così inutilizzato quello che contiene lo script della password.

Per cercare di dare un parziale "lieto fine" difensivo all'impostazione della password: volendo ostacolare il "bypass" consentito dall'invocazione di "PowerShell -NoProfile" da CMD, si può eliminare il percorso di PowerShell da PATH nelle variabili di sistema. Così facendo PowerShell potrà essere lanciato nei modi consueti, ma non da CMD, che quindi non potrà essere usato per aggirare la richiesta di password (ma rimane purtroppo valido il "bypass" tramite link, inserendo il percorso corretto e il suddetto parametro).

[CUB3]

Il semplice escamotage sta nel come chiudere quella finestra senza perdere anche l'uso della shell

Ctrl+c

La variabile $PROFILE mi pare sia consultabile solo da "dentro" PowerShell,

Ah, OK! Credevo fosse una variabile di sistema.

[Zigul]

Il semplice escamotage sta nel come chiudere quella finestra senza perdere anche l'uso della shell

Ctrl+c

Esatto; quando ho parlato di "restrizione più invasiva" (per evitare questo "bypass") alludevo infatti a disabilitare la combinazione Ctrl+C all'interno di Powershell, aggiungendo un'apposita riga all'inizio del file del profilo:

Codice: Seleziona tutto

[console]::TreatControlCAsInput = $true

La sola aggiunta di questa riga, tuttavia, rendeva possibile chiudere la finestra di Show-Command nei modi che prima erano disabilitati (come cliccare su Cancel). Dopo qualche prova, mi sono ora accorto che aggiungendo semplicemente "exit" alla fine dello script, questo problema viene risolto (ho modificato lo script nell'articolo di conseguenza).

[CUB3]

Codice: Seleziona tutto

[console]::TreatControlCAsInput = $true

La sola aggiunta di questa riga, tuttavia, rendeva possibile chiudere la finestra di Show-Command nei modi che prima erano disabilitati (come cliccare su Cancel). Dopo qualche prova, mi sono ora accorto che aggiungendo semplicemente "exit" alla fine dello script, questo problema viene risolto (ho modificato lo script nell'articolo di conseguenza).

Ottimo lavoro!