Come prevenire l'hack sethc.exe?

Esiste un exploit che consente agli utenti di reimpostare la password dell'amministratore su Windows. Viene eseguito avviando da un disco di ripristino, avviando il prompt dei comandi e sostituendo C: \ Windows \ System32 \ sethc.exe con C: \ Windows \ System32 \ cmd.exe.

Quando si preme la combinazione di tasti permanenti nella schermata di accesso, gli utenti ottengono l'accesso a un prompt dei comandi con privilegi di amministratore.

Questo è un enorme buco di sicurezza, rende il sistema operativo vulnerabile a chiunque abbia anche la minima conoscenza dell'IT. Ti fa quasi venire voglia di passare a Mac o Linux. Come può essere prevenuto?

Al fine di impedire a un utente malintenzionato di avviarsi da un disco di riparazione e utilizzarlo per ottenere l'accesso al sistema, è necessario eseguire alcuni passaggi. In ordine di importanza:

• Utilizzare le impostazioni BIOS / UEFI per impedire l'avvio da supporti rimovibili o richiedere una password per l'avvio da supporti esterni. La procedura per questo varia da scheda madre a scheda madre.
• Rinchiudi la tua torre. Di solito c'è un modo per ripristinare le impostazioni BIOS / UEFI (comprese le password) se un utente malintenzionato ottiene l'accesso fisico alla scheda madre, quindi ti consigliamo di impedirlo. Quanto lontano vai dipende da fattori come l'importanza dei dati che stai proteggendo, quanto sono dedicati i tuoi aggressori, il tipo di sicurezza fisica che porta alla tua workstation (es. È in un ufficio a cui solo i collaboratori possono accedere o è in una zona isolata aperta al pubblico) e per quanto tempo un tipico aggressore dovrà infrangere la tua sicurezza fisica senza essere visto.
• Usa una sorta di crittografia del disco come BitLocker o TrueCrypt. Sebbene ciò non impedirà a un utente malintenzionato dedicato di riformattare il sistema se è in grado di ottenere l'accesso fisico e reimpostare la password del BIOS, impedirà a quasi tutti di ottenere l'accesso al sistema (supponendo che protegga bene le chiavi e che l'attaccante non ha accesso a qualsiasi backdoor).

Il problema qui è l'accesso fisico alla macchina. Disabilita la possibilità di avviare da CD / USB e bloccare il BIOS con una password. Tuttavia, ciò non impedirà a qualcuno con abbastanza tempo da solo con la macchina di penetrare con numerosi metodi diversi.

SETHC.exe può anche essere sostituito con una copia di explorer.exe (o di qualsiasi altro .exe) che fornisce anche l'accesso completo a livello di sistema dalla schermata di accesso. Non per ripetere gli altri, ma se stai parlando della sicurezza del server, penso che una certa quantità di sicurezza fisica sia già in atto. Quanto dipende dal rischio accettabile indicato dalla tua organizzazione.

Sto pubblicando questo forse per seguire una strada diversa. Se si teme che la comunità di utenti dell'organizzazione possa o lo farà sulle workstation di Windows 7 (come descritto nella domanda), l'unico modo per aggirare questi tipi di attacchi è "spostare" il calcolo nel centro dati. Ciò può essere realizzato con qualsiasi numero di tecnologie. Sceglierò i prodotti Citrix per una breve panoramica del processo, anche se molti altri fornitori offrono offerte simili. Utilizzando XenApp, XenDesktop, Machine Creation Services o Provisioning Services è possibile "spostare" la workstation nel datacenter. A questo punto (purché il tuo datacenter sia sicuro) hai la sicurezza fisica sulla workstation. È possibile utilizzare thin client o workstation completamente capaci per accedere al desktop ospitato dal datacenter. In uno di questi scenari avresti bisogno di un hypervisor come cavallo di battaglia. L'idea è che lo stato di sicurezza della macchina fisica su cui si trova l'utente sia a rischio minimo, indipendentemente dal fatto che sia compromesso o meno. Fondamentalmente, le workstation fisiche hanno accesso solo a un numero molto limitato di risorse (AD, DHCP, DNS, ecc.). Con questo scenario, tutti i dati e tutti gli accessi sono concessi solo alle risorse virtuali nel controller di dominio e anche se la workstation o il thin client sono compromessi, non è possibile ottenere alcun guadagno da tale endpoint. Questo tipo di installazione è più adatto alle grandi aziende o agli ambienti ad alta sicurezza. Ho pensato di buttarlo fuori come una possibile risposta. L'idea è che lo stato di sicurezza della macchina fisica su cui si trova l'utente sia a rischio minimo, indipendentemente dal fatto che sia compromesso o meno. Fondamentalmente, le workstation fisiche hanno accesso solo a un numero molto limitato di risorse (AD, DHCP, DNS, ecc.). Con questo scenario, tutti i dati e tutti gli accessi sono concessi solo alle risorse virtuali nel controller di dominio e anche se la workstation o il thin client sono compromessi, non è possibile ottenere alcun guadagno da tale endpoint. Questo tipo di installazione è più adatto alle grandi aziende o agli ambienti ad alta sicurezza. Ho pensato di buttarlo fuori come una possibile risposta. L'idea è che lo stato di sicurezza della macchina fisica su cui si trova l'utente sia a rischio minimo, indipendentemente dal fatto che sia compromesso o meno. Fondamentalmente, le workstation fisiche hanno accesso solo a un numero molto limitato di risorse (AD, DHCP, DNS, ecc.). Con questo scenario, tutti i dati e tutti gli accessi sono concessi solo alle risorse virtuali nel controller di dominio e anche se la workstation o il thin client sono compromessi, non è possibile ottenere alcun guadagno da tale endpoint. Questo tipo di installazione è più adatto alle grandi aziende o agli ambienti ad alta sicurezza. Ho pensato di buttarlo fuori come una possibile risposta. e anche se la workstation o il thin client sono compromessi, non è possibile ottenere alcun guadagno da tale endpoint. Questo tipo di installazione è più adatto alle grandi aziende o agli ambienti ad alta sicurezza. Ho pensato di buttarlo fuori come una possibile risposta. e anche se la workstation o il thin client sono compromessi, non è possibile ottenere alcun guadagno da tale endpoint. Questo tipo di installazione è più adatto alle grandi aziende o agli ambienti ad alta sicurezza. Ho pensato di buttarlo fuori come una possibile risposta.

Disattiva semplicemente il prompt dei tasti permanenti quando si preme shift 5 volte. Quindi, quando CMD viene rinominato in SETHC, non verrà visualizzato. Risolto.

Win7:

1. Start> digita "cambia il funzionamento della tastiera"
2. Fai clic sulla prima opzione
3. Fai clic su imposta chiavi adesive
4. Deseleziona attiva i tasti adesivi quando si preme il tasto 5 volte.

Non hai davvero bisogno di avere un disco o un'immagine di Windows su una USB per far funzionare l'exploit. Sto cercando di dire che disabilitare il PC dall'avvio da un'unità diversa da quella del sistema interno non impedisce l'esecuzione dell'exploit. Questa soluzione alternativa viene eseguita reimpostando il computer all'avvio e utilizzando una riparazione all'avvio per ottenere l'accesso al file system per rinominare CMD in SETHC. Certo, è difficile sull'unità disco, ma se stai entrando nella macchina di qualcun altro, non ti interessa davvero.