domingo, 23 de enero de 2011
Estafas a jugadores de FarmVille al recibir "extraños animales de regalo"
13:35 | 
Publicado por
Tony Orozco |
Una cadena de estafas relacionada con FarmVile ha venido apareciendo en Facebook en los últimos días, en las cuales se persuade a los usuarios de llenar formularios que son usados para ofrecerles animales extrañoso bonos de Farm Cash.
Facecrooks advierte que un simple clic en la liga contenida en estos mensajes, y los usuarios son dirigidos a la página donde se les pide que instalen una "barra de juego libre para Farmville", además publica información de la aplicación en el muro de los usuarios, lo que hace que la estafa se propague más rápido.
Una vez que terminan el formulario, los usuarios deben completar una encuesta con el fin de ser acreedores al animal extraño. A los estafadores se les paga por cada encuesta completada, la cual es llenada por los usuarios, además se corre el riesgo de que la información proporcionada por los usuarios pueda ser usada para futuras estafas.
Algunas veces los usuarios también son incitados a inscribirse a un servicio de tarificación adicional, otras veces para descargar y terminar un juego con el objetivo de obtener un premio final.
Lo peor de esto, es que en algunas ocasiones el juego descargado por los usuarios no es por completo un juego, es un malware disfrazado para engañar a los usuarios y ser instalado en el sistema.
En cualquier caso, si usted es tentado por estas ofertas, lo mejor es verificar su legitimidad mediante la comprobación oficial de Farmville y los sitios Zynga.
Gusano de Twitter golpea goo.gl y redirige a antivirus falso
Un gusano de Twitter de rápida propagación que utiliza el servicio de redirección de Google, goo.gl, anda en circulación y lleva a usuarios desprevenidos a una notoria campaña malware scareware (antivirus falso).
De acuerdo con los "cazadores" de malware a cargo de buscar la amenaza, la cadena de redirección del gusano lleva a los usuarios a una página web que aloja el Rogue AV "Security Shield". La página utiliza técnicas de ofuscamiento que incluye una implementación de criptografía RSA en JavaScript para ocultar el código.
El investigador de malware, Nicolas Brulez, de laboratorios Kaspersky, comentó que los enlaces originales de "goo.gl"en los mensajes de Twitter, redirigen a los usuarios a diferentes dominios con la página "m28sx.html". Esa página posteriormente redirige a un dominio estático con una dirección ucraniana de alto nivel.
Por si esto no fuera suficiente, el dominio redirige al usuario a otra dirección IP, la cual ha sido relacionada anteriormente con la distribución de antivirus falsos. "Esta dirección IP hará el trabajo final de redirección, el cual lleva al sitio actual del AV falso", explicó Brulez.
Una vez que la sesión de navegador del usuario es redirigida al sitio malicioso, un mensaje de advertencia alerta de que la máquina está ejecutando aplicaciones sospechosas y el usuario es encaminado a realizar un escaneo. Como siempre, el resultado es que la máquina está contaminada con amenazas maliciosas y la estafa resulta al engañar al usuario para descargar una falsa herramienta de desinfección.
Vulnerabilidad en el motor de proceso de gráficos en Windows
Vulnerabilidad en el motor de proceso de gráficos en Windows.
Sistemas Afectados:
Windows XP SP3 y x64 SP2
Windows Server 2003 y x64 SP2, y 2003 para Itanium
Windows Vista y x64
Windows Server 2008, x64 e Itanium
Nota: Las vulnerabilidades descritas en este aviso no afectan a las ediciones compatibles de Windows Server 2008 que han sido instaladas con la opción Server Core. Microsoft está investigando una vulnerabilidad en el motor de proceso de gráficos en Windows (Windows Graphics Rendering Engine).
Microsoft propone una solución temporal hasta que se publique alguna actualización de seguridad o un fix-it que solucione el problema. Esta solución consistiría en modificar el ACL sobre shimgvw.dll para hacerla más restrictiva.
Esta vulnerabilidad fue revelada en Diciembre del 2010 por Moti y Xu Hao en la conferencia “Power of Community” en la que explicaron como crear un fichero de imagen para explotar esta vulnerabilidad. El thumbnail es almacenado en un archivo de mapa de bits. Estableciendo el número de los índices de la tabla de colores a un número negativo (biClrUsed) es posible explotar esta vulnerabilidad, la cual además permite eludir DEP y SafeSEH.
Esta vulnerabilidad por tanto puede ser explotada desde diferentes vectores de ataque por ejemplo visitando una página web especialmente manipulada o abriendo un fichero adjunto de un correo electrónico. La explotación de esta vulnerabilidad podría permitir a un atacante ejecutar código arbitrario en el contexto de seguridad del usuario conectado.
Aviso tecnico de Technet en el siguiente link:
http://blogs.technet.com/b/msrc/archive/2011/01/04/microsoft-releases-security-advisory-2490606.aspx
Aviso tecnico de Microsoft en el siguiente link:
https://www.microsoft.com/technet/security/advisory/2490606.mspx
Actualizaciones de Microsoft para múltiples Vulnerabilidades
Existen múltiples vulnerabilidades en Microsoft Data Access Components y Windows Backup Manager. Microsoft ha liberado actualizaciones para solucionar estas vulnerabilidades.
Sistemas Afectados
*Microsoft Data Access Components
*Windows Backup Manager
Descripción
*El boletín de Seguridad de Microsoft para Enero de 2011 describe vulnerabilidades en Microsoft Data Access Components y Windows Backup Manager. Microsoft ha liberado actualizaciones para solucionar estas vulnerabilidades.
Impacto:
Un usuario remoto no autenticado podría ejecutar código arbitrario, causar una denegación de servicio u obtener acceso a archivos del sistema.
Solución:
Aplicar las actualizaciones. Microsoft ha liberado actualizaciones para estas vulnerabilidades en el Compendio de Boletines de Seguridad Microsoft de Enero de 2011. Los boletines describen los problemas conocidos relacionados con las actualizaciones.
Se recomienda a los administradores tomar en cuenta estos problemas y realizar pruebas sobre cualquier efecto adverso. Así mismo deben considerar usar un sistema de distribución automática de actualizaciones como Windows Server Update Services (WSUS).
Referencias
Microsoft Security Bulletin Summary for January 2011
Microsoft Windows Server Update Services
Según el New York Times, Stuxnet fue creado y financiado por los gobierno de Estados Unidos de América e Israel
New York Times ha venido a confirmar lo que ya se rumoreaba desde hace tiempo: Stuxnet, un gusano que sorprendió a propios y extraños por su extrema complejidad y profesionalidad, ha sido financiado por el
gobierno de Estados Unidos de América e Israel, y su objetivo eran las centrales nucleares de Irán.
Desde mediados de 2010, Stuxnet ha marcado un antes y un después en la mitología del malware, acaparando titulares. Técnicamente, es muy avanzado: el uso combinado e inteligente de vulnerabilidades
desconocidas hasta el momento para difundirse, el uso de certificados válidos, y unos objetivos muy concretos (el software para controlar ciertos aspectos de las centrales nucleares) hacían pensar que detrás de este código debía existir un despliegue fuera de lo común. Se necesita mucho conocimiento, poder, investigación y tiempo (o sea, mucho dinero en resumen) para desarrollar Stuxnet y esta tarea ya se le reservaba a los gobiernos. Por ejemplo, en octubre ya escribíamos en una-al-día que Stuxnet fue "diseñado y financiado supuestamente por algún gobierno para atacar el plan nuclear Iraní" y Eugene Kaspersky consideraba en esas mismas fechas que Stuxnet "era el prototipo funcional de una ciber-arma, que dará el pistoletazo de salida a una ciber-guerra en el mundo"
Lo que sugiere el New York Times es que Estados Unidos e Israel desarrollaron el gusano para paralizar el plan nuclear iraní. Durante dos años se utilizó una central nuclear de Dimona (al sur de Israel) como laboratorio para examinar y ensayar Stuxnet con el objetivo de sabotear las centrifugadoras nucleares en Irán. En Dimona, los israelitas utilizaron el mismo tipo de centrifugadoras que operan en la central iraní de Natanz, donde se produce el enriquecimiento de uranio. Así consiguieron que fuese tan efectivo: el gusano paralizó la quinta parte de las centrifugadoras de uranio de Natanz. Stuxnet primero modificaba sus parámetros de regulación para destruirlas y luego enviaba señales al sensor para aparentar que todo estaba correcto.
En principio, la información del New York Times viene de "expertos militares y de inteligencia norteamericanos", pero muy probablemente nunca será confirmado oficialmente (aunque todo apunta a que sea cierto).
Por ejemplo, en la noticia se habla de que llevaban dos años trabajando en el gusano. Según nuestra base de datos de Virustotal, la primera referencia a Stuxnet viene el 1 de julio de 2009. Sí, 2009 (Stuxnet saltó a los medios en julio de 2010). Pero no es el troyano como tal. Lo que encontramos entonces son las primeras referencias a malware que aprovecha una vulnerabilidad por entonces llamada simplemente por algunos antivirus "Autorun". Solo era detectado por 6 motores. Lo que no sabían, es que esta sería la vulnerabilidad que más tarde (un año más tarde) se calificaría como CVE-2010-2568, y que permitía a Stuxnet la ejecución de código a través de enlaces LNK. En pocas palabras: esta vulnerabilidad (que obligó a Microsoft a publicar un parche de emergencia por su gravedad) era conocida desde hacía más de un año y,
aunque algunos motores la detectaban entonces, no descubrieron que era "nueva". La metieron en el saco de malware genérico que se ejecutaba a través del Autorun. Tuvo que entrar en escena Stuxnet para que se
analizase, saliera a la luz y fuera corregida.
Las primeras muestras en aprovechar este fallo vienen desde Vietnam, China y una casa antivirus en el Reino unido en julio de 2009. Se siguen recibiendo muestras, pocas, durante todo 2009 y 2010, y no es hasta
julio de 2010 que es ampliamente reconocida como lo que realmente es. Una muestra real de Stuxnet en nuestra base de datos la encontramos por primera vez el 16 de mayo de 2010. Se trata de un driver (archivo .sys que contiene la funcionalidad de rootkit de Stuxnet) que no era detectado entonces por ningún motor. Sigue pasando relativamente desapercibido hasta el 7 de julio, cuando un antivirus lo bautiza como
Stuxnet. A partir de ahí, recibimos muchas muestras, pero no es hasta finales de julio que es detectado por la mayoría.
El primer ejecutable Stuxnet del que tenemos noticia, se remonta también al 16 de mayo de 2010 y sigue una trayectoria muy similar al driver en nivel de detección.
Más información:
Israel y EEUU crearon el virus que dañó el programa nuclear iraní
Israel y EEUU crearon el virus que daño el programa nuclear irani | Mundo | elmundo.es
gobierno de Estados Unidos de América e Israel, y su objetivo eran las centrales nucleares de Irán.
Desde mediados de 2010, Stuxnet ha marcado un antes y un después en la mitología del malware, acaparando titulares. Técnicamente, es muy avanzado: el uso combinado e inteligente de vulnerabilidades
desconocidas hasta el momento para difundirse, el uso de certificados válidos, y unos objetivos muy concretos (el software para controlar ciertos aspectos de las centrales nucleares) hacían pensar que detrás de este código debía existir un despliegue fuera de lo común. Se necesita mucho conocimiento, poder, investigación y tiempo (o sea, mucho dinero en resumen) para desarrollar Stuxnet y esta tarea ya se le reservaba a los gobiernos. Por ejemplo, en octubre ya escribíamos en una-al-día que Stuxnet fue "diseñado y financiado supuestamente por algún gobierno para atacar el plan nuclear Iraní" y Eugene Kaspersky consideraba en esas mismas fechas que Stuxnet "era el prototipo funcional de una ciber-arma, que dará el pistoletazo de salida a una ciber-guerra en el mundo"
Lo que sugiere el New York Times es que Estados Unidos e Israel desarrollaron el gusano para paralizar el plan nuclear iraní. Durante dos años se utilizó una central nuclear de Dimona (al sur de Israel) como laboratorio para examinar y ensayar Stuxnet con el objetivo de sabotear las centrifugadoras nucleares en Irán. En Dimona, los israelitas utilizaron el mismo tipo de centrifugadoras que operan en la central iraní de Natanz, donde se produce el enriquecimiento de uranio. Así consiguieron que fuese tan efectivo: el gusano paralizó la quinta parte de las centrifugadoras de uranio de Natanz. Stuxnet primero modificaba sus parámetros de regulación para destruirlas y luego enviaba señales al sensor para aparentar que todo estaba correcto.
En principio, la información del New York Times viene de "expertos militares y de inteligencia norteamericanos", pero muy probablemente nunca será confirmado oficialmente (aunque todo apunta a que sea cierto).
Por ejemplo, en la noticia se habla de que llevaban dos años trabajando en el gusano. Según nuestra base de datos de Virustotal, la primera referencia a Stuxnet viene el 1 de julio de 2009. Sí, 2009 (Stuxnet saltó a los medios en julio de 2010). Pero no es el troyano como tal. Lo que encontramos entonces son las primeras referencias a malware que aprovecha una vulnerabilidad por entonces llamada simplemente por algunos antivirus "Autorun". Solo era detectado por 6 motores. Lo que no sabían, es que esta sería la vulnerabilidad que más tarde (un año más tarde) se calificaría como CVE-2010-2568, y que permitía a Stuxnet la ejecución de código a través de enlaces LNK. En pocas palabras: esta vulnerabilidad (que obligó a Microsoft a publicar un parche de emergencia por su gravedad) era conocida desde hacía más de un año y,
aunque algunos motores la detectaban entonces, no descubrieron que era "nueva". La metieron en el saco de malware genérico que se ejecutaba a través del Autorun. Tuvo que entrar en escena Stuxnet para que se
analizase, saliera a la luz y fuera corregida.
Las primeras muestras en aprovechar este fallo vienen desde Vietnam, China y una casa antivirus en el Reino unido en julio de 2009. Se siguen recibiendo muestras, pocas, durante todo 2009 y 2010, y no es hasta
julio de 2010 que es ampliamente reconocida como lo que realmente es. Una muestra real de Stuxnet en nuestra base de datos la encontramos por primera vez el 16 de mayo de 2010. Se trata de un driver (archivo .sys que contiene la funcionalidad de rootkit de Stuxnet) que no era detectado entonces por ningún motor. Sigue pasando relativamente desapercibido hasta el 7 de julio, cuando un antivirus lo bautiza como
Stuxnet. A partir de ahí, recibimos muchas muestras, pero no es hasta finales de julio que es detectado por la mayoría.
El primer ejecutable Stuxnet del que tenemos noticia, se remonta también al 16 de mayo de 2010 y sigue una trayectoria muy similar al driver en nivel de detección.
Más información:
Israel y EEUU crearon el virus que dañó el programa nuclear iraní
Israel y EEUU crearon el virus que daño el programa nuclear irani | Mundo | elmundo.es
Etiquetas:
EUA,
Iran,
Israel,
New York Times,
Programa Irani Nuclear Arruinado por Stuxnet,
Stuxnet
|
0
comentarios
"Geinimi" troyano para Android con capacidad para recibir ordenes
Recientemente se ha observado un nuevo ejemplar de Troyano para la plataforma móvil Android con ciertas características similares a las encontradas en el malware asociado a botnets.
La primera observación fue efectuada por la empresa china de seguridad NetQin. A principios de diciembre ya se publicó una noticia en CNETNews China sobre este malware alertando de su existencia.
El ejemplar, estudiado por investigadores de la empresa LookOut, es más sofisticado de lo habitual ya que permite una vez instalado en el dispositivo de la víctima recibir comandos desde un servidor
remoto de control.
El resto de características presenta los puntos comunes y esperables en este tipo de malware: El troyano va insertado en aplicaciones reempaquetadas y que presentan un aspecto "sano", descargables desde páginas chinas de aplicaciones para Android.
De hecho, el ejemplar, en principio solo afecta al público chino. Tras la instalación y la solicitud al usuario de los permisos y excepciones de seguridad, el ejemplar se dedica a recabar datos sobre el terminal como el IMEI, el IMSI (número de identificación de la SIM) o la geolocalización del usuario entre otros. También reseñar que el troyano puede desinstalar e instalar aplicaciones, aunque para ello necesite el
permiso del usuario.
Geinimi viene con una lista de unos diez dominios preconfigurados a los que interroga cada 5 minutos. Si uno de ellos responde el troyano envía los datos capturados al servidor.
El bytecode de Geinimi está ofuscado y partes de la comunicación entre el troyano y el servidor de control se envía y recibe cifrada como medio de defensa frente a análisis.
Más información:
La primera observación fue efectuada por la empresa china de seguridad NetQin. A principios de diciembre ya se publicó una noticia en CNETNews China sobre este malware alertando de su existencia.
El ejemplar, estudiado por investigadores de la empresa LookOut, es más sofisticado de lo habitual ya que permite una vez instalado en el dispositivo de la víctima recibir comandos desde un servidor
remoto de control.
El resto de características presenta los puntos comunes y esperables en este tipo de malware: El troyano va insertado en aplicaciones reempaquetadas y que presentan un aspecto "sano", descargables desde páginas chinas de aplicaciones para Android.
De hecho, el ejemplar, en principio solo afecta al público chino. Tras la instalación y la solicitud al usuario de los permisos y excepciones de seguridad, el ejemplar se dedica a recabar datos sobre el terminal como el IMEI, el IMSI (número de identificación de la SIM) o la geolocalización del usuario entre otros. También reseñar que el troyano puede desinstalar e instalar aplicaciones, aunque para ello necesite el
permiso del usuario.
Geinimi viene con una lista de unos diez dominios preconfigurados a los que interroga cada 5 minutos. Si uno de ellos responde el troyano envía los datos capturados al servidor.
El bytecode de Geinimi está ofuscado y partes de la comunicación entre el troyano y el servidor de control se envía y recibe cifrada como medio de defensa frente a análisis.
Más información:
Security Alert: Geinimi, Sophisticated New Android Trojan Found in WildThe Official Lookout Blog | Security Alert: Geinimi, Sophisticated New Android Trojan Found in Wild
Suscribirse a:
Entradas (Atom)
About Me
- Tony Orozco
- Mmmm, pues bien soy honesto a veces demasiado, sencillo, sincero, amo la vida y la vivo a cada instante y al limite