Operaciones Policiales contra el fraude con tarjetas de crédito

Categorias: Botnets,Troyanos | | Sin comentarios » |

Junio ha sido un mes provechoso para las fuerzas de seguridad en su lucha contra el fraude con tarjetas de crédito. Durante este mes se han llevado operaciones policiales tanto en Estados Unidos como en Rusia que han permitido desarticular varias de las mayores redes de robo de tarjetas de crédito a nivel mundial.

Englobado dentro de la Operación “Carderprofit”, el FBI ha conseguido detener a 26 sospechosos de traficar con tarjetas de crédito robadas. Esta operación ha tenido una duración de 2 años y se calcula que ha generado unas pérdidas de 205 millones de dólares. Entre los detenidos se encuentran 11 personas residentes en Estados Unidos, mientras que el resto se reparte en diversos países como Japón, Noruega o Australia.

Entre los detenidos se encuentra “JoshTheGod”, un miembro del grupo de hacking UGNazi al que se le ha encontrado en posesión de los datos de más de 50.000 números de tarjetas de crédito. Este grupo se ha dado a conocer en las últimas semanas por varios ataques a empresas y filtraciones de datos.

Durante este mes también se han producido detenciones en Rusia de personas que realizaban acciones fraudulentas con tarjetas robadas. A principios de mes se detuvieron a 6 personas acusadas de haber robado 125 millones de rublos (alrededor de 3 millones de euros) usando variantes de malware, entre las que se encontraba Carberp.

Este tipo de operaciones contra estos grupos de delincuentes son frecuentes en Rusia e incluso se informa con vídeos de las detenciones. A pesar de existir una gran variedad de troyanos bancarios, Carberp es especialmente dominante en esta región, aunque en España tampoco nos libramos de sus efectos y, durante 2011, nos encontramos entre los tres primeros países con más infecciones por Carberp.

Hace apenas unos días, las autoridades rusas anunciaban la detención de un individuo sospechoso de estar detrás de una botnet encargada de recopilar datos bancarios. Se calcula que a través de esta botnet consiguió robar alrededor de 4.5 millones de dólares de usuarios infectados.

Se especula con que el detenido, de tan solo 22 años, consiguió infectar a un número considerable de usuarios con variantes modificadas del troyano Carberp, número que algunas fuentes sitúan en un máximo de 6 millones, estando 4.5 millones de estas infecciones activas en el momento de procederse a la detención.

Estas acciones policiales están orientadas a terminar con las grandes redes de fraude con tarjetas de crédito, pero existen miles de otros delincuentes que operan a menor escala y que resultan más difíciles de perseguir. Pero, ¿cómo consigue un futuro ciberdelincuente todo el material para poder robar tarjetas de crédito y traficar con ellas?

La realidad es que es mucho más simple de lo que uno se podría imaginar. Con tan solo buscar un poco de información sobre cómo cometer este tipo de delitos, uno puede encontrarse con multitud de foros donde explican de qué manera obtener muestras del malware usado como troyano bancario, e incluso con servicios de soporte técnico 24 horas por un módico precio extra.

Asimismo, se pueden obtener packs de números de tarjeta con su correspondiente PIN por una cantidad razonable, y así poder realizar compras online o clonar tarjetas usando material fácilmente asequible. No es difícil conseguir, por ejemplo, clonadores de tarjetas de todos los modelos y precios buscando un poco entre estos foros.

No obstante esta facilidad, los aprendices de ciberdelincuentes también pueden ser estafados por aquellos que dicen ayudarles a cometer sus delitos online e incluso algunos grupos de hacktivistas proporcionan información de estas actividades a las autoridades para que tomen cartas en el asunto y detengan a los delincuentes.

Que el cibercrimen deja mucho dinero, y que algunas fuentes calculan en decenas de miles de millones de euros, es algo conocido. No es de extrañar que mucha gente se sienta atraída por esta forma ilícita de hacer dinero, más con los tiempos de crisis que corren. No obstante, las fuerzas policiales tienen equipos de actuación específica contra este tipo de delitos, por lo que cada vez quedan menos impunes, incluso en aquellos países como Rusia que hasta hace poco contaban con una legislación más permisiva con este tipo de delitos.

Desde el laboratorio de ESET en Ontinet.com seguimos vigilando y colaborando con las autoridades para terminar con estas actividades que causan tanto daño a nuestra economía, sobre todo porque la mayoría de afectados son usuarios particulares que ven cómo se roba impunemente el dinero que tanto les ha costado ganar.

Josep Albors
@JosepAlbors



El Gobierno español asume la Directiva Europea 2009/136/CE que regula la privacidad en la Red

Categorias: Privacidad | | Sin comentarios » |

Finalmente, y aunque con 10 meses de retraso, el Gobierno español ha asumido, el pasado 30 de marzo, la Directiva Europea 2009/136/CE que regula la privacidad en Internet, sobre todo en lo que se refiere a las cookies. Así, tras su adopción, ha quedado plasmada en el artículo 22.2 de la Ley 34/2002 de Servicios de la Sociedad de la Información y Comercio Electrónico.

Básicamente, y a modo de resumen, el nuevo texto comunitario obliga a los portales, productos y servicios de Internet a informar del uso que harán con la información que recaban utilizando cookies, dejando de esta manera libertad a los usuarios de consentir o no la recopilación de dicha información y su posterior tratamiento. Hasta aquí, genial. Pero… (siempre hay un pero) lo que no establece la Directiva ni el texto incluido en la Ley 34/2002 es cuál es el procedimiento que se ha de seguir. Esto ha propiciado que cada país haya adaptado la norma de diferente manera.

El Ejecutivo español se ha mostrado contrario a establecer e implementar mecanismos de control por vía legal para asegurarse del cumplimiento de esta manera, por lo que apuesta por el código de autorregulación de las empresas. Es decir, delega esta responsabilidad en las diferentes compañías para no frenar el desarrollo de Internet, hecho muy positivo si no fuera porque ya nos conocemos todos.

Según Salvador Soriano, el coordinador del área de la Secretaría de Estado de las Telecomunicaciones, “la Directiva europea obliga a proteger a los usuarios finales pero no expresa cómo. Así que no sabemos cuáles son las medidas que se suponen que cumplen con estos principios en la práctica”, y añade: “el Gobierno no debería legislar respecto a esta cuestión porque sería encorsetar el desarrollo de la industria de Internet, por lo que los códigos de autorregulación juegan aquí un gran papel”.

ESET España Privacidad en Redes Sociales

Evidentemente, esta medida está causando un clima de crispación en la Red debido a varios y diversos motivos. Por un lado, se entiende que afecta a empresas españolas, pero no queda claro si afectaría también a empresas internacionales que operan en España, o en cualquier otro país de la Unión Europea. Dado que cada uno estamos adaptando la Directiva a nuestra manera, las empresas multinacionales con operaciones en varios países se verían con el reto de implementar un sistema diferente en cada territorio nacional con el fin de adaptarse a las exigencias locales.

Por otro lado, el informar a los usuarios del uso que se le va a dar a su información, por un lado, y facilitar la tarea de elegir si quieren ser rastreados o no, también genera una cierta incomodidad entre empresas operativas en la actualidad, start-ups y los llamados “business angels” o inversores. El mayor negocio de la Red ha sido, es y seguirá siendo el de los datos personales. Cuanto más fácil les pongamos a los usuarios el elegir -algo que es de sentido común-, más pondremos en riesgo la cantidad de información que las empresas recopilan, pudiendo verse impactado su valor de cara al mercado.

De nuevo asistimos a un escenario donde los responsables que deben legislar y establecer las pautas de comportamiento no lo hacen; por un lado, los usuarios o no saben que se está recopilando su información (en la mayoría de las ocasiones) o claman por su libertad de elección, y por otro las empresas y los anunciantes que defienden “a capa y espada” su principal valor, que es la información personal. En fin, una tarta difícil de digerir.

Esperamos que entre unos y otros se logre un consenso común y al gusto de todos en el que, por encima de otras razones económicas, prime el derecho a la libertad de elección de los internautas y a su derecho a la privacidad.

Yolanda Ruiz Hervás

@yolandaruiz



Win32/Sirefef: evolución de un molesto malware

Categorias: Informes,Malware | | 8 Comentarios » |

Entre las amenazas más persistentes detectadas por las soluciones de seguridad de ESET se encuentra el malware Win32/Sirefef. Son ya varios los meses en los que esta amenaza se ha colado entre el Top 10 de las más detectadas y uno de los motivos es la actualización constante a la que los creadores de esta amenaza la someten. Para analizar las últimas modificaciones de este malware hemos procedido a adaptar el siguiente análisis de nuestro compañero Aleksandr Matrosov.

A finales de la primavera de 2012, la familia de rootkits Win32/Sirefef y Win64/Sirefef (también conocidos como ZeroAccess) se actualizaron. Empezamos a observar las primeras muestras actualizadas a principios de mayo, cuando empezó un nuevo programa de afiliación para distribuir una nueva versión de ZeroAccess. La versión actualizada de Sirefef no utiliza drivers en modo de kernel, tal y como hacía previamente, y tampoco tiene un almacén de ficheros ocultos. El programa de afiliación sustituye los resultados de los motores de búsqueda por los suyos propios para así obtener beneficios.

 

Según se comenta en el mensaje del foro verified.ms que vemos arriba, las regiones más interesantes para instalar esta nueva variante de ZeroAccess son los Estados Unidos, Australia, Canadá y el Reino Unido. El precio por instalar esta amenaza en 1.000 máquinas de los Estados Unidos es de 500$. También hay un precio especial por instalaciones activas en una máquina infectada, dependiendo de los privilegios del sistema.

 

El panel de administración para el nuevo programa de afiliación usado para distribuir la nueva versión de ZeroAccess luce tal que así:

 

En el centro de mando y control (C&C) hay un apartado especial que revisa la detección por parte de los antivirus tras una actualización del malware.


Técnicas para inyectar código

En su versión anterior, ZeroAccess usaba un driver en modo kernel para acceder a un almacén de ficheros ocultos y para proteger componentes usando técnicas de autodefensa. En la versión más reciente, los desarrolladores de ZeroAccess han rechazado el uso de componentes en modo kernel y han encontrado técnicas interesantes para la inyección de código.

 A continuación explicamos cómo funciona la técnica de inyección de código:

  1. En el primer paso se extrae la shellcode (x86 o x64 dependiendo de la plataforma) de un archivo cab almacenado en el lanzador del malware (dropper).

 

2. Se crea una carpeta oculta del sistema, donde el nombre que se le asigne depende de la técnica usada por el inyector de código (anteriormente ZeroAccess usó el almacenamiento de ficheros ocultos como un método de almacenar sus componentes):

  • “%USERPROFILE%\Local Settings\Application Data\
  • “%WINDOWS%\Installer\

3. En el siguiente paso, el shellcode se inyecta en services.exe (gestor de control de servicios):

  • El gráfico de la llamada al shellcode inyectado es así:

 

  • La función para inyectar código en services.exe tiene esta apariencia en pseudocódigo:

 

4. En esta versión de ZeroAccess se usan dos técnicas de inyección de código:

  • El primer método usa una técnica con ZwOpenThread()/ZwOpenProcess(), con una modificación directa de la memoria y ZwQueueApcThread(), usada para sistemas x86 o si otro método devuelve un mal estado.
  • El segundo método se usa en sistemas x64 para proporcionar modificaciones en el archivo de gestión del control de servicios al descriptor de seguridad en el archivo services.exe.

 

En el siguiente paso de la inyección de código en el fichero services.exe, se crea un objeto de sección llamando a ZwCreateSection() y se copian los contenidos del fichero dentro de esta sección. Luego el lanzador del malware escribe en shellcode para remplazar la función ScRegisterTCPEndpoint() original y elimina la bandera de soporte ASLR desde una cabecera PE (la razón para realizar esta acción es hacer el shellcode más estable con unas direcciones de funciones preestablecidas).

 Alguna de las últimas modificaciones a ZeroAccess realizan pasos adicionales modificando services.exe: manipulaciones de la sección de reubicación (.reloc) y la creación de un callback TLS (almacenamiento local de hilos) a services.exe (ZeroAccess – From Rootkit to Nasty Infection).

 5. El punto final es la creación de un nuevo fichero con el mismo nombre (services.exe) pero que ha sido previamente modificado para atender las necesidades del atacante. Se crea un nuevo fichero por la función ZwCreateFile() y se rellenan los parámetros de los atributos del NTFS extendido desde el búfer con el código de la librería dll maliciosa.

 El módulo con el código malicioso no se almacena directamente en el fichero services.exe, sino que se carga al utilizar de forma incorrecta ciertas características de NTFS. La información básica también se copia desde el fichero original (fecha de su creación, última vez a la que se accedió, última vez en la que se escribió, fecha de su último cambio y atributos del fichero). El shellcode inyectado en el paso 3 busca un atributo extendido con el nombre “731” usando la función ZwQueryEaFile() y arranca el código malicioso al ejecutarse. La siguiente capa del shellcode busca el origen de modulo de la dll maliciosa, prepara el punto de entrada y lo ejecuta. El gráfico de llamadas de la shellcode inyectada sería así:

 

Las soluciones de seguridad de ESET detectan las modificaciones en los procesos del sistema services.exe como Win64/Patched.B.Gen. El proceso services.exe modificado de acuerdo al programa BinDiff se muestra en el siguiente gráfico:

 

El proceso services.exe antes (izquierda) y después (derecha) de las modificaciones maliciosas.

 

ScRegisterTCPEndpointbefore() antes de las modificaciones (arriba) y después de las modificaciones (abajo).

 Estadísticas de detección

Las estadísticas de detección por región, desde principios de año, son las siguientes (según la información recopilada por la tecnología ESET LiveGrid®):

[Detecciones de Win64/Sirefef por región]

 

[Detecciones de Win32/Sirefef por región]

 Después de que el desarrollador de ZeroAccess cambiase las tácticas de infección y dejara de usar componentes en modo kernel en última versión, hemos seguido el crecimiento de las infecciones para x64.

  Las estadísticas de detección de Win32/Sirefef y Win64/Sirefef son las siguientes:

 

ZeroAccess muestra cómo los desarrolladores de rootkits buscan otros métodos de distribución y encuentran interesante el uso de técnicas para infectar el sistema en modo usuario. Ya hemos hablado largo y tendido sobre el tema (Amenazas bootkit: análisis a fondo de ingeniería inversa y defensa) de la ingeniería inversa de bootkits en la reciente conferencia REcon celebrada en Montreal, pero hay más de un camino para el malware complejo para funcionar en sistemas x64, tal y como demuestran las últimas muestras de ZeroAccess.

 Josep Albors

@JosepAlbors



Cómo opera la red de ciberespionaje Medre que roba ficheros de AUTOCAD [infografía]

Categorias: Espionaje,Herramientas,Infografías | | Sin comentarios » |

Hace poco os informábamos a través de este blog de ACAD/Medre.A, un gusano que podría ser la punta del iceberg de un supuesto caso de espionaje industrial con un objetivo muy claro: robar ficheros de AUTOCAD de países de habla hispana y enviarlos a direcciones chinas. Todos los detalles los encontráis en el post técnico, pero para facilitar la comprensión de cómo opera este gusano, os dejamos una infografía donde se describe todo el proceso.

Recordad que si sois usuarios de AUTOCAD y queréis estar seguros de que Medre no os ha afectado, hemos puesto a vuestra disposición una herramienta gratuita que detecta la amenaza y la neutraliza de forma automática.

ESET España - Operación Medre - Modus operandi del espionaje industrial

 

Seminario online informativo y gratuito

Nuestros compañeros de ESET Latinoamérica van a ofrecer gratuitamente un seminario online informativo y gratuito sobre Medre y contestarán a todas las preguntas que los asistentes pudieran tener al respecto de este ciberataque y sus consecuencias. Si estás interesado, serás bienvenido. La cita es el próximo jueves, 28 de junio, a las 21,00 horas (hora española) y 16,00 horas (hora de Buenos Aires).

Yolanda Ruiz Hervás

@yolandaruiz



Vuelve nuestro ¿héroe? Cálico Electrónico fiel a su cita semanal

Categorias: Cálico Electrónico | | Sin comentarios » |

Poco a poco nos vamos acostumbrando a él, pero afortunadamente no pierde la capacidad de sorprendernos cada día más. En esta entrega, como veis más abajo, Cálico no cesa en su empeño de ser un auténtico héroe, pero… o bien todavía no domina mucho las prácticas del curso de “Spanish Super Jirou” o el curso es muy “maluno”. Sea como fuere, ¡gracias por hacernos sonreír!

ESET España - Tira cómica Cálico Electrónico

¡Feliz martes!

Josep Albors

@josepalbors

Yolanda Ruiz Hervás

@yolandaruiz

 



Lanzamos nuevos productos: ESET Mail Security para Lotus Domino y ESET File Security para Windows Server Core

Categorias: Herramientas,Productos | | Sin comentarios » |

Hoy estamos de estreno, ya que lanzamos las  nuevos productos para servidor: ESET Mail Security para IBM Lotus Domino y ESET File Security para Microsoft Windows Server Core.

ESET Mail Security es una potente solución que ofrece protección sin sobrecargar los sistemas en servidores de correo electrónico con alta carga basados en IBM Lotus Domino. Gracias a la completa protección contra cualquier tipo de amenaza procedente del correo electrónico, ESET Mail Security para IBM Lotus Domino ofrece una alta precisión a la hora de gestionar la seguridad del tráfico en servidores corporativos de correo.

ESET Mail Security para IBM Lotus Domino es compatible con ESET Remote Administrator y soporta Lotus Domino Partitions. La solución excluye automáticamente archivos críticos del servidor a  la hora de realizar los chequeos.

Además, incluye como características clave:

  • Antivirus y antispyware: elimina cualquier tipo de amenaza, incluyendo virus, rootkits, gusanos y spyare. Protege a las pasarelas de email en los niveles SMTP y NRPC y escanea de forma regular todos los datos almacenados en Domino Server. La solución integra todas las herramientas para una protección global del servidor, incluyendo un escudo residente y un motor de exploración bajo demanda.
  • Antispam: retiene mensajes de phishing y spam de forma efectiva. La configuración del motor antispam se puede realizar desde una interfaz muy intuitiva.
  • Estadísticas y logs: mantiene al usuario al corriente de la situación del sistema con logs y estadísticas completas y detalladas que incluyen logs de spam y listas grises.

Y como estamos de novedades, hemos pensado aprovechar para lanzar también la nueva versión de ESET File Security para Microsoft Windows Server Core, que ofrece antivirus, antispyware, protección multiplataforma y gestión centralizada compatible con ESET Remote Administrator, ESET SysInspector y ESET SysRescue.

Ambas soluciones están disponibles para su prueba solicitándolas a través de la  web de ESET España.

Yolanda Ruiz Hervás

@yolandaruiz



Medre, un posible caso de espionaje industrial

Categorias: Espionaje,Filtraciones | | Sin comentarios » |

De un tiempo a esta parte, las noticias relacionadas con ataques dirigidos o robo de información a empresas o Gobiernos se han vuelto algo más frecuentes de lo que muchos desearíamos. En ESET somos conscientes de la preocupación que este tipo de noticias despierta y nuestros equipos de investigación realizan una gran labor detectando nuevas amenazas como la que analizamos a continuación y que ofrecemos una descripción más detallada en un documento preparado para la ocasión. Revisando nuestro sistema LiveGrid® observamos cómo Medre, un gusano escrito en AutoLISP (el mismo lenguaje que utiliza la aplicación AutoCAD) tenía una alta tasa de detección en Perú.

Este pico de infecciones no es nada habitual, así que decidimos investigar en qué otros países se detectaba esta amenaza de forma significativa. No nos sorprendimos al encontrar que otros países limítrofes con Perú o de habla hispana también habían experimentado un crecimiento en la detección de esta amenaza (aunque a un nivel mucho menor que Perú). El único país que no seguía esta pauta era China, aunque no sería ninguna sorpresa una vez nos pusimos a analizar este malware.

Pero, ¿por qué Perú parecía ser el objetivo principal? Al analizar los datos de ESET LiveGrid®, capaz no solo de detectar las infecciones activas sino también de detectar direcciones URL específicas, nos dimos cuenta de que un sitio web concreto estaba distribuyendo la plantilla de AutoCAD que parece ser la fuente para esta infección localizada, ya que estaba infectada con ACAD/Medre.A. Si consideramos que las empresas que quieren hacer negocios en esta región deben usar esta plantilla, tiene lógica que este malware apareciese principalmente en Perú y países limítrofes. Lo mismo para aquellas empresas que, aun no siendo de la región, hacen negocios a través de sus oficinas regionales.

Con respecto a la funcionalidad del malware, ACAD/Medre.A es capaz de infectar versiones de AutoCAD desde la 14.0 hasta la 19.2 mediante la utilización de un archivo con extensión FAS (archivos ejecutables en lenguaje AutoLISP), ubicado en la misma carpeta del proyecto. Cuando el usuario abre un proyecto de AutoCAD (.dwg), se ejecuta el archivo malicioso que, por un lado, modifica un archivo LSP ubicado en la carpeta del programa, para así seguir infectando cualquier otro proyecto que abra el usuario en el sistema. Posteriormente, se ejecuta un script en lenguaje Visual Basic (.vbs) que posee rutinas para enviar todos los proyectos que se abran en AutoCAD en el sistema infectado a cuentas de correo del atacante, más de 40 cuentas distribuidas en dos servicios de correo en China.

Los creadores de este malware han usado scripts en Visual Basic que se ejecutan utilizando el interprete Wscript.exe que está integrado en los sistemas operativos Windows desde Windows 2000. El autor asume que su código funcionará incluso en versiones futuras de AutoCAD, previstas para ser lanzadas en 2013, 2014 y 2015.

Tras una configuración inicial, ACAD/Medre.A empieza a enviar los diversos archivos de AutoCAD que son abiertos a una dirección de email perteneciente al proveedor de Internet chino 163.com. De hecho, los intentos de enviar los archivos robados se realizan usando 22 cuentas de correo en 163.com y otras 21 en qq.com, otro proveedor de servicios chino. Estos envíos se realizan accediendo a smtp.163.com y smtp.qq.com con diferentes datos de acceso. Normalmente se recomienda tener el puerto 25 abierto permitiendo el puerto saliente, por lo que no es de extrañar que tanto los usuarios que se han visto afectados en Perú y otras partes del mundo permitieran este envío de emails sin su consentimiento.

Además de enviar los archivos, este malware genera un fichero .rar protegido con contraseña, fichero que contiene los diseños, y los archivos acad.fas y .dxf. La contraseña usada solo tiene un carácter, siendo este el número “1”, lo cual nos trae recuerdos de otras amenazas como Win32/Bagle, que usaba la misma contraseña en los archivos .rar.

El archivo .dxf que se incluye en estos emails es generado por ACAD/Medre.A y contiene información que el receptor necesita para cargar el diseño robado en el sistema correcto y con el lenguaje correcto.

Todos aquellos interesados en conocer más a fondo el funcionamiento de ACAD/Medre.A pueden consultar la información publicada por nuestro compañero Robert Lipovsky y la descripción que hemos publicado en la Enciclopedia de Amenazas de ESET.

Cuando nuestros investigadores revisaron las cuentas de correo usadas por ACAD/Medre.A se dieron cuenta de que la bandeja de entrada estaba llena (cerca de 100.000 emails). Todos los mensajes en la bandeja de entrada contenían avisos de error al intentar entregar mensajes a un receptor que ya tenía la bandeja de entrada llena. Y eso sin contar los cerca de 5.000 mensajes que aún estaban por enviar.

 

Gracias a que la ruta y el nombre del fichero se encuentran en los adjuntos, pudimos realizar un análisis basándonos en la localización donde se almacenaban los diseños y su posible contenido. Nuestro análisis también muestra que muchos usuarios aúnutilizan una cuenta de administrador o almacenan sus diseños en el escritorio. En el siguiente gráfico podemos observar los nombres más frecuentes de los archivos robados:

Por los datos obtenidos del análisis de los emails usados podemos deducir la escala del ataque y concluir que decenas de miles de diseños AutoCAD fueron filtrados. Esto representa una elevada cantidad de datos filtrados y decidimos que debíamos pasar a la acción. Tras darnos cuenta de la magnitud del problema, ESET contactó con Tencent, propietarios del dominio qq.com. Gracias a la rápida intervención de Tencent, las cuentas usadas para renviar los correos con los diseños robados han sido bloqueadas y ya no se producirán más filtraciones. Desde estas líneas nos gustaría expresar nuestra gratitud a la división de seguridad corporativa de Tescent por su cooperación y su rápida reacción.

Asimismo, ESET también contactó con CVERC, el centro nacional de China de respuesta de emergencias relacionadas con malware, obteniendo una respuesta rápida de manos del subdirector de este organismo, que también ayudó a eliminar las cuentas de correo usadas para enviar los diseños robados.

Dentro de ACAD/Medre.A hay código que revisa la presencia de Foxmail u Outlook en sus versiones 11.0, 12.0 o 13.0. Si Outlook está presente, el gusano intenta enviar un archivo PST encontrado en el ordenador del receptor final en China vía los reenvíos de qq.com. Los archivos PST de Outlook contienen el correo, calendarios, contactos y otro tipo de información. Si es Foxmail la aplicación presente en el sistema, hay otra parte del código en ACAD/Medre.A diseñado para obtener y enviar la libreta de direcciones de Foxmail y la carpeta de elementos enviados, pero errores de esa parte del código hacen que esto no suceda.

Tras descubrir este malware, en ESET decidimos ofrecer una herramienta de limpieza para todos aquellos que la necesiten. Asimismo, también contactamos con Autodesk, fabricantes de AutoCAD, que se tomaron inmediatamente el asunto muy en serio y nos proporcionaron una completa asistencia.

ACAD/Medre.A es un serio ejemplo de un posible caso de espionaje industrial. Cada diseño nuevo es enviado de forma automática a los creadores de este malware. No hace falta decir que esto puede causarle grandes pérdidas al propietario del diseño original mientras que los cibercriminales tendrán en su poder estos diseños incluso antes de que pasen a producirse. Este ataque puede tener consecuencias tan graves como que los delincuentes patenten el diseño antes de que lo haga su creador original.

Si hay algo que resulta obvio por nuestra experiencia con este tipo de malware, es que contactar con diferentes organismos y empresas para minimizar el daño no solo es la mejor manera que actuar, sino que además funciona. Podríamos haber intentado solucionar este problema sin la ayuda de Autodesk, Tencent o el CVERC, centrándonos solamente en eliminar el malware de las máquinas infectadas. Trabajando codo con codo con estas empresas fuimos capaces no solo de alertar e informar a los usuarios, sino que también pudimos desmontar el sistema de envío de emails usados por los atacantes, negándoles el acceso a sus bandejas de entrada y minimizando el daño causado.

(Este texto ha sido adaptado a partir de la información publicada por nuestros compañeros de ESET Latinoamérica y Righard Zwienenberg, investigador senior de ESET, en el blog de ESET.com)

Josep Albors

@JosepAlbors

 



Cientos de sistemas Scada al descubierto

Categorias: Scada,seguridad | | Sin comentarios » |

Desde que Stuxnet sacara a la luz los ataques a los que se exponen las infraestructuras críticas hace ya dos años, no son pocas las noticias que hemos ido conociendo acerca de lo expuestos que se encuentran algunos de estos sistemas. El valor que tienen es innegable, ya que no hay algo más atractivo (y mediático) para un cibercriminal (o Gobierno) que atacar una infraestructura crítica, como demostró Stuxnet o, más recientemente, Flame.

La realidad es que estos sistemas están mucho más presentes de lo que mucha gente imagina. Desde sistemas domóticos de control de temperatura en oficinas, pasando por controles de temperatura de frigoríficos en grandes superficies hasta llegar a los sistemas que controlan la red eléctrica de un país, por ejemplo.

Es por ello que cada filtración o ataque a uno de estos sistemas debe ser analizado con cautela, y casos como la reciente publicación de más de 2000 direcciones IP con acceso a sistemas Scada deben darnos un toque de atención sobre si se protegen debidamente.

En esta ocasión, las víctimas parecen ser sistemas gobernados por el software i.Lon 100 Internet Server, encargado de conectar todo tipo de dispositivos a una red corporativa. Obviamente, el acceso a estos sistemas está protegido por un procedimiento que requiere login, tal y como cabría esperar:

No obstante, solo con que indaguemos un poco buscando manuales sobre este software encontraremos la contraseña que viene configurada por defecto y a partir de ahí la labor de un atacante se reduce a ver cuál de las múltiples direcciones IP filtradas viene con las contraseñas por defecto (más de las que esperaríamos encontrar). Una vez se ha obtenido acceso al sistema, ya solo queda ver qué tipo de dispositivo hay detrás y qué acciones se desean realizar.

Aunque para muchas personas pueda ser divertido acceder a los paneles de control de estos sistemas y modificar los valores que se muestran, hay que recordar que un mal uso de estos sistemas puede acarrear desde simples molestias a graves daños en instalaciones críticas. Por su parte, todas aquellas empresas que utilizan este tipo de sistemas, y especialmente quienes los fabrican, deberían revisar la seguridad de los mismos puesto que hace años que se ha comprobado como la “seguridad por oscuridad” es infectiva ante un grupo de atacantes decididos.

Josep Albors

@JosepAlbors



Reflexiones sobre la vulnerabilidad CVE2012-1889: MSXML

Categorias: General,Vulnerabilidades | | Sin comentarios » |

Nuestro compañero Aleksandr Matrosov, responsable del equipo de investigación y seguridad de ESET, ha estado siguiendo de cerca la evolución de la vulnerabilidad CVE2012-1889. A continuación ofrecemos una adaptación de sus conclusiones.

Tan pronto como Microsoft lanzó los parches de seguridad para el boletín de seguridad MS12-037 (que solucionaba 13 vulnerabilidades para Internet Explorer), Google publicó información (vulnerabilidad de Microsoft XML está siendo aprovechada) sobre una nueva vulnerabilidad zero-day (CVE-2012-1889) en Microsoft XML Core Services. A veces las vulnerabilidades se descubren a un ritmo que sobrepasa el proceso de parcheo, por lo que se necesita un arreglo temporal. Esto es lo que ha proporcionado Microsoft en esta ocasión: un parche temporal. Recomendamos encarecidamente que se instale este parche, puesto que ya estamos observando varios exploits que se aprovechan de esta vulnerabilidad.

Pero aún hay más: hace unos días, un exploit para la vulnerabilidad CVE-2012-1889 se hizo público a través de una publicación  en el repositorio de Metasploit Framework (nuevo exploit crítico Zero-day para Microsoft IE en Metasploit). Las soluciones de seguridad de ESET detectan esa vulnerabilidad como JS/Exploit.CVE-2012-1889. No obstante, es muy aconsejable instalar el parche si se está usando software vulnerable, tal y como se detalla en el documento informativo sobre seguridad de Microsoft (2719615).

Sobre los detalles técnicos: CVE-2012-1889 se aprovecha de problemas en la corrupción de memoria en Microsoft XML Core Services cuando se intenta acceder a un nodo XML que no ha sido inicializado, usando la llamada a la API get_definition, lo que puede causar corrupciones en la memoria y permitir la ejecución de código remoto. Este tipo de vulnerabilidad, conocida como Use-after-free, se encuentra de forma bastante frecuente en programas desarrollados en lenguajes C/C++.

Esta vulnerabilidad resulta fácil de aprovechar en todas las versiones conocidas de Internet Explorer. El atacante puede realizar una petición de identificación-CLSID llamando a métodos de librerías MSXML y crear un identificador de objetos para tratar de acceder a un objeto inexistente. Existe código como prueba de concepto que puede causar que un cuelgue del sistema se asemeje a lo siguiente:

Este código parece simple, pero genera corrupción de memoria y hace que falle Internet Explorer. El código intenta una petición a un objeto no iniciado, pero la referencia en la región de la memoria ya existe. La corrupción de la memoria sucede en la función de ayuda _dispatchImpl :: InvokeHelper() dentro de la librería MSXML. Es posible ejecutar código remoto tras iniciar la siguiente instrucción:

call    dword ptr [ecx+18h]

Así que si un atacante modifica los valores de la pila, este código transfiere el control al shellcode. Para poder modificar la pila los atacantes pueden usar técnicas de heap-spray que pueden resultar en un control del proceso de ejecución, tal y como se muestra en los siguientes pasos.

En la siguiente imagen se muestran todas las ejecuciones de la pila después de que Internet Explorer sufra el fallo.

En la pila, es posible averiguar el momento en el que el objeto del nodo XML se maneja.

En el siguiente paso de ejecución, la shellcode recibe el control y se ejecuta, y como resultado es posible realizar operaciones maliciosas en la máquina afectada.

Por supuesto, en Windows 7 o Vista los atacantes necesitan saltarse ASLR, DEP y otros mecanismos de seguridad incorporados en el sistema operativo. Pero en el laboratorio ya disponemos de varios ejemplos de exploits reales que pueden usar este mecanismo y no existe un método universal para detener a los atacantes en este momento. Lo que es peor, hay maneras en las que es posible para un exploit hacer uso de ficheros .DOC. Las versiones de Microsoft Office que se ven afectadas son la 2003/2007. Recomendamos encarecidamente instalar el parche temporal en el sistema para mitigar este vector de ataque.

La siguiente versión de Microsoft Internet Explorer incluirá una nueva revisión de seguridad para frames de la pila y mecanismos para mitigar ataques que transfieran control a direcciones de la shellco de (Protecciones de memoria mejoradas en IE10)

 Josep Albors

@JosepAlbors



¿Es Gandalf? No… pero es Cálico Electrónico

Categorias: Cálico Electrónico | | Sin comentarios » |

Aquí estamos de nuevo en nuestra cita semanal con el humor de Cálico Electrónico en forma de tira cómica. ¡¡¡Ya quisiera Cálico ser Gandalf!!!  Pero parece que o bien tiene que ensayar un poquito más o intentarlo con otro personaje. Sea como fuere, aquí os la dejamos para que sonriáis un poco, que falta nos hace a todos ;-).

ESET España - Tira Cálico Electrónico

¡Feliz jueves!

Josep Albors

@josepalbors

Yolanda Ruiz Hervás

@yolandaruiz

 



Artículos Anteriores »

Atención: nuestra página utiliza cookies Al utilizar nuestro sitio web, consiente nuestra política de uso.

Aceptar y ocultar este mensaje