Un grupo de investigadores publicó en su blog, una nueva alerta de un ataque masivo a páginas con inyección de iframe activo, que estuvo particularmente focalizado en sitios de e-commerce. El ataque fue reportado con más de 90 mil páginas afectadas. El iframe permite la ejecución de contenido externo en la página que se está visitando. De esta forma, los visitantes de todos los sitios afectados podían infectarse con malware por el solo hecho de visitar un sitio web de confianza.
A través de diversas vulnerabilidades, todas las páginas afectadas se encuentran con la siguiente inyección de iframe:
Una vez que el usuario visita alguna de las web infectadas, se ejecuta en la maquina del usuario, a través de un ataque multi-stage, código javascript que explota las siguientes vulnerabilidades que afectan al explorador web:
CVE-2010-0840 – Java Trust
CVE-2010-0188 – PDF LibTiff
CVE-2010-0886 – Java SMB
CVE-2006-0003 – IE MDAC
CVE-2010-1885 – HCP
Los dominios donde se alojan los exploit se encuentran en Rusia y son bloqueadas por nuestro software de seguridad. Analizando los sitios donde se encontraba presente este iframe, pudimos encontrar que estos son sensibles a inyecciones de SQL.
Es por eso que ante estos casos, si un desarrollador se encuentra ante este problema, debería revisar el código fuente de todas las páginas del sitio, para buscar este tipo de contenido no legítimo y verificar si el sitio web está infectado. Así también es importante tener en cuenta los siguientes consejos:
Que todas las contraseñas del FTP sean rotadas y se utilicen contraseñas fuertes para todos los usuarios. También se recomienda borrar usuarios que no estén en uso.
Que el sistema operativo no tenga vulnerabilidades, es decir que que todas las actualizaciones de software estén instaladas.
Que las aplicaciones (especialmente la aplicación web o el gestor de contenidos) también tengan todos los parches de seguridad instalados.
Vale destacar que, a este momento, se encuentran en el mismo enlace del buscador provisto por los investigadores, muchos más sitios web infectados por el mismo incidente:
El código malicioso que se descarga en el último paso del ataque, es un troyano.
Para lograr este objetivo, los atacantes realizan lo que se conoce como un ataque de pharming local, en donde a través de la modificación del archivo hosts se redirecciona al usuario a una página falsa, para robar sus claves de acceso. El ataque es simple, la posible víctima ingresa al sitio, cree que está accediendo a su correo electrónico, e intenta iniciar sesión. Sin embargo, al utilizar sus datos para inicio de sesión, recibe un mensaje de error.
Lo que realmente ocurre es que ha caído víctima de este ataque, y ahora sus credenciales se encuentran en manos de los atacantes, quienes podrán utilizarlas para continuar propagando esta amenaza a todos sus contactos. A continuación se puede observar qué es lo que realmente se almacena en este servidor:
En la imagen anterior, se puede observar parte de los archivos de texto en donde se almacenan más de 27.000 credenciales de usuarios de Hotmail, en 13.406 archivos de texto, creados entre el 21 de julio a las 21:56 hasta el martes 26 a las 11:14. Actualmente el sitio se encuentra caído.
Durante un total de 6 días de actividad, los usuarios cuyos equipos se encuentran infectados con esta amenaza, generaron un total de 27.211 registros de correos y contraseñas.
Sobre el total de los datos robados, se encuentran 8.233 direcciones de correos únicas, lo que resulta en un promedio de 3 accesos por usuario, que no pudieron reconocer una página falsa, en un total de 6 días de actividad del sitio malicioso. En otras palabras, más de 8.200 personas son víctimas potenciales del robo de información e identidad por parte de los desarrolladores de este ataque.
Tomando las fechas de los datos registrados en el servidor de los atacantes, se puede concluir, que las víctimas del engaño, infectaron sus equipos a través de los correos falsos que decían contener un video de la presidenta de Brasil, Dilma Rousseff, y las fotos del fallecimiento de Amy Winehouse.
En conclusión, los atacantes, hacen uso de la Ingeniería Social, con el objetivo de atraer la atención de los usuarios y así robar su información.
Un usuario comenta en su blog la presentación de Greg Stein, ingeniero administrador del grupo Open Source de Google, en la reciente SDForum Python Meeting: En Google, Python es uno de 3 "lenguajes oficiales", junto con C++ y Java. Oficial significa que los empleados de Google pueden usar estos lenguajes en proyectos de producción (los que usamos todo el mundo).
Internamente, la gente de Google puede usar muchas otras tecnologías, incluyendo PHP, C#, Ruby y Perl. Python está bien adecuado a los procesos de ingeniería en Google. El típico proyecto en Google tiene un equipo pequeño (de 3 pesonas) y una corta duración (de 3 meses).
Después de que el proyecto se ha terminado, los desarrolladores pueden irse a otros proyectos. Los proyectos más grandes pueden subdividirse en otros más pequeños presentables en 3 meses, y los equipos pueden elegir su propio lenguaje para el proyecto.
A los ingenieros se les da el 20% del tiempo en su trabajo para que lo apliquen en lo que sea que quieran. Muchas de las nuevas ideas de Google provienen de este 20%, y "de abajo hacia arriba" parece ser el mantra en Google.
Internamente, Google ha estado usando Python 2.2. Es difícil para ellos mudarse a la v2.3 o v2.4 por la gran cantidad de computadoras que tienen y la compatibilidad entre todas ellas. Sin embargo, pronto intentarán actualizarse a la v2.4.
Los programadores Python en Google deben seguir una estricta pauta de estilo (basada en PEP8 con indentación de 2 espacios). Cuando a los ingenieros se les otorga acceso al sistema de Google de administración de código fuente, deben pasar antes una prueba de estilo. Todo el código debe pasar la supervisión de 2 pares de ojos antes de ser aceptado.
El sistema de builds de Google está escrito en Python. Todo el código corporativo de Google es alamacenado en un repositorio y las dependencias y la construcción de este código es administrado por Python. Stein mencionó que crear code.google.com llevó 100 líneas de código Python. Pero debido a que tenía tantas dependencias, el sistema de builds generó un archivo makefile de 3 Mb para él.
Google tiene un sistema interno de empaquetado de software, similar al RPM de Red Hat. Estos paquetes son creados usando Python.
Alex Martelli está trabajando en optimizar las transferencias de datos binarios entre miles de servidores, usando Python.
Todo el monitoreo, reinicialización y recolección de datos de los servidores de producción se realiza en Python.
Los logs son anlizados y los reportes generados usando Python.
Python también se usa en algunos servicios como code.google.com y los Google Groups. La mayoría de los front-ends están escritos en C++ (incluído www.google.com) y también en Java (como Gmail). Todos los servicios web están construidos sobre un servidor http altamente optimizado que cuenta con SWIG para conectar programas escritos en C o C++ con otros lenguajes de scripting como Perl, Ruby o Python.
Stein también comentó que el código que Google liberó como Open Source hasta ahora no ha sido muy interesante. Pero espera que eso cambie en el futuro cercano. También notó que probablemente liberen su sistema de empaquetado de software.
Desde el editor de registro de windows Inicio - Ejecutar - "Regedit"
Vamos a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
Ahora clic derecho > Nueva Clave
Y creamos una nueva clave con el nombre de StorageDevicePolicies
En el panel derecho vamos a crear un nuevo valor DWORD
Ahora, para proteger contra escritura los dispositivos que se conecten, basta con asignarle dicho valor a 1 (uno). Para desactivar la protección asignamos 0 (cero).
Si quisieramos automatizar dicho procedimiento, solo basta con exportar la clave que generamos.
Podemos crear ambos estados (Protección ON – OFF) para facilitar la tarea.
El contenido de cada .reg debe ser similar al de la imagen
Por lo tanto, si requerimos activar la protección contra escritura de un dispositivo USB, solo tenemos que hacer doble click en la llave con el valor 1. Y si trataramos de escribir de alguna manera en dicho dispositivo, nos encontramos con la siguiente advertencia.
Funciona correctamente en Windows XP, Vista y 7. No recuerdo en cuales, me parece que en los ultimos dos, necesita reiniciar.
Internet se ha transformado en una preciada plataforma de ataque donde la diseminación de malware a través de aplicativos crimeware es cosa de todos los días. Una gran parte del malware actual se encuentra diseñado con la intención de reclutar computadoras zombis que luego formarán parte de alguna botnet.
Por ejemplo aquí tenemos una pantalla de login del Comando y Control (C&C) de una de estas redes:
Este tipo de aplicativos permiten a los botmaster administrar y controlar cada una de las computadoras infectadas a través de una panel de administración desde el cual pueden ejecutar de manera remota, además de la propagación de malware, otros tipos de acciones maliciosas como DDoS (Denegación de Servicio Distribuida) o el envío de spam, como es el caso de la botnet formada por el troyano Waledac. Aquí, uno de estos panel donde se puede ver la cantidad de sistemas controlados por país:
Hace tiempo pudimos conocer el poder de las botnets cuando se polemizó la prueba realizada por la BBC en torno a una investigación sobre el crimeware actual, dejando en completa evidencia que para quienes se dedican a ello, las botnet, el malware y el crimeware en general, constituyen un negocio sin fronteras.
ZeuS (o Zbot) representa una de las botnet con mayor actividad de la actualidad formando parte del conjunto de aplicativos crimeware que permiten su administración vía web a través de una interfaz.
Sus diferentes módulos de ataque, escritos en PHP, le permiten al botmaster (o a cualquiera de los personajes que alquilan la botnet, como por ejemplo un spammer) llevar a cabo diferentes actividades de índole delictiva y propagar diferentes códigos maliciosos que colaboran con los ataques; siendo uno de los más activos, los ataques de phishing.
El Kit de este crimeware, ya posee una serie de archivos escritos en html donde cada uno de ellos es la clonación de la página web de diversas entidades bancarias, que ZeuS clasifica de acuerdo al idioma. Es decir, dentro de su estructura encontramos carpetas que alojan cada phishing en idioma español, inglés, ruso (este crimeware proviene de Rusia) y en algunos casos alemán dependiendo de la versión del Kit, listos para ser propagados por el ciberdelincuente.
La siguiente captura muestra el phishing a dos conocidas entidades bancarias:
Las posibilidades fraudulentas que ofrece la botnet son más amplias y no sólo posee clonaciones de páginas de entidades bancarias sino que también de compañías que ofrecen servicios a través de Internet. Entre las que forman parte de la nómina se encuentran:
gruposantander.es
finanzportal.fiducia.de
bankofamerica.com
bbva.es
bancaja.es
online.lloydstsb.co.uk
bancopopular.es
ebay.com
us.hsbc.com
e-gold.com
paypal.com
usbank.com
citizensbankonline.com
extranet.banesto.es
citibank.de
bancoherrero.com
Además, este crimeware propaga diferentes códigos maliciosos diseñados para realizar diferentes actividades delictivas.
Al igual que otros kits de control, administración y monitoreo vía web a través de una interfaz, estos paquetes crimeware incorporan diferentes módulos de ataque que posibilitan al botmaster propagar diferentes códigos maliciosos a través de diferentes técnicas.
En este sentido, ya vimos una breve introducción a ZeuS, mostrando también la capacidad que posee de realizar ataques de phishing a importantes entidades bancarias y otras compañías que ofrecen servicios por Internet.
Ahora, para completar un poco más el conocimiento sobre esta botnet, que en la actualidad se encuentra muy activa y con alto porcentaje de equipos infectados que forman parte de su red, veamos cuáles son los diferentes códigos maliciosos que propaga.
En principio cabe aclarar que la cantidad y variedad de malware capaz de propagar ZeuS cambia levemente con cada versión del Kit, salvo por el propio código malicioso de la botnet, creado a partir de una aplicación interna del paquete.
Es decir, que también propaga el malware que describo a continuación:
Win32/PSW.LdPinch: un troyano cuyo objetivo es recolectar información sensible y confidencial relacionada a nombres de usuarios y contraseñas
Win32/TrojanClicker.Delf: otro tipo de troyano que busca registrar la mayor cantidad de click sobre servicios como AdSense y similares
Win32/TrojanDownloader.Small: diseñado para descargar otros códigos maliciosos en el equipo infectado
Pero tampoco se queda con ese grupo de cuatro códigos maliciosos, ZeuS es capaz de propagar otros, quizás un poco más conocidos por nuestros lectores:
Se trata de tres códigos maliciosos detectado por ESET NOD32 como:
Win32/Adware.SpywareProtect2009: un conocido rogue ampliamente propagado, incluso por otros aplicativos crimeware
Win32/Koobface: un gusano diseñado para explotar diferentes redes sociales robando información sensible de los usuarios que hacen uso de ella, volviéndo a la carga recientemente.
PDF/Exploit.Pidief: orientado a explotar vulnerabilidades conocidas en los lectores de archivos PDF Acrobat Reader y Foxit Reader
Como podemos apreciar, un total de siete códigos maliciosos que dejan en evidencia que la capacidad de propagación de malware de este crimeware son muy amplias.
Eso es todo, el que esté interesado en el descargar el source de ZeuS puede hacerlo desde aquí:
A la hora de analizar malware, los analistas e investigadores nos encontramos con todo tipo de muestras. Muchas veces nos encontramos con binarios empaquetados cuya finalidad es dificultar su estudio. En esta oportunidad analizaremos una muestra que no solo esta empaquetada, sino que tiene otras características adicionales orientadas a dificultar su análisis y detección.
El binario estudiado en este caso, esta empaquetado con el popular empaquetador UPX, cosa que podemos ver fácilmente con el detector de packers ProtectionID:
Si queremos verificar esto, podemos mirar el Entry Point (EP) con un debugger:
Aquí podemos ver el clásico PUSHAD en el EP de un archivo empaquetado con UPX. Para desempaquetarlo podemos hacerlo a mano, utilizando un método llamado PUSHAD (no lo explicaremos en esta oportunidad pero si alguien quiere consultarlos, puede dejarnos un comentario), o el método mas sencillo, mediante el comando upx -d como vemos en el siguiente gráfico:
Vale destacar que este método no siempre funciona en versiones de UPX modificadas. Finalmente, con cualquiera de ambos métodos llegamos al Original Entry Point, mas conocido como OEP. Para este malware el mismo esta en la dirección 4012c2:
Ya con el programa desempaquetado, al ejecutarlo, una de las primeras llamadas a funciones interesantes que encontramos es GetUserDefaultUILanguage de la librería Kernel32.dll. Esta función sirve para identificar la configuración del lenguaje del teclado en el sistema operativo.
¿Por qué decimos que es una función interesante ? Porque serviría para restringir la infección del malware a determinados equipos con la finalidad de acotar su expansión geográfica. Este tipo de chequeos regionales podemos verlos en Swizzor, que utiliza la función GetSystemDefaultLangID para obtener el lenguaje del sistema. Luego lo compara con un valor hexadecimal para decidir si infecta o no el equipo. También observamos este tipo de acciones en Conficker, que utiliza la función GetKeyboardLayoutList, de la cual obtiene la distribución del teclado y a partir de ella chequea si se instala o no.
Siguiendo con el tema de protecciones anti-debugging, podemos ver que esta muestra posee protecciones contra máquinas virtuales y chequea si es ejecutado en alguno de los entornos virtuales mas conocidos como son VMware. VirtualBox, VirtualPC y QEMU. A continuación podemos ver dicha porción en el código:
Cómo vemos en la imagen de arriba, el código aparece completamente en amarillo, esto se debe a que al iniciar el programa, las direcciones de memoria donde están las instrucciones anti-virtuales se encontraban vacías. Esto nos indica que el código se descomprimió en ejecución. Para poder visualizar este código hay que ejecutarlo, sino solo veríamos estas secciones vacías. Aquí una imagen de como se veían estas mismas secciones antes de ejecutar el programa:
Para terminar con el análisis de las protecciones, esta muestra también chequea nombres y ID de procesos, en este caso como lo debuggeamos con el programa Immunity Debugger, el malware identifica el proceso Immunitydebugger.exe. Otra cosa interesante que hace es identificar si existe o no alguna solución antivirus instalada.
De todas las protecciones que detallamos en este post, la que mas nos perjudica a la hora de analizar malware es la protección anti-VM. Existen muchas formas de detectar que un archivo esta siendo debuggeado en un entorno virtual. Esto puede llegar a ser muy tedioso, ya que la mayoría de los análisis que se hacen son dentro de estos entornos virtualizados, para tratar de aislar así la infección y poder simular lo más posible el comportamiento del malware en un entorno “real”. Por suerte existen varias formas de saltearse estas detecciones y lograr ejecutar el malware adentro de una maquina virtual, pero esto ya requiere mas conocimientos para poder identificar en que momento se realiza este chequeo. Una opción mas fácil y totalmente viable, aunque más costosa, seria poseer una maquina física específicamente dedicada para el análisis de malware ya que no recomendamos analizar muestras directamente en la computadora que se utiliza a diario.
The MS-RPC functionality in smbd in Samba 3.0.0 through 3.0.25rc3 allows remote attackers to execute arbitrary commands via shell metacharacters involving the (1) SamrChangePassword function, when the "username map script" smb.conf option is enabled, and allows remote authenticated users to execute commands via shell metacharacters involving other MS-RPC functions in the (2) remote printer and (3) file share management. Explotando un servidor Samba con acceso a privilegios de Root
Mostrar Temas
