In merito all’exploit del path hijacking, mi è sorto un dubbio relativamente ad un suo effettivo impiego. L’obiettivo del path hijacking è quello di prendere il controllo della shell della vittima, ma per eseguire l’intyera procedura(scrivere un programma malevolo che sostituisce l’originale, modifcare il path etc) sulla shell della vittima è gia implicito il fatto che debba gia avere il controllo di essa. Mi stavo quindi chiedendo operativamente in quale contesto viene usato.
1 Like
Ciao, la tua è una osservazione importante da approfondire! Cerchiamo quindi di capirci qualcosa.
La tecnica di PATH Hjacking è una tecnica di LPE, ovvero di Local Privilege Escalation. La parola “local” significa che un attaccante per poter sfruttare la tecnica DEVE aver ottenuto in qualche modo accesso alla macchina. La tecnica è pericolosa nel momento in cui può essere sfruttata contro un programma privilegiato. In questi casi l’attaccante potrebbe passare da account normal (diciamo www-data), ad account amministrativo (diciamo root).
Quindi, il vero vantaggio di un PATH hijacking non è ottenere una shell nel server remoto, ma bensì quello di passare da una shell ordinaria (che può scrivere nuovi programmi, modificare il proprio PATH, etc), ad una amministrativa.
In un classico attacco quello che succede è: un attaccante trova un modo per ottenere un primo accesso al sistema. Questo è anche detto Foodhold. Per fare questo le applicazioni web sono ottime, in quanto espongono una ricca superficie di attacco. Ma una volta dentro un attaccante ha bisogno di essere amministratore, e quindi comincia a ricercare vettori di attacco di tipo LPE, come ad esempio un Path hijacking. Una volta diventato amministratore poi un attaccante può installare meccanismi di persistenza profondi.
Riassumendo, uno schema è:
- Foothold → LPE → Persistence
L’insieme delle operazioni effettuate da un attore malevolo per attaccare un sistema è anche nota come “cyber kill-chain”.
Da un punto di vista difensivo questo significa che possiamo (e dobbiamo) implementare una “defense in depth”, ovvero una difesa a vari livelli, sia per evitare foothold, e sia per evitare LPE. Una volta diventato amministratore diventa molto più difficile proteggersi, in quanto l’attaccante può sfruttare i suoi privilegi per modificare il funzionamento del sistema, rendendo molto più difficile il monitraggio etc.
Ok chiarissimo, in sostanza ho misinterpretato il path hijacking come una tecnica per reverse shell, quando in realtà è una tecnica per aumentare i propri privilegi. La mia confusione derivava anche dal fatto che eseguendo il file malevolo non mi apriva alcuna shell root ma semplicemente mi riportava alla shell dell’user. Forse è necessario che il file malevolo eseguibile sia settato SUID(mi riferisco nello specifico al comando cat). Dopo provo a ripetere la procedura. Grazie
Si esatto, per avere “impatto” è necessario che il programma esegui con i privilegi da root. Quindi o tramite SUID o tramite SUDO. Se poi è possibile fare hijacking del programma che esegue da root, allora siamo in grado di introdurre codice da root e quindi abbiamo una escalation effettiva. Se però facciamo la stessa tecnica ma su un binario che non gira da root, allora non abbiamo impatto.
E questa è anche la ragione per cui configurare SUID o SUDO è pericoloso se fatto male.
1 Like