In informatica, si intende con privilege escalation (inteso come sorpasso delle autorizzazioni) lo sfruttamento di una falla, di un errore di progetto o di configurazione di un software applicativo o di un sistema operativo al fine di acquisire il controllo di risorse di macchina normalmente precluse a un utente o a un'applicazione. Un'applicazione con maggiori autorizzazioni di quelle previste dallo sviluppo originale o fissate dall'amministratore di sistema può, ovviamente, mettere in opera azioni impreviste e non autorizzate.

Aspetti generali

La "scalata" verso un livello più alto di autorizzazioni è possibile in caso di progetto errato o di funzionalità di sistema mal gestite: ciò apre una falla nella sicurezza tramite la quale un utente o un software male intenzionato può mettere in opera azioni dei seguenti tipi:

1. Scalata verticale: un utente accede a funzioni, autorizzazioni e privilegi più alti di quelli assegnatigli: per fare un esempio finanziario, un'utenza che accede a livelli di amministrazione.
   1. Come corollario, questo comporta anche la possibilità per l'utente divenuto amministratore di retrocedere i privilegi di altri amministratori al livello di semplice utente.
2. Scalata orizzontale: un utente a pari livello di autorizzazione di altri utenti, ma con accesso ad aree differenti rispetto a questi ultimi, guadagna accesso a dette aree.

Vertical privilege escalation

Questo tipo di privilege escalation esiste quando l'utente o il processo è in grado di ottenere un livello di accesso più alto di quello di un amministratore o di quello voluto dallo sviluppatore del sistema, possibilmente eseguendo operazioni a livello del kernel (kernel-level).

Esempi di vertical privilege escalation

In alcuni casi un'applicazione con alti privilegi si presume sarà soltanto provvista di input che vada bene con la sua specifica interfaccia, senza però convalidare l'input. Un Attacker può quindi essere in grado di utilizzare questo presupposto in modo che un codice non autorizzato giri con gli stessi privilegi dell'applicazione:

1. Alcuni servizi Windows sono configurati per girare sotto un account utente del Local System. Una vulnerabilità così come il buffer overflow può essere usata per eseguire un codice arbitrario con privilegi elevati nel Local System. In alternativa, un servizio di sistema che si sta spacciando per un utente minore può elevare i propri privilegi se durante tale operazione gli errori che ne conseguono non vengono maneggiati correttamente.
2. Sotto alcune passate versioni del sistema operativo Microsoft Windows, tutti gli screensaver di tutti gli utenti girano sotto l'account Local System, ogni account che può sostituire il corrente screensaver binario nel file system o Registro può perciò aumentare i privilegi.
3. * In certe versioni del kernel di Linux era possibile scrivere un programma che dovrebbe posizionare la sua directory corrente in /etc/cron.d, per richiedere che un core dump sia capace in caso di crash che esso stesso venga ucciso da un altro processo. Il file core dump dovrebbe essere posizionato nella directory corrente del programma, cioè, /etc/cron.d, e cron dovrebbe essere trattato come un file di testo istruendo esso a far girare programmi su schedule. Poiché i contenuti dei file dovrebbero essere sotto il controllo dell'attacker, esso dovrebbe essere capace di eseguire qualunque programma con i privilegi di root.
4. Cross Zone Scripting è un tipo di attacco privilege escalation nel quale un sito web sovverte il modello di sicurezza dei browser del web così che può girare codice malevolo sui computer di tipo client.
5. Un jailbreak è l'atto o lo strumento usato per effettuare l'evasione chroot o jail in sistemi operativi tipo UNIX o bypassando i digital rights management (DRM). Nel primo caso, esso permette all'utente di vedere file esterni al file system che l'amministratore intende rendere disponibili per le applicazioni o su richiesta degli utenti. Nel contesto del DRM, ciò permette che l'utente faccia girare arbitrariamente un codice definito su dispositivi gravati dal DRM così pure da evadere le restrizioni del tipo chroot. I dispositivi gravati dal DRM come l'Xbox, PSP, iPhone, e iPod touch sono state ripetutamente soggetti a jailbreaks, permettendo l'esecuzione di codice arbitrario, ma hanno avuto i jailbreaks disabilitati dagli updates dei rispettivi venditori.

• In particolare l'iPhone è stato un terreno fertile di battaglia. Il gruppo di hacker dell'iPod touch/iPhone tuttavia, risponde ai più recenti updates dei venditori creando nuovi modi per abilitare applicazioni di terzi quasi istantaneamente. È stato solo quando aumentò la popolarità dell'iPhone che il termine jailbreaking diventò ben noto in tutto il mondo.
• Un metodo simile di jailbreaking esiste per la piattaforma S60 degli smartphones, il quale richiede l'installazione di patch softmod-style, che richiede il patching di certi file ROM mentre sono caricati nella RAM o il firmware editato (simile all'M33 firmware hackato usato per la PlayStation Portable) per raggirare le restrizioni su codice non firmato. Nokia ha pubblicato degli updates per mettere un freno ai jailbreaking non autorizzati, in maniera simile ad Apple.

1. Ci sono anche situazioni dove un'applicazione può usare altri servizi con alti privilegi e assunzioni incorrette su come un client potrebbe manipolare l'uso di questi servizi. Un'applicazione che può eseguire una Command line o una shell di comandi potrebbe avere una vulnerabilità Shell Injection se usa input invalidati come parte di un comando eseguito. Un attacker dovrebbe essere in grado di far girare comandi di sistema usando i privilegi delle applicazioni.
2. I calcolatori della Texas Instruments (in particolare il TI-85 e il TI-83) furono originariamente progettati per usare solo programmi interpretati scritti nella dialettica del TI-BASIC; tuttavia, dopo che gli utenti scoprirono dei bug che potrebbero essere utilizzati per permettere al codice nativo Z-80 di girare su l'hardware del calcolatore, i Texas Instruments pubblicarono i dati necessari alla programmazione (programming data) per supportare lo sviluppo di terzi. (Ciò non manda avanti gli ARM-based TI-Nspire, per i quali i jailbreaks non sono stati ancora trovati con successo.)

Esempio famoso di attacco usando il Demone Cron

Un esempio famoso era un programma che faceva uso del demone cron che consentiva agli utenti la schedulazione del lavoro. In genere veniva eseguito come root avendo quindi libero accesso a tutti i file di sistema e a tutti gli account utente. Principalmente l'attacco avveniva in questo modo:

1. L'attaccante crea un programma che avrà come directory di lavoro proprio quella del demone cron.
2. Dopo di che serve che venga creato un core dump e questo può avvenire in 2 modi, o va in errore così da generare un core dump o si lascia uccidere così da ottenere lo stesso un core dump.
3. I core dump sono generati nella directory di lavoro che coincide in questo caso con quella del demone cron. Poiché i dump sono fatti dal sistema possono essere scritti senza che venga fermato dal sistema di protezione. L'immagine della memoria del programma attaccante aveva una struttura tale da essere formata da un insieme valido di comandi per il demone cron che poteva eseguirli come root di sistema avendo massimi privilegi.
4. A questo punto l'attaccante si ritrovava un codice arbitrario che era in esecuzione come superuser.

Fortunatamente questo particolare bug è stato risolto ma rimane sempre un ottimo esempio di questo tipo di attacco.

Strategie per ridurre il rischio

I sistemi operativi e gli utenti possono usare le seguenti strategie per ridurre il rischio di privilege escalation:

1. Data Execution Prevention
2. Address space layout randomization (per rendere più difficile i buffer overruns ed eseguire istruzioni privilegiate su indirizzi conosciuti in memoria)
3. Facendo girare applicazioni con il minimo privilegio (per esempio facendo girare Internet Explorer con la SID dell'Amministratore disattivata nel processo di tokenizzazione) in modo da ridurre l'abilità dell'azione buffer overrun di abusare dei privilegi di un utente elevato.
4. Richiedendo che il codice in kernel-mode abbia la firma digitale
5. Fare l'up-to-date del software antivirus
6. Facendo il Patching
7. Usando compilatori che ingannino il buffer overruns
8. Criptando il software e/o i componenti del firmware

Horizontal privilege escalation

Horizontal privilege escalation accade quando un'applicazione permette all'attacker di guadagnare l'accesso alle risorse le quali normalmente dovrebbere essere state protette da un'applicazione o da un utente. Il risultato è che l'applicazione esegue azioni con lo stesso ma differente contesto di sicurezza di quello inteso dalla sviluppatore dell'applicazione o dall'amministratore del sistema; ciò è effettivamente una forma limitata di privilege escalation (specificatamente, il non autorizzato presupposto sulle capacità di imitare altri utenti).

Esempi di horizontal privilege escalation

Questo problema capita spesso nelle applicazioni web. Consideriamo il seguente esempio:

1. Utente A ha accesso all'account della banca in un'applicazione di servizi bancari online.
2. Utente B ha accesso all'account della banca nella medesima applicazione di servizi bancari online.
3. La vulnerabilità si manifesta quando l'Utente A è in grado di accedere all'account dell'Utente B eseguendo qualche tipo di attività malevola.

Questa attività malevola può essere possibile dovuta a debolezze o vulnerabilità delle comuni applicazioni web. Le potenziali vulnerabilità dell'applicazione web che possono portare a questa condizione includono:

1. La prevedibile session ID's nel HTTP cookie dell'utente
2. Session fixation
3. Cross-site scripting
4. La semplice intuizione delle password