Ho una funzione che accetta un nome di percorso e sostituisce ogni occorrenza di '% u' con una determinata stringa. Per il mio scenario questa data String è l'accesso che un utente / utente malintenzionato inserisce tramite ssh durante l'autenticazione. Il nome del percorso (compreso '% u') è fisso e non può essere modificato dall'utente / utente malintenzionato.
Diciamo che il percorso fisso è:
/usr/local/etc/ssh/keystore/%u/authorized_keys
Se l'utente / utente malintenzionato, ad es. sta ora emettendo il seguente comando:
ssh [email protected]
Il percorso sarà esteso a:
/usr/local/etc/ssh/keystore/root/authorized_keys
Se la root utente è ora autorizzata (sarà determinata dall'appartenenza al gruppo ldap) e ha un certificato x509 valido, la chiave pubblica del certificato x509 verrà scritta nel file authorized_keys esaminato. Se l'utente non è autorizzato, il file authorized_keys verrà troncato.
Un utente malintenzionato ora è in grado di troncare ogni file authorized_keys esistente sul filesystem a causa del fatto che non viene eseguita alcuna convalida dell'input per il dato accesso utente.
Considera la seguente connessione ssh:
ssh ../keystore/[email protected]
Il percorso sarà esteso a:
/usr/local/etc/ssh/keystore/../keystore/foo/authorized_keys
Con una probabilità piuttosto alta l'utente '../keystore/foo' non è autorizzato ad accedere al sistema che conduce al troncamento del file authorized_keys di un utente possibilmente legale 'foo'.
Anche se durante il prossimo collegamento di foo il suo file authorized_keys viene aggiornato di nuovo, voglio liberarmi di questo vettore di attacco.
Mi sono venute in mente due possibili soluzioni:
1. Convalida il login utente con un'espressione regolare (approccio whitelist)
es. usa il NAME_REGEX predefinito:
^ [a-z] [- a-z0-9] * \ $
Ancora se il sistema non usa la funzionalità NAME_REGEX gli utenti verrebbero chiusi da ssh
2. Controlla se il percorso espanso contiene '..' e fallisce se è così (approccio blacklist)
Ciò non chiuderebbe gli utenti, ma non sono ancora sicuro se questo è sufficiente o se esistono altri pattern che potrebbero portare allo stesso comportamento di cui sopra