Hace algunos días compartimos con ustedes información acerca de ciclo de vida una vulnerabilidad, de qué manera prevenirse ante este tipo de situaciones y cómo dar una respuesta eficiente. Sin embargo, hoy vamos a hablar acerca de la otra cara de la moneda: qué pasa cuando no se aplican los parches y de qué manera dos vulnerabilidades conocidas podrían afectar la seguridad de la empresa. En particular vamos a analizar cómo la combinación de una vulnerabilidad utilizada por Stuxnet (MS10-046) y otra implementada por Conficker (MS08-068) podría permitir el acceso remoto por parte de un atacante.

La primera de las vulnerabilidades, refiere a la explotación de los accesos directos de Windows (archivos con extensión LNK) y su fecha de publicación es del 2010. Sus efectos permiten que a través de un archivo LNK se pueda cargar y ejecutar una librería maliciosa (de manera local o remota) utilizando la ruta del ícono del acceso directo. Por otro lado, la segunda vulnerara, con más de tres años de antigüedad y ampliamente utilizada por Conficker para propagarse a través de una red infectada permite mediante una falla de seguridad en la autenticación del protocolo SMB.

Combinando ambas vulnerabilidades un atacante podría obtener el acceso a un sistema remoto sin la necesidad de obtener las claves del usuario. Un acceso directo, alojado en las carpetas compartidas forzarían a la ejecución del exploit de Stuxnet para obtener una sesión válida en la máquina de la víctima. Este ataque podría ser utilizado tanto de manera interna en la red como de manera remota, pero para el segundo caso la complejidad aumenta un poco más. El resultado de este ataque le permite al atacante obtener las credenciales de la persona que cae en el engaño y carga el acceso directo, el mayor impacto se logra cuando un usuario con permisos de administrador de la red accede a la carpeta compartida y se ejecutan los exploit.

Hay ciertas puntos que deben ser tenidos en cuenta acerca de este enfoque, el primero de ellos remarca la importancia de mantener el sistema actualizado con todos los parches de seguridad instalados. Años después de la publicación del parche que mitiga la vulnerabilidad utilizada por Conficker, todavía continúa entre los códigos maliciosos con mayor índice de detección. Además, confirma que no se deben utilizar usuarios con permisos de administrador, y que tales privilegios no  es una buena práctica. Para conocer más acerca de las buenas prácticas para la seguridad empresarial les recomendamos leer los 10 mandamientos de la seguridad de la información en la empresa.

Pablo Ramos
Especialista en Awareness & Research

Categories: Corporativo, Vulnerabilidades
1 Comment »

Esta semana se ha vuelto a hablar de esta amenaza que apareció el último mes y ha causado muchos comentarios en Internet. Esto se debe, mayoritariamente, al hecho de que muchos medios han vinculado Duqu fuertemente con Stuxnet, el famoso código malicioso que atacaba los equipamientos SCADA de Siemens y que causó estragos en muchos países, atacando desde sistemas industriales hasta plantas nucleares.

Según el Laboratorio de Criptografía y Sistemas de Seguridad de Budapest, Hungría (CrySyS); Duqu está explotando una vulnerabilidad 0-day en el kernel de Windows. Dicha vulnerabilidad ya ha sido reportada a Microsoft por parte del laboratorio de seguridad húngaro. Por su lado, Microsoft alegó estar en este momento trabajando para poder localizar y corregir el problema.

Al analizar las comparaciones realizadas entre Duqu y Stuxnet podemos apreciar que, si bien Duqu es un código malicioso que posee características similares a Stuxnet, como por ejemplo la utilización de certificados digitales y, además que ambas amenazas comparten algunas porciones de código; esta información no es suficiente para afirmar que Duqu es el sucesor del primero. Muchas de las complejas características que se vieron en las variantes de Stuxnet, como las instrucciones para atacar plantas industriales y específicamente sistemas SCADA, no fueron detectadas en Duqu. Eso no quita, sin embargo, que en un futuro esta amenaza pueda evolucionar, volverse más compleja y, por ende, desarrollar características más peligrosas.

Duqu es un código malicioso y representa una amenaza, por lo tanto el usuario debe mantenerse protegido para no ser una eventual víctima, sin embargo no nos parece adecuado alarmar a la sociedad y generar un escenario de inestabilidad con noticias afectadas por cierto grado de especulación que solo llevarían al usuario a un estado de incertidumbre y no de precaución. Si el escenario cambia, entonces lo haremos nosotros también, informando inmediatamente a la comunidad sobre el nuevo paradigma de infección y cómo protegerse al respecto.

Ver más… »

Categories: Alertas, Malware
1 Comment »

A fines del año pasado les presentamos varios informes detallando cómo actuaba la popular amenaza Stuxnet y las distintas vulnerabilidades que este explotaba. Para quienes no lo recuerdan, esta amenaza posee la particularidad de afectar solo a sistemas de control industrial del tipo SCADA.

La propagación que tuvo fue tal que llegó a afectar a más de 45.000 sistemas de carácter crítico en un periodo muy corto de tiempo, entre ellos una planta de energía nuclear Iraní, retrasando y perjudicando su funcionamiento y el desarrollo de su programa nuclear.

Ahora bien, mas allá de explotar 3 vulnerabilidades del tipo 0-day, ¿se podría haber evitado que Stuxnet afectara a este tipo de sistemas? Desde el Laboratorio de Análisis e Investigación de ESET Latinoamérica creemos que si.

Las empresas o entidades que brindan servicios tan vitales y críticos como los que pueden ser manejados por sistemas SCADA (plantas potabiliza-doras de agua, petrolíferas, nucleares, etc) deberían de poseer una serie de protocolos de seguridad al igual que cumplir con la serie de normas ISO/IEC 27000, las cuales son estándares de seguridad publicados por la Organización Internacional para la Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC).

Uno de dichos estándares detalla medidas de protección contra amenazas a la integridad, entre ellas verificadores de integridad. Estos últimos son aplicaciones que se encargan de comparar el HASH (identificador único) de los archivos críticos del sistema contra una base de datos donde previamente se almacenaron estos valores en su estado original, alertando al administrador de cualquier modificación no autorizada de forma inmediata.

Para ilustrar la obtención del HASH y su variación de valor en relación a pequeñas modificaciones realizadas, les facilitamos la siguiente imagen:

El ataque que realizaba la amenaza Stuxnet consistía en que, luego de ganar acceso al sistema mediante alguna de las vulnerabilidades explotadas, modificaba un archivo .DLL (librería) de la aplicación WinCC (aplicación SCADA) afectando así su funcionamiento.

De haber poseído un verificador de integridad con alertas o incluso acciones de mitigación automática, las víctimas de esta amenaza, no hubieran sido tales, y solo se hubieran enterado de forma temprana de posibles brechas de seguridad en sus sistemas.

La seguridad de un sistema no solo se basa en poseer una solución antivirus con detección proactiva, o el sistema operativo actualizado, sino también en la implementación de protocolos y controles de seguridad que verifiquen la integridad del mismo.

Stuxnet fue una amenaza de gran renombre por afectar sistemas críticos, pero la noticia no debería ser el funcionamiento de esta, sino la falta de controles de seguridad por parte de los sistemas afectados.

Joaquín Rodríguez Varela
Malware Lab Engineer

Categories: Análisis de malware, Curiosidades
4 Comments »

Finalizando el mes de octubre, hace unos pocos días, el código malicioso Koobface, que se ha venido propagando por redes sociales desde casi dos años (incluso su nombre deriva de la red social Facebook) ha vuelto a la acción con una particularidad: una variante multi-plataforma. Además, continuando con el resumen mensual, durante el transcurso del mismo pudimos obtener más detalles sobre la amenaza Stuxnet, la cual es un claro ejemplo de la evolución que está tomando el malware para obtener beneficios económicos. A continuación les presentamos los hechos más relevantes del mes:

• Una nueva campaña de  infección de Koobface apareció. Este código malicioso trae la nueva particularidad que afecta a las plataformas Linux y Mac OS. Esta variante se difunde  mediante redes sociales, con un mensaje que intenta captar la atención del usuario (Ingeniería Social) simulando ser un video online, el cual intentará ejecutar el código malicioso. Con esto podemos ver la evolución del malware a múltiples plataformas.
• A través de diversos papers se dio a conocer más información sobre Stuxnet. El código malicioso, identificado por ESET NOD32 como Win32/Stuxnet.A, se caracteriza por explotar tres vulnerabilidades del tipo 0-day sobre Windows y una cuarta que explota una falla propia de WinCC y PCS 7 de los sistemas Siemens (CVE-2010-2568). Cabe recalcar la importancia de este ataque dirigido especialmente a los sistemas de control industrial SCADA, para el cual ya se pudo confirmar que hay más de 45 mil equipos de control industrial afectados por este gusano.
• Durante este mes se llevo a cabo el cierre de la conferencia Virus Bulletin 2010, donde los expertos de la industria de antivirus y antispam exponen las problemáticas del año dejando mucho material interesante. En esta oportunidad se destaca  nuevamente a Stuxnet como el código malicioso más importante del año, también las redes sociales ocuparon su lugar en las problemáticas, ya que se habló de las amenazas que afectan a las mismas, siendo uno de los principales medios  para los atacantes, los archivos PDF tuvieron su cuota en la conferencia ya que una de las charlas se planteó un interesante debate sobre este estándar abierto.
• Nuevamente las redes botnet fueron noticia durante el mes. En primer lugar, Zeus dio que hablar con un curioso hecho, ya que el creador de este malware dejará de dar soporte a su cliente, dejando a cargo todo el código fuente al creador de SpyEye, otro código del tipo bot diseñado con fines similares, y se espera que ambas amenazas se fusionen en un futuro. Asimismo, la botnet de Bredolab fue dada de baja, siendo otra de las redes de computadoras zombis que sufren este hecho durante el año, una tendencia que cada vez es más frecuente.
• Una noticia que también repercutió mucho en los medios, fue el ataque de denegación de servicio a la SGAE (Sociedad General de Autores y Editores) por parte del grupo conocido como Anonymous el cual luego extendió su ataque al  MCU (Ministerio de Cultura Español) y a PROMUSICAE (Productores de Música de España), demostrando que este tipo nuevo de protesta 2.0 adquiere gran relevancia ya que los mismos usuarios son los voluntarios para realizar el ataque, lo que se ha dado a conocer como ciber activismo.
• Los incidente de seguridad por malware, reportados durante este año por parte de los usuarios, indicaron que la gran mayoría sufrió al menos un incidente, siendo los USB los dispositivos utilizados como principal método de propagación. Los sitios web también tuvieron un gran porcentaje por lo cual recordamos  tener en cuenta lo siguiente ante un incidente de este tipo, como último pero no menos importante el phishing demostró también tener un margen en los incidentes, donde una vez más una entidad financiera es involucrada  generando graves problemas a la confidencialidad de la información.
• Una vez más las noticias del momento se utilizan para distribuir amenazas, y este mes no fue excepción ya que los mineros en Chile fueron utilizados para propagar malware, en este caso con una curiosidad ya que la noticia chilena fue utiliza en Brasil, en idioma portugués a través de correos electrónicos con técnicas de Ingeniería Social.

Para obtener mayor información sobre las amenazas destacadas de octubre, pueden visitar nuestro ranking de propagación y el informe de amenazas destacadas del mes.

Claudio Cortés Cid
Especialista de Awareness & Research

Categories: Reportes mensuales
3 Comments »

El siguiente post es una traducción del texto realizado por Aleksandr Matrosov, Eugene Rodionov, Juraj Malcho y David Harley, especialistas de seguridad de ESET, y publicado en el blog de ESET en inglés sobre las vulnerabilidades explotadas por Stuxnet.

Si bien la vulnerabilidad parcheada por LNK MS10-046 dominó los titulares cuando el carnaval Stuxnet comenzó a rodar de nuevo a principios del verano de 2010, una de las sorpresas luego de un análisis más profundo de los archivos binarios y componentes de Stuxnet, es que explotan al menos tres vulnerabilidades más que fueron en general desconocidos en ese momento. El ataque de cola de impresión (MS10-61) es, como la vulnerabilidad LNK, descrito en nuestro extenso análisis “Stuxnet bajo el microscopio“.

Sin embargo, también se indica en ese documento que hay dos vulnerabilidades de Elevación de Privilegios (EOP) las cuales elegimos no describir hasta que los parches se encontraran disponibles. Uno de estas ya ha sido parcheada (MS10-073, CVE-2010-2743), por lo que estamos ahora en condiciones de publicar parte de la información que tenemos de ella (cuando la otra vulnerabilidad haya sido parcheada, tenemos la intención de actualizar el documento de Stuxnet con información sobre ambas).

Cuando el gusano Win32/Stuxnet no tiene privilegios suficientes para instalarse en el sistema, explota una vulnerabilidad 0-day parcheada recientemente en el módulo del sistema win32k.sys para así escalar privilegios hasta lograr acceso a nivel  SISTEMA, lo que le permite realizar cualquier acción que guste en el equipo local. Los sistemas vulnerables son los siguientes:

• Microsoft Windows 2000
• Windows XP – todos los service packs

Para realizar este truco, carga un archivo de distribución del teclado especialmente diseñado , lo que le permite ejecutar código arbitrario con privilegios de SYSTEM. Esta elevación de privilegio se produce mientras se envían los datos ingresados desde el teclado en el módulo Win32k.sys. Mientras se procesa lo ingresado desde el teclado usando el servicio del sistema NtUserSendInput, el código ejecuta lo siguiente:

El propósito de este código es determinar cómo distribuir el código de la tecla virtual de la tecla pulsada. El registro ecx especificado en la tabla de procedimiento _aNLSVKProc indica el tipo de controlador utilizado, de acuerdo con la distribución de teclado que se posea. Esta tabla se compone de tres controladores:

Como podemos ver en la figura anterior, el _aNLSVKProc es seguido por tres DWORD, el último de los cuales (en rojo) se puede interpretar como un indicador que apunta a 0×60636261 en el espacio de direcciones en modo de usuario. Por lo tanto, si ponemos el registro ecx en el código en la figura 1 con el valor apropiado, en este caso 5, entonces podremos ejecutar código en el 0×6036261 con privilegios de SYSTEM.

Podríamos manipular el registro ecx en este código al cargar un archivo de teclado especialmente diseñado que especifique la carga de ciertos códigos de tecla virtual indexados como 5. El archivo de distribución de teclado es una librería de enlace dinámico que esté especialmente estructurada en la sección .datos del mismo.  A continuación se presenta una estructura que las claves de los mapas virtuales de los procedimientos correspondientes de dicha tabla.

El gusano carga un archivo de distribución de teclado especialmente armado, llamado por NtUserLoadKeyboardLayoutEx y le pasa la constante hexadecimal 0x01AE0160 como parámetro offTable. Las palabra en minúscula de este parámetro especifican el RVA (Relative Virtual Address) de la estructura KBDTABLES desde el principio del archivo, mientras que la palabras en mayúscula especifican el RVA de KBDNLSTABLES, que es de particular interés. La estructura de este último determina la dirección y el tamaño de la matriz de estructuras VK_F contenida en el archivo.

En la siguiente figura se presenta el contenido de la sección .datos ,donde podemos ver que la estructura de KBDNLSTABLES ubicada en RVA 0x1AE especifica una estructura VK_F situada en el RVA 0x01C2.

Como podemos ver, el archivo de distribución de teclado contiene exactamente una estructura VK_F a la cual se le asigna una tecla virtual con un código igual a el procedimiento de _aNLSVKProc con indexado 5.

Una cosa que tenemos que hacer para aprovechar esta vulnerabilidad es asignar un buffer para el código que se ejecutará en la dirección 0×60636261 como en el caso de Stuxnet, que asigna 32 KB de la memoria en 0×60630000 y escribe el código shell a 0×60636261:

Aleksandr Matrosov
Eugene Rodionov
Juraj Malcho
David Harley

Categories: Análisis de malware, Vulnerabilidades
4 Comments »