Feeds:
Entradas
Comentarios

Posts Tagged ‘amenazas’

Nuestros amigos de Hispasec, avisan a los usuarios de Apple que ha desaparecido la presunta “calma” que habían dejado los chicos malos a su sistema.  De hecho, comunican que les han “Troyanizado”…  Veamos en su integridad como anda la cuestión:

——————————————————————-
Hispasec – una-al-día 16/10/2011
Todos los días una noticia de seguridad
www.hispasec.com
Síguenos en Twitter: http://twitter.com/unaaldia
——————————————————————-
Primer troyano para MAC que detecta la virtualización
—————————————————–
Desde el blog de F-Secure alertan de la aparición del primer troyano para Mac que detecta si está siendo ejecutado en una máquina virtual, para así alterar su comportamiento y evitar ser analizado. El hecho de que el malware compruebe si se está ejecutando en un entorno de virtualización no es nada nuevo. Es una
técnica que viene siendo utilizada desde hace años por gran cantidad de malware. Esto tiene un claro objetivo: los que analizamos malware solemos ejecutarlo en un entorno virtual, que permite aislar los efectos y poder volver rápidamente a un entorno “limpio” restaurando a un estado anterior. Existen infinitas técnicas para comprobar si se está en una máquina virtual, y se ha convertido casi en un arte: buscar procesos característicos, ficheros, drivers que suelen venir en los virtualizadores más populares… Los troyanos realizan una comprobación nada más
ser ejecutados y, si los detectan, no continúan. Los analistas debemos entonces o bien pasar a un entorno físico, intentar conocer qué buscan e intentar engañarlos, o bien utilizar software de virtualización menos popular (evitar VirtualBox o VMWare). También el malware utiliza la detección de máquinas virtuales para eludir los análisis automáticos que suelen realizar sandboxes públicas que se encuentran automatizadas. Si bien es un método antiguo, sí es cierto que es la primera vez que se observa este tipo de comportamiento en malware destinado al sistema operativo de Apple. Como viene siendo habitual, los avances técnicos de los creadores de malware suelen estar enfocados hacia evitar a los analistas “manuales”. De entre sus “enemigos”, son los más “peligrosos”
para ellos. Desde luego, el usuario final no le supone tanto problema por ahora. Con la ingeniería social le basta y no le hacen falta artificios técnicos. En el caso de Mac, su enemigo más fuerte tampoco son los antivirus ni necesita esforzarse demasiado por
eludirlos. La muestra analizada por F-Secure en concreto, se hacía pasar por una actualización de Adobe Flash Player, y en caso de detectar que está siendo ejecutando sobre una máquina virtual, detiene por completo su ejecución. Por el momento, la única máquina virtual que sobre la que se comprueba si está corriendo es VMWare. Existen numerosos métodos para comprobar si se está en un entorno virtual. Se puede encontrar información en la propia página de VMWare, con sus pros y sus contras:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
En este caso en concreto no se utiliza ninguna de las técnicas descritas en la web de VMWare, muy posiblemente porque no funcionan en el 100% de los casos. Este troyano en cuestión recurre a un método descubierto por el investigador Ken Kato, que consiste en
interactuar con un puerto de Entrada/Salida (puerto ‘VX’) que no debería existir en un entorno no virtualizado, puesto que es utilizado por la máquina huésped para comunicarse con la máquina virtual.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/4740/comentar

Más información:
Mac Trojan Flashback.B Checks for VM http://www.f-secure.com/weblog/archives/00002251.html
Sergio de los Santos ssantos@hispasec.com

¡¡Maligno saludos!!

Read Full Post »

Je, je los chicos del Grupo de Delitos Tecnológicos de la Guardia Civil, advierten que están llegando mensajes de correos reclamando facturas falsas, más información en este enlace.

Por otro lado, tener cuidado con las cuentas de correo electrónico de Hotmail, están empezando a llegar mensajes de cuentas de correo de nuestros amigos en Hotmail, no abráis, comentárselo a vuestra/os corresponsales y decirles que cambien de password de correo con frecuencia.

Por otro lado, vigilar las actualizaciones de Microsoft Windows 7, puede ocasionar problemas.  Menos mal, que los chicos de Redmond han previsto en los arranques a prueba de fallo la posibilidad (o mecanismo) de hacer rollback (anulación) de la actualización…

¡¡Malignos saludos!!

Read Full Post »

Los chicos de Symantec (leída a través de Hispasec) 😉 comunican que han descubierto una técnica de secuestro de sistemas Android, en esta dirección de Symantec, esta la referencia completa pero en inglés …

En resumen, viene a ser algo así como lo que pego a continuación:

La técnica descubierta en Android es similar a este “DLL Hijacking” y
tampoco es un problema específico del sistema operativo, sino de si la
aplicación gestiona incorrectamente la procedencia de sus dependencias.
Así, para aprovecharla, sería necesario encontrar una aplicación
vulnerable instalada en el teléfono y hacer que cargue librerías o
plugins del atacante en vez de los suyos legítimos. Para ello, primero
estas librerías deben estar localizadas en un punto donde todos puedan
escribir para que sean reemplazadas. Por ejemplo, la tarjeta SD del
teléfono.

Android ofrece dos clases, DexClassLoader y PathClassLoader para cargar
código dinámicamente. La primera API optimiza un código y devuelve el
resultado en la variable dexOutputDir, que muchos desarrolladores e
incluso documentación de Android, definen como la tarjeta SD. En ella
puede escribir cualquiera. Así que un atacante simplemente tendría que
reemplazar ese código, y la aplicación lo cargaría creyendo que es el
suyo. El atacante heredaría sus permisos.

PathClassLoader tiene un problema parecido con su parámetro libPath.
Android irá a buscar librerías de sistema donde diga este valor, y
muchos programadores lo establecen a la ruta de la tarjeta SD. Sin
embargo esto no funcionará en ningún caso, puesto que se monta por
defecto con permisos de no ejecución. Lo curioso es que se han
encontrado varias aplicaciones en el Marketplace que lo intentan.

Lo ideal entonces, es que el desarrollador se preocupe de que todos los
archivos son emplazados y cargados desde lugares seguros, (nunca la
tarjeta SD). Desde Symantec han contactado con Google para que al menos,
en la documentación oficial, se mencione este potencial problema.

¿Y qué es eso del DLL HIJACKING?  Viene a ser una “malformación” o “falta de escritura”  de la llamada a una librería.  Una descripción bastante buena esta en este enlace.

Huy, que mal rolloooooo!!!  ¿Y por qué?  Bueno, en principio, no informan de que desde la tienda de aplicaciones de Android, controlen estos programas mal formados, y además, no tiene una solución inmediata, podría pensar en una sand-box, pero hay que probar una a una cada aplicación y eso lleva tiempo.  Habrá que esperar la evolución de esta situación para ver porque solución se opta para solventar esta situación.

¡¡Malignos saludos!!

Read Full Post »

Ejem, para mi vergüenza, llevo varios meses sin escribir nada, la vida que la he llevado muy liada 😉  Bueno al lío.  Hoy he leído en los chicos de Hispasec, sobre la influencia de los “chicos malos” en la evolución de los aspectos de seguridad de los fabricantes de software.

Se titula “Lulzsec: la botella medio llena” y muestra como los fabricantes cambian sus comportamientos a base de “empentones”/sustos. Cito un párrafo tal cual está y da auténtico miedo:

“El mayor argumento en contra de LulzSec sugiere que vamos a traer a Internet más leyes si continuamos con nuestras travesuras, y que nuestras acciones hacen que payasos con plumas escriban reglas para ti. Pero ¿y si no hubiésemos publicado nada? ¿Y si nos mantuviésemos en silencio? Eso significaría que estaríamos secretamente dentro de empresas afiliadas al FBI ahora mismo, dentro de PBS, de Sony… vigilando y abusando.”

“¿Crees que cada hacker anuncia todo lo que ha hackeado? Sin duda nosotros no lo hemos hecho, y estamos condenadamente seguros de que otros “juegan” en silencio. ¿Os sentís seguros con vuestras cuentas de Facebook, de Gmail, de Skype? ¿Qué os hace pensar que un hacker no está sentado ahora mismo dentro de esas cuentas ahora, vendiendo datos? Eres un peón para esa gente. Un juguete. Una cadena de caracteres con un valor.”

“De esto es de lo que tendrías que tener miedo, no de nosotros publicando cosas, sino del hecho de que alguien lo haga público.”

Espero que esto os de que pensar…

¡Malignos saludos!

Read Full Post »

Unos cuántos de ellos.Parafraseando a mi compañero Jokin, “tengo miedoooo”. Los chicos de Hispasec han participado en un estudio que se encuentra haciendo clic en el enlace, y que muestra o advierte de los riesgos de seguridad que tiene la proliferación de smarphones, da igual la marca..

Como ideas principales, propone:

  1. La popularización de smartphones:  Todo el mundo tiene acceso fácil a uno de estos telefónos.
  2. Limitada concienciación de los usuarios en torno a la seguridad de sus sistemas.
  3. Por último, recomienda una serie de buenas prácticas para usar de forma segura estos nuevos sistemas.

Leerlo con detenimiento, y ¡malignos saludos!

Read Full Post »

Copio literalmente este aviso de la Guardia Civil, para avisar a mis lectores de que hay que ser cuidadoso con estas cuestiones…Una vez, los chicos de la GC, velan por nosotros 😉 

IMPORTANTE, smshing de tarjetas visa.

19-01-2011.- Acaba de lanzarse una importante campaña de “smshing”, “esmishing”, o como queramos llamarlo. ¿Y eso que es lo que es? Pues otro intento de captura de datos y contraseñas de nuestras tarjetas de crédito a través de un SMS o mensaje de telefonía.

De repente recibimos un SMS que dice ¡IMPORTANTE! Nuestra tarjeta visa ha sido comprometida y por ello bloqueada. Si queremos desbloquearla debemos acceder a una web. Si accedemos a la web nos pedirán el número de tarjeta, la fecha de caducidad, el nombre del titular, la entidad emisora, el cv2 y el PIN.

Lo de siempre, envío masivo desde una plataforma de envío de mensajes a un rango de numeración muy amplio. Estadísticamente, alguno será víctima del engaño y dará sus datos.
¡Qué nadie se deje engañar! Ni los bancos ni las entidades gestoras de tarjetas se dirigen a sus clientes por email ni por SMS, para asuntos de seguridad de sus cuentas o tarjetas. ¡A ver si logramos que el esfuerzo de los phishers, esta vez, sea baldío!
Lo de siempre, os esperamos en GDT. Entre todos haremos una red más segura.

Read Full Post »

Hoy me ha llegado un mensaje procedente de Hispasec (una-al-día) que me ha sacado del mundo de las películas o series de ciencia ficción y me ha traído al mundo real.  Habla de un rootkit que ha sido bautizado como Stuxnet. En el mensaje, se comenta el “posible origen” del bichito y cual es el uso.

¿Mi opinión?  Acabamos de entrar en un nuevo ámbito de la guerra donde no sólo interesa causar heridos o bajas, arruinar la infraestructura del enemigo, sino además, usar las comunicaciones para paralizar y atacar lugares delicados del contrario.  Se producirán daños colaterales, porque soltar a las redes semejantes bichos, aunque sea sobre un objetivo, siempre acaba rebotando y apareciendo en otros lugares.  Pone extremadamente nervioso, en el mundo de lo digital con que facilidad se puede conseguir atacar, conseguir o parar los recursos electrónicos de otra gente.

Os pego el mensaje y dejo al amable lector  que se forme su opinión:

-------------------------------------------------------------------
  Hispasec - una-al-día                                  15/01/2011
  Todos los días una noticia de seguridad          www.hispasec.com
 -------------------------------------------------------------------

 Según el New York Times, Stuxnet fue creado por el gobierno de
 Estados Unidos 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. 

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/4466/comentar

Más información:

Israel y EEUU crearon el virus que dañó el programa nuclear iraní
http://www.elmundo.es/elmundo/2011/01/16/internacional/1295180388.html

Éxitos y fracasos de Stuxnet (I)
http://www.hispasec.com/unaaldia/4382

Éxitos y fracasos de Stuxnet (II)
http://www.hispasec.com/unaaldia/4383

Éxitos y fracasos de Stuxnet (y III)
http://www.hispasec.com/unaaldia/4384

Sergio de los Santos
ssantos@hispasec.com

¡¡Asustados saludos!!

Read Full Post »

Older Posts »