È possibile diventare root tramite un link simbolico rotto di proprietà di root e scrivibile globalmente?

Question

È possibile diventare root tramite un link simbolico rotto di proprietà di root e scrivibile globalmente?

#1 da (1 voti)
#2 da (1 voti)

5

Sto cercando una vulnerabilità su un server. Sto cercando nella directory /var e ottengo qualcosa di simile a questo:

drwxr-xr-x  3 root root 4.0K Aug 14 21:02 kerberos
drwxr-xr-x 12 root root 4.0K Nov 11 05:04 lib
drwxr-xr-x  2 root root 4.0K Jun 10  2014 local

lrwxrwxrwx  1 root root   11 Aug 14 21:00 lock -> ../run/lock     <-- CHECK THIS

drwxr-xr-x  3 root root 4.0K Aug 14 21:05 log
lrwxrwxrwx  1 root root   10 Aug 14 21:00 mail -> spool/mail
drwxr-xr-x  2 root root 4.0K Jun 10  2014 nis
drwxr-xr-x  2 root root 4.0K Jun 10  2014 opt
drwxr-xr-x  2 root root 4.0K Jun 10  2014 preserve
lrwxrwxrwx  1 root root    6 Aug 14 21:00 run -> ../run
drwxr-xr-x  4 root root 4.0K Aug 14 21:00 spool

Se guardo le autorizzazioni del lock "file", vedo che le autorizzazioni per gli altri sono rwx . Suppongo che sia quindi possibile per un altro utente che non è il proprietario (root in questo caso), leggere, eseguire e scrivere questo "file", quindi controllo che tipo di file lock è:

file lock
lock: broken symbolic link to '../run/lock'

stat lock

File: ‘lock’ -> ‘../run/lock’
  Size: 11          Blocks: 0          IO Block: 4096   symbolic link
Device: fb01h/64257d    Inode: 6424574     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-11-14 00:18:52.218518690 +0000
Modify: 2015-08-14 21:00:52.000000000 +0000
Change: 2015-11-11 04:56:35.543404826 +0000
 Birth: -

In base a queste informazioni, è possibile ottenere root, utilizzare questa autorizzazione per accedere ad altre informazioni o eseguire comandi?

Ad esempio, ho provato:

echo  "ls /etc" >> lock

Ma ottengo Permission denied .

Alcune domande:

La mia interpretazione delle autorizzazioni di blocco è corretta?
Posso fare qualcosa per ottenere un vantaggio con questo link simbolico rotto?
Che tipo di domande devono essere poste con questo link simbolico rotto?

linux symlink exploit privilege-escalation

posta Cristian Chaparro A. 14.11.2015 - 04:57

fonte

2 risposte

1

Le autorizzazioni per un collegamento simbolico sono per lo più prive di significato. Se non hai il permesso di lettura, non puoi vedere dove punta e se non hai i permessi di scrittura, non puoi retargetarlo, ma questo è tutto - e in realtà creare un link con permessi diversi da 0777 è abbastanza il trucco. Le autorizzazioni sulla destinazione del collegamento determinano cosa puoi fare con la destinazione: se dovessi sostituire la destinazione di un collegamento interrotto di proprietà della radice con un file che hai creato, l'obiettivo sarebbe di tua proprietà e agirebbe appropriatamente indipendentemente se l'hai effettuato direttamente o tramite il link.

risposta data 19.12.2015 - 08:09
fonte

Leggi altre domande sui tag linux symlink exploit privilege-escalation

Libri da studiare per GCIA (GIAC Certified Intrusion Analyst) [chiuso] Utilizzo dell'autenticazione AD in una webapp pubblicamente accessibile

score 1 · Accepted Answer

No, di solito non è possibile ottenere la root usando tali collegamenti.

Per rispondere alle tue domande più specifiche:

1. La mia interpretazione delle autorizzazioni di blocco è corretta?

Se questo "file" era un file reale e non un collegamento simbolico, la tua interpretazione sarebbe corretta, ma non lo è.

I permessi

link simbolici (aka symlinks) sono quasi sempre ignorati: i collegamenti simbolici ereditano le loro effettive autorizzazioni dal file a cui puntano, l'autorizzazione rwxrwxrwx mostrata può essere considerata semplicemente come riempimento. Questo è così vero che lo standard POSIX non definisce nemmeno quale autorizzazione deve mostrare il sistema operativo per link simbolico:

The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-2008 shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified.

Alcuni sistemi mostrano tutti i set di bit di autorizzazione ( rwxrwxrwx , come nel tuo caso), altri mostrano il permesso sul file collegato, se esiste, alcuni fanno cose più fantasiose (come un e em> operazione tra il collegamento e le autorizzazioni di destinazione ...).

Ho detto sopra che questi permessi quasi sono sempre ignorati, questo perché non è completamente vero in una manciata di sistemi operativi. Ad esempio, i sistemi Mac OS X si discostano dallo standard POSIX citato sopra e l'autorizzazione read controlla l'abilità di risoluzione del link, che ha un impatto molto limitato (buono o cattivo) in termini di sicurezza (fa semplicemente il sistema un po 'più difficile da mantenere).

Quindi, con tutto questo in mente, qual è il tuo attuale permesso con questo link interrotto? È lo stesso del target se esiste . Tuttavia, poiché il target non esiste, non puoi fare nessuna operazione con il link, anche se avresti abbastanza parametri (è per questo che è rotto: semplicemente non funziona).

2. Posso fare qualcosa per ottenere un vantaggio con questo link simbolico rotto?

I collegamenti interrotti da soli non sono anormali e non presentano alcuna debolezza di sicurezza. Troverai spesso collegamenti interrotti in ambienti utilizzando chroot o condivisione di rete, in cui i collegamenti simbolici risolveranno con successo solo uno che usi la radice corretta o che abbia montato la giusta condivisione di rete.

3. Che tipo di domanda deve essere posta con questo link simbolico rotto?

Hai un link il cui percorso è /var/lock che punta alla directory non esistente /run/lock . È sufficiente che tu sia in grado di manomettere solo uno di questi due percorsi per acquisire il percorso di /var/lock .

Hai i permessi di scrittura sulla directory principale del target o su una directory che lo compone? Se sì, sarai in grado di creare e acquisire la directory mancante. In caso contrario, non sarà possibile manomettere in alcun modo la directory di destinazione mancante: rimarrà mancante.

Hai i permessi di scrittura sulla directory padre del link o su una directory che lo compone? È sì, sarai in grado di sostituire il link con un altro, puntando alla directory che possiedi (puntando a /home/myuser/fakelock per esempio), controllando così tutti i blocchi che un'applicazione proverebbe a inserire nel percorso var/lock .

Se hai i permessi di scrittura su nessuna di queste directory, allora sei matto e devi solo continuare la tua indagine: non c'è niente da sfruttare qui.