"Esta zona del blog no será actualizada. Visita el nuevo Blog del Laboratorio Hispasec"

19
junio
2012

¿Bing poisoning?

Las técnicas de Google poisoning o Google image poisoning son más que conocidas. Consisten en comprometer una página y hacer que se comporte diferente según de donde venga la visita. Los atacantes añaden código en la web para comprobar el "Referer". Si el visitante viene de Google, es redirigido a alguna página de spam o malware. Si no, la página se muestra sin problemas. De esto ya hablé en el artículo con el celebrado título Elefantes que defecan malware. Lo curioso es que esta mañana me he encontrado con un caso que creía "Bing poisoning"... pero al final no. Buscando en estos momentos "economía for dummies" en Google, acabas en esta web:


La página está comprometida. En este caso, en vez de un script en JavaScript, parece que le han introducido un 302 que lleva a la web maliciosa. Como ya sabemos, estas páginas suelen fijarse en el Referer como condición para redirigir, así que lo comprobamos con la cadena "google".



No funcionaba. Devolvía la página original. Extraño. Después de varios intentos infructuosos, comprobamos que, con Bing y otros buscadores, sí que funciona la redirección.



¿Estamos ante un "Bing poisoining"? ¿Se ha vuelto tan popular el buscador de Microsoft que han obviado a Google y se han centrado solo en Bing? No, evidentemente. Después de inspeccionar el tráfico, comprobamos que, para la redirección, los atacantes no solo tienen en cuenta el dominio google, sino también un parámetro concreto. "sa". Solo con ese parámetro, más "google.com" en la cadena de Referer, se produce la redirección.



Investigando, comprobamos la utilidad del parámetro. Al parecer controla el "Search engine results page", o sea, cómo se usa la página de resultados de búsqueda. Esto quiere decir que solo funciona si de verdad has buscado esos términos en Google, y se ha elegido uno de los resultados. Parece que no sirve para GoogleBot o cualquier otro uso en el que se incluya solo "google" en el Referer.


Fuente: http://www.blueglass.com/blog/google-search-url-parameters-query-string-anatomy/


Así que en realidad, se trata de un pequeño refinamiento en el comportamiento con (y solo con) el buscador de Google y no un cambio de tendencia...

Enviado por ssantos a las 11:12 | Enlace permanente | Comentarios (0) | Trackbacks (0)
08
junio
2012

Descarga el certificado usado por TheFlame

Por si alguien tiene curiosidad, este es el certificado que ha usado TheFlame para firmar su código.


http://blog.hispasec.com/laboratorio/recursos/MSFlame.cer

Enviado por ssantos a las 13:08 | Enlace permanente | Comentarios (0) | Trackbacks (0)
23
mayo
2012

Windows permite, por defecto, eludir el modo protegido a programas de hace casi 10 años

Desde su versión Vista, Windows implementa MACL ("Mandatory Access Control List"). Todos sus objetos tienen un “nivel de integridad” asociado. Normalmente “medio”. Los objetos (procesos, ficheros, carpetas…) que tengan asociado un nivel de integridad “bajo”, no podrán acceder a niveles superiores (“medio”o “alto”), mientras que los de nivel “medio” o “alto” sí podrán acceder a los objetos definidos con nivel de integridad “bajo”. Esto deja a los procesos o archivos definidos con nivel de integridad “bajo”, en una especie de sandbox, puesto que no pueden llegar nada con nivel medio… o sea, nada del disco duro.


Uno de los programas que hace eso de estos niveles de integridad es Internet Explorer, y al hecho de usarlo en sus procesos (pestañas) Windows lo llama “Modo protegido”. Pero claro, ¿cómo es posible grabar algo descargado desde el navegador, o realizar cambios en el sistema, si en teoría con el modo protegido el navegador no puede acceder a esas partes del disco? Internet Explorer maneja el concepto de “broker” que es un proceso en modo de integridad medio, que siempre se ejecuta y hace de intermediario para que el navegador y sus pestañas no se encuentren totalmente aisladas.


Esto puede suponer un punto de exposición. ¿Quién es "broker" en Windows? ¿Qué otros programas actúan de esta manera? Los que están definidos en esta rama de registro:


SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

Tanto en su versión de LocalMachine como de CurrentUser.


Muchass extensiones y plugins de Internet Explorer requieren de estas políticas de elevación para poder funcionar cómodamente. Si no fuese así, muchas de estos programas integrados en el navegador, necesitarían confirmación cada vez que son ejecutados, y aparecería un diálogo como este:




Así que si la rama "Policy" del programa "broker" tiene el valor 3, una instancia del programa que se ejecute con integridad “baja” podrá invocarlo de forma silenciosa (sin que apareciese el diálogo) y manejará la petición en modo de integridad “medio”... lo que supone un peligro. Una buena parte del adware que se instala en forma de barra en Internet Explorer, también se introduce en esa rama del registro para ejecutarse de forma transparente. Sobre todo este asunto de la seguridad avanzada en Windows, se habla en este libro: Máxima seguridad en Windows


Mientras trabajaba en un pequeño programa para estudiar esto, he notado que todos los Windows Vista, 7, e incluso 8 en todas sus versiones, vienen con una serie de programas predefinidos por defecto para poder eludir la política sin preguntar (valor 3). Esto no sería demasiado sorprendente, porque podría responder a acuerdos comerciales con algunos fabricantes, lo que no dejaría de ser malo, pero al menos tendría lógica. Así, algunos programas querrían poder ejecutarse sin necesidad de que apareciese por defecto, o al menos la primera vez, un diálogo de confirmación. Como digo, “sería normal”… si no fuera por la antigüedad de los programas.


En concreto, tanto Windows Vista, 7 como 8, en todas sus versiones, traen de serie estas rutas como los programas a los que se le permite “eludir” el modo protegido:


C:\Program Files (x86)\adobe\acrobat 6.0\Acrobat\acrobat.exe

C:\Program Files (x86)\adobe\acrobat 6.0\reader\acrodr32.exe

C:\Program Files (x86)\adobe\acrobat 6.0\reader\ acrodr32.exe

C:\Program Files (x86)\adobe\acrobat 7.0\Acrobat Elements\Acrobat Elements.exe

C:\Program Files (x86)\adobe\acrobat 7.0\Acrobat\acrobat.exe

C:\Program Files (x86)\adobe\acrobat 7.0\reader\acrodr32.exe

C:\Program Files (x86)\adobe\acrobat 6.0\Acrobat Elements\Acrobat Elements.exe




Estos programas son de 2003 y 2005. No existe ninguna razón para instalarlos (llevan años sin soporte) y mucho menos permitirles por defecto el eludir la política de modo protegido de Internet Explorer. Incluso para cuando se creó Windows Vista (y se introdujo el modo protegido), estos programas ya eran antiguos.


Lo normal es que el programa pregunte (en la imagen de más arriba un ejemplo de Foxit Reader preguntando en el navegador) y, si se marca la opción, se almacenaría en el registro la entrada correspondiente.


No parece existir ninguna razón para almacenar estas ramas del registro ahí. Incluso pueden llevar a engaño y a suponer un problema de seguridad. ¿Alguien en el desarrollo de Windows al que se le olvidó eliminar unas pruebas? Quién sabe.

Enviado por ssantos a las 12:37 | Enlace permanente | Comentarios (4) | Trackbacks (0)
24
abril
2012

Buscamos analista de malware

Vamos a ampliar el personal de Hispasec con más analistas de malware físicamente en Málaga. Los requisitos que pedimos son los propios de la actividad:


  1. Ingeniería inversa avanzada.

  2. Desempaquetamiento avanzado de binarios.

  3. Creación de documentación e informes asociados.

  4. Creación de firmas de detección.

  5. Trabajar en equipo. Imprescindible.

  6. Python (deseado).


Si estás interesado, escribe a empleo@hispasec.com.

Enviado por ssantos a las 14:21 | Enlace permanente | Comentarios (0) | Trackbacks (0)
18
abril
2012

Microsoft, alguien tiene que decírtelo: las disqueteras ya no se usan

Tenía ganas de probar el Windows 8 desde hace tiempo. Lo primero es desactivar Metro, para que pueda usarse. Es absolutamente inusable esa interfaz en un escritorio. Lo segundo, mirar si han actualizado un par de cosas que llevan tiempo en el código... pero no.

Por si alguien lo dudaba, la “vulnerabilidad” de las sticky keys sigue presente. Y sigue presente porque no es una vulnerabilidad, pero cuando salió Vista hace años, la "noticia" hizo mucho ruido: "Vista sigue vulnerable...", se podía leer. No se considera un fallo de seguridad porque, para que ocurra, debes ser administrador.



La otra cosa que quería mirar es lo de Syskey. Ante el problema que supuso el pobre sistema de cifrado local de las contraseñas (LM y NTLM), Microsoft introdujo una mejora en forma de parche para Windows NT y de serie para Windows 2000 y posteriores. El sistema se llamó "Syskey" (System key) y añade una nueva capa de seguridad. Aunque todos los Windows actuales lo utilizan y mantienen activo, Syskey es una de las funcionalidades menos conocidas. Básicamente, se cifra de nuevo con una contraseña maestra (System key) las firmas o hashes LM y NTLM almacenados en la SAM para intentar protegerlos. Esto es, como suele ser habitual, una buena idea mal utilizada. En la práctica resulta un sistema de seguridad inútil. Tras aplicar ingeniería inversa, se descubrió e hizo público el sistema de cifrado de Microsoft para Syskey y existen programas de 'crackeo' que permiten saltarse este método de seguridad sin mayor problema. Sin embargo, si Syskey se utiliza correctamente, no es una mala idea.


Posibilidades que ofrece Syskey


Se puede teclear 'syskey' (como administrador) en la línea de comandos para comprobar que se tiene activo por defecto. No hay forma de deshabilitarlo. Si se decide sacar provecho real de Syskey, se debe saber que permite tres tipos de almacenamiento diferentes para la contraseña maestra (con la que cifra la SAM), pero muy pocos lo usan.


Opción 1: La contraseña Syskey para cifrar la SAM puede ser almacenada en el registro a través de un algoritmo de ocultación ideado por Microsoft (garantía de desastre… para el cifrado, se debe usar criptografía estándar). La contraseña es elegida por el propio sistema y el usuario no tiene por qué conocerla. El algoritmo de ocultación de la contraseña maestra no es en absoluto complejo y ha sido descifrado y hecho público. Esta es la opción que usan todos los Windows por defecto. Es como guardar el candado y la llave juntas. Inútil.


Opción 2: Se le puede indicar al sistema que nos pida la contraseña maestra al arrancar Windows. De esta forma el administrador elije la "System key" y se tendrá que utilizar tanto esta clave maestra como la contraseña habitual de usuario para poder presentarse. Buena seguridad.





Opción 3: Por último, se puede almacenar la clave maestra en un dispositivo externo y tener doble factor de autenticación… pero Windows solo acepta como dispositivo el disquete…. Y sí, después de más de 13 años, sigue permitiendo solo y exclusivamente almacenarla en un disquete. Y cuando digo disquete, digo la unidad A:, que no puede ser modificada. Syskey tiene incrustado que debe mirar en la unidad A y no en otra. Y sigue igual en Windows 8, y no permiten buscar en otra unidad… como un USB.




Con esta configuración, Syskey no pedirá la contraseña al iniciar Windows, la tomará directamente del disquete introducido y el sistema no arrancará si no está presente.


Sobre cómo eludir esta absurda restricción del disquete, hablo más extensamente en el libro Máxima Seguridad en Windows, que por cierto, hoy, desde las 9 am hasta las 9 am de mañana, se puede conseguir por 15 euros (y no 20, que es su precio habitual) si al comprarlo indicas el código HSMSEWST.

Enviado por ssantos a las 08:44 | Enlace permanente | Comentarios (1) | Trackbacks (0)
05
abril
2012

Elefantes que defecan malware (ejemplo práctico de envenenamiento de imágenes en Google)

A mi hijo le gustan los elefantes. Los animales en general, pero los elefantes en particular desde que le enseñé el Libro de la Selva. De vez en cuando miramos imágenes en Google para pasar el rato. Esta mañana, buscando dibujos de estos animales, he acabado en una página que me invitaba a instalar malware. Hasta aquí normal, si no fuera porque he tenido la oportunidad de comprobar que un método detectado hace un año, sigue plenamente vigente. Dada la oportunidad, veamos un ejemplo práctico.


Si buscas "elefantes" en las imágenes de Google, aparece esta foto tan simpática ante la que ningún niño podría resistirse.






Después de pinchar... automáticamente soy redirigido a:




Donde se me invita a instalar un setup.exe. Por cierto, con una detección muy pobre por firmas: 5 de 42 motores.

Con un rápido análisis manual se comprueba que es un FakeAv "clásico", con una interfaz muy trabajada.




Finalmente, como es normal, pide los datos de tarjeta para comprar. Al introducirlos (solo una vez, porque luego almacena en un servidor remoto quién ha picado) vuelve a pedirlos a través de una verificación falsa de Visa.




De vuelta a la redirección del elefante, hay que destacar que la imagen es inocente (y el elefante también). Está colgada originalmente aquí, uno de los servidores de Google.
http://3.bp.blogspot.com/_BSCeP9r5uD8/TB9KPaywIqI/AAAAAAAABTQ/DqHwdrBKPJg/s1600/elefantes.jpg

A su vez, la web "original" que la contiene es esta:

http://www.hoogwaterlaagland.nl/elefantes-asiaticos&page=6




Que parece claramente comprometida, puesto que se han añadido imágenes (muchas) de elefantes bajo el texto.

El caso es que la web ha sido comprometida y se le ha añadido un script que genera este tipo de contenido (términos habitualmente buscados en Google) automáticamente. Así, comprobamos como en el código fuente de la web se observan imágenes y texto aleatorio sobre el término, con el único fin de ser indexado por Google y recibir visitas. Además, se le ha introducido un script previo que redirige o no a la página de malware según ciertas condiciones. Esto se comprueba visitando la web http://www.hoogwaterlaagland.nl/elefantes-asiaticos&page=6. No redirige a ningún punto sospechoso, sin embargo, desde Google sí. ¿Cómo? Evidentemente diferencia la IP o el referrer. Está comprometida con otro script que lo comprueba. Vamos a verlo. Visitamos la web con wget, y comprobamos que descargamos todo el código fuente:





Ahí descarga unos 16 ks (el contenido real). Sin embargo, si el referer contiene "Google.*" (da igual el país), lo que muestra es muy distinto. Solo 164 caracteres.




Lo abrimos y aquí tenemos el misterio.




El "if" siempre redirige a la página del malware, solo que se preocupa de hacerlo de una manera u otra dependiendo si está dentro de un iframe. O sea, si la imagen se encuentra en un iframe (primer caso del "if", comprobando que no es la imagen "top") lo que redirige hacia el malware es la página madre que aloja el marco (la "top", en este caso la de Google que muestra diferentes iframes). Si no hiciera esta distinción, la redirección quedaría dentro del iframe. No sería "tan real". En resumen, lo que pretende la comprobación de "si no es ventana "top"" es escapar de este frame (que es lo que se vería si la página no estuviese comprometida)




Como indico, es un método ya descubierto en su día por Denis Sinegubko, que escribió una extensión de Firefox para detectar las imágenes "envenenadas"... pero no se había vuelvo a hablar demasiado de ello, aunque evidentemente es una técnica que sigue activa.
Enviado por ssantos a las 17:01 | Enlace permanente | Comentarios (1) | Trackbacks (0)