Vulnerabilità simbolica dei link, PATH e escalation dei privilegi

Question

Vulnerabilità simbolica dei link, PATH e escalation dei privilegi

#1 da (3 voti)

3

Sono un po 'inesperto per questo ...

Sto utilizzando questo VM link per esercitarti e c'è un passaggio che non capisco . Qui: link

After calling strings on the binary, I can see one path that is not correctly limited to a static path - mail. A rather crude way of finding the vulnerability, but effective.

Quindi fondamentalmente per ottenere la shell di David Gmmmour ho bisogno di creare un link simbolico a / bin / sh in / tmp / mail e modificare la variabile PATH. Ma non capisco perché ciò sia fatto, né come funzioni. Qualcuno può spiegarmi?

So che la variabile PATH è dove sono gli eseguibili, un po 'come in Windows, quindi quando scrivo, ad esempio, "cat" o qualche altro comando nel prompt dei comandi funziona e non devo scrivere il intero percorso per il gatto (almeno questo è quello che credo che faccia).

E perché il collegamento simbolico è stato salvato in / tmp / mail? E perché viene usato un collegamento simbolico?

symlink vulnerability privilege-escalation

posta Mark Read 02.02.2016 - 18:13

fonte

1 risposta

Leggi altre domande sui tag symlink vulnerability privilege-escalation

Impedire la manipolazione del database delle password Dove salvare il file Keepass? [chiuso]

score 3 · Accepted Answer

L'autore dell'attacco sta tentando di ottenere una shell in esecuzione come DavidGilmour utente. Sulla base delle loro esplorazioni, la decisione è di provare a sfruttare una vulnerabilità nel binario shineon perché quel binario è setuid a DavidGilmour :

$ ls -lah /usr/local/bin/shineon
-rwsr-s---  1 DavidGilmour  RichardWright   7.3K Oct 25 07:58 /usr/local/bin/shineon

Notare s nelle autorizzazioni. Ciò indica che quando viene eseguito shineon , verrà eseguito come DavidGilmour . Ma come shineon è un programma con funzionalità limitate, non ha un comando start shell . Invece, l'utente malintenzionato esamina la funzionalità fornita dalla shell:

1. Calendar
2. Who
3. Check Internet
4. Check Mail
5. Exit

e poi guarda le stringhe all'interno del binario. Le stringhe rilevanti sono:

/usr/bin/cal
/usr/bin/who
/sbin/ping -c 3 www.google.com
mail

L'utente malintenzionato indovina che quelle sono le stringhe di comando utilizzate per eseguire la funzionalità dell'applicazione: Calendar corrisponde a /usr/bin/cal , ecc ... L'utente malintenzionato nota che mail non ha un percorso completo. Ciò significa che lo script eseguirà il primo comando mail che trova in PATH . Quindi l'attaccante crea un comando chiamato mail in qualche directory casuale. Hanno scelto /tmp , ma quella scelta non è importante. Il comando è un collegamento simbolico a /bin/sh . Un collegamento simbolico crea un alias tra due file. In questo caso, quando il sistema operativo esegue /tmp/mail , eseguirà effettivamente /bin/sh . Potrebbero aver copiato anche /bin/sh in /tmp/mail , ma perché preoccuparsi. La copia richiede tempo e utilizza lo spazio su disco. Il collegamento simbolico è altrettanto efficace e più veloce.

Il passaggio finale è impostare la variabile di ambiente PATH per iniziare con /tmp in modo che quando il sistema operativo va a eseguire il comando mail , troverà /tmp/mail . E, visto che questo è solo un link simbolico a /bin/sh , eseguirà /bin/sh come DavidGilmour (ricorda che il programma è setuid in modo che venga sempre eseguito come DavidGilmour ).

Obiettivo raggiunto!