Privilege escalation: differenze tra le versioni

Versione delle 21:32, 18 ago 2011

Versione delle 18:24, 8 set 2011

Riga 4:

Privilege escalation esiste quando un’applicazione con privilegi elevati ha un bug che permette di bypassare la sicurezza, o in alternativa, si presuppone sia imperfetto il modo con cui essa sarà utilizzata. Privilege escalation esiste in tre forme:

# '''Vertical privilege escalation''', anche conosciuta come ''[[privilege elevation]]'', dove un utente (user) con privilegi più bassi accede a funzioni o contenuti riservati ad utenti (users) con privilegi più alti (ad esempio: un Utente A dei servizi Bancari Online accede alle funzioni di Amministratore)

# '''Horizontal privilege escalation''', dove un utente normale accede a funzioni o contenuti riservati ad altri utenti normali (ad esempio: un Utente A dei servizi Bancari Online accede all’account Bancario Online di un Utente B)

# '''Privilege descalation''', dove un utente con un alto privilegio ma nella riservatezza (esempio utente/amministratore della sicurezza, comunemente visto nell’ambiente [[SOx]] ) è in grado di fare il downgrade (degradare) il livello di accesso di altri utenti fino a quello delle funzioni di un utente normale.

==Vertical privilege escalation==

Riga 13:

===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:

# 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.

# Sotto alcune passate versioni del sistema operativo [[Microsoft Windows]], tutti gli [[Salvaschermo|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 di sistema|Registro]] può perciò aumentare i privilegi.

# '''*''' In certe versioni del [[kernel]] di [[Linux]] era possibile scrivere un programma che dovrebbe posizionare la sua directory corrente in <code>/etc/cron.d</code>, 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è, <code>/etc/cron.d</code>, e <code>[[cron]]</code> 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 (informatica)|root]].

# [[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]]..

# Un [[jailbreak (informatica)|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 ([[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]], [[PlayStation Portable|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 [[Read Only Memory|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 rilasciato degli updates per mettere un freno ai jailbreaking non autorizzati, in maniera simile ad [[Apple]].

# 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 (informatica)|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.

# 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]] rilasciaronopubblicarono 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 [http://root root] avendo quindi libero accesso a tutti i file di sistema e a tutti gli account utente. Principalmente l’attacco avveniva in questo modo:

# L’attaccante crea un programma che avrà come directory di lavoro proprio quella del demone cron.

# 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]].

# 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 (utente)|root]] di sistema avendo massimi privilegi.

# 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:

# [[Data Execution Prevention]]

# [[Address space layout randomization]] (per rendere più difficile i [[buffer overruns]] ed eseguire istruzioni privilegiate su indirizzi conosciuti in memoria)

# 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.

# Richiedendo che il codice in [[kernel-mode]] abbia la firma digitale

# Fare l’ up-to-date del [[software]] [[antivirus]]

# Facendo il [[Patching]]

# Usando compilatori che ingannino il [[buffer overruns]]

# Criptando il [[software]] e/o i componenti del [[firmware]]

Riga 48:

===Esempi di horizontal privilege escalation===

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

# Utente A ha accesso all’account della banca in un’applicazione di servizi bancari online.

# Utente B ha accesso all’account della banca nella medesima applicazione di servizi bancari online.

# 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:

# La prevedibile [[session ID]]'s nel [[HTTP cookie]] dell’utente

# [[Session fixation]]

# [[Cross-site Scripting]]

# La semplice intuizione delle [[password]]

Riga 70:

==Bibliografia==

* James Quintana Pearce (2007-09-27), IPhone Hackers, Forbes, http://www.forbes.com/technology/2007/09/27/apple-orange-iphone-tech-cx_pco_0927paidcontent.html, retrieved 2008-08-04

* http://www.computerworld.com/s/article/9054719/Reports_Next_iPhone_update_will_break_third_party_apps_bust_unlocks?taxonomyId=11&intsrc=hm_topic

* http://forum.dailymobile.se/index.php?topic=1165.0

* http://symbianism.blogspot.com/2009/02/helloox-103-one-step-hack-for-symbian.html

* http://thinkabdul.com/2007/10/29/tutorial-bypass-symbian-signed-install-unsigned-sisxj2me-midlets-on-nokia-s60-v3-with-full-system-permissions/

* "Microsoft Minimizes Threat of Buffer Overruns, Builds Trustworthy Applications". Microsoft. September 2005. http://download.microsoft.com/documents/customerevidence/12374_Microsoft_GS_Switch_CS_final.doc. Retrieved 2008-08-04. [dead link]