sábado, 30 de junio de 2012

Elevación de privilegios a través de la configuración de Sendmail en IBM AIX

Se ha publicado una vulnerabilidad en la configuración por defecto de Sendmail para IBM AIX que podría permitir a un atacante local escalar privilegios.

Sendmail es un agente de transporte de correo electrónico o MTA. Su propósito es transferir y encaminar los correos desde los agentes de correo de usuario (MUA) hasta otros MTA para que lleguen a su destino.

Sendmail es muy popular y configurable. Permite a los usuarios especificar alias de correo electrónico mediante el archivo .forward, ubicado en su directorio /home. En este archivo también se pueden especificar otros usuarios, así como ficheros, o programas donde se enviará el correo.

Existe un error de falta de comprobación al procesar el contenido del fichero .forward en la configuración por defecto de Sendmail en IBM AIX. Podría producirse la ejecución de comandos arbitrarios contenidos en este fichero con los privilegios de root. Así, un atacante local podría aprovechar esta vulnerabilidad para elevar sus privilegios y ejecutar código arbitrario a través de un fichero .forward especialmente manipulado.

Esta vulnerabilidad, a la que se ha asignado el identificador CVE-2012-2200, afecta a IBM AIX en sus versiones 6.1 y 7.1.

IBM ha publicado un parche para resolver los errores que la producen, pudiéndose descargar desde la página web o el FTP oficial.

Más información:

IBM SECURITY ADVISORY: Vulnerability in AIX sendmail




Juan José Ruiz


viernes, 29 de junio de 2012

Ejecución de código remoto en SAP NetWeaver


Se han publicado tres vulnerabilidades que afectan a SAP NetWeaver 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.

En Zero Day Initiative (ZDI) han anunciado tres vulnerabilidades en "msg_server.exe" en SAP NetWeaver que podrían ser utilizadas por un atacante remoto sin autenticar para ejecutar código arbitrario. Son debidas a faltas de comprobación del tamaño de determinados parámetros y cadenas antes de utilizarlos.

Cuando se procesar paquetes con "opcode 0x43" y "sub-opcode 0x04", se utiliza un campo en el que el usuario indica el tamaño de la cadena "Parameter Name" y otros parámetros. De esta forma, un paquete especialmente manipulado podría provocar una corrupción de memoria y ser aprovechado para ejecutar código remoto en el contexto del proceso en ejecución.

SAP ha publicado una actualización para corregir estas vulnerabilidades.

Más información:

SAP Netweaver ABAP msg_server.exe Parameter Value Remote Code Execution
Vulnerability

SAP Netweaver ABAP msg_server.exe Opcode 0x43 Remote Code Execution
Vulnerability

SAP Netweaver ABAP msg_server.exe Parameter Name Remote Code Execution
Vulnerability


Juan José Ruiz


jueves, 28 de junio de 2012

Múltiples vulnerabilidades en Cisco WebEx Player

Cisco ha publicado un boletín con múltiples vulnerabilidades en WebEx Player que podrían permitir a un atacante remoto realizar una denegación de servicio y, potencialmente, ejecutar código arbitrario.
   
WebEx proporciona herramientas para realizar reuniones online, conferencias web y videoconferencias, y compartir archivos. Pero su uso no se limita al sector empresarial sino que también es muy utilizado para tareas educativas mediante seminarios web sobre diversos temas tanto en tiempo real como a través de grabaciones de los eventos en formato WRF o ARF.

Existen cuatro vulnerabilidades en el reproductor WebEx para archivos .WRF (Recording Format) y una para archivos .ARF (Advanced Recording Format). Todas las vulnerabilidades podrían causar un desbordamiento de memoria intermedia y ser aprovechadas por un atacante remoto para llevar a cabo una denegación de servicio y, potencialmente, ejecutar código arbitrario con los permisos del usuario que ejecuta WebEx. Para aprovechar estas vulnerabilidades únicamente se necesita convencer a un usuario para que reproduzca una grabación en formato WRF o ARF especialmente manipulada.

Dichas vulnerabilidades son debidas a los siguientes errores:


Cisco ha liberado nuevas versiones de WebEx Player para plataformas Microsoft Windows, Apple Mac, y Linux, que corrigen las vulnerabilidades anteriores. Están disponibles para su descarga desde la página oficial.

Más información:

Buffer Overflow Vulnerabilities in the Cisco WebEx Player

CVE-2012-3053: Cisco WebEx Advanced Recording Format Player Arbitrary Code Execution Vulnerability

CVE-2012-3054: Cisco WebEx Recording Format Player WRF File Heap Overflow Vulnerability

CVE-2012-3055: Cisco WebEx Recording Format Player JPEG DHT Chunk Stack Buffer Overflow Vulnerability

CVE-2012-3056: Cisco WebEx Recording Format Player Memory Corruption Arbitrary Code Execution Vulnerability

CVE-2012-3056: Cisco WebEx Player Audio File Processing Arbitrary Code Execution Vulnerability


Juan José Ruiz


miércoles, 27 de junio de 2012

Corregida una vulnerabilidad de ejecución de código arbitrario en QuickTime Player


Se ha publicado una vulnerabilidad en el reproductor QuickTime de Apple, descubierta por Luigi Auriemma que podría permitir la ejecución de código arbitrario a través un archivo de medios especialmente manipulado.

QuickTime Player es un popular reproductor multimedia extensible presente en los equipos Mac OS X y disponible para sistemas Windows.

La vulnerabilidad, a la que se le ha asignado el CVE-2011-3459, se produce al procesar un fichero de vídeo en los cuáles los 'atoms' tienen distinta longitud de cadena. Estos 'atoms' son bloques de información contenidos dentro de un fichero de vídeo.

Cuando la aplicación efectúa una redimensión de memoria reservada para dichos 'atoms' olvida el espacio correspondiente al carácter de terminación de línea, produciéndose un error de 'off-by-one'. Si un atacante consigue emplazar código malicioso en el segmento del heap, próximo a la cadena vulnerable, este podría ejecutarse al producirse la lectura de dicha cadena.

Un atacante podría causar una denegación de servicio en la aplicación y potencialmente ejecutar código arbitrario a través de un archivo de medios especialmente manipulado. Dichos archivos podrían alojarse en la web y ser invocados a través del navegador via la extensión de QuickTime.

La vulnerabilidad se reportó a Apple el día 21 de Octubre de 2011 y se ha hecho pública 8 meses después (el 27 de junio de 2012).

La última versión de QuickTime Player 7.7.2 corrige esta vulnerabilidad.

Más información:

Descarga de QuickTime Player:

Apple QuickTime Dataref URI Buffer Remote Code Execution Vulnerability

OS X Lion v10.7.3 and Security Update 2012-001:


Antonio Sánchez

martes, 26 de junio de 2012

Actualización de seguridad de java-1.7.0-openjdk para Red Hat Enterprise Linux 6


Red Hat ha publicado el boletín de seguridad RHSA-2012-1009 que afecta al paquete java-1.7.0-openjdk de la versión 6 de Red Hat Enterprise Linux en sus ediciones Desktop, Server, Workstation y HPC Node. Esta actualización es consecuencia de las múltiples actualizaciones que Oracle hizo públicas para Java el pasado 12 de Junio.

En total, se corrigen 10 vulnerabilidades: Una de importancia baja, tres de gravedad moderada, una importante y cinco críticas. Las vulnerabilidades tratadas en el boletín por la actualización son las siguientes:

  • Dos vulnerabilidades localizadas en CORBA (Common Object Request Broker Architecture), con identificadores CVE-2012-1719 y CVE-2012-1711, calificadas como moderada y crítica respectivamente y explotables de forma remota la primera y local la segunda. Podrían permitir el salto de las restricciones de seguridad impuestas por el sandbox de Java para acceder a datos del sistema, modificarlos, y en el caso de CVE-2012-1711 causar además una denegación parcial del servicio, a través de una aplicación Java maliciosa.
       
  • La vulnerabilidad CVE-2012-1713 reside en el administrador de fuentes, calificada como crítica y explotable remotamente. Este error podría permitir a un atacante remoto provocar una denegación de servicio parcial en la máquina virtual de Java o potencialmente ejecutar código remoto con los privilegios del usuario a través de un fichero especialmente manipulado.
       
  • Otra vulnerabilidad con CVE-2012-1716 en el componente Swing y de importancia crítica. Un atacante remoto, a través de una aplicación Java maliciosa, podría acceder a elementos de la interfaz de usuario para provocar una denegación parcial del servicio o saltar las restricciones de la sandbox de Java.
       
  • La vulnerabilidad con CVE-2012-1717 (de gravedad baja) afecta a varias clases de la librería estándar de Java Runtime, al provocar que estas creen ficheros temporales con permisos incorrectos. Esto podría permitir a un atacante local acceder a información sensible.
       
  • El identificador CVE-2012-1718, corresponde a un fallo al manejar la Lista de Certificados Revocados (CRL, Certificate Revocation Lists). Una lista con números de serie de certificados duplicados podrá ser ignorada, lo que podría permitir una denegación de servicio parcial. Se le asigna una importancia moderada.
       
  • Dos vulnerabilidades críticas en Java HotSpot Virtual Machine (CVE-2012-1723 y CVE-2012-1725). Estos fallos podrían permitir a un atacante remoto realizar una denegación de servicio en la máquina virtual de Java, saltar las restricciones de su sandbox o potencialmente ejecutar código arbitrario a través de una aplicación Java especialmente manipulada.
      
  • El parseador XML de Java del componente JAXP contiene un error al tratar determinados archivos XML. Un atacante remoto podría aprovechar este problema para para hacer que entre en un bucle infinito a través de un fichero XML manipulado para tal efecto. Esta vulnerabilidad ha sido calificada como moderada, y se le ha asignado el identificador CVE-2012-1724.
      
  • Por último y calificada como importante, la vulnerabilidad CVE-2012-1726, alojada en la función java.lang.invoke.MethodHandles.Lookup, que no concede correctamente los modos de acceso. Lo que podría permitir a una aplicación Java no verificada saltar las restricciones de seguridad impuestas por la sandbox.

Adicionalmente, se corrige un bug a la hora de compilar scripts SystemTap.

Más información:

Important: java-1.7.0-openjdk security and bug fix update

Oracle Java SE Critical Patch Update Advisory - June 2012


Francisco López

lunes, 25 de junio de 2012

Actualización automática ¿Bendición o condena?


El caso TheFlame ha promovido muchas reacciones: los articulistas rellenan páginas con prefijos "ciber" y la palabra "guerra". Las casas antivirus lo usan como arma de venta  (aun sin haberlo detectado en cinco años) y Microsoft queda en evidencia con su PKI y la refuerza. TheFlame ha minado también la confianza: en los gobiernos, en los antivirus... pero sobre todo, en la criptografía y en la actualización automática.

Criptografía


El caso de los certificados falsos de Microsoft usados en TheFlame debería lanzar una nueva advertencia sobre la gestión de la criptografía. Si el SSL está "roto socialmente" porque no se entiende, porque se usa mal (todavía con hashes MD5, por ejemplo), porque las autoridades certificadoras sufren intrusiones, o porque se abusa del negocio alrededor de los certificados..., la mala gestión de una PKI como la de Microsoft vuelve a hacerle un flaco favor a la seguridad que proporciona la criptografía en general.

Y hay que cuidarla. Porque la criptografía actual es lo mejor que tenemos, y es en lo único que podemos basar nuestra confianza en estos momentos. Sin criptografía no hay Internet. La criptografía permite, por ejemplo, que se dé vía libre a la ejecución automática de código en el sistema con ciertas garantías (hasta ahora), de forma que se pueda parchear antes  y se reduzca el riesgo. Es esencial.

Automatización

Y es que el software ha migrado hacia la "autoactualización": la automatización total de las actualizaciones. Desde que el año 2000 Microsoft debutara con "Windows Update", y estableciera más tarde por defecto la actualización automática, las aplicaciones se han apuntado al carro. Chrome fue de los primeros programas  populares que no tuvo miedo a dejar de contar totalmente con el usuario para actualizarse. Y le ha ido bastante bien. Sus usuarios no solo parchean en tiempo récord, sino que tienen la sensación de que nunca tienen que hacerlo... lo que vende muy bien estos días.

Luego Mozilla, Acrobat, Flash no hace mucho... Incluso Chrome fue más allá y comenzó a actualizar sus propios plugins... Todos, ante graves problemas de seguridad, han optado finalmente por actualizarse sí o sí, por defecto. Actualizar es la absoluta prioridad en el mundo de la seguridad. Sin embargo no todos los sistemas de actualización están totalmente automatizados (muchos programas todavía confían en que el usuario acepte antes de aplicar el parche) ni todos lo hacen correctamente. Ciertos programas han realizado una mala implementación de sus sistemas de actualización y de eso se aprovecha la herramienta EvilGrade, todo un framework para explorar esas rendijas que proporcionan las actualizaciones de más de 60 programas. Para algo tan delicado como la automatización, los programadores deberían tomar muchas más precauciones.

Y es que fríamente y por definición, la automatización, es una mala idea. Trasladar ciegamente el poder a las máquinas siempre debería ser menos confiable que llevarlo al lado "razonable" del usuario. No podemos dejar total control en las máquinas porque, una vez encontrada la rendija adecuada, puede llevar a unas desastrosas consecuencias. Pero como la criptografía, es lo mejor que tenemos en estos momentos para obligar a actualizar. Incluso así, parece aún peor dejar que el usuario decida:

  • En entornos caseros, suele resultar una molestia y aplicarse tarde. Está demostrado que los niveles de parcheo total son muy pobres. El software pirata en este caso, también hace mucho daño en este entorno.
      
  • Y en redes corporativas, las actualizaciones automáticas serían muy útiles pero resultan muy "poco populares" entre los administradores. El pánico a interrumpir la producción ante el más mínimo inconveniente les lleva a enterrar la seguridad como prioridad en el trabajo. Esto les resta mucha agilidad a la hora de actualizar y se vuelven muy vulnerables. Las facilidades para automatizar que proporciona Chrome, por ejemplo, es inútil en estos entornos.

Así que no hay respuesta para la pregunta que encabeza este artículo. ¿Centrarse en una automatización más controlada, quizás? ¿Educar al usuario? Al final, se llega al callejón sin salida del tópico: "la comodidad está reñida con la seguridad"... Pero hoy en día, parece que quien se acomode, pierde.

Más información:

flame's impact on trust

1.91% of all PCs are fully patched!


Sergio de los Santos
Twitter: @ssantosv


domingo, 24 de junio de 2012

Debian publica cuatro avisos de seguridad


Debian ha publicado cuatro avisos de seguridad (del DSA-2499 hasta el DSA-2502) que corrigen otros tantos paquetes. Tres de los avisos solucionan varios fallos de seguridad y otro un error de programación. En total se han corregido 13 vulnerabilidades.

DSA-2499: Corrige tres vulnerabilidades en el cliente de correo electrónico "Icedove". Los CVEs asignados son: CVE-2012-1937, CVE-2012-1939, CVE-2012-1940, que solucionan distintos problemas relacionados con la memoria que podrían permitir la ejecución de código arbitrario.

DSA-2500: Con este aviso se han corregido seis fallos de seguridad que afectan al sistema de tracking de errores "Mantis Bug Tracker". Los CVEs de las vulnerabilidades corregidas son: CVE-2012-1118, CVE-2012-1119, CVE-2012-1120, CVE-2012-1122, CVE-2012-1123, CVE-2012-2692. Los errores solucionados están relacionados con la gestión de bugs y con la API SOAP que proporciona este sistema.

DSA-2501: Soluciona tres vulnerabilidades (con CVEs: CVE-2012-0217, CVE-2012-0218 y CVE-2012-2934) del gestor de entornos de virtualización "Xen". Se solucionan distintos fallos en el hypervisor relacionados con la gestión de direcciones en CPUs de 64 bits, con las instrucciones SYSCALL y SYSENTER, y con la detección de CPUs antiguas de AMD.

DSA-2502: Este último boletín soluciona una vulnerabilidad en la biblioteca crypto de Python, cuyo CVE es CVE-2012-2417. El fallo reside en la producción de números primos utilizados por el algoritmo ElGamal para generar una clave. Esto podría facilitar a un atacante obtener la clave privada mediante un ataque de fuerza bruta.

Se recomienda actualizar estos paquetes a través de la herramienta apt-get.

Más información:

DSA-2499-1 icedove:

DSA-2500-1 mantis:

DSA-2501-1 xen:

DSA-2502-1 python-crypto:


Antonio Sánchez


sábado, 23 de junio de 2012

Sexta lección del algoritmo RSA en el MOOC Crypt4you de Criptored

Se encuentra disponible en el Massive Open Online Course MOOC de Crypt4you la sexta lección del curso El Algoritmo RSA, dedicada al uso del teorema chino de los restos en las operaciones de cifra.

Podrás encontrarla desde el acceso directo de la lección en el curso:

O bien como lección destacada en la sección En portada en la págin a principal de este proyecto:

La sexta lección del curso tiene como objetivo la presentación, estudio, análisis y aplicación del teorema chino del resto TRC en las operaciones de cifra con RSA. Un teorema de las matemáticas discretas con diversas aplicaciones en la vida real y que cumple un interesante papel en RSA, especialmente en las operaciones de descifrado en un intercambio de clave donde todos los números son muy grandes, aumentando en unas cuatro veces la velocidad de cómputo.

De hecho, los parámetros que se presentan en esta lección para el uso del TRC son los que entrega OpenSSL cuando se genera una clave RSA con dicho software y que veremos en la séptima lección del curso.

Lección 6: RSA y el teorema chino del resto

Apartado 6.1. ¿Por qué se recomienda usar este teorema?
Apartado 6.2. Definición del teorema chino del resto y su uso en RSA
Apartado 6.3. Aplicación del TRC en el descifrado RSA
Apartado 6.4. Enlaces, documentos y otros ejemplos del TRC
Apartado 6.5. Test de evaluación de la Lección 6

La próxima entrega de este curso, Lección 7 de título Generación de claves con OpenSSL, se publicará a mediados del mes de julio de 2012, dejando la publicación de las tres últimas lecciones sobre ataques al algoritmo RSA para septiembre y octubre de este año. Esto debido a que, aunque se ha hecho una amplia difusión del curso en Internet a través de diversos colaboradores, se observa que sigue siendo aún mayoritario el número de internautas que acceden a las lecciones de presentación y primera, como se observa en este enlace http://www.criptored.upm.es/paginas/crypt4youmensual.htm y cuyo comportamiento se sigue observando en este mes de junio.

Con ello, queremos dar tiempo suficiente para que el mayor número de alumnos accedan a las tres últimas lecciones del curso habiendo ya estudiado las anteriores, puesto que aquellas son básicas para el buen seguimiento de estas últimas.

Además, se recuerda que existe esta encuesta online http://www.criptored.upm.es/crypt4you/encuesta/index.php agradeciendo se cumplimente y envíe.


Jorge Ramió, Alfonso Muñoz
Equipo Crypt4you

viernes, 22 de junio de 2012

iTunes soluciona, sin mencionarlo, un problema de ejecución de código


En su última versión 10.6.3.25, iTunes ha corregido un grave problema de seguridad que permite ejecutar código arbitrario a través de una lista de reproducción (.m3u) especialmente manipulada.

iTunes es un software de gestión de contenido multimedia que permite realizar compras de audio y vídeo, gestión de dispositivos Apple, etc.

Los archivos .m3u son usados para definir una lista de reproducción y utilizan, para cada una de las canciones contenidas en ella, dos líneas. En la primera se indica, precedido de la etiqueta #EXTINF, el número de segundos que dura la pista y su título. En la segunda, la ruta de la canción o vídeo.

iTunes carga en memoria el contenido que se sitúa detrás de la etiqueta #EXTINF sin validarlo, lo que produce el error y lleva a la vulnerabilidad. Para aprovecharla sólo es necesario cargar desde iTunes un archivo .m3u especialmente modificado. Puede ser explotado tanto de manera local (importando el archivo desde el propio equipo) o de manera remota, cargando un archivo m3u desde el navegador web usando el protocolo 'itms'. Este protocolo es utilizado para que el navegador reconozca automáticamente que debe mandar ese archivo a iTunes para su reproducción. Safari no avisa al usuario cuando se usa este protocolo para lanzar iTunes, lo que agrava la situación. El resto de navegadores piden permiso al usuario cuando se encuentran con esta situación.

Las versiones afectadas según el exploit publicados son las 10.4.0.80 a la 10.6.1.7. El exploit también permite eludir DEP. Apple ha publicado la versión 10.6.3.25 donde, sin hacer mención explícita a este fallo, lo corrigen.

Más información:

Descarga última versión iTunes:

Extended m3u Stack Buffer Overflow Remote Code Execution:

M3U


Antonio Sánchez

jueves, 21 de junio de 2012

Dos vulnerabilidades en Internet Explorer están siendo explotadas activamente


En estos momentos dos fallos de seguridad en Internet Explorer son públicos y están siendo aprovechados por atacantes. Para uno existe solución y para otro, un remedio temporal. Además de disponer de todos los detalles técnicos, se sabe que las dos vulnerabilidades han sido utilizadas con fines muy concretos contra ciertas organizaciones.

La primera vulnerabilidad, CVE-2012-1875, fue tratada y corregida (junto con otras 13) en el boletín MS12-037 del día 12 de junio. Se trata de un error al intentar acceder a objetos ya borrados en Internet Explorer (relacionados con la misma ID) que podría causar un acceso inválido a memoria y permitiría la ejecución de código con solo visitar una web.

Cuando se publicó este parche, Microsoft sabía que el fallo estaba siendo usado (al menos desde el 1 de junio), pero en "ataques limitados". En realidad siempre suelen decir lo mismo, aunque el ataque se produzca a gran escala. De hecho, poco después se comprobó que la página de AmnistíaInternacional de Hong Kong había sido comprometida, e infectaba con malware a quien la visitara, aprovechando este mismo fallo. Apenas unos días más tarde, se hicieron públicos los detalles técnicos y por tanto, cualquiera puede aprovechar ya el fallo.

El mismo día que liberaron los parches, hicieron pública una alerta sobre una vulnerabilidad en el intérprete XML no resuelta. CVE-2012-1889, de la que decía que se habían detectado ataques (esta vez, omitían la palabra "limitados"). Afecta a de Internet Explorer y Office. En vez de un parche, Microsoft publica un "FixIt", que soluciona temporalmenteel problema. Como curiosidad, los FixIt suelen "deshabilitar" el componente afectado, pero en este caso no. Deshabilitar el XML Core Services entorpecería demasiado la navegación, por lo que en el FixIt lo que se hace es prácticamente arreglar el problema, inicializando el objeto que causa la vulnerabilidad siempre que Internet Explorer se lanza (puesto que el fallo se da cuando se accede y aún no ha sido inicializado ese objeto). Lo que no aclaran es si este FixIt soluciona también el problema en Office.

Se sabe que esta vulnerabilidadparece haber sido utilizada de manera sofisticada contra usuarios muy concretos de Gmail.

En esta alerta recomiendan por primera vez EMET como contramedida eficaz para detener las técnicas más avanzadas de los exploits. En estemos momentos con su versión 3 recién publicada, Microsoft la integra y reconoce aún más como una herramienta indispensable para detener los exploits.

Más información:

Una vulnerabilidad en Microsoft XML Core Services podría permitir la ejecución remota de código

MSXML: Fix it before fixing it

Google warns Gmail users of 'state-sponsored' hacks

CVE-2012-1875 Exploited in the Wild - Part 1 (Trojan.Naid)



Sergio de los Santos
Twitter: @ssantosv



miércoles, 20 de junio de 2012

Corregidas dos vulnerabilidades en Joomla!


Joomla se ha actualizado a la versión 2.5.5 para corregir dos vulnerabilidades que podrían permitir a un atacante remoto revelar información sensible y escalar privilegios.

Joomla! es un sistema de gestión de contenidos o CMS, de código abierto y programado en su mayor parte en PHP. Es muy utilizado para la creación de portales y sitios web. La gran cantidad de extensiones existentes y su fácil integración con el sistema proporcionan un gran potencial a este CMS.

La primera de las vulnerabilidades, descubierta por Nils Rückmann, es causada por un error al realizar determinadas comprobaciones de forma incorrecta y podría permitir a un atacante elevar sus privilegios. A esta vulnerabilidad se ha asignado una severidad media-alta por parte del Joomla! Security Center.

La segunda es debida a una falta de filtrado en los errores de SQL cuando la opción 'display_errors' se encuentra activada. Aprovechando este fallo un atacante remoto podría conseguir revelar información sensible (dónde está instalado el programa) provocando un error SQL y mirando el código fuente de la página resultante. Esta vulnerabilidad fue descubierta por Jakub Galczyk en abril y publicó una prueba de concepto.

Estas vulnerabilidades afectan a las versiones de Joomla! anteriores a la 2.5.5.

Más información:

[20120602] - Core - Information Disclosure

[20120601] - Core - Privilege Escalation



Juan José Ruiz

martes, 19 de junio de 2012

Elevación de privilegios a través de Symantec LiveUpdate Administrator


Se ha publicado una vulnerabilidad en Symantec LiveUpdate Administrator que podría permitir a un atacante local elevar privilegios.

LiveUpdate Administrator es una utilidad empleada para actualizar los productos de Symantec, descargando las actualizaciones desde los servidores de la compañía, verificando e instalándolas. LiveUpdate se encuentra incluido en muchos productos de Symantec.

La vulnerabilidad está causada por una insegura asignación de permisos a determinados archivos durante la instalación por defecto de LiveUpdate Administrator. Estos archivos disponen de permisos de "Control total" para "Todos" los usuarios.

Un atacante local sin privilegios podría sustituir estos ficheros y, a la hora de ser lanzados, aprovechar esta vulnerabilidad para elevar privlegios. Esto le permitiría acceder y modificar ficheros arbitrarios del sistema para los que no tiene autorización, y crear scripts y ejecutar comandos arbitrarios con privilegios de SYSTEM.

Se ha asignado el identificador CVE-2012-0304 a esta vulnerabilidad, que afecta a las versiones de LiveUpdate Administrator 2.3 y anteriores.

Symantec ha publicado la versión 2.3.1 que corrige este fallo.

Más información:

Symantec LiveUpdate Administrator 2.3 Insecure File Permissions


Juan José Ruiz

lunes, 18 de junio de 2012

Elevación de privilegios en los procesadores de 64 bits de Intel


Se ha hecho público un problema de elevación de privilegios que afecta a varios sistemas operativos de 64 bits y software de virtualización que corran bajo microprocesadores de Intel.

El problema ha sido descubierto por Rafal Wojtczuk, que hablará de ello en la Black Hat 2012 en julio. La vulnerabilidad está basada a su vez en un fallo similar encontrado en el kernel de Linux en 2006.

Para aprovechar esta vulnerabilidad, un atacante local previamente autenticado, debe ejecutar una aplicación específicamente diseñada para ser ejecutada por el kernel después de una excepción de "protección general" (#GP). El fallo será manejado antes del cambio de pila, por lo que el manejador de la excepción será ejecutado en el kernel en un RSP (registro de puntero de pila) elegido por el atacante.

Si es explotado con éxito, este agujero de seguridad podría aprovecharse para escalar privilegios y pasar del ring3, que supone el espacio de usuario, al ring0, que es el espacio con máximos privilegios donde se mueve el kernel. Es posible también escapar de un sistema de virtualización que esté corriendo en un sistema operativo de 64 bits.

Se encuentran afectados numerosos sistemas operativos. Red Hat, Windows y FreBSD ya han publicado parche oficial. El sistema de virtualización Xen también ha publicado una actualización.

Apple, VMware y en general los procesadores ARM o AMD, no se ven afectados por este problema.

Más información:

SYSRET 64-bit operating system privilege escalation vulnerability on Intel CPU hardware
http://www.kb.cert.org/vuls/id/649219


Daniel Vaca

domingo, 17 de junio de 2012

XII Reunión Española sobre Criptología y Seguridad de la Información (RECSI 2012)


La Reunión Española sobre Criptología y Seguridad de la Información (RECSI) es el congreso científico referente español en el tema de la Seguridad en las Tecnologías de la Información, donde se dan cita de forma bianual los principales investigadores españoles en el tema, así como invitados extranjeros de reconocido prestigio. Se celebrará el 4 al 7 de septiembre en Donostia-San Sebastián.

RECSI acercará los últimos avances científicos en materia de Seguridad a los principales agentes de la Sociedad de la Información, con el objetivo de proveer un foro para el intercambio de ideas, aumentar el conocimiento y compartir experiencias en el ámbito de la Seguridad. Para ello, la RECSI, organizada por Mondragon Unibertsitatea, reunirá a la mayoría de grupos de investigación y a las principales empresas que se dedican a diseñar métodos para la protección de la información (Criptografía), a analizar estos métodos para descubrir vulnerabilidades (Criptoanálisis), al igual que los métodos para la protección de los sistemas informáticos y las redes de comunicación (Seguridad de la Información).

Áreas de interés

Criptología y criptoanálisis, Autenticación y firma digital, Aplicaciones de la criptografía, Privacidad y anonimato, Marcas de agua y esteganografía, Control de accesos, Detección de intrusiones y máquinas trampa, Análisis de malware, Detección de spam, Seguridad en redes sociales, Seguridad en sistemas embebidos, Informática forense,...

Conferenciantes invitados:

  • Matt Bishop (University of California, Davis)
Matt Bishop recibió su doctorado en Informática por la Universidad de Purdue, donde se especializó en seguridad informática, en 1984. Actualmente es catedrático en el Departamento de Ciencias de la Computación en la Universidad de California en Davis. Su principal área de investigación es el análisis de las vulnerabilidades en los sistemas informáticos, incluyendo el modelado, la construcción de herramientas para la detección de vulnerabilidades, y la mejora o la eliminación de las mismas. En la actualidad, tiene proyectos de investigación relacionados con la desinfección de datos, modelado de procesos electorales, y la atribución en los grandes bancos de pruebas, tales como GENI.

Matt hablará sobre el mundo académico y la enseñanza en seguridad informática, y nos mostrará su percepción sobre cómo se está haciendo en España.

  • Fausto Montoya (CSIC)
Fausto Montoya Vitini es doctor ingeniero en Telecomunicación por la Universidad Politécnica de Madrid. Ha sido profesor agregado honorífico del grupo de Cátedra XXII en la ETSI de Telecomunicación de la UPM; director técnico del proyecto de Construcción del Centro Nacional de Ingeniería Genética y Biotecnología del Consejo Superior de Investigaciones Científicas; coordinador del Área de Física y Tecnologías Físicas; director en funciones de la Unidad de I+D TAGS; presidente de la Comisión de Coordinación y Asesoramiento Informático de la Presidencia del CSIC; y miembro del Consejo Científico del Centre de Supercomputació de Catalunya.

Fausto compartirá con los asistentes su testimonio sobre su extensa experiencia en la investigación en criptología y seguridad.


La inscripción temprana debe darse antes del 15 de junio, 2012, la regular antes del 15 de julio, 2012 y se considerará tardía la realizara después del 15 de julio, 2012

Más información y registro:




Urko Zurutuza


sábado, 16 de junio de 2012

Logran eludir el sistema Google Bouncer para Android Market


Google, en un intento de mejorar la calidad y seguridad del Market de Android (ahora denominado Google Play), creó el sistema Google Bouncer para detectar y combatir las posibles aplicaciones maliciosas que se puedan subir al mismo. Ciertos investigadores han conseguido eludir esta medida de seguridad.

Cada aplicación subida al Market pasa por un análisis de seguridad, realizado por el sistema Bouncer. En base a ciertas reglas y análisis ejecuta cada aplicación y determina si es potencialmente peligrosa. En caso negativo, la aplicación es publicada.

Según los investigadores Jon Oberheide (@jonoberheide) de Duo Security y Charlie Mille (@0xcharlie) de Accuvant Labs, existiría la manera de poder detectar la presencia del análisis realizado por Bouncer y salir indemne del proceso, consiguiendo el objetivo de ver publicada la aplicación. La demostración pública fue realizada durante este fin de semana en la SummerCON (New York, USA).

Como no existe información pública alguna sobre los procedimientos seguidos por Bouncer, los investigadores decidieron crear y enviar falsas aplicaciones al Market que se dedicaban a registrar los procesos del sistema y lanzar una conexión reversa a sus propios servidores. Consiguieron así conectarse de manera remota a las instancias de Bouncer en los servidores de Google e investigar así el entorno utilizado por el sistema. Descubrieron la presencia de un sistema virtual de emulación basado en QEMU.

En el siguiente video se puede observar todo el proceso y demás datos que recolectaron de las instancias de Google Bouncer:


Según los investigadores, tendríamos una manera efectiva de realizar un fingerprint del sistema Bouncer y así poder evitar su detección, modificando las aplicaciones APK mandadas al market a tal efecto.

Más información:

Dissecting Android’s Bouncer

SummerCON 2012

Bouncer, la lucha contra el malware en el Market de Android


José Mesa Orihuela




viernes, 15 de junio de 2012

TheFlame, el francotirador


En los últimos días, y a modo de reflexión sobre lo ocurrido con el troyano TheFlame, algunas voces se han sumado a la crítica hacia la industria antivirus, como responsable de que el troyano pasara desapercibido durante años. Pero no lo son (en todo caso, no son los únicos). ¿Qué lecciones se pueden aprender de la detección y análisis de este malware?

"When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010 and 2011 [...] What this means is that all of us had missed detecting this malware for two years, or more. That´s a spectacular failure for our company, and for the antivirus industry in general."

Y es razonable, por la manera en la que trabajan las casas antivirus (que no los antivirus en sí). Reciben alrededor de 100.000 muestras al día. No todas son malware y, lógicamente, no todas son analizadas a mano. Es imposible. Simplificando el proceso, las muestran pasan por sistemas automáticos que intentan clasificarlas. Si alguna resulta claramente malware, pasa sin más a ser detectada por firma (genérica). Si solo resulta sospechosa, quizás llegue a un segundo filtro manual. Si aquí se confirma como malware (un proceso que puede llevarle muchas horas a un analista) se incluye en las firmas, y se repasan de nuevo las muestras que han llegado para analizarlas con esa nueva firma y detectar más. Este un proceso costoso, sin fin, y muy complejo... cuyos volúmenes están incrementando.

Kaspersky hablaba en Twitter de que, en el último año, el número de muestras "detectadas" diariamente había pasado de unas 75.000 a 125.000. No sabemos si ese "detectadas" está bien empleado. De hecho, Jorge Mieres, de la misma compañía, decía un poco más tarde en Twitter "En los últimos meses ha aumentado un 80% el número de muestras únicas procesadas por día. 125.000."

En este proceso de automatización, los antivirus prefieren pecar por defecto y no caer en detección de falsos positivos. Una muestra firmada por Microsoft, como TheFlame, no tenía la más mínima posibilidad de pasar como sospechosa por ningún filtro.

Otra frase de Hypponen llama la atención:

"Yet we failed to do that with Stuxnet and DuQu and Flame. This makes our customers nervous."
                          

Los antivirus están sometidos a un gran peso comercial, de imagen, de ventas y beneficios. Deben contentar a sus clientes. Y la alerta mediática generada les pone nerviosos. Sin embargo, no se debe perder el foco. Aunque se deban invertir recursos en detectar muestras extremadamente sofisticadas, es mucho más importante controlar de forma eficaz la inmensa oleada de malware "común" como las nuevas versiones de Zeus o SpyEye. Quizás no usen certificados de Microsoft para ocultarse, pero podemos asegurar que sus índices de infección (y robo real de cuentas bancarias) son infinitamente más altos. ¿Cómo repartes tus recursos entonces? ¿Es mejor invertir en medicinas para curarte de una enfermedad mortal detectada en algunos puntos de Irán que afecta principalmente a una raza característica? ¿O dedicarlos a la lucha contra las enfermedades comunes? Los clientes de antivirus lo querrán todo... pero eso sería una evaluación de riesgos muy pobre. Por otro lado, culpar únicamente a las casas antivirus sería injusto.

Un antivirus no está diseñado para detectar malware de este calibre, simple y llanamente. Si hacemos una analogía de guerra, un antivirus sería como un chaleco antibalas. Puede llegar a proteger del fuego cruzado, de las balas perdidas... Es posible que no se muestre eficaz con cierto tipo de munición destinada específicamente a traspasarlo, pero puedes reforzarlo periódicamente y proteger tu cuerpo. Por supuesto, esto no exime al que lo acarrea de ocultarse en lo posible de la primera línea de fuego y otros métodos para salvarse. Pero ¿quién te protege de un francotirador que, apostado estratégicamente en un edificio, apunta a tu cabeza desde hace días? TheFlame es un francotirador, con mucha puntería y la mejor arma. Un chaleco antibalas no protege contra francotiradores.

¿Se tambalea entonces la confianza en los antivirus? No. No hay que quitarse el chaleco antibalas. Lo que hay que hacer es mejorarlo y complementarlo. Si se cuestiona algo, que sean los cimientos de los procesos automatizados y de las políticas de seguridad aplicadas. Una bofetada que debería hacernos despertar y replantear incluso aquello que parece que "funciona bien". Porque pueden existir otros métodos.

Más información:

Why Antivirus Companies Like Mine Failed to Catch Flame and Stuxnet

Kaspersky

Jorge Mieres



Sergio de los Santos
Twitter: @ssantosv

jueves, 14 de junio de 2012

Apple "deja de ser mejor" que Microsoft (la próstata de Apple II)

Apple vuelve a dar signos de cambio. Ha eliminado las referencias a Windows y a la "seguridad por comparación" en su página oficial. Casualmente, hace muy pocos días escribíamos aquí sobre lo desacertado de esta política.

Durante años, en la web de Apple se ha podido leer "Razones para adorar el Mac".
"Inmune a los virus del PC. El Mac es invulnerable a los miles de virus que amenazan a los ordenadores con Windows gracias a las defensas integradas de Mac OS X, que lo mantienen a salvo sin ningún esfuerzo por tu parte."






     
No hace mucho, a raíz de la publicación de un documento que explicaba la seguridad del sistema operativo iOS, realizábamos la siguiente reflexión sobre el párrafo anterior:
"Donde se ataca directamente a Windows que, si bien cuenta con las mismas (y más) defensas integradas que Mac OS X, es evidente que es más atacado por malware, circunstancia que aprovecha comercialmente Apple. Aunque se trate de una estrategia de marketing totalmente legítima, el problema es la forma en la que se plantea. Afirmar que el hecho de que a Mac no le afecten "los virus de PC" es una ventaja, es como decir que las mujeres son más sanas que los hombres porque no les afectan los problemas de próstata. Además, no se debería alabar la seguridad de un sistema por comparación. Tendría que ser una cualidad intrínseca."

Casualmente, desde hace unos días, han desaparecido las referencias a Windows en la página de Apple. En estos momentos, en todos los idiomas, se puede leer:
"Las defensas integradas en OS X evitan que descargues software dañino en el Mac sin darte cuenta. Seguro. En sí mismo. OS X ha sido diseñado con tecnologías avanzadas que velan por la seguridad de tu Mac. Por ejemplo, la técnica de aplicaciones enjauladas (sandboxing) evita los ataques de hackers a tus aplicaciones, ya que restringe las acciones que pueden realizar en el Mac, los archivos a los que pueden acceder y los programas que pueden abrir."

   
Sin embargo, y a modo de anécdota, parece que no han modificado por completo su página. Desde este enlace, http://www.apple.com/es/why-mac/, todavía se puede leer el texto original:

 
    
Por tanto, Apple deja de compararse explícitamente con Windows, y potencia una imagen de seguridad inherente, "en sí mismo". Un buen paso que esperemos no se quede solo en una estrategia de marketing y realmente se lleve a la práctica.

Más información:

Apple explica la seguridad de iOS


Sergio de los Santos