Questo diagramma è molto accurato per XP e precedenti. Il motivo per cui è così complicato sono i diversi livelli di astrazione coinvolti.
Ci sono due modi primari (come in, "più utilizzati") di accedere a Windows - come utente di workstation standalone e come membro di un dominio. In entrambi i casi, su XP tali credenziali passano attraverso il client LSA e il suo server.
Nel back-end, quindi, LSA deve determinare "chi chiedere" per determinare se le credenziali sono effettivamente valide. È qui che entra in gioco il blocco "negoziato", che farà una delle due cose:
- Se il sistema è configurato come workstation, utilizzare lo schema NTLM come configurato nella casella e parlare con il database SAM.
- Se il sistema è configurato come parte di un dominio, parla al server per vedere cosa supporta e dargli ciò di cui ha bisogno.
In sostanza, questo processo non è tanto diverso dal negoziare quale tipo di hashing usare per dire un metodo di autenticazione HTTP: il server dice quello che vuole (PLAIN, DIGEST, MD5) e inviamo la password secondo necessità.
C'è un'allusione ad altri tipi di credenziali che si adattano qui sotto forma di "msgina.dll". Questo è il componente responsabile della conversazione con l'utente dopo Ctrl + Alt + Canc e può essere sostituito per fornire una nuova interfaccia utente come l'impronta digitale e l'accesso con smart card. In ognuno di questi casi, LSA deve comunque parlare con il database di back-end (ovunque sia) per ottenere un token di autenticazione di qualche forma.
È anche possibile aggiungere protocolli di autenticazione aggiuntivi a LSA tramite provider LSA. Questo è il corrispondente componente "parla al database di autenticazione per determinare se questo è un utente valido" e puoi leggere su questi componenti qui e istruzioni su come scrivere uno qui .
Ora, una volta completato questo processo, l'utente riceve un token di autenticazione chiamato token di accesso . UAC a parte, presentando questo token è come i processi indicano al sistema che sono già autorizzati ad agire per conto dell'utente.
Questo è ciò che sta succedendo e in che modo LSA e i vari componenti combaciano.
Ora, seconda parte della mia risposta. LSA mirato alla fiamma per due motivi:
- È estensibile. È possibile registrare nuovi protocolli di autenticazione, nuovi GINA / Credential Provider (rispettivamente XP / Vista +).
- Funziona all'avvio del sistema, con
NT AUTHORITY\SYSTEM privilegi.
Questo lo rende un posto meraviglioso da cui lanciare il tuo malware e rimanere persistente nel sistema. Vedi questa analisi
Come puoi immaginare, ci sono controlli e contrappesi che impediscono a qualsiasi vecchio programma di installarsi lì e persino di essere eseguiti lì, per mezzo di Authenticode . Tuttavia, Flame ha utilizzato un certificato rubato per aggirare questo, che è dove le cose si sono fatte interessanti Le informazioni, in particolare il nome comune, contenute nel certificato di autenticità vengono visualizzate come parte della finestra di dialogo di avviso di autenticazione. Quindi, in questo caso, il malware sembrerebbe essere stato creato da "Microsoft Corporation". Una volta che fanno clic su OK ed eseguono Flame con privilegi elevati, allora ha tutto l'accesso che vuole. Può quindi registrarsi come fornitore LSA e verrà eseguito automaticamente ogni volta che si avvia il sistema.
