jueves, 28 de febrero de 2013

Nueva actualización para Adobe Flash Player


Adobe ha publicado una nueva actualización para Adobe Flash Player para evitar tres nuevas vulnerabilidades que afectan al popular reproductor. Estas vulnerabilidades podrían permitir a un atacante tomar el control de los sistemas afectados.

Las vulnerabilidades afectan a las versiones de Adobe Flash Player 11.6.602.168 (y anteriores) para plataformas Windows, Adobe Flash Player 11.6.602.167 (y anteriores) para plataformas Macintosh y Adobe Flash Player 11.2.202.270 (y anteriores) para Linux. 

Esta actualización, publicada bajo el boletín APSB13-08, resuelve un problema de permisos en la sandbox de Firefox (CVE-2013-0643), una vulnerabilidad en la característica ExternalInterface ActionScript (CVE-2013-0648) y un desbordamiento de búfer en el servicio broker de Flash Player (CVE-2013-0504). Todos los problemas podrían permitir la ejecución remota de código.

Adobe advierte que los problemas con CVE-2013-0643 y CVE-2013-0648 se están explotando en la actualidad en ataques dirigidos diseñados para que el usuario pulse sobre un enlace que le dirige a un sitio web malicioso con contenido Flash (SWF) malicioso. Este exploit está diseñado para afectar al navegador Firefox.

Adobe ha publicado las siguientes versiones de Adobe Flash Player destinadas a solucionar las vulnerabilidades, y se encuentran disponibles para su descarga desde la página oficial:

  • Adobe Flash Player 11.6.602.171 para Windows y Macintosh.
  • Adobe Flash Player 11.2.202.273 para Linux.
  • Adobe Flash Player 11.6.602.171 para Google Chrome (actualización automática).
  • Adobe Flash Player 11.6.602.171 para Internet Explorer 10 para Windows (actualización automática).

Más información:

Security updates available for Adobe Flash Player



Antonio Ropero
Twitter: @aropero

miércoles, 27 de febrero de 2013

10 años de phishing: la eficacia de lo simple (y II)

Los ataques de tipo phishing llevan ya más de 10 años, pero en realidad no fue hasta 2003 que se popularizaron. Contra entidades españolas, quizás un poco más tarde. 10 años después, el phishing sigue funcionando prácticamente igual que cuando comenzó, e incluso algunas medidas para darle credibilidad intentadas durante esta última década, han sido descartadas por los atacantes en favor de lo sencillo... porque no merece la pena. Sigue siendo igual de efectivo.

Más evolución

Los casos de phishing más "evolucionados", realizan MiTM (hombre en el medio). Consiste en que la página falsa recoge el usuario y contraseña del usuario y los prueba contra la web real del banco. Si no son válidos muestra un mensaje de error. Esto da realismo al phishing, y aun hoy se sigue usando, aunque solo en los casos más sofisticados.

Hacia 2007, a medida que las entidades bancarias implantaban las tarjetas de coordenadas, los phishing simplemente comenzaron a pedir todos los datos de la tarjeta. El usuario, convencido de que cuantos más códigos de la tarjeta se pidan, más conciencia de seguridad muestra el banco ("cuantas más contraseñas más seguro"), rellena gustoso todas las coordenadas. Esta técnica sigue siendo extremadamente usada hoy en día.

Y desde entonces, no se han dado grandes saltos técnicos. Puntualmente, para mejorar su difusión, se intentaron ataques del tipo SMiShing (que tuvo un cierto repunte en 2011), pero el coste asociado solo es asumible por las mafias más consolidadas. Consistía en el envío de, en vez de un correo basura o un mensajes en foros, un SMS con el enlace al sitio falso.

Así que sigue funcionando el simple hecho de colgar una web parecida a la del banco en alguna URL (da igual el tipo o lo parecida o no que resulte al objetivo), y enviar por email un supuesto aviso del banco que apunte a ella. Los intentos de mejorar el sistema se han quedado en el camino, y la base continúa siendo eficaz y barata para los atacantes, que siguen una economía de esfuerzo habitual en cualquier mercado. De hecho, hace poco publicábamos que el 66% de los phishings se cuelgan en páginas comprometidas, lo que habitualmente significa que las URLs no se parecen lo más mínimo a la original y no se protegen por SSL.

Contramedidas

Lo curioso es que a pesar de que los atacantes no han evolucionado, las contramedidas por parte de los "buenos" sí lo han hecho, pero ninguna ha contrariado demasiado a los phishers. El primer paso contra el phishing (y el más eficaz) ya estaba inventado desde mucho antes: SSL y certificados. Pero el usuario nunca les hizo demasiado caso, por lo que no ha dado los resultados esperados. La autenticación con coordenadas tampoco ha frenado a los atacantes, e incluso los tokens de generación de contraseñas de un solo uso (según la implementación) han sido (y siguen siendo) derrotados por un simple phishing "de toda la vida".
Las barras de detección o listas negras, como cualquier elemento reactivo, no están siendo suficientes. Los navegadores cada vez han mostrado mensajes más agresivos para disuadir al usuario de que visite páginas catalogadas como phishing, o con certificados inválidos, pero con resultados pobres.

Los sistemas antispam, encargados de que los emails de phishing no lleguen a su destino sí han mejorado, pero no tanto como se esperaba. Los atacantes han recurrido a otros métodos de difusión como pueden ser las redes sociales para promocionar su estafa, o se aprovechan de sistemas de correo de banco poco asegurados que permiten una suplantación del dominio. No implementan DKIM o SPF, por ejemplo.

Conclusiones

En 10 años, se han tomado medidas preventivas, reactivas e incluso legales con un éxito muy escaso mientras que, sin apenas cambios técnicos o de filosofía, los atacantes siguen usando el phishing con regularidad y efectividad. Como el correo basura, sigue siendo una realidad palpable, manteniendo métodos muy parecidos desde que comenzó hace incluso más años que el phishing.

La razón es que el phishing (el "hermano pobre" de los troyanos, como mencionamos alguna vez por aquí) es barato, sencillo y eficaz. Y si es, pongamos, 100 veces menos eficaz que hace diez años, lo único que hay que hacer es intentarlo 100 veces más. Todo es cuestión de matemáticas. Para obtener una víctima, quizás hace 10 años necesitaba enviar 100 correos (un 1% de eficacia). Hoy, si el ratio de éxito es de 0,001% de los usuarios, la solución es multiplicar por 1.000 el número de correos para conseguir el mismo beneficio. Y si un banco lo pone difícil implementando medidas de seguridad complejas, simplemente elegirán otro banco que no lo haga. Y en el peor de los casos, recurrirán a páginas que usan una sola contraseña, como redes sociales, correos web o juegos online. Estos datos siempre son vendibles a terceros o aprovechables económicamente. Así de "sencillo", así de eficaz.

Más información:

Phishing, el "hermano pobre" de los troyanos

Fraude a la banca electrónica con OTP

Intento de fraude a los clientes del BBVA

Los secretos del éxito del phishing

Por qué funciona el phishing                                                  

Técnicas phishing afectan a Internet Explorer

El SMiShing llega a España

El 66% de los phishings se cuelgan en páginas comprometidas



Sergio de los Santos
Twitter: @ssantosv


martes, 26 de febrero de 2013

Ejecución remota de código en RealPlayer al reproducir MP4

Se ha anunciado una vulnerabilidad en el popular reproductor multimedia RealPlayer, que podría permitir a un atacante remoto tomar el control de los sistemas afectados.

El problema (con CVE-2013-1750) reside en un desbordamiento de búfer basado en heap al tratar archivos MP4 específicamente manipulados, que podría permitir a un atacante remoto ejecutar código arbitrario en los sistemas afectados. El código se ejecutaría con los privilegios del usuario atacado.

Se recomienda actualizar a las versiones RealPlayer 16.0.1.18 (para Windows XP, Vista y Win7).

Más información:

RealNetworks, Inc. Releases Update to Address Security Vulnerabilities.


Antonio Ropero
Twitter: @aropero

10 años de phishing: la eficacia de lo simple (I)

Los ataques de tipo phishing llevan ya más de 10 años, pero en realidad no fue hasta 2003 que se popularizaron. Contra entidades españolas, quizás un poco más tarde. 10 años después, el phishing sigue funcionando prácticamente igual que cuando comenzó, e incluso algunas medidas para darle credibilidad intentadas durante esta última década, han sido descartadas por los atacantes en favor de lo sencillo... porque no merece la pena. Sigue siendo igual de efectivo.

Comienzos

Aunque el concepto se inventó en 1996, no fue hasta que la banca online se popularizó (2003) que el phishing comenzó siendo un negocio rentable. Comenzaron con tímidos ataques contra AOL en Estados Unidos, en la segunda mitad de los 90. Los atacantes experimentaron con copias de páginas y correos falsos para conseguir contraseñas de estos servicios.

Hacia 2001 se fijaron en e-gold, en un ataque sonado por aquel momento. En 2003 se lanzaron agresivas campañas contra usuarios de eBay y PayPal. Ahí comenzaba el juego, puesto que eran sistemas de pago que permitían un lucro interesante e inmedidato. Además, imaginamos el éxito de aquellas primeras campañas cuando los usuarios no estaban concienciados y no existía ninguna herramienta preventiva. En 2004 empezó el ataque masivo por parte de miles de atacantes contra todo tipo de bancos.

Evolución

Los primeros ataques se basaban en comprar dominios parecidos a los de los atacados. Aprovechaban equivocaciones al escribirlos o enviaban emails a sus víctimas. Con el tiempo, los atacantes comenzaron simplemente a usar cualquier dominio, normalmente páginas comprometidas a las que subían el contenido. El efecto seguía siendo el mismo (el usuario no suele reparar en el dominio al que va, simplemente pulsa sobre el enlace) con lo que con el tiempo se usan ambas técnicas por igual. Incluso, según nuestra experiencia, la mayoría de atacantes no se preocupa en absoluto del aspecto del dominio.

Durante un tiempo en (sobre 2004), algunos casos intentaron algo curioso. Aprovechaban JavaScript para ocultar la barra del navegador (Internet Explorer 6) con la URL real del banco, superponiendo una imagen emergente en el punto exacto para que se confundiera con el propio navegador. Esto fue muy llamativo, pero era fácil de combatir y no se siguió usando.

Durante esa época, también se experimentó con diferentes vulnerabilidades en el navegador para que el "ancla" en HTML simulara la URL real, pero realmente te llevara a otra web al hacer click sobre un enlace. Así, con solo poner el ratón sobre el enlace parecía que fuese a redirigir a la página legítima, cuando en realidad no era cierto. Durante unos meses, el juego del gato y el ratón entre Microsoft  y los que descubrían técnicas diferentes fue constante.

Otras técnicas que se observaron durante un tiempo fueron los phishings bajo SSL. Después de que se machacara al usuario con la idea simplista de que "el candado en el navegador indica que es seguro", muchos casos de phishing comenzaron a alojar sus plagios de web en páginas bajo SSL. Los certificados eran gratuitos, autofirmados o baratos... y por supuesto consiguieron un gran éxito. Aparecía el candado y el usuario se sentía seguro. Esta técnica ha sido también abandonada últimamente, y no es tan habitual observar casos de phishing bajo SSL.

Veremos más en la siguiente entrega.

Más información:

Fraude a la banca electrónica con OTP

Intento de fraude a los clientes del BBVA

Los secretos del éxito del phishing

Por qué funciona el phishing                                                  

Técnicas phishing afectan a Internet Explorer





Sergio de los Santos
Twitter: @ssantosv

lunes, 25 de febrero de 2013

Buenas prácticas contra el phishing por parte de los bancos: SPF

El envío de correo es un sistema que, por definición, carece absolutamente de seguridad. Esto permite que, por ejemplo, sea tan sencillo falsificar un remitente de un email. Para solucionar esto, se han propuesto varios métodos que son como "parches" en el protocolo SMTP. Uno es "Sender Policy Framework" (SPF) que se considera una buena práctica contra la falsificación de correos en general y el phishing en particular.

El phishing se suele basar en el envío de correos falsos, que dicen venir de la entidad bancaria. Para conseguir dar credibilidad a estos correos, los atacantes suelen, entre otros métodos, utilizar logotipos de entidad atacada o el envío desde direcciones pertenecientes al dominio de la entidad. Por ejemplo, es más probable que una potencial víctima del phishing dé más credibilidad a un correo que viene de soporte@banco.com, que si viene de soporte@gmail.com pidiendo las contraseñas de la que es cliente.

SPF se basa en que un correo de un dominio, debe haber sido enviado desde el servidor de correo de ese dominio, y nada más. Cuando un email llega a un servidor, el programa se cuestiona: Este correo dice venir de @banco.com, y ha sido enviado desde la dirección IP 1.2.3.4. ¿Está la dirección 1.2.3.4 autorizada a enviar correos en nombre de ese domino? Y a continuación le pregunta a @banco.com por sus IPs autorizadas. Solo los correos enviados desde el servidor de correo legítimo de banco.com, se considerarán válidos. ¿Cómo sabe el servidor qué direcciones IP son las válidas? Esta información se deja en un registro DNS público de la entidad, en el que básicamente se constata qué direcciones IP están autorizadas a enviar y qué con qué política marcar a los correos que no han sido enviados desde ellas. Y las políticas (entre otras) que se pueden seguir son estas:

  • Dejar pasar los válidos y marcar el resto como "hardfail", o sea, que se marcan en la cabecera como correos falsos a todas luces.
       
  • No hacer nada.
       
  • Dejar pasar los válidos y marcar el resto como como "softfail", o sea, que se marcan como falsos pero tampoco "tajantemente".


En realidad, las dos últimas opciones se suelen usar para comprobar que funciona en fases de pruebas. Es responsabilidad de la entidad una buena configuración de sus registros DNS para que funcione correctamente el SPF.

Imaginemos que un phisher envía un correo a una cuenta de Gmail cualquiera, diciendo que es seguridad@banco.es y lo envía desde una IP (1.2.3.4) que no corresponde al registro SPF del banco (la lista de IPs que considera legítimas para enviar correo en su nombre). Gmail marcará el correo en su cabecera con esto:

Received-SPF: fail (google.com: domain of seguridad@banco.es does not designate 1.2.3.4 as permitted sender)

Donde vemos un "fail", o sea, un hardfail. El administrador del servidor de correo al que llega (en este caso Gmail), decide qué hacer con esto. Por ejemplo, descartarlos o desterrarlos al spam y que no llegue el buzón de los usuarios (que probablemente sea lo más conveniente, tratándose de un "hardfail").

En resumen, SPF ayuda a que los correos con el remitente falsificado lleguen en menor medida a las bandejas de entrada de los usuarios, pero no es definitivo. Primero porque el phisher puede usar otro dominio inventado (por ejemplo @soportebanco.com) que no use SPF y que también puede convencer a la víctima. Segundo porque es el servidor que recibe el email el que elige qué hacer con el correo... siempre se marca, pero no garantiza que lo descarte totalmente por fallar en el SPF, aunque puede tomarlo como un punto más en la evaluación como correo basura. Y tercero porque, si no se configura bien, el atacante podría usar otros dominios legítimos para engañar al usuario, por ejemplo, enviarlo desde @www.banco.com, que también tendría credibilidad a los ojos de una potencial víctima.

Existen otros métodos más efectivos como DKIM para validar el correo, pero son menos populares entre los administradores y mucho más complejos de implementar. La ventaja de SPF es que es trivial de configurar, y mitiga en parte el impacto del phishing.




Sergio de los Santos
Twitter: @ssantosv

domingo, 24 de febrero de 2013

Múltiples vulnerabilidades en Pidgin

Se han publicado varias vulnerabilidades que afectan al popular cliente de mensajería instantánea Pidgin y podrían permitir la manipulación de datos, causar una denegación de servicio y ejecutar código arbitrario de forma remota.

Pidgin es un programa de mensajería instantánea multicuenta y multiprotocolo distribuido bajo licencia GNU GPL. Permite por tanto conectarse de manera simultánea a varios servicios de mensajería como AIM, MSN, Jabber, Gtalk o ICQ entre otros.

Las vulnerabilidades son las siguientes:

  • Un error en el protocolo MXit al guardar imágenes podría ser aprovechado para sobrescribir determinados ficheros del sistema afectado. Ha sido descubierta por Chris Wysopal de Veracode y se le ha asignado el identificador CVE-2013-0271.
        
  • Un error de comprobación de límites al procesar cabeceras http entrantes, en la función 'mxit_cb_http_read' localizada en el fichero 'libpurple/protocols/mxit/http.c' que podría utilizarse para lograr la ejecución de código arbitrario (CVE-2013-0272).
        
  • Un error en la función 'mw_prpl_normalize' (en 'libpurple/protocols/sametime/sametime.c') al procesar identificadores de usuario (user ID) de longitud superior a 4096 bytes podría emplearse para provocar una denegación de servicio. Su identificador es CVE-2013-0273.
        
  • Múltiples errores en las funciones 'upnp_parse_description_cb', 'purple_upnp_discover_send_broadcast', 'looked_up_public_ip_cb', 'looked_up_internal_ip_cb', 'purple_upnp_set_port_mapping()', y 'purple_upnp_remove_port_mapping' cuando procesan peticiones UPnP podrían causar una denegación de servicio (CVE-2013-0274).


Las tres últimas vulnerabilidades han sido descubiertas por el equipo de Coverity Static Analysis (CSA).

La versión de Pidgin 2.10.7, que corrige todos los errores anteriormente descritos, se encuentra disponible para su descarga desde el sitio oficial. http://www.pidgin.im

Más información:

Remote MXit user could specify local file path

MXit buffer overflow reading data from network

Sametime crash with long user IDs

Crash when receiving a UPnP response with abnormally long values



Juan José Ruiz



sábado, 23 de febrero de 2013

VMWare soluciona vulnerabilidades en vCenter Server, ESX y ESXi


VMWare ha publicado el boletín VMSA-2013-0003, donde resuelve varias vulnerabilidades para sus sistemas vCenter Server, ESX y ESXi, tanto de sus librerías como de las de terceros.

La primera de estas (CVE-2013-1659) trata un fallo en el protocolo NFC (Network File Copy) en los sistemas VMWare. Este protocolo es utilizado al realizar copias de datos de máquinas virtuales (discos virtuales, por ejemplo) a través de la red. Un atacante remoto que realizara un ataque "hombre en el medio" entre el cliente y el servidor podría capturar los datos de la copia y cambiarlos, pudiendo escribir código arbitrario en ellos, que quedaría en l sistema de destino. Afecta a todas las versiones de ESX y ESXi, además de a todas las de vCenter excepto la 4.1.

En cuanto a las vulnerabilidades de terceros, también se ha solucionado una vulnerabilidad en OpenSSL (CVE-2012-2110), que afecta a ESX 3.5. Localizada en la función "asn1_d2i_read_bio", redica en varios fallos de conversión entre variables enteras con distinta longitud podrían provocar a un desbordamiento del buffer, y en consecuencia la corrupción de la memoria. Este error se puede explotar a través del procesado de certificados X.509 o claves públicas RSA. El principal impacto es una denegación de servicio, aunque posiblemente pueda tener otros.

Por último, se publica el parche para las vulnerabilidades publicadas por Oracle para la rama 5 de Java en Octubre de 2012, aunque en las referencias aparece el boletín de febrero de 2012. En total, se trata de 14 vulnerabilidades con impactos diversos, entre ellas cinco de ejecución de código arbitrario de manera remota sin necesidad de autenticación, con puntuaciones CVSS de 10 en 3 de ellas y 7.6 en el resto. Afectan a los sistemas VirtualCenter 2.5 y ESX 3.5 y 4, y vCenter 4, aunque solo los dos primeros reciben el parche.

Las actualizaciones se encuentran disponibles a través de los canales oficiales:
Bulletin VMSA-2013-0003

Más información:

VMware vCenter Server, ESXi and ESX address an NFC Protocol memory corruption and third party library security issues.




Francisco López

viernes, 22 de febrero de 2013

Oracle soluciona las últimas vulnerabilidades de su boletín de febrero

A pesar de que Oracle solucionó una larga lista de vulnerabilidades (50) al adelantar la publicación de su boletín el pasado día cuatro de febrero, ya advertía que algunas no habían podido solucionarse y serían publicadas en la fecha establecida a priori. Precisamente estas son las que aloja este boletín, inusualmente corto, con solo cinco problemas solucionados.

Sin embargo, esto no significa que las vulnerabilidades sean baladíes. Las cinco son explotables remotamente sin necesidad de autenticación. Tres de ellas (CVE-2013-1487, CVE-2013-1486 y CVE-2013-1484) permiten la ejecución de código arbitrario, con una puntuación CVSS base de 10. Las dos restantes son de impacto más discreto; una de ellas afecta a la integridad (CVE-2013-1485), y la otra a la confidencialidad (CVE-2013-0169), ambas de manera parcial.

Solo la última es aplicable a la versión servidor de Java. Esta es la conocida como "Lucky thirteen". Se trata de una debilidad en la implementación del protocolo TLS/SSL que permite que, capturada la información cifrada que se quiere conocer, obtener el texto plano descifrado estudiando los tiempos de respuesta del servidor a los mensajes generados por el atacante. Podría servir, por ejemplo, para obtener el texto plano de una cookie de autenticación cifrada.

El resto, se aplican a la versión cliente de Java, afectando a los componentes "Deployment", "JMX" y "Libraries". Estas vulnerabilidades se pueden explotar en los navegadores a través de Java Web Start.

Con este boletín, Oracle da por terminado el soporte público para la versión 6 de JRE. A partir de ahora, tanto las actualizaciones de esta rama como las de la 5 estarán solo disponibles para los usuarios poseedores de una licencia. Sin embargo, Oracle no permitirá que haya versiones de Java 6 sin soporte instaladas en los equipos. A partir de ahora, al actualizar la versión 6 de Java a través de su sistema automático, se instalará la última versión de la rama 7 y se desinstalará cualquier versión de la rama 6 que se encuentre.

Más información:

Updated Release of the February 2013 Oracle Java SE Critical Patch Update

Updates to February Critical Patch Update for Java SE

una-al-dia (06/02/2013) Múltiples vulnerabilidades en la implementación TLS/SSL en OpenSSL


Francisco López

jueves, 21 de febrero de 2013

Fines y medios: Ahora la NBC

Durante unas horas, la página oficial de la popular cadena norteamericana NBC estuvo infectando con troyanos bancarios a los sistemas Windows no actualizados que la visitaran. Este incidente se suma a una larga lista de páginas populares de medios de comunicación comprometidas.

Hace unas semanas, se conocía que uno de los subdominios de Los Angeles Times había sido infectado al menos durante mes y medio. Al menos, la NBC ha sido comprometida solo durante unas horas. También otras de las páginas de sus programas. Se detectó que varios sitios web incluían IFRAMES de tamaño minúsculo que cargaban código que llevaba al visitante al kit de explotación Red Kit. Aquí, el programa intenta explotar (sorpresa) vulnerabilidades en Java (una muy reciente, CVE-2013-0422, arreglada en la versión 11) y Adobe Reader. De tener éxito, el usuario es infectado por una variante de Citadel (una familia de Zeus). El troyano se encargará de modificar la web del banco y robarle las credenciales (en la muestra se han encontrado como objetivo los más populares de Estados Unidos) para realizar transferencias sin su consentimiento.


Dancho Danchev ha observado los "whois" de algunos de los dominios. En ellos, el email de registro aparece un viejo conocido (lockwr@rocketmail.com), encargado de otras recientes campañas a gran escala, en las que se inducía a los usuarios a "desbloquear" su cuenta de Facebook visitando un enlace y otra que involucraba la imagen de Verizon. Esto podría demostrar que esta banda está actuando en paralelo a través de varios frentes y, sobre todo, a gran escala en Estados Unidos.

Los binarios descargados eran muy poco detectados por los antivirus en el momento en el que estaban siendo servidos. En el mejor de los casos, siete motores lo detectaban a través de Virustotal. Google se encargó rápidamente de bloquear la página y marcarla como peligrosa y Facebook bloqueó el acceso desde su portal.

Fines y medios

Una vez más, nos presentamos antes un ataque en el que la NBC es un mero intermediario, y no el fin. Quizás la NBC sea un sitio complejo de comprometer, pero lejos están los tiempos en los que el ataque en sí, demostrar que era posible, representaba el fin en sí mismo. Ahora, el valor de atacar la NBC no es la hazaña de conseguirlo, sino su potencial en visitas. Más visitas, más gente infectada. Más gente infectada, más beneficios. Y ese es el verdadero fin. Igual que ocurrió hace poco con Bit9, en el caso en el que los atacantes consiguieron robar un certificado privado de la compañía, con el único objetivo de atacar a terceros que se encontraban protegidos por su software. Los medios para conseguir el fin pueden llegar a ser complejos, pero hoy ya se traducen en simples efectos colaterales.

¿Qué hubiera pasado?

Aunque en este caso el malware estaba destinado a bancos norteamericanos, existen bandas muy activas que lo programan para atacar a víctimas que visitan numerosas cajas y bancos españoles. Por pequeña que parezca, hemos observado que los atacantes tienen en cuenta prácticamente todas las entidades bancarias españolas en su código. ¿Qué hubiera pasado si se lanza una campaña de este tipo en España?

Realicemos un ejercicio hipotético, sin más valor que el de concienciar sobre las cifras. La NBC.com, según Alexa ocupa el puesto 2.211 en visitas globalmente en la Red. Un medio de televisión español popular, por ejemplo RTVE.es, ocupa el puesto 1.915. Según la propia RTVE esto significa que ha sumado casi 14 millones de usuarios únicos en enero de 2013. Imaginemos que alguien lo compromete, y comienza a lanzar malware desde ese portal solo durante un día. Esto hace 500.000 potenciales víctimas. De ellas, descartemos los usuarios de tabletas y televisores (31,2% según RTVE), Mac y Linux (añadamos sobre un 9% más). Pensemos que solo un 60% de los visitantes es una potencial víctima. Esto nos deja en 300.000 máquinas Windows. Aunque se eliminen de la ecuación los usuarios parcheados y a los que les bloquea el antivirus, seguiría siendo una suculenta cifra. Incluso de los ya infectados, no todos caerían en la trampa, visitaría el banco antes de que su antivirus lo detectase, etc. Imaginemos que apenas un 1% de esos 300.000 finalmente es estafado. Estamos hablando de 3.000 usuarios. Los atacantes se atreven a traspasar hasta 3.000 euros por estafado cuando existe dinero en la cuenta y para no levantar sospechas, pero la media en el robo de este tipo son 1.000 euros. Esto nos sitúa en un negocio de unos hipotéticos 3 millones de euros en beneficios por conseguir una buena difusión... ¿Merece la pena?

Estamos seguros de que en la banda, los encargados de encontrar espacios en los que esparcir el malware, se habrán llevado una buena comisión por este "éxito" en la NBC.

Más información:

RTVE.ES logra el mejor enero de su historia con casi 14 millones de usuarios únicos

Dissecting NBC's Exploits and Malware Serving Web Site Compromise

Exploit Sat on LA Times Website for 6 Weeks




Sergio de los Santos
Twitter: @ssantosv

miércoles, 20 de febrero de 2013

Boletines de seguridad para productos Mozilla

La Fundación Mozilla ha publicado ocho boletines de seguridad que en total corrigen 14 vulnerabilidades, que afectan al navegador Firefox, al gestor de correo Thunderbird y la suite SeaMonkey. Los boletines van desde el MFSA 2013-21 hasta el MFSA 2013-28 y se detallan a continuación.

  • MFSA 2013-21: Corrige dos vulnerabilidades de corrupción de memoria que podrían permitir la ejecución de código en la máquina afectada (CVE-2013-0783 y CVE-2013-0784).
        
  • MFSA 2013-22: Corrige una vulnerabilidad en la función 'RasterImage::DrawFrameTo' que permitiría obtener información sensible o provocar una denegación de servicio a través de una imagen GIF especialmente manipulada (CVE-2013-0772).
        
  • MFSA 2013-23: Corrige una vulnerabilidad en el wrapper de objetos 'WebIDL' que podría eludir restricciones de seguridad (CVE-2013-0765).
       
  • MFSA 2013-24: Corrige una vulnerabilidad en las implementaciones Chrome Object Wrapper (COW) y System Only Wrapper (SOW) que podría revelar información sensible y, posiblemente, ejecutar código JavaScript a través de una página web especialmente manipulada (CVE-2013-0773).
        
  • MFSA 2013-25: Corrige una vulnerabilidad al no procesar adecuadamente la información obtenida de un worker de JavaScript, con un un impacto indeterminado (CVE-2013-0774).
       
  • MFSA 2013-26: Se corrige una vulnerabilidad de utilización de memoria liberada 'user-after-free' en la función 'nsImageLoadingContent::OnStopContainer' que podría permitir ejecutar código arbitrario a través de una página web especialmente manipulada (CVE-2013-0775).
       
  • MFSA 2013-27: Corrige una vulnerabilidad que permitiría un ataque de hombre en el medio a través del engaño de la barra de direcciones operando con un servidor proxy que retorne un código de error 407 (CVE-2013-0776).
       
  • MFSA 2013-28: Corrige 6 vulnerabilidades que podrían provocar una denegación de servicio, e incluso la ejecución de código arbitrario a través de vectores no especificados. Las funciones donde se encuentran los errores son las siguientes: 
    'nsOverflowContinuationTracker::Finish', 'nsSaveAsCharset::DoCharsetConversion', 'nsDisplayBoxShadowOuter::Paint', 'ClusterIterator::NextCluster', 'nsCodingStateMachine::NextState', 'nsPrintEngine::CommonPrint'. Los CVE asignados a estas vulnerabilidades van desde el CVE-2013-0777 al CVE-2013-0782.

La solución a estas vulnerabilidades y las nuevas funcionalidades del  navegador se han introducido en las versiones Firefox 19.0, Firefox ESR 17.0.3, Thunderbird 17.0.3, Thunderbird ESR 17.0.3 y SeaMonkey 2.16.

Más información:

Mozilla Foundation Security Advisories
  


Jose Ignacio Palacios Ortega

martes, 19 de febrero de 2013

Java detrás de los ataques a Apple, Facebook y Twitter

Estos últimos días se han conocido varias noticias de ataques relevantes: los ingenieros de Facebook, Twitter y Apple han sido infectados por malware en las redes internas de estas compañías. Los ataques parecen tener en común varios elementos, pero básicamente, están basados en fallos de seguridad en Java.

El viernes 15 de febrero Facebook publicaba una nota en la que admitía que durante el mes de enero, sistemas (al parecer, portátiles) internos (probablemente de ingenieros) habían sido comprometidos con malware. No aclaraba cuántos. Según cuenta Facebook, una página que trataba sobre el desarrollo para móviles (al parecer iPhoneDevSDK) había sido comprometida. En ella, habían subido un exploit para Java que aprovechaba una vulnerabilidad previamente desconocida y que permitía la ejecución de código. Facebook se apresura a admitir que sus sistemas estaban completamente actualizados y que contaban con un antivirus. Estas medidas son necesarias (en especial la de actualizar) pero, lógicamente, insuficientes.

Poco después, el día 19, Apple también admite un problema de seguridad. De nuevo, sus desarrolladores visitan una web específica para programadores y el plugin de Java hace el resto, infectando los sistemas Mac.

Tanto Facebook como Apple aseguran que no han accedido a datos sensibles de su red y que siguen con las investigaciones. Por su parte, Facebook reportó a Oracle el fallo utilizado y fue corregido en su actualización del 1 de febrero.

Precisamente ese día, Twitter admite algo parecido. Detectaron accesos a sus datos (esta vez los atacantes sí que tuvieron éxito) y los pudieron acceder a las contraseñas (afortunadamente cifradas y salteadas) de 250.000 usuarios. Aunque no acusa directamente a Java, en la misma nota recomiendan la desactivación de Java del navegador.

Un ataque ingenioso

Los 0-day (fallos aprovechados por atacantes antes de que exista parche) solo pueden ser mitigados por la seguridad en profundidad. Curiosamente, las vulnerabilidades de este tipo están siendo muy habituales en los últimos tiempos, mientras que la seguridad en profundidad sigue olvidada en favor del mantra obsoleto que confía ciegamente en el antivirus, cortafuegos y sentido común... herramientas que por sí mismas no solucionan nada.

Introducir un exploit previamente desconocido en una web visitada por programadores es una buena idea. Evidentemente, este fallo no solo afectó a Facebook o Apple, sino que seguro son muchos más los infectados. No se trataría por tanto de un ataque dirigido contra estas empresas, pero sí que quizás "orientado" hacia programadores, con todo lo que ello significa. El truco consistiría en esperar a que las víctimas acudieran a una web, en vez de enviar un enlace, fichero o cualquier otro señuelo como sucede habitualmente. Esto incluso lo hace menos sospechoso y las víctimas pueden sentirse mucho más confiadas en que realmente, "no han hecho nada malo".

Usar un exploit de Java es una garantía de éxito además. Es sencillo de explotar, elude muchas restricciones sin complejidad, y está más que estudiado por la ingeniería de las mafias del malware cómo evitar la inmensa mayoría de los motores antivirus. Por si fuera poco, al esparcirse a través del navegador, se consigue entrar en las redes internas de las compañías sin demasiado esfuerzo. Hoy en día, pensar en que los ataques se producen desde fuera, saltando servidores, cortafuegos, IDS y otras medidas es un concepto muy de los 90. ¿Por qué pelear contra los altos y vigilados muros del castillo, si puedes "aparecer" ya dentro gracias a la magia de las vulnerabilidades en los navegadores? Los ataques se realizan sobre los equipos de escritorio de las personas que ya están en la red interna, y a través del navegador preferiblemente.

¿Por qué no estaban protegidos?

En los últimos meses, se ha advertido desde todos los frentes que es necesario (no recomendable, sino imprescindible) desactivar Java del navegador o activarlo exclusivamente para ejecutar ciertos applets firmados muy concretos. Esta es una buena medida contra los 0-days que han aparecido y aparecerán contra este software. Al parecer, algunos programadores de Facebook, Twitter y Apple no lo tuvieron en cuenta.

Lamentablemente, cualquier compañía puede ser comprometida de esta manera, pero el hecho de que los atacantes hayan tenido éxito a través de un software tan probadamente atacado como Java, hace que piense en que, al menos, podía haberse evitado esta vía sin demasiado esfuerzo y que se le ha puesto muy fácil a los atacantes. Este tipo de incidentes aporta muy mala imagen a las empresas que lo sufren. No hay más que ver el amable eufemismo usado para titular las notas de prensa en las que Twitter y Facebook admiten que han sido atacadas: "Seguimos manteniendo seguros a nuestros usuarios" y "Protegiendo a la gente de Facebook".

Más información:

Keeping our users secure

Protecting People On Facebook

Exclusive: Apple, Macs hit by hackers who targeted Facebook


Sergio de los Santos
Twitter: @ssantosv


lunes, 18 de febrero de 2013

El 66% de los phishings se cuelgan en páginas comprometidas

Los creadores de phishing tienen dos opciones a la hora de colgar sus réplicas de páginas de banca online: o bien compran un dominio o espacio web o bien comprometen una página legítima y suben en ella los archivos necesarios para la estafa. Según el estudio interno basado en los casos tratados por nuestro departamento de antifraude, un 66% de los phishings se alojan en páginas a las que han atacado.

Las fases básicas de un ataque phishing son las siguientes:

1) El atacante realiza una copia de la página legítima. La modifica para pedir todas las coordenadas de la tarjeta, una segunda contraseña, o el móvil, o los datos de la tarjeta de crédito, etc. También para que los datos sean o bien enviados por email al atacante o bien retenidos en el servidor hasta que los recoja.

2) El atacante busca un lugar donde subir la réplica modificada de la página de banca online. Aquí puede decidir entre un hosting (de pago o gratuito), comprar un dominio (o usar uno gratuito), una web comprometida, etc.

3) Una vez con el sistema montado, envía el enlace de forma masiva a una lista de correos. Este envío se puede hacer a través de servicios de terceros, páginas comprometidas, o programas especiales. Por último, también a veces estos enlaces pueden servir de infraestructura para un troyano que debe "esparcir".

En el paso 2, está en manos del atacante cómo hacerlo. Depende de su "profesionalidad" puede que elija un método u otro. Uno de los más "creíbles" resulta en la compra de un dominio parecido al dominio al que pretende suplantar. Esto lo aloja en un hosting "bulletproof" y desde ahí envía a sus víctimas el enlace. Un servidor "bulletproof" son los que, conocedores que sus servicios son usados para el fraude, reclamarán más dinero por alojar webs ahí, a cambio de hacer caso omiso de cualquier petición de eliminar el contenido ofensivo. Cuanto más tiempo online, más posibilidades de recoger los datos de más víctimas. Suelen estar alojados en Rusia.

La otra opción es la de romper la seguridad de una página cualquiera, y subir en ella el código. La elección de la web víctima suele hacerse por su tipo de software. Si el atacante conoce bien o sabe cómo aprovechar una vulnerabilidad en el software X, versión Y, buscará páginas de este tipo no aseguradas y ahí subirá su phishing. No compra ningún dominio ni se preocupa del aspecto de la URL.

Según nuestro estudio, basado sólo en casos de phishing (excluyendo troyanos), esta última opción es escogida en el 66% de los ataques en los casos que hemos tratado durante los últimos cuatro años. El 30% recurre a hostings gratuitos o de pago, y el resto opta por otras opciones (como por ejemplo adjuntar la página HTLM directamente en un correo, y que la víctima la cargue en local).

Este estudio está basado en los ataques que reciben nuestros propios clientes y atendidos con nuestro servicio de antifraude. Pero dado el número de casos estudiado y la variedad de entidades atacadas, creemos que puede resultar en una buena aproximación.

Conclusiones

Se pueden sacar dos sencillas conclusiones de esta pequeña recopilación basada en nuestra propia experiencia:

  • Los atacantes no se "complican la vida". Obtienen un buen ratio de efectividad realizando un mínimo esfuerzo. Por tanto, simplemente con comprometer una web, no necesitan registrarse en hostings, comprar dominios, o realizar ningún tipo de inversión (en tiempo o dinero). Solo buscar una web vulnerable,  comprometerla y subir ficheros es lo más sencillo para ellos.
        
  • El hecho de que lo más sencillo para los atacantes sea subir una página web en una página comprometida indica que "hay donde elegir", es decir, es más fácil comprometer una web que buscar un espacio en un hosting.


Laboratorio Hispasec

domingo, 17 de febrero de 2013

Salto de restricciones en Apple iOS 6 (o cómo realizar llamadas desde un iPhone bloqueado)

Se ha publicado una vulnerabilidad que afecta a la última versión del sistemaoperativo móvil de Apple, iOS 6, y que permitiría eludir restricciones de seguridad.

La vulnerabilidad se debe a un error al realizar llamadas de emergencia mientras se mantiene pulsado el botón de apagado del teléfono, lo que concedería acceso al contenido del terminal evitando la protección de la contraseña de desbloqueo. De esta forma sería posible acceder a la agenda de contactos, realizar llamadas, editar la información, etc.

En Youtube se ha publicado un vídeo demostrativo.


Se encuentran afectados los terminales iPhone 3GS, 4 y 5 con sistema operativo iOS 6.x. La vulnerabilidad ha sido reportada a Apple, aunque por el momento no existe parche oficial para subsanarla.

No es la primera vez que iOS se encuentra con un fallo de este tipo. La mayoría de las ramas anteriores han sufrido un problema similar que ha permitido eludir el código de bloqueo de iOS.

Más información:

Nueva forma de saltarte la contraseña del iPhone con iOS 6.1

Saltar passcode en pantalla de bloqueo en iOS 6.X



Juan José Ruiz

sábado, 16 de febrero de 2013

Ejecución de código remoto en SAP NetWeaver 7


Se han publicado dos vulnerabilidades que afectan a SAP NetWeaver 7 y que podrían permitir a un atacante remoto ejecutar código arbitrario.

NetWeaver es una plataforma compuesta por todas las aplicaciones SAP con objeto de lograr una mejor integración entre dichas aplicaciones, utilizar estándares para asegurar la interoperabilidad, aportar una gran flexibilidad, y reducir los costos. SAP NetWeaver es ampliamente utilizado en el mundo empresarial.

Martin Gallo y Francisco Falcon, de Core Security, han descubierto dos vulnerabilidades en SAP NetWeaver 7, concretamente en 'Message Server' (msg_server.exe). Ambas vulnerabilidades podrían provocar una corrupción de la memoria y ser aprovechadas de forma remota para ejecutar código arbitrario en el sistema afectado. Están causadas por:

  • Un error al validar el índice de un array en la función '_MsJ2EE_AddStatistics' (CVE-2013-1592)
        
  • Un error en la función 'WRITE_C' al procesar paquetes con opcode 0x15 (CVE-2013-1593)


SAP ha publicado la nota de seguridad 1800603 en relación a estos problemas además de los parches necesarios para corregir ambas vulnerabilidades.

Más información:

SAP security note 1800603

SAP Netweaver Message Server Multiple Vulnerabilities



Juan José Ruiz

viernes, 15 de febrero de 2013

¿El fin del virus de la policía?

En estos días se anuncia un indiscutible éxito (otro) de la policía española. La Brigada de Investigación Tecnológica (BIT) de la Policía Nacional ha detenido a 11 individuos en relación al "virus de la policía". Pero desde luego no es el fin de este tipo de malware y, como de costumbre, los medios generalistas se están dedicando a intoxicar la información real con titulares demasiado optimistas.

No se han detenido los responsables del virus de la policía como si se tratase de un equipo reducido de personas que se dedicaban a infectar a los usuarios. En la página del ministerio del interior, lo explican:
"Los agentes han desarticulado la célula financiera de la organización ubicada en la Costa del Sol y que blanqueaba el dinero logrado por este fraude, obteniendo sólo este grupo más de 1.000.000 € al año"

Lo que se ha desarticulado es uno de los grupos dedicado a lavar la impresionante cantidad de dinero que estaban consiguiendo con solo una de las decenas de variantes creadas por uno de los muchísimos grupos que están en ello. En el vídeo que acompaña a la noticia, las 200 tarjetas de crédito que aparecen (clonadas o creadas a través de números robados) dejan claro que eran más el departamento "financiero" que técnico. Además, se dice que:
"Entre los arrestados se encuentra el responsable de la creación, desarrollo y difusión de las diferentes versiones del malware a nivel internacional: un ciudadano de 27 años y origen ruso que fue detenido en los Emiratos Árabes Unidos"

Este hombre fue arrestado en diciembre, en realidad. Pero no pensamos que sea "el máximo responsable". Además, si lo fuera, no importaría demasiado (luego veremos por qué). Pensamos que la creación, desarrollo y difusión son precisamente tres actividades más bien independientes que muy extrañamente pueden recaer sobre la misma persona.
  
  • La creación la adjudicamos a la persona que tuvo la idea de usar la imagen de la policía, las acusaciones... como reclamo para secuestrar el ordenador. Puede que este mismo fuera quien lo programase en primera instancia y comenzara su distribución a pequeña escala... o no. Además, por supuesto esto es una evolución de otras ideas. Recordemos que en 2009 ya pudimos ver secuestros del ordenador en nombre de la RIA (Recording Industry Association of America) acusando al usuario de tener contenido descargado ilegalmente y pidiendo rescate. Un ataque muy parecido. El virus de la policía como tal, comenzó en Alemania en 2010.
        
  • El desarrollo se lo adjudicamos a quien lo programó, y a todos los que observaron rápidamente que era una genial idea. Estos plagiaron la idea, creando variantes propias, copiaron el código, o mandaron a terceros su programación, quién sabe. El caso es que sería ingenuo pensar que existe una única banda creando y distribuyendo algo que está teniendo tanto éxito, en un mundo en el que se puede copiar lo que sea, y que además está al margen absoluto de la ley. Todos copian en una especie de sálvese quien pueda y recoge la parte del pastel más grande posible.
       
    Hemos observado variantes buenas y malas técnicamente hablando... que usaban muy diferentes técnicas para bloquear el sistema: desde Internet Explorer en modo quiosco hasta la creación de escritorios virtuales pasando por ventanas sin bordes. Otros activaban la cámara y otros cifraban correos... No todos han sido creados por el mismo grupo, ni el mismo grupo ha creado una sola variante.
         
  • La difusión es lo más curioso. Habitualmente, su éxito ha sido distribuirse por vulnerabilidades en Java a travésde kits de exploits. Y aquí estamos totalmente convencidos de que poco han tenido que ver los creadores del malware en sí. La distribución a través de kits de exploits es un mundo muy grande, que se complementa con el malware pero que opera a otro nivel. La difusión ha podido hacerse a través de terceros, pagando sus servicios de uso de kits, de investigación de vulnerabilidades, etc... y más frentes, alejados quizás del núcleo "duro" de la creación. Como en el comercio habitual, la distribución puede ser totalmente externalizada. Quizás existan grupos reducidos que han plagiado la idea, programado el malware y distribuido a pequeña escala, todo a la vez... pero serán los menos (aunque quizás no por ello menos en número).

En definitiva, ni mucho menos es el fin del virus de la policía. Es un modelo demasiado lucrativo como para que sea descartada por los atacantes a corto plazo. Hemos tenido la suerte de colaborar en cierto modo con la policía, y además le hemos hecho un seguimiento muy de cerca al desarrollo de este malware. Sin duda su éxito ha sido arrollador, como en otros tiempos ocurría con virus concretos con gran difusión.

Pero no se trata de, como "antiguamente" un malware con nombre y apellidos. Lo que ha triunfado, el éxito, debe atribuirse al modelo: no al malware, no a un archivo concreto, no a un solo método de distribución. Lo que ha permitido que solo una cédula de blanqueo de dinero haya conseguido un millón de euros en un año es la idea, el concepto global de un ransomware bien distribuido y convincente. Y eso no se va a detener con la desarticulación de un grupo de personas. Lamentablemente, quizás tampoco tenga un efecto disuasorio pronunciado. Se juzgará a un reducido número de personas que se han lucrado con el malware (que no es poco).

En cualquier caso, la actuación de la policía ha sido impresionante. No es sencillo detectar (y mucho menos detener) a este tipo de delincuentes, o al menos abatir una de sus patas imprescindibles (la encargada de lavar el dinero). El esfuerzo en coordinación es complejo y merece todo nuestro reconocimiento.

Más información:

Golpe policial a una de las mayores redes cibercriminales especializada en infectar millones de ordenadores de todo el mundo

una-al-dia (21/06/2011) Vídeo: Troyano secuestra el ordenador en nombre de la policía nacional acusando al usuario de terrorista zoofílico

una-al-dia (28/02/2012) Vuelve el troyano que se hace pasar por la policía: Cómo protegerse (de verdad)

una-al-dia (02/03/2012) El virus de la policía "evoluciona" e impide el acceso en modo seguro

una-al-dia (06/03/2012) Más información sobre el virus de la policía

una-al-dia (09/03/2012) El malware de la policía aprovecha un exploit de Java "in-the-wild" y el secreto su "éxito"

una-al-dia (18/03/2012) WhitePaper: Estudio técnico del troyano de la policía

una-al-dia (24/05/2012) Nuevas versiones del malware de la policía y cómo eludirlas


Sergio de los Santos
Twitter: @ssantosv