Ho trovato questo post che descrive un problema nell’autenticazione a dominio di Windows. È utile leggere non solo il post, che tutto sommato dice relativamente poco, ma anche i commenti, che aiutano a chiarire molto. Anche quest’altro post aiuta a capire il problema, e se serve anche queste slide. La cosa interessante è che si parla anche di un attacco di pass-the-ticket per Kerberos. Purtroppo non ho trovato dettagli al riguardo (se qualcuno ne ha, mi interessano). Da notare che ancora una volta Vista mantiene i problemi dei sistemi precedenti; il fatto di scrivere meglio il codice non aiuta se il problema è nella funzionalità o nella compatibilità all’indietro. Ne vorrei approfittare per fare qualche ragionamento sul meccanismo dell'”agente” che conserva delle credenziali per l’utente e le utilizza per le autenticazioni successive, alla base di molti strumenti (es. di Single Sign On) e a prescindere da Windows.
Il concetto dell’agente è in qualche modo parte di qualsiasi meccanismo che permetta di autenticarsi una volta e poi accedere ad altri servizi (o più volte allo stesso) senza che venga richiesta all’utente una nuova autenticazione. La cosa si può presentare in diversi modi. Un sistema è memorizzare direttamente le credenziali, temporaneamente o permanentemente. Il “remember this password” di qualche browser rientra in questa logica, e ne è l’implementazione peggiore. Altre volte vengono memorizzati dei dati utilizzati temporaneamente per un certo tempo, come i cookie utilizzati come autenticazione. Non è un concetto nuovo: il Ticket Granting Ticket di Kerberos rientra nella categoria. In altri casi il concetto di agente è più esplicito, come quello di ssh (che memorizza direttamente la chiave privata, non un’informazione derivata). La prima conseguenza ovvia è che chi è amministratore sul sistema su cui è in esecuzione l’agente è in grado di accedere alle credenziali memorizzate. Se l’informazione memorizzata sono le credenziali dell’utente, queste sono compromesse. Se l’informazione memorizzata è un dato derivato, la compromissione sarà limitata a quanto è accessibile con quell’informazione (come servizi e come tempo). Quanto poi sia limitato dipende dal caso specifico.Compromettere l’ssh agent ha un effetto più “generale” che compromettere le credenziali di autenticazione (es. coockie) utilizzate per un solo servizio e una sola sessione, proprio perché conserva la chiave privata. Per l’attaccante, è generalmente più semplice accedere alle informazioni memorizzate in un file su disco che a quelle memorizzate temporaneamente nella memoria di un agente, ma memorizzarle nell’agente è comunque un palliativo che offre poche protezioni in più. Del resto, se l’attaccante ha privilegi di amministratore e controlla il sistema da cui opera l’utente di cui vuole ottenere le credenziali, i sistemi per ottenerle non gli mancano. Tuttavia, c’è un punto che è necessario evidenziare: le credenziali dovrebbero essere memorizzate solo sui sistemi dai quali l’utente si deve autenticare, non su quelli ai quali si autentica. Ad esempio, se io amministro dei sistemi dalla mia postazione mediante ssh/scp e compagnia, l’agente avrà bisogno di essere attivo solo sulla mia macchina: nel momento in cui io accedo ad un altro sistema non ho necessità, in generale, di portarci le mie credenziali di amministratore e di esporle; quindi, non ci dovrebbe essere nessun automatismo che propaga automaticamente le mie credenziali di amministratore (o di utente, anche se il caso dell’amministratore è più critico) sulle macchine alle quali accedo. Vale la pena di sottolineare che nè ssh nè Kerberos richiedono che la macchina sulla quale mi autentico abbia delle informazioni critiche sulle mie credenziali per effettuare l’autenticazione: ssh usa un meccanismo a chiave pubblica (quindi io ho la chiave privata, e la macchina alla quale accedo ha solo quella pubblica) e Kerberos usa i ticket. Cosa succede però se io dalla macchina che sto amministrando ho bisogno di accedere a delle risorse? Ecco, a questo punto mi servono delle credenziali. La cosa interessante però è che in moltissimi casi non servono assolutamente le credenziali di amministratore. Ad esempio, se devo installare degli aggiornamenti, la risorsa in rete dalla quale li prendo può essere pubblica o comunque accessibile con un utente non amministratore, seppure magari dedicato. Fin qui, tutto fattibile con gli strumenti esistenti. Potrei al limite propagare automaticamente solo queste credenziali non privilegiate quando mi connetto ad una macchina. Tuttavia, ci possono essere delle attività (non frequenti) per le quali io mi posso dover presentare a risorse o servizi esterni come amministratore della macchina, o comunque devo utilizzare delle credenziali privilegiate la cui compromissione causerebbe danni considerevoli. In questi casi la soluzione corretta non sarebbe certo quella di esporre le credenziali su un sistema del quale non si può garantire la sicurezza. Una soluzione corretta (ce ne possono essere altre) sarebbe ad esempio mediare le richieste attraverso il sistema dal quale l’amministratore opera direttamente (il suo PC), cosa che darebbe anche la possibilità di autorizzare singolarmente le attività. Questo concetto (un “proxy” che riceve una richiesta e la prosegue aggiungendo le proprie credenziali) non è certo un concetto nuovo, ma se il protocollo e il servizio non lo prevedono c’è poco che il sistemista ci possa fare. Anche la logica dei ticket di Kerberos offre delle protezioni, ad esempio i “proxyabletickets”; cito dall’RFC 4120: “At times it may be necessary for a principal to allow a service to perform an operation on its behalf. The service must be able to take on the identity of the client, but only for a particular purpose. A principal can allow a service to do this by granting it a proxy.”
